4 ms·

I don't agree with your point. Leaving in debug code, especially for an entire part of the launch that doesn't exist anymore by bringing in reused and untested

I don't agree with your point. Leaving in debug code, especially for an entire part of the launch that doesn't exist anymore by bringing in reused and untested code, seems like the real problem. I'm pretty sure integer overflow in this case would be undefined behavior, so you don't know what the compiler would do, especially since things were a lot more wild on the hardware side in 1996. Your point sounds like arguing that preferring Objective-C would prevent all those pesky `NullPointerException`s in Java since it allows sending messages to nil (null), but that's success by coincidence. If you read the ESA's report [1], there were a lot of things which failed before you even get to the language. This software failure is the only one in the entire Ariane series of rockets. Considering that this is 1996, the list of languages to pick from was pretty slim, e.g. this predates C++ initial standardization (1998), `enum class` and other modern C++ features. Even using just Ada 83 (of which 95, 2005, 2012, and 2022 succeeded and improved), I would argue that its forward looking features of preventing mixed mode arithmetic having properly typed checked enums and other features (like being strong typed) probably prevented a significant number of failures should other available languages at the time been used. [1]: http://sunnyday.mit.edu/nasa-class/Ariane5-report.html http://sunnyday.mit.edu/nasa-class/Ariane5-report.html

ncmncm 5y ago
You miss that all the Ariane 4s were launched with the same flaw: any of them would have blown up for the same reason, if their vibration had peaked a bit beyond expected amplitude.
- pyjarrett 5y ago
  It wasn't a flaw in Ariane 4 because it used a very different rocket flight path. This means the BH value which caused the error was physically impossible. > The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values. > o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.
  - ncmncm 5y ago
    It is a flaw exactly because, while Ariane 4 should not produce such an acceleration, if it ever did, momentarily and otherwise non-destructively, the spurious trap code would have automatically destroyed the vehicle by dumping garbage to the gimbal. The Ariane 5 disaster was implicit in the design. Without that built-in flaw, the Ariane 4 inertial platform would have worked correctly as-was, and the first Ariane 5 would have delivered its $half-billion payload successfully, instead of obliterating it. There is no circumstance where dumping debug tracebacks down a control channel not prepared for that is ever correct. Period. Anyone suggesting otherwise is displaying their blinders.
    - pyjarrett 5y ago
      > There is no circumstance where dumping debug tracebacks down a control channel not prepared for that is ever correct. Period. Anyone suggesting otherwise is displaying their blinders. We agree here. Did you read the report? > The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose. > The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5. > m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off. > The reason for the three remaining variables, including the one denoting horizontal bias, being unprotected was that further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty. > Ariane 4 should not produce such an acceleration My point is that it's a velocity, not an acceleration and hence is physically impossible by the design and flight parameters on the Ariane 4. It's like saying an unsigned byte (8 bits) is okay for a speedometer for a minivan because >255 mph is outside the physical capabilities of the vehicle, but reusing that speedometer code for a fighter jet is not appropriate. All code is written with these assumptions of value ranges, it's just a manner of how the language handles them, and whether that behavior is predictable (UB or not) or crashes when outside those bounds. A lot of C and C++ code is written with short/int/long without realizing that those are fuzzy boundaries (short <= int <= long) and without going to ensure sufficient sizes (e.g. uint32_t). Math code which doesn't account for this can produce wild and usually incorrect behavior. When enabled, any value in Ada can throw a constraint check if violated, and it just makes it explicit. You're assuming that "Don't crash on overflow" is always a good thing based on a single case, there's a lot of systems, particularly mechanical ones, in which a broken sensor reporting a pegged sensor value would want an immediately halt to operation. Also in space applications, out of bounds values can arise from other conditions as well, such as cosmic rays flipping bits, in which a computer restart (relying on the redundant system) is the correct and expected behavior.

ncmncm 5y ago

You miss that all the Ariane 4s were launched with the same flaw: any of them would have blown up for the same reason, if their vibration had peaked a bit beyond expected amplitude.

pyjarrett 5y ago
It wasn't a flaw in Ariane 4 because it used a very different rocket flight path. This means the BH value which caused the error was physically impossible. > The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values. > o) In Ariane 4 flights using the same type of inertial reference system there has been no such failure because the trajectory during the first 40 seconds of flight is such that the particular variable related to horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present in the software.
- ncmncm 5y ago
  It is a flaw exactly because, while Ariane 4 should not produce such an acceleration, if it ever did, momentarily and otherwise non-destructively, the spurious trap code would have automatically destroyed the vehicle by dumping garbage to the gimbal. The Ariane 5 disaster was implicit in the design. Without that built-in flaw, the Ariane 4 inertial platform would have worked correctly as-was, and the first Ariane 5 would have delivered its $half-billion payload successfully, instead of obliterating it. There is no circumstance where dumping debug tracebacks down a control channel not prepared for that is ever correct. Period. Anyone suggesting otherwise is displaying their blinders.
  - pyjarrett 5y ago
    > There is no circumstance where dumping debug tracebacks down a control channel not prepared for that is ever correct. Period. Anyone suggesting otherwise is displaying their blinders. We agree here. Did you read the report? > The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose. > The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5. > m) The inertial reference system of Ariane 5 is essentially common to a system which is presently flying on Ariane 4. The part of the software which caused the interruption in the inertial system computers is used before launch to align the inertial reference system and, in Ariane 4, also to enable a rapid realignment of the system in case of a late hold in the countdown. This realignment function, which does not serve any purpose on Ariane 5, was nevertheless retained for commonality reasons and allowed, as in Ariane 4, to operate for approx. 40 seconds after lift-off. > The reason for the three remaining variables, including the one denoting horizontal bias, being unprotected was that further reasoning indicated that they were either physically limited or that there was a large margin of safety, a reasoning which in the case of the variable BH turned out to be faulty. > Ariane 4 should not produce such an acceleration My point is that it's a velocity, not an acceleration and hence is physically impossible by the design and flight parameters on the Ariane 4. It's like saying an unsigned byte (8 bits) is okay for a speedometer for a minivan because >255 mph is outside the physical capabilities of the vehicle, but reusing that speedometer code for a fighter jet is not appropriate. All code is written with these assumptions of value ranges, it's just a manner of how the language handles them, and whether that behavior is predictable (UB or not) or crashes when outside those bounds. A lot of C and C++ code is written with short/int/long without realizing that those are fuzzy boundaries (short <= int <= long) and without going to ensure sufficient sizes (e.g. uint32_t). Math code which doesn't account for this can produce wild and usually incorrect behavior. When enabled, any value in Ada can throw a constraint check if violated, and it just makes it explicit. You're assuming that "Don't crash on overflow" is always a good thing based on a single case, there's a lot of systems, particularly mechanical ones, in which a broken sensor reporting a pegged sensor value would want an immediately halt to operation. Also in space applications, out of bounds values can arise from other conditions as well, such as cosmic rays flipping bits, in which a computer restart (relying on the redundant system) is the correct and expected behavior.