7 ms·

Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-p

by zlsa 3y ago

Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-performance Ariane 5. https://en.wikipedia.org/wiki/Ariane_flight_V88 https://en.wikipedia.org/wiki/Ariane_flight_V88

h0l0cube 3y ago
Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.
- kitd 3y ago
  IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.
  - h0l0cube 3y ago
    I would imagine a simulation would factor in the higher acceleration
  - mpweiher 3y ago
    Except it was worse: 1. The module that failed actually was no longer in use for that part of the flight. 2. The acceleration for the part of the flight where it was in use was within the parameters. 3. Instead of just ignoring / clamping the out-of-bounds values, the no-longer-needed module sent a big error dump. 4. That error dump was sent to the next module in-line, which was expecting...I think numbers, but certainly not big textual error dumps. And so that failed as well. 5. I don't know if that second module was needed. So had the module just (a) processed the incoming data normally or (b) clamped the values silently or (c) dropped the out-of-bounds values silently, the Ariane 5 would not have exploded. Instead it did the "make it impossible to represent invalid states"-thing and exploded. While I understand the appeal of that idea, I think it is overrated with any software that has to interact in some way shape or form with the real world, however indirectly. Because programmers tend to have a pretty limited understanding of what states are valid or invalid in the real world. (See also: the "falsehoods programmers believe about XXX" series)

by zlsa 3y ago

h0l0cube 3y ago

Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.

kitd 3y ago
IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.
- h0l0cube 3y ago
  I would imagine a simulation would factor in the higher acceleration
- mpweiher 3y ago
  Except it was worse: 1. The module that failed actually was no longer in use for that part of the flight. 2. The acceleration for the part of the flight where it was in use was within the parameters. 3. Instead of just ignoring / clamping the out-of-bounds values, the no-longer-needed module sent a big error dump. 4. That error dump was sent to the next module in-line, which was expecting...I think numbers, but certainly not big textual error dumps. And so that failed as well. 5. I don't know if that second module was needed. So had the module just (a) processed the incoming data normally or (b) clamped the values silently or (c) dropped the out-of-bounds values silently, the Ariane 5 would not have exploded. Instead it did the "make it impossible to represent invalid states"-thing and exploded. While I understand the appeal of that idea, I think it is overrated with any software that has to interact in some way shape or form with the real world, however indirectly. Because programmers tend to have a pretty limited understanding of what states are valid or invalid in the real world. (See also: the "falsehoods programmers believe about XXX" series)