Crashing an In-Flight Entertainment System
rabblerouzer writes "Hugh Thompson, who was interviewed by Slashdot on the dangers of e-voting, now has a cool blog entry on how he was able to bring down the gaming/movie console on an airplane. He calls it one of the most interesting examples of a software 'abuse case' he has ever seen." Fortunately the IFE system is totally disjoint from the avionics.
SwissAir 111 went down because the in-flight entertainment & gambling system had been rushed into service, and due to its design overheated and burned down the plane in-flight. This was its design: a separate computer for each seat. The computers (presumably single cards) were located in the ceiling near the front of the passenger compartment. So were the avionics wires. The entertainment/gambling devices overheated, caught fire and the plane crashed near Nova Scotia. Greed. SwissAir is no more.
Okay, I *am* an avionics programmer. Here's some background.
FAA regulations categorize software in 5 different levels of criticality, depending on how a failure of the software would affect the safety of the plane. Level "A" software is reserved for things like the "low fuel" alarm, which could potentially knock the plane out of the air on failure, to level "C" for things like the cabin pressurization system where the pilots can take emergency actions to compensate, to level "E" for things like the microwave in the kitchen.
(Beware: I gloss over a few details for clarity.)
The higher levels of software criticality have progressively higher levels of standards for testing. In the case of level-A software, each individual line of code must be examined for correctness in the context of the rest of the code. Each line of code must be executed as part of testing and actively shown to be correct, and each line of code must be individually code reviewed by another engineer.
At the higher levels of software, limit testing is required for all function arguments and if-statements. Multiple-clause if statements such as "if A and B but not C" must be tested for all combinations of the subject clauses, and so on.
In addition to this, all avionics software I've worked on makes a distinction between showing erroneous information and showing *no* information (or, working incorrectly versus not working at all). If the digital altimeter goes blank, the pilots will notice and can take corrective action. If the altimeter is reading the wrong information, then that's a critical failure which could cause an accident.
Thus, avionics software innards are heavily checked throughout execution to ensure proper operation, and any failure causes the system to immediately go offline. All function arguments are ASSERT'ed for correct range, all calculations are checked for range and accuracy, &c.
The entertainment system, and in particular a game within the entertainment system, is almost certainly a level-E software component, and so is not required to go through such rigorous testing. The hardware has to be shown to not interfere with the avionics and that's about it.
Actually, no, it takes more inside information than that. My dad worked for Swissair for 30 years and its downfall was actually the acquisition of Sabena and the contractual agreement created in the acquisition. At the time, it was a solid investment, but as the overall financial state of Sabena fell apart, Swissair was legally obligated to have to try and save them, draining their resources. The in-flight entertainment was simply a last can of gasoline tossed on an intensely burning flame.