3 ms·

"suggested it may be down to a high-energy atmospheric particle striking one of the integrated circuits within the unit." Radiation shielding aside, how in God

"suggested it may be down to a high-energy atmospheric particle striking one of the integrated circuits within the unit." Radiation shielding aside, how in God's name would you design a system to survive those kinds of errors? If some circuit deep down in the core logic of the black box just suddenly spiked a random voltage, it would be really hard to predict (and correct) the damage. Hell, that voltage spike might even kill the actual error-handling code! Redundancy seems to be the best way to go (with three being the optimal number), but I guess there's still always a chance of things going wrong. I'm glad everyone survived

virtuabhi 15y ago
Instead of plain redundancy, error correcting codes (e.g. Hamming code) should be able to control errors http://en.wikipedia.org/wiki/Error-correcting_code#List_of_error-correcting_codes http://en.wikipedia.org/wiki/Error-correcting_code#List_of_e...
- ars 15y ago
  What happens when your error correcting circuit gets hit with such a particle? Or worse - the CRC generating circuit does, generating a value which causes you to "correct" things to an incorrect value.
  - bdonlan 15y ago
    If your CRC generator gets damaged, then it will produce values that are inconsistent with the CRC checker, which is in another piece of equipment. At which point your component gets kicked out of the system entirely, and all is well. Note also that CRC is an error detection code, and cannot correct detected errors.
- anacrolix 15y ago
  Won't that just decrease the possibility orders and orders of magnitude, but it will still exist?
darklajid 15y ago
Well, but what about this part: "When the data from the first two ADIRUs is inconsistent then the flight computer uses the data it received 1.2 seconds previously. However, the software couldn’t handle the two ADIRUs putting out data spikes that were more than 1.2 seconds apart and this caused the plane to behave erratically." I assume _this_ is the error referenced in the title. Whatever caused the black box to fail, the result was that the code afterwards failed in software, as far as I read the text.
- deleted 15y ago
  [deleted]
ramchip 15y ago
It's called radiation hardening, there's many methods. Here's a pretty thorough paper about those used for the LHC detector: http://www-physics.lbl.gov/~spieler/radiation_effects/rad_tutor.pdf http://www-physics.lbl.gov/~spieler/radiation_effects/rad_tu... [PDF] Wiki link: http://en.wikipedia.org/wiki/Radiation_hardening http://en.wikipedia.org/wiki/Radiation_hardening One way is simply to use larger transistor, so that errors are more difficult to create in the first place.
bdonlan 15y ago
First, the black box doesn't actually do anything safety-critical. It's a pure data recorder, and only comes into play _after_ an accident. You're thinking more of the flight control computers, as well as the air data inertial reference units (ADIRUs). These components are indeed redundant; from the sounds of the report, one of the ADIRUs malfunctioned (there are three), sending incorrect angle-of-attack data (as well as a lot of other incorrect data). Although the flight computers have monitoring routines for identifying and disregarding erroneous inputs, there was an unforeseen scenario in which a very specific pattern of erroneous AOA data could avoid detection - and this happened here. It's important to note that the plane was not in autopilot at the time - the autopilot disengaged itself immediately upon detecting an input discrepancy (several seconds prior to the actual pitch down event that caused the injuries) and the captain took manual control. However, due to the fly-by-wire system, the flight controls are normally processed through a rather complex system that (under normal circumstances) helps prevent accidents due to human error (eg, it's impossible to stall an Airbus A330 under normal conditions; the plane will respond to your commands until just before it stalls, at which point it'll force a pitch down or thrust increase to maintain lift). This invalid AOA data made the flight computers believe the plane was indeed in a dangerously steep climb, in danger of a stall (the stall warnings even sounded multiple times during the flight), and automatic protections called for a pitch down movement (ie, a descent). Due to the precise timing needed for the AOA fault to go unnoticed, some of the flight computers were unaffected - as such, shortly after each of the two pitch down events, flight computer error detection systems triggered failovers - but not until the flight computer currently in charge triggered a descent. The second time this happened, none of the primary computers were eligible for controlling pitch angle (due to each having a pitch-angle-related failure already) and so control passed to a more primitive backup system - incidentally disabling the pitch angle protections that had caused the problems, and allowing the crew to regain control.
trurl 15y ago
See www.cs.princeton.edu/~dpw/papers/lambdazap-icfp06.pdf

virtuabhi 15y ago

Instead of plain redundancy, error correcting codes (e.g. Hamming code) should be able to control errors http://en.wikipedia.org/wiki/Error-correcting_code#List_of_error-correcting_codes http://en.wikipedia.org/wiki/Error-correcting_code#List_of_e...

ars 15y ago
What happens when your error correcting circuit gets hit with such a particle? Or worse - the CRC generating circuit does, generating a value which causes you to "correct" things to an incorrect value.
- bdonlan 15y ago
  If your CRC generator gets damaged, then it will produce values that are inconsistent with the CRC checker, which is in another piece of equipment. At which point your component gets kicked out of the system entirely, and all is well. Note also that CRC is an error detection code, and cannot correct detected errors.
anacrolix 15y ago
Won't that just decrease the possibility orders and orders of magnitude, but it will still exist?

darklajid 15y ago

Well, but what about this part: "When the data from the first two ADIRUs is inconsistent then the flight computer uses the data it received 1.2 seconds previously. However, the software couldn’t handle the two ADIRUs putting out data spikes that were more than 1.2 seconds apart and this caused the plane to behave erratically." I assume _this_ is the error referenced in the title. Whatever caused the black box to fail, the result was that the code afterwards failed in software, as far as I read the text.

deleted 15y ago
[deleted]

ramchip 15y ago

It's called radiation hardening, there's many methods. Here's a pretty thorough paper about those used for the LHC detector: http://www-physics.lbl.gov/~spieler/radiation_effects/rad_tutor.pdf http://www-physics.lbl.gov/~spieler/radiation_effects/rad_tu... [PDF] Wiki link: http://en.wikipedia.org/wiki/Radiation_hardening http://en.wikipedia.org/wiki/Radiation_hardening One way is simply to use larger transistor, so that errors are more difficult to create in the first place.

bdonlan 15y ago

First, the black box doesn't actually do anything safety-critical. It's a pure data recorder, and only comes into play _after_ an accident. You're thinking more of the flight control computers, as well as the air data inertial reference units (ADIRUs). These components are indeed redundant; from the sounds of the report, one of the ADIRUs malfunctioned (there are three), sending incorrect angle-of-attack data (as well as a lot of other incorrect data). Although the flight computers have monitoring routines for identifying and disregarding erroneous inputs, there was an unforeseen scenario in which a very specific pattern of erroneous AOA data could avoid detection - and this happened here. It's important to note that the plane was not in autopilot at the time - the autopilot disengaged itself immediately upon detecting an input discrepancy (several seconds prior to the actual pitch down event that caused the injuries) and the captain took manual control. However, due to the fly-by-wire system, the flight controls are normally processed through a rather complex system that (under normal circumstances) helps prevent accidents due to human error (eg, it's impossible to stall an Airbus A330 under normal conditions; the plane will respond to your commands until just before it stalls, at which point it'll force a pitch down or thrust increase to maintain lift). This invalid AOA data made the flight computers believe the plane was indeed in a dangerously steep climb, in danger of a stall (the stall warnings even sounded multiple times during the flight), and automatic protections called for a pitch down movement (ie, a descent). Due to the precise timing needed for the AOA fault to go unnoticed, some of the flight computers were unaffected - as such, shortly after each of the two pitch down events, flight computer error detection systems triggered failovers - but not until the flight computer currently in charge triggered a descent. The second time this happened, none of the primary computers were eligible for controlling pitch angle (due to each having a pitch-angle-related failure already) and so control passed to a more primitive backup system - incidentally disabling the pitch angle protections that had caused the problems, and allowing the crew to regain control.

trurl 15y ago

See www.cs.princeton.edu/~dpw/papers/lambdazap-icfp06.pdf