3 ms·
This is on the event of the last Ariane 5 launch, but the first Ariane 5 launch failed due to software. The inertial reference system (SRI) was derived from Ar
by kps 3y ago
This is on the event of the last Ariane 5 launch, but the first Ariane 5 launch failed due to software.
The inertial reference system (SRI) was derived from Ariane 4. Since 5 was faster, a numeric conversion overflowed, which was not physically possible on 4. Since overflow was ‘impossible’, there was no explicit handling. Since the code was written in a ‘safe’ language (Ada), an ‘unsafe’ undefined result was impossible, so the module panicked. The SRI operation at that point was not actually required on the 5, but they had not wanted to make ‘unnecessary’ changes to disable it. Finally, the flight computer interpreted the SRI crash diagnostic data as flight data, and sent the rocket wildly off course.
https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf
- fermigier 3y agohttps://www.irisa.fr/pampa/EPEE/Ariane5.html https://www.irisa.fr/pampa/EPEE/Ariane5.html "The truly unacceptable part is the absence of any kind of precise specification associated with a reusable module."
- danvk 3y agoThis is fascinating. It reminds me of the infamous MCAS on the Boeing 737 MAX. A system was designed, implemented and rigorously tested to be used in a specific scenario. A decision was then made much later to use it in a very different scenario without any understanding of the consequences.
- TMWNN 3y agoAnother such case is Atari BASIC. Revision A has a bug that causes a crash. Revision B fixed the bug, but the fix was then erroneously applied to similar code elsewhere, causing the same crash much more often than in Revision A!
- orbital-decay 3y agoAlso notable as one of the few actual software-related failures in spaceflight. It's usually some other design flaw at fault, as software has relatively small complexity footprint.
- rsynnott 3y agoDepends exactly how you define software, but most of the N1 failures were caused or exacerbated by bad behaviour by the control system. A few early Proton failures were also caused by control system failure, and then of course there was the Mars Climate Orbiter...
- orbital-decay 3y agoThese issues didn't have the software as some kind of cause - MCO failed due to the spec mismatch. Another example of this is Cassini failing to initialize Huygens fully before separation, and many others - these were not software issues as software was compliant with the spec. AFAIR early Proton-Ks failed due to the process issues - impossibly high cadence (typical at the time) and the lack of integration testing with Block D, and N1 3L's issue with KORD was external interference caused by fire. Edit: I stand corrected - the MCO failure report [1] says that the software behavior was against the spec. So yeah, it's a software failure indeed. [1] http://sunnyday.mit.edu/accidents/MCO_report.pdf http://sunnyday.mit.edu/accidents/MCO_report.pdf
- sidewndr46 3y agoThere was a Russian sigint satellite that somehow got programmed to roll 360 degrees and execute its initial burn to reach the desired orbit. Satellites are generally launched upside down. So it basically rolled over and de-orbited itself, fast. Would you consider that a software failure or not?
- okl 3y agoIt didn't fail "due to software", it failed because the analysis wasn't redone, that came to the conclusion that range checks, as specified by the Ada programming language, can be disabled to increase performance.
- barelyauser 3y agoPedantic and pointless.
- aftoprokrustes 3y agoWhat I really "like" about the footage of the launch is how the commentator says "every parameter nominal" literally as the thing is blowing up. This is a great illustration of how fast the system failed.
- jldugger 3y agoCommentator's curse in action!