The Explosion of the Ariane 5
ima.umn.edu
ima.umn.edu
https://en.wikipedia.org/wiki/Cluster_%28spacecraft%29
Edit: The above Wikipedia article has the Ada source code that caused the problem.
These systems have become so big and expensive. This was the case since ICBM:s and it got only worse with Apollo.
Yet they are so vulnerable since there is no way to abort intactly once you have flown something like 0.1 seconds. (At least Saturn V had some redundancy.) You do not get a second try.
Both issues create a perfect recipe for stagnation - everything has to be checked and rechecked for years before and after a software or hardware change. If someone tries something new, and there is a launch or spacecraft failure, it is a political issue and heads will roll. People's technical and political careers are destroyed.
In short, this way is not likely to reach real spacefaring.
A more organic approach with lots of smaller actors working in parallel and trying and failing a lot more - but with better processes built in to handle said failures (technical, political and cultural) could be much more conducive to real progress like increase in operational flexibility, shortened schedules, better reliability and lowered price.
Reasonable sized reusable rockets with good intact abort capability in a testing and development program could up the launch rate hugely, and all kinds of different solutions could be quickly tested. I find it likely that this will eventually happen, but it is frustrating how long it is taking.
In this "horizontal velocity overflow" case, you could do an intact abort if you had a fallback to some alternate control law or even manual control. Those are not incorporated to current expendable space launchers but they exist in aircraft. (Saturn V and also the Lunar Module did have manual backup. You could fly the Saturn to orbit. The LM was hard got get to the right orbit where the CM was waiting...)
There's certainly a much larger - and probably quite informative - story here.
When stored in miles, the value would never got outside the range of a 16 bit unsigned int, but the actual value used was in kilometers, and when converted to kilometers, the value would overflow.
More details about the Ariane 5 failure here: http://people.cs.clemson.edu/~steve/Spiro/arianesiam.htm
The value was horizontal velocity. I imagine in metric it would be expressed in m/s while in imperial it's going to be feet per second (mph seems highly improbable).
AFAIK (correct me if wrong)...
- The code was re-used from the Ariane 4, which was designed for launch only in the northern hemisphere. The Ariane 5 was launched from south of the equator, hence the importance of unsigned vs signed.
- A run-time warning was generated. Problem was where to put the warning, which wasn't specified, and which thru dangling pointer overwrote current position/velocity data. Watchdog code noticed the now-impossible trajectory, decided the system was very very confused, and initiated self-destruct for (relative) safety.
Kourou is in French Guiana (Cayenne), not Guyana. They are different countries. Similarity in name is due because three neighboring colonies used to be called "the Guianas." French, British and Dutch. British Guiana became independent in 1966 and changed its name to Guyana.
Minor, and rather pedantic, detail, but seeing the place you were born being constantly mischaracterized is a bit irritating after a while :-)
Anyway, as always wikipedia has an interesting list of software bugs : http://en.wikipedia.org/wiki/List_of_software_bugs
I found interesting the computer crash of F22-Raptors after crossing the International Date Line.
(edit) ... and I'm downvoted. Lovely. Totally makes sense.
I have never heard that was software related, but it also is a decent bet software was involved, e.g. for stiffening the suspension. What top of the line car did not have software, in 1997?
Here is one of the "b" instead of "m" stories published on the day of the crash:
http://www.cnbc.com/id/36998463
Here is the Wikipedia summary of the event which lists "fat finger trade" as one of the discredited theories:
http://en.wikipedia.org/wiki/2010_Flash_Crash#Early_theories
According to Expert C Programming : Deep C Secrets by Peter Van Der Linden page 61:
'Table 2-2 The Truth About Two Famous Space Software Failures
WHEN MISSION ERROR RESULT CAUSE
Summer 1961 Mercury . used instead of , nothing; error found before flight Flaw in Fortran language
July 22, 1962 Mariner 1 "R" instead of "R̅" $12M rocket and probe destroyed programmer followed error
(to Venus) written in specification in specification'
http://www.e-reading-lib.org/bookreader.php/138815/Linden_-_...
or just use what little Google Books provides
http://books.google.co.uk/books?id=4vm2xK3yn34C&q=fortra...
As you can see neither mission involved Mars and the faulty . being used instead of a , was found before it caused any harm.
More information follows on the failed Ariane 5 launch - which Bertrand Meyer attributes to "insufficient specification":
http://se.inf.ethz.ch/~meyer/publications/computer/ariane.pd...
The failure review concluded that the probable cause of loss was that the landing system software apparently interpreted the deployment of lander's legs as touchdown and shut down the descent engines. The vibrations caused by the deployment of the legs was not taken into account when designing the software.
The point is that SpaceX procedures seem to be able to prevent similar software bugs in the Ariane 5 from causing a catastrophic abort or failure.
This means, that even using the most reliable language and trying to test as much as possible, there is always a risk of an overseen bug.
"the programmers had decided that this particular velocity figure would never be large enough to cause trouble. After all, it never had been before. Unluckily, Ariane 5 was a faster rocket than Ariane 4. One extra absurdity: the calculation containing the bug, which shut down the guidance system, which confused the on-board computer, which forced the rocket off course, actually served no purpose once the rocket was in the air. Its only function was to align the system before launch. So it should have been turned off. But engineers chose long ago, in an earlier version of the Ariane, to leave this function running for the first 40 seconds of flight -- a "special feature" meant to make it easy to restart the system in the event of a brief hold in the countdown."
Based on the quote I* have to agree with the developer then: this particular 'horizontal velocity' figure would never be large enough to cause overflow, it would always be zero since the rocket should still be on the platform.
So maybe the existence of the routine was the root cause, and not so much the potential for overflow inside the routine?
* I am not a rocket scientist
Perhaps it had something to do with calibration prior to launch. The report states: "The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time."
Except the Earth is not stationary, nor is the surface of the Earth moving at a constant velocity.
The problem was that nobody had formally detailed all of the assumptions and risks for every part of the code, so when the conditions changed and those assumptions became faulty nobody was the wiser because nobody was aware they were actually making such an assumption about the speed of the rocket.