EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 186 of 189

e BREAK POINTS leaving the spacecraft spinning and unable to complete its mission. A sequencing etTor triggered an opening of valves for four of the vehi- cle's 12 attitude control thmsters, using up all of the propellant. o fuel , no go. Unfornmately, I've been unable to obtain more detailed information about the nature of the software error. However, tJ1ere's an enticing-and as yet unavailable-reference in the appendix of the NEAR report to a memo called "How Clementine Really Failed and What NEAR Can Learn." Is it possible that NEAR's software failure had been anticipated four years earlier? NASA published a report on tJ1e mis- sion tJ1at mentions tJ1e failure but does not delve into root causes.2 Clementine was a technology demonstrator operat- ed by the Ballistic Mi sile Defense Organization; NASA was a partner, not the main force behind the mission. The Clementine report, though short on firmware details, does delve into the htunan pt-ice of a schedule tJ1at's too tight. A few quotes follow; there' ยท not much one can add! "The tight time schedule forced swift decisions and lowered costs, but also took a human toll. The stringent budget and the firm limitations on reserves guaranteed that the mission would be relatively inexpensive, but surely reduced the mission 's capabili- ty, may have made it less cost-effective, and perhaps ultimately led to the loss of tJ1e spacecraft before the comple- tion of the asteroid flyby component of the mission." "The mission opet-ations phase of the Clementine project appears to have been as much a triumph of human ded- ication and motivation as tJ1at of deliber- ate organization. The inadequate sched- ule ... ensured tJ1at tJ1e spaceo-aft was launched witJ1out all of tlle software hav- ing been written and tested." "Further, the spacecraft perfor- mance was marred by numerous com- puter crashes. It is no surpt-ise that the team was exhausted by the end of the lunar mapping phase." Embedded Systems Programming NOVEMBER 2000 183 There's an enticing-and as yet unavailable-reference in the appendix of the NEAR report to a memo called "How Clementine Really Failed and What NEAR Can Learn." Is it possible that NEAR's software failure had been anticipated four years earlier? Ariane 5 In May 1998 I described tJ1e 1996 fai l- ure of Ariane 5 ("Disaster," p. 113), tlle large launch vehicle that tumbled and destroyed itself 40 seconds after blast-off. Since then more information has come to my attention. Shot-tJy after launch, the Inertial Reference System (SRI, the apparently scrambled acronym a result of transla- tion from French to English) detected an overflow when converting a 64-bit floating-point number to 16-bit signed integer. An exception handler noted tJ1e problem and shut the SRI down. Due to tJ1e incredible expense of these missions (this maiden flight itself had two commercial spacecraft aboard, each valued at about $100 million) a back-up SRI stood ready to take over in case of tJ1e primary's failure. SRI number two did indeed assume navi- gation responsibility, but it ran identi- cal code, encountered the same error, and shut down as well. Why did the overflow occur? This code had been ported from the much smaller Ariane 4. According to the report " ... it is important to note that it was jointly agreed [between project partners at several contractual levels] not to include the A.riane 5 trajectory data in the SRI requirements and

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12