Re: Ariane 5 failure

[rav@goanna.cs.rmit.edu.au (@@ robin)]

Steve Bell <sb635@delphi.com> writes:

	>Michael Dworetsky wrote:
	>> 
	>> >Just a point for your information. From clari.tw.space:
	>> >
	>> >        "An inquiry board investigating the explosion concluded in
	>> >July that the failure was caused by software design errors in a
	>> >guidance system."
	>> >
	>> >Note software DESIGN errors - not programming errors.
	>> >
	>> 
	>> Indeed, the problems were in the specifications given to the programmers,
	>> not in the coding activity itself.  They wrote exactly what they were
	>> asked to write, as far as I could see from reading the report summary.
	>> 
	>> The problem was caused by using software developed for Ariane 4's flight
	>> characteristics, which were different from those of Ariane 5.  When the
	>> launch vehicle exceeded the boundary parameters of the Ariane-4 software,
	>> it send an error message and, as specified by the remit given to
	>> programmers, a critical guidance system shut down in mid-flight. Ka-boom.
	>> 

	>I work for an aerospace company, and we recieved a fairly detailed accounting of what 
	>went wrong with the Ariane 5. Launch vehicles, while they are sitting on the launch 
	>pad, run a guidance program that updates their position and velocity in reference to 
	>an coordinate frame whose origin is at the center of the earth (usually called an 
	>Earth-Centered-Inertial (ECI) frame). This program is usually started up from 1 to 3-4 
	>hours before launch and is allowed to run all the way until liftoff, so that the 
	>rocket will know where it's at and how fast it's going at liftoff. Although called 
	>"ground software," (because it runs while the rocket is on the ground), it resides 
	>inside the rocket's guidance computer(s), and for the Titan family of launch vehicles, 
	>the code is exited at t=0 (liftoff). This code is designed with knowing that the 
	>rocket is rotating on the surface of the earth, and the algorithms expect only very 
	>mild accelerations (as compared to when the rocket hauls ass off the pad at liftoff). 
	>Well, the French do things a little differently (but probably now they don't). The 
	>Ariane 4 and the first Ariane 5 allow(ed) this program to keep running for 40 secs 
	>past liftoff. They do (did) this in case there are any unanticipated holds in the 
	>countdown right close to liftoff. In this way, this position and velocity updating 
	>code would *not* have to be reset if they could get off the ground within just a few 
	>seconds of nominal. Well, it appears that the Ariane 5 really hauls ass off the pad, 
	>because at about 30 secs, it was pulling some accelerations that caused floating pount 
	>overflows

---Definitely not.  No floating-point overflow occurred.  In
Ariane 5, the overflow occurred on converting a double-precision
(some 56 bits?) floating-point to a 16-bit integer (15
significant bits).

   That's why it was so important to have a check that the
conversion couldn't overflow!


	in the still functioning ground software. The actual flight software (which 
	>was also running, naturally) was computing the positions and velocities that were 
	>being used to actually fly the rocket, and it was doing just fine - no overflow errors 
	>there because it was designed to expect high accelerations. There are two flight 
	>computers on the Ariane 5 - a primary and a backup - and each was designed to shut 
	>down if an error such as a floating point overflow occurred,

---Again, not at all.  It was designed to shut down if any interrupt
occurred.  It wasn't intended to be shut down for a routine thing as
a conversion of floating-point to integer.

	 thinking that the other 
	>one would take over. Both computers were running the ground software, and both 
	>experienced the floating point errors.


---No, the backup SRI experienced the programming error (UNCHECKED
CONVERSION from floating-point to integer) first, and shut itself
down, then the active SRI computer experienced the same programming
error, then it shut itself down.

	Actually, the primary went belly-up first, and 
	>then the backup within a fraction of a second later. With no functioning guidance 
	>computer on board, well, ka-boom as you say.