Disastrous debut

In June 1995, after faulty software delayed the final static test firings of the Vulcain engine, the first Ariane V was postponed from November 1995 to January 1996, and in September it was slipped to late April 1996.13,H The second one was to launch in September with Intelsat 709 as a demonstration funded by Arianespace, as a precursor to the first commercial mission with PanAmSat 6 in early 1997. The mounting delay was due to oil and propellant leaks suffered in testing the first stage, some of which necessitated significant modifications. The payload for the first vehicle was a stack of four Cluster A comparison of the configurations satellites, each weighing 1.2 tonnes, which of the Ariane 4 and Ariane V. had been developed by the European Space

Agency to monitor the Earth's magneto-sphere.15 Fortunately, they did not need to be launched on a specific date.16 After the loss of Intelsat 708 on a Long March 3B on 14 February 1996, Intelsat 709 was withdrawn and dispatched on an Ariane 44P on 15 June to plug the gap, and the European Space Agency's Atmospheric Re-entry Demonstrator assigned in its place.17

The debut mission on 4 June 1996 appeared to have an excellent start, with the vehicle lifting off when the solids lit some 6 seconds after the main engine had ignited, but 30 seconds later it suddenly toppled over, and the auto-destruction system destroyed it at a height of 12,000 feet. In fact, the vehicle had already started to disintegrate as a result of the aerodynamic stress imposed by the increasing angle of attack, which was in response to the three engine nozzles being commanded to slew 'hard over' as a result of the failure of the inertial reference system. As the European Space Agency's press release wryly observed, the flight ''did not result in validation of Europe's new launcher''.18 This is an interesting study in software engineering, due in part to an unwarranted reliance on heritage from its exceptionally reliable predecessor. Early in the development of the Ariane V, it was decided to reuse as many components of the Ariane 4 as possible in order to cut costs. In particular, the inertial reference system that had proved itself was carried over. The part of the software at issue was used prior to launch to initialise the inertial reference system and also, on the Ariane 4, to facilitate a rapid realignment of that system in the event of a last-minute hold in the countdown. While this realignment function served no role on the Ariane V, it was retained for commonality reasons, and allowed (as on the Ariane 4) to operate for approximately

40 seconds after lift-off.19 Simulations had indicated that the software would function properly in the new vehicle, but no tests were made using real hardware to confirm this. It was discovered that flaws in the specification and design of the software had resulted in the total loss of guidance and attitude data.20,21,22>23 In particularly, no thought had been given to the values that certain variables might take. Also, as the Ariane V rose more rapidly than its predecessor, its horizontal acceleration was five times faster, and a variable conversion between a 64-bit floating point value and a 16-bit signed integer resulted in an overflow condition as a result of producing a number higher than could be represented this way, and the software crashed. The software was written in Ada, and only some of the software variables were protected against overflow - a decision that had been agreed to by all the project partners. The others were expected to be either physically constrained, or small enough with a large margin of safety. This logic proved to be faulty for the Horizonal Bias, the variable that caused the exception in the inertial reference units. As guidance system flaws are difficult to identify (because hardware cannot be accelerated to high speed in a laboratory!) this represented another classic mistake. The investigation noted that the 'culture' was based on protecting against random hardware failures, and both of the inertial reference units had the same flawed software. Consequently, in the space of 20 milliseconds at T+30 seconds, the backup and then the primary unit both raised an overflow exception and the guidance system, which was left to 'fly blind', ordered the Vulcain engine of the core and the nozzles of the strap-ons to gimbal over to their limit.24,2S The investigation issued 40 recommendations, including revising the management to assign Arianespace overall responsibility for the embedded software.26 The modifications included redesigning the shroud for smoother aerodynamics, structural reinforcement to eliminate the buffeting that had been observed near the base of the vehicle, and more effective thermal protection for the solid strap-on separation points.

Was this article helpful?

0 0

Post a comment