Re:How Is Critical Life or Death Software Tested?
by infinotize on Monday June 01, 2015 @08:57PM
(#9643202)
To be fair this seems to be more of a classic example of a documentation or training problem. Right from your link:
> During the mishap sequence, the MP started engines, perfomled an IBIT, and had a fully functioning Flight Control System. Subsequently, the MP shut down engines to allow maintenance personnel to service the Stored Energy System. During engine shut down, the MA's Auxiliary Power System (APU) was running. The MP believed the APU provided continuous power to the Flight Control System, and therefore another IBIT after engine restart was unnecessary. This belief was based on academic training, technical data system description, and was shared by most F/A-22 personnel interviewed during the investigation.
Re:How Is Critical Life or Death Software Tested?
by michaelt on Tuesday June 02, 2015 @05:26AM
(#9644741)
To be fair this seems to be more of a classic
example of a documentation or training problem.
Maybe - but if you were designing a consumer product, you wouldn't rely on the user following a checklist; the IBIT would run automatically when they turned on the ignition and sound an alarm (or even prevent takeoff) if the vehicle would be uncontrollable.So you could also classify this as a user interface / design problem.
Re:How Is Critical Life or Death Software Tested?
by dugmartin on Tuesday June 02, 2015 @01:08PM
(#9647268)
SBIT & PBITs are the ones that run automatically, with SBIT running automatically at startup and PBIT running on a watchdog. The SBIT time budget and scope is usually much smaller than IBIT so time intensive tests like ones that talk to sensors on the bus aren't present in SBIT. You can think of the stages as SBIT: can I run? IBIT: should I run? PBIT: am I running right?
Re:How Is Critical Life or Death Software Tested?
by neurotech1 on Tuesday June 02, 2015 @12:41AM
(#9643894)
True. The pilot wasn't the only one who misunderstood the details.
As I recall, they modified the sensors to avoid latch up (extra pullup resister) and updated the FCS software to provide a warning if all 3 sensors return zero output. Even though this wasn't really an error in the FCS software, It could be argued that it failed to detect an erroneous input from 3 redundant sensors that latched up for the same reason.
This is a classic example of a pilot who misunderstood the pre-takeoff checklist procedure and cost the USAF a $325m aircraft.
[0] http://usaf.aib.law.af.mil/ExecSum2005/F-22A_20Dec04.pdf