Micro controller crash, crashes Ariane 5 rocket (1996)

[3v0]

I was watching a TV program that mentioned the AES cluster mission June 4, 1996. They indicated the rocket blew up shortly after launch but provided no other details so I check Wikipedia. What I found is interesting and contains a lesson for anyone who write code, more so for firmware engineers.

The link

Flight 501, which took place on June 4, 1996, was the first, and unsuccessful, test flight of the European Ariane 5 expendable launch system. Due to an error in the software design (inadequate protection from integer overflow), the rocket veered off its flight path 37 seconds after launch and was destroyed by its automated self-destruct system when high aerodynamic forces caused the core of the vehicle to disintegrate. It is one of the most infamous computer bugs in history.
As it was an unmanned flight, there were no victims, but the breakup caused the loss of four Cluster mission spacecraft, resulting in a loss of more than US$370 million. (3v0 TV show said 500 million.)...
The Ariane 5 software reused the specifications from the Ariane 4, but the Ariane 5's flight path was considerably different and beyond the range for which the reused computer program had been designed....

Because of the different flight path, a data conversion from a 64-bit floating point to 16-bit signed integer value caused a hardware exception (more specifically, an arithmetic overflow, as the floating point number had a value too large to be represented by a 16-bit signed integer). Efficiency considerations had led to the disabling of the software handler (in Ada code) for this error trap, although other conversions of comparable variables in the code remained protected. This caused a cascade of problems, culminating in destruction of the entire flight.

I see a few important lessons.

Know you data. Then test not only for expected values, but also unexpected values. Had this been done the problem would have been discovered during software testing, maybe as early as Ariane 4.

There is not such thing as bug free code for any but trivial applications. Using "solid" code in a new environment or application requires additional and substantial testing. Management never wants to here this.

There was no mechanism in place to deal with the exception. In this case it was a hard error and I have no concept of what could have been done to recover from it. But had it been a soft error the system should have had a mechanism in place to recover from the error.

"Efficiency considerations had led to the disabling of the software handler (in Ada code) for this error trap, " Without being there we can not know what screw up pushed the programmers so far into a corner that they turned off error checking.

The lesson we can learn is when choosing a processor it is best to have adequate head room. I like to work with a processor family that will easily allow moving the program between various family members. Do not start with the fastest family member as you will have no where to go if you find you need more speed or memory. If you know you can not switch processor pick one that is faster then you need.

The failure also harmed the excellent success record of the European Space Agency's rocket family, set by the high success rate of the Ariane 4 model. It was not until 2007 that Ariane 5 launches were recognised as reliable as those of the predecessor model.[5]

 

[be80be]

Kind of reminds me of a project I was trying out I used a word to hold value and it would be find for a small range of values
but it needed a integer because the value could go below 0

But me hard headed I didn't think about that and made it work