Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The disintegration of the Ariane 5 rocket 37 seconds after launch on her maiden voyage (Flight 501) is commonly referred to as one of the most expensive software bugs in history1:

It took the European Space Agency 10 years and $7 billion to produce Ariane 5, a giant rocket capable of hurling a pair of three-ton satellites into orbit with each launch and intended to give Europe overwhelming supremacy in the commercial space business.

All it took to explode that rocket less than a minute into its maiden voyage last June, scattering fiery rubble across the mangrove swamps of French Guiana, was a small computer program trying to stuff a 64-bit number into a 16-bit space.

One bug, one crash. Of all the careless lines of code recorded in the annals of computer science, this one may stand as the most devastatingly efficient. From interviews with rocketry experts and an analysis prepared for the space agency, a clear path from an arithmetic error to total destruction emerges.

What major changes did Flight's 501 failure and the subsequent investigations inspire to the research of safety critical systems and software testing?

I'm not looking for an explanation of the bug itself, but for an explanation of the historical impact of the bug, in terms of research that were inspired from or were directly related to the investigation(s) of the failure. For example this paper concludes:

We have used static analysis to:

  • check the initialization of variables,
  • provide the exhaustive list of potential data access conflicts for shared variables,
  • exhaustively list the potential run time errors from the Ada semantics.

To our knowledge this is the first time boolean-based and non boolean-based static analysis techniques are used to validate industrial programs.

Similarly, this paper(pdf) notes:

Abstract interpretation based static program analyses have been used for the static analysis of the embedded ADA software of the Ariane 5 launcher and the ARD. The static program analyser aims at the automatic detection of the definiteness , potentiality, impossibility or inaccessibility of run-time errors such as scalar and floating-point overflows, array index errors, divisions by zero and related arithmetic exceptions, uninitialized variables, data races on shared data structures, etc. The analyzer was able to automatically discover the Ariane 501 flight error. The static analysis of embedded safety critical software (such as avionic software) is very promising.

I would love a thorough explanation of the impact this single event had on software testing approaches and tools.

1 The $7 billion figure possibly refers to the total cost of the Ariane 5 project, Wikipedia reports that the failure resulted in a loss of more than $370 million. Still a quite expensive failure but nowhere near the $7 billion figure.

share|improve this question
5  
Define "worst"... Worst because it was expensive? I don't know... I think the Therac-25 would have be a much worse bug if you were one of the people subjected to massive overdoses of radiation during cancer treatment. users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html ; courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html ; en.wikipedia.org/wiki/Therac-25 –  FrustratedWithFormsDesigner May 23 '12 at 18:17
2  
@FrustratedWithFormsDesigner Answering your own question is perfectly acceptable, we even got a feature recently that encourages self answers. I was going to test drive it for this question, however given that this is a contest question (not that it has a chance) I decided to let someone else answer it. –  Yannis Rizos May 23 '12 at 18:27
3  
Do we really want to establish that didactic questions are in scope? If so, I can see a wave of mildly annoying questions meant to lead us somewhere and teach us something without the OP really needing an answer. Up to you, but it seems risky. –  Corbin March May 23 '12 at 18:30
4  
@gnat Never said it was the only answer, just a hint that the question has an answer to appease the close voters. But here you go: articles.adsabs.harvard.edu//full/1998ESASP.422..201L/… & dl.acm.org/citation.cfm?id=263750 (ACM paywall) –  Yannis Rizos May 23 '12 at 18:55
3  
@FrustratedWithFormsDesigner: Sometimes I have questions for which I think I know the answer, but I am not sure. So I would like to ask them, not to have my thesis confirmed, but rather being open for all kinds of answers I am going to get. So, in general, I think it makes sense to ask a question even if I have already some ideas regarding possible answers. –  Giorgio May 23 '12 at 19:19

3 Answers 3

As others have mentioned, it caused the industry in general to re-examine the concept of re-use, and place it in a larger frame of reference whereby components are not evaluated in isolation but in the context of the whole system. This significantly reduces the attractiveness of re-use, since even if a component can be re-used without changes, it still has to be analyzed with a new set of assumptions. Another corollary is that backup hardware running the same software is not nearly as attractive, since most modern hardware is orders of magnitude more reliable than modern software. I have heard that some defense contracts require two separate software systems developed by different teams using different technologies working from the same specification to verify proper implementation.

share|improve this answer
1  
References please... –  Yannis Rizos May 23 '12 at 19:50
1  
Mostly half-remembered from an old ACM article, but some more information is here. –  TMN May 23 '12 at 19:56
    
The ideas of separate computers , with code developed by different teams was used by the Space shuttle program, and maybe even earlier. –  mhoran_psprep May 23 '12 at 22:31
    
@mhoran_psprep : Read up on the AT&T Exchange failure and it's outcomes. Sorry - no reference, know of it from memory. –  mattnz May 24 '12 at 4:31

Technically speaking, it was more a case of "software rot". The flight control software was recycled from the earlier Ariane 4 rocket, a sensible move given how expensive it is to develop software, especially when it's mission critical software which must be tested and verified to far more rigorous standards than most commercial software needs to be.

Unfortunately, nobody bothered testing what effect the change in operating environment would have, or if they did they didn't do said testing to a sufficiently thorough standard.

The software was built to expect certain parameters to never exceed certain values (thrust, acceleration, fuel consumption rates, vibration levels, etc). In normal flight on an Ariane 4 this wasn't a problem because those parameters would never reach invalid values without something already being spectacularly wrong. The Ariane 5, however, is much more powerful and ranges that would seem to be silly on the 4 could quite easily happen on the 5.

I'm not sure what parameter it was that went out of range (it might have been acceleration, I'll have to check), but when it did, the software was unable to cope and suffered an arithmetic overflow for which there had been insufficient error checking and recovery code implemented. The guidance computer started sending garbage to the engine nozzle gimbals, which in turn started pointing the engine nozzle pretty much randomly. The rocket started to tumble and break up, and the automatic self-destruct system detected the rocket was now in an unsafe irrecoverable attitude and finished the job.

To be honest, this incident probably didn't teach any new lessons, as the kind of problems have been unearthed before in all manner of systems, and there are already strategies in place to deal with finding and fixing errors. What the incident did do was ram home the point that being lax in following those strategies can have enormous consequences, in this case millions of dollars of destroyed hardware, some extremely pissed off customers and an ugly dent in the reputation of Arianespace.

This particular case was especially glaring because a shortcut taken to save money ended up costing a huge amount, both in terms of money and lost reputation. If the software had been tested just as robustly in an Ariane 5 simulated environment as it had been when it was originally developed for Ariane 4, the error surely would have come to light long before the software was installed in launch hardware and put in command of an actual flight. Additionally, if a software developer had deliberately thrown some nonsense input into the software then the error might have even been caught in the Ariane 4 era, as it would have highlighted the fact that the error recovery that was in place was inadequate.

So in short, it didn't really teach new lessons, but it rammed home the dangers of not remembering old ones. It also demonstrated that the environment within which a software system operates is every bit as important as the software itself. Just because the software is verifiably correct for environment X doesn't mean it's fit for purpose in the similar but distinct environment Y. Finally it highlighted how important it is for mission critical software to be robust enough to deal with circumstances that shouldn't have happened.

Contrast flight 501 with Apollo 11 and its computer problems. Whilst the LGC software suffered from a serious glitch during the landing, it was designed to be extremely robust and was able to remain in an operational state in spite of the software alarms that were triggered, without putting any astronauts in danger and still being able to complete its mission.

share|improve this answer
4  
References....? –  FrustratedWithFormsDesigner May 23 '12 at 19:18
1  
My own memories of engineering ethics lectures when studying computer science at university :) –  GordonM May 24 '12 at 5:49

It was mostly a reuse problem and management problem and not a coding one. From my recollections (I'm problably getting some things wrong) of the report.

  • one subsystem had been designed for Ariane IV. Trajectories of Ariane IV could not result in the overflow and it was then purposely decided that if it occured, it was an hardware problem and shutting down the subsystem and going to the spare was the right thing to do.

  • for Ariane V, it was decided to reuse that subsystem and not to review the assumptions and the code but rely on testing.

  • further it was decided to drop full testing.

Different flight parameters of Ariane V made the overflow occurs. Shut down the primary. Shut down the spare. Autodestruction.

Additional things I remember:

  • the subsystem at the time of overflow was no more useful. One could argue that its failure shouldn't have triggered the autodestruction. (On the other hand, the added complexity could itself be a source of problems).

  • there was debug data sent to a bus when it shouldn't. I don't remember the specific.

share|improve this answer
    
Ah, I know what the bug was, that's not really my question. I've oftenly heard that the bug changed our approach to software testing, and that's what I'm asking about. –  Yannis Rizos May 23 '12 at 18:14
    
    
ISTR the mechanism behind the failure was that the code threw an overflow exception, which the caller didn't catch. The exception was propagated up until it was caught by the default exception handler, which aborted the offending module. However, since the exception had percolated up so many levels, the "offending module" at that point was the entire RSI (inertial reference system). –  TMN May 23 '12 at 19:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.