From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 101deb,885dab3998d28a4 X-Google-Attributes: gid101deb,public X-Google-Thread: f74ae,eca28648989efca9 X-Google-Attributes: gidf74ae,public X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public X-Google-Thread: 107079,eca28648989efca9 X-Google-Attributes: gid107079,public From: rav@goanna.cs.rmit.edu.au (@@ robin) Subject: Re: Ariane 5 failure Date: 1996/10/09 Message-ID: <53fhsg$45$1@goanna.cs.rmit.edu.au> X-Deja-AN: 188202402 expires: 1 January 1997 00:00:00 GMT distribution: inet references: <52a572$9kk@goanna.cs.rmit.edu.au> <843845039.4461.0@assen.demon.co.uk> <1996Oct1.093107.47351@ucl.ac.uk> <325572AA.4663@delphi.com> organization: Comp Sci, RMIT, Melbourne, Australia newsgroups: sci.astro,sci.math.num-analysis,comp.lang.pl1,comp.lang.ada nntp-posting-user: rav Date: 1996-10-09T00:00:00+00:00 List-Id: Steve Bell 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.