1/14/12 ARIANE 5 Failure - Full Report

1/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
Paris, 19 July 1996
ARIANE 5
Fligh 501 Failre
Report by the Inquiry Board
The Chairman oI the Board :
ProI. J. L. LIONS
|originally appeared at http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html|
FOREWORD
On 4 June 1996, the maiden Ilight oI the Ariane 5 launcher ended in a Iailure. Only about 40 seconds aIter
initiation oI the Ilight sequence, at an altitude oI about 3700 m, the launcher veered oII its Ilight path, broke up
and exploded. Engineers Irom the Ariane 5 project teams oI CNES and Industry immediately started to
investigate the Iailure. Over the Iollowing days, the Director General oI ESA and the Chairman oI CNES set
up an independent Inquiry Board and nominated the Iollowing members :
- ProI. Jacques-Louis Lions (Chairman) Academie des Sciences (France)
- Dr. Lennart Lbeck (Vice-Chairman) Swedish Space Corporation (Sweden)
- Mr. Jean-Luc Fauquembergue Delegation Generale pour l'Armement (France)
- Mr. Gilles Kahn Institut National de Recherche en InIormatique et en Automatique (INRIA), (France)
- ProI. Dr. Ing. WolIgang Kubbat Technical University oI Darmstadt (Germany)
- Dr. Ing. SteIan Levedag Daimler Benz Aerospace (Germany)
- Dr. Ing. Leonardo Mazzini Alenia Spazio (Italy)
- Mr. Didier Merle Thomson CSF (France)
- Dr. Colin O'Halloran DeIence Evaluation and Research Agency (DERA), (U.K.)
The terms oI reIerence assigned to the Board requested it
- to determine the causes oI the launch Iailure,
- to investigate whether the qualiIication tests and acceptance tests were appropriate in relation to the
problem encountered,
- to recommend corrective action to remove the causes oI the anomaly and other possible weaknesses
oI the systems Iound to be at Iault.
The Board started its work on 13 June 1996. It was assisted by a Technical Advisory Committee composed
oI :
- Dr Mauro Balduccini (BPD)
- Mr Yvan Choquer (Matra Marconi Space)
- Mr Remy Hergott (CNES)
- Mr Bernard Humbert (Aerospatiale)
- Mr Eric LeIort (ESA)
In accordance with its terms oI reIerence, the Board concentrated its investigations on the causes oI the
1/14/12 ARIANE 5 Failure - Full Report
2/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
Iailure, the systems supposed to be responsible, any Iailures oI similar nature in similar systems, and events
that could be linked to the accident. Consequently, the recommendations made by the Board are limited to
the areas examined. The report contains the analysis oI the Iailure, the Board's conclusions and its
recommendations Ior corrective measures, most oI which should be undertaken beIore the next Ilight oI
Ariane 5. There is in addition a report Ior restricted circulation in which the Board's Iindings are documented
in greater technical detail. Although it consulted the telemetry data recorded during the Ilight, the Board has
not undertaken an evaluation oI those data. Nor has it made a complete review oI the whole launcher and all
its systems.
This report is the result oI a collective eIIort by the Commission, assisted by the members oI the Technical
Advisory Committee.
We have all worked hard to present a very precise explanation oI the reasons Ior the Iailure and to make a
contribution towards the improvement oI Ariane 5 soItware. This improvement is necessary to ensure the
success oI the programme.
The Board's Iindings are based on thorough and open presentations Irom the Ariane 5 project teams, and on
documentation which has demonstrated the high quality oI the Ariane 5 programme as regards engineering
work in general and completeness and traceability oI documents.
Chairman oI the Board
1. HE FAILE
1.1 GENEAL DECIPION
On the basis oI the documentation made available and the inIormation presented to the Board, the Iollowing
has been observed:
The weather at the launch site at Kourou on the morning oI 4 June 1996 was acceptable Ior a launch that
day, and presented no obstacle to the transIer oI the launcher to the launch pad. In particular, there was no
risk oI lightning since the strength oI the electric Iield measured at the launch site was negligible. The only
uncertainty concerned IulIilment oI the visibility criteria.
The countdown, which also comprises the Iilling oI the core stage, went smoothly until H0-7 minutes when the
launch was put on hold since the visibility criteria were not met at the opening oI the launch window (08h35
local time). Visibility conditions improved as Iorecast and the launch was initiated at H0 09h 33mn 59s
local time (12h 33mn 59s UT). Ignition oI the Vulcain engine and the two solid boosters was nominal, as
was liIt-oII. The vehicle perIormed a nominal Ilight until approximately H0 37 seconds. Shortly aIter that
time, it suddenly veered oII its Ilight path, broke up, and exploded. A preliminary investigation oI Ilight data
showed:
nominal behaviour oI the launcher up to H0 36 seconds;
Iailure oI the back-up Inertial ReIerence System Iollowed immediately by Iailure oI the active Inertial
ReIerence System;
swivelling into the extreme position oI the nozzles oI the two solid boosters and, slightly later, oI the
Vulcain engine, causing the launcher to veer abruptly;
selI-destruction oI the launcher correctly triggered by rupture oI the links between the solid boosters
and the core stage.
1/14/12 ARIANE 5 Failure - Full Report
3/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
The origin oI the Iailure was thus rapidly narrowed down to the Ilight control system and more particularly to
the Inertial ReIerence Systems, which obviously ceased to Iunction almost simultaneously at around H0
36.7 seconds.
1.2 INFORMATION AVAILABLE
The inIormation available on the launch includes:
- telemetry data received on the ground until H0 42 seconds
- trajectory data Irom radar stations
- optical observations (IR camera, Iilms) - inspection oI recovered material.
The whole oI the telemetry data received in Kourou was transIerred to CNES/Toulouse where the data were
converted into parameter over time plots. CNES provided a copy oI the data to Aerospatiale, which carried
out analyses concentrating mainly on the data concerning the electrical system.
1.3 RECOVER OF MATERIAL
The selI-destruction oI the launcher occurred near to the launch pad, at an altitude oI approximately 4000 m.
ThereIore, all the launcher debris Iell back onto the ground, scattered over an area oI approximately 12 km2
east oI the launch pad. Recovery oI material proved diIIicult, however, since this area is nearly all mangrove
swamp or savanna.
Nevertheless, it was possible to retrieve Irom the debris the two Inertial ReIerence Systems. OI particular
interest was the one which had worked in active mode and stopped Iunctioning last, and Ior which, thereIore,
certain inIormation was not available in the telemetry data (provision Ior transmission to ground oI this
inIormation was conIined to whichever oI the two units might Iail Iirst). The results oI the examination oI this
unit were very helpIul to the analysis oI the Iailure sequence.
1.4 UNRELATED ANOMALIES OBSERVED
Post-Ilight analysis oI telemetry has shown a number oI anomalies which have been reported to the Board.
They are mostly oI minor signiIicance and such as to be expected on a demonstration Ilight.
One anomaly which was brought to the particular attention oI the Board was the gradual development,
starting at Ho 22 seconds, oI variations in the hydraulic pressure oI the actuators oI the main engine nozzle.
These variations had a Irequency oI approximately 10 Hz.
There are some preliminary explanations as to the cause oI these variations, which are now under
investigation.
AIter consideration, the Board has Iormed the opinion that this anomaly, while signiIicant, has no bearing on
the Iailure oI Ariane 501.
2. ANALSIS OF THE FAILURE
2.1 CHAIN OF TECHNICAL EVENTS
In general terms, the Flight Control System oI the Ariane 5 is oI a standard design. The attitude oI the
1/14/12 ARIANE 5 Failure - Full Report
4/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
launcher and its movements in space are measured by an Inertial ReIerence System (SRI). It has its own
internal computer, in which angles and velocities are calculated on the basis oI inIormation Irom a "strap-
down" inertial platIorm, with laser gyros and accelerometers. The data Irom the SRI are transmitted through
the databus to the On-Board Computer (OBC), which executes the Ilight program and controls the nozzles oI
the solid boosters and the Vulcain cryogenic engine, via servovalves and hydraulic actuators.
In order to improve reliability there is considerable redundancy at equipment level. There are two SRIs
operating in parallel, with identical hardware and soItware. One SRI is active and one is in "hot" stand-by,
and iI the OBC detects that the active SRI has Iailed it immediately switches to the other one, provided that
this unit is Iunctioning properly. Likewise there are two OBCs, and a number oI other units in the Flight
Control System are also duplicated.
The design oI the Ariane 5 SRI is practically the same as that oI an SRI which is presently used on Ariane 4,
particularly as regards the soItware.
Based on the extensive documentation and data on the Ariane 501 Iailure made available to the Board, the
Iollowing chain oI events, their inter-relations and causes have been established, starting with the destruction
oI the launcher and tracing back in time towards the primary cause.
The launcher started to disintegrate at about H0 39 seconds because oI high aerodynamic loads due
to an angle oI attack oI more than 20 degrees that led to separation oI the boosters Irom the main
stage, in turn triggering the selI-destruct system oI the launcher.
This angle oI attack was caused by Iull nozzle deIlections oI the solid boosters and the Vulcain main
engine.
These nozzle deIlections were commanded by the On-Board Computer (OBC) soItware on the basis
oI data transmitted by the active Inertial ReIerence System (SRI 2). Part oI these data at that time did
not contain proper Ilight data, but showed a diagnostic bit pattern oI the computer oI the SRI 2, which
was interpreted as Ilight data.
The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a
Iailure due to a soItware exception.
The OBC could not switch to the back-up SRI 1 because that unit had already ceased to Iunction
during the previous data cycle (72 milliseconds period) Ior the same reason as SRI 2.
The internal SRI soItware exception was caused during execution oI a data conversion Irom 64-bit
Iloating point to 16-bit signed integer value. The Iloating point number which was converted had a
value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand
Error. The data conversion instructions (in Ada code) were not protected Irom causing an Operand
Error, although other conversions oI comparable variables in the same place in the code were
protected.
The error occurred in a part oI the soItware that only perIorms alignment oI the strap-down inertial
platIorm. This soItware module computes meaningIul results only beIore liIt-oII. As soon as the
launcher liIts oII, this Iunction serves no purpose.
The alignment Iunction is operative Ior 50 seconds aIter starting oI the Flight Mode oI the SRIs which
occurs at H0 - 3 seconds Ior Ariane 5. Consequently, when liIt-oII occurs, the Iunction continues Ior
approx. 40 seconds oI Ilight. This time sequence is based on a requirement oI Ariane 4 and is not
required Ior Ariane 5.
The Operand Error occurred due to an unexpected high value oI an internal alignment Iunction result
called BH, Horizontal Bias, related to the horizontal velocity sensed by the platIorm. This value is
calculated as an indicator Ior alignment precision over time.
The value oI BH was much higher than expected because the early part oI the trajectory oI Ariane 5
1/14/12 ARIANE 5 Failure - Full Report
5/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
diIIers Irom that oI Ariane 4 and results in considerably higher horizontal velocity values.
The SRI internal events that led to the Iailure have been reproduced by simulation calculations. Furthermore,
both SRIs were recovered during the Board's investigation and the Iailure context was precisely determined
Irom memory readouts. In addition, the Board has examined the soItware code which was shown to be
consistent with the Iailure scenario. The results oI these examinations are documented in the Technical Report.
ThereIore, it is established beyond reasonable doubt that the chain oI events set out above reIlects the
technical causes oI the Iailure oI Ariane 501.
2.2 COMMEN ON HE FAILE CENAIO
In the Iailure scenario, the primary technical causes are the Operand Error when converting the horizontal bias
variable BH, and the lack oI protection oI this conversion which caused the SRI computer to stop.
It has been stated to the Board that not all the conversions were protected because a maximum workload
target oI 80 had been set Ior the SRI computer. To determine the vulnerability oI unprotected code, an
analysis was perIormed on every operation which could give rise to an exception, including an Operand
Error. In particular, the conversion oI Iloating point values to integers was analysed and operations involving
seven variables were at risk oI leading to an Operand Error. This led to protection being added to Iour oI the
variables, evidence oI which appears in the Ada code. However, three oI the variables were leIt unprotected.
No reIerence to justiIication oI this decision was Iound directly in the source code. Given the large amount oI
documentation associated with any industrial application, the assumption, although agreed, was essentially
obscured, though not deliberately, Irom any external review.
The reason Ior the three remaining variables, including the one denoting horizontal bias, being unprotected
was that Iurther reasoning indicated that they were either physically limited or that there was a large margin oI
saIety, a reasoning which in the case oI the variable BH turned out to be Iaulty. It is important to note that the
decision to protect certain variables but not others was taken jointly by project partners at several contractual
levels.
There is no evidence that any trajectory data were used to analyse the behaviour oI the unprotected variables,
and it is even more important to note that it was jointly agreed not to include the Ariane 5 trajectory data in
the SRI requirements and speciIication.
Although the source oI the Operand Error has been identiIied, this in itselI did not cause the mission to Iail.
The speciIication oI the exception-handling mechanism also contributed to the Iailure. In the event oI any kind
oI exception, the system speciIication stated that: the Iailure should be indicated on the databus, the Iailure
context should be stored in an EEPROM memory (which was recovered and read out Ior Ariane 501), and
Iinally, the SRI processor should be shut down.
It was the decision to cease the processor operation which Iinally proved Iatal. Restart is not Ieasible since
attitude is too diIIicult to re-calculate aIter a processor shutdown; thereIore the Inertial ReIerence System
becomes useless. The reason behind this drastic action lies in the culture within the Ariane programme oI only
addressing random hardware Iailures. From this point oI view exception - or error - handling mechanisms are
designed Ior a random hardware Iailure which can quite rationally be handled by a backup system.
Although the Iailure was due to a systematic soItware design error, mechanisms can be introduced to mitigate
this type oI problem. For example the computers within the SRIs could have continued to provide their best
estimates oI the required attitude inIormation. There is reason Ior concern that a soItware exception should be
1/14/12 ARIANE 5 Failure - Full Report
6/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
aed, ee eied, cae a ce ha hie hadig ii-ciica eie. Ideed, he
f a e fae fci i haad becae he ae fae i bh SRI i. I he cae
f Aiae 501, hi eed i he ich-ff f i heah ciica i f eie.
The igia eiee acccig f he cied eai f he aige fae afe if-ff a
bgh fad e ha 10 ea ag f he eaie de f Aiae, i de ce ih he ahe
ie ee f a hd i he c-d e.g. beee - 9 ecd, he figh de a i he SRI f
Aiae 4, ad - 5 ecd he ceai ee ae iiiaed i he ache hich ae eea h ee.
The eid eeced f hi cied aige eai, 50 ecd afe he a f figh de, a
baed he ie eeded f he gd eie ee f c f he ache i he ee f a
hd.
Thi ecia feae ade i ibe ih he eaie ei f Aiae, ea he c- d ih
aiig f a aige, hich ae 45 ie e, ha a h ach id cd i be
ed. I fac, hi feae a ed ce, i 1989 Figh 33.
The ae eiee de a Aiae 5, hich ha a diffee eaai eece ad i a
aiaied f cai ea, eab baed he ie ha, e e ecea, i a
ie ae chage i fae hich ed e Aiae 4.
Ee i he cae hee he eiee i fd be i aid, i i eiabe f he aige fci
be eaig afe he ache ha ifed ff. Aige f echaica ad ae a-d af
ie ce aheaica fie fci e aig he -ai he gai ai ad fid h
dieci f Eah ai eig. The ai f efigh aige i ha he ache i iied a
a ad fied ii. Theefe, he aige fci i a died he efed dig
figh, becae he eaed ee f he ache ae ieeed a e ffe ad he
cefficie chaaceiig e behai.
Reig he fae e, he Bad ihe i ha fae i a eei f a high
deaied deig ad de fai i he ae ee a a echaica e. Fhee fae i feibe
ad eeie ad h ecage high deadig eiee, hich i ead ce
ieeai hich ae diffic ae.
A deig hee i he deee f Aiae 5 i he bia ad he iigai f ad faie. The
ie f he SRI a fig he ecificai gie i, hich iaed ha i he ee f a
deeced ecei he ce a be ed. The ecei hich cced a de ad
faie b a deig e. The ecei a deeced, b iaiae haded becae he ie had
bee ae ha fae hd be cideed cec i i i h be a fa. The Bad ha ea
beiee ha hi ie i a acceed i he aea f Aiae 5 fae deig. The Bad i i fa f
he ie ie, ha fae hd be aed be fa i aig he ce acceed be
acice ehd ca deae ha i i cec.
Thi ea ha ciica fae - i he ee ha faie f he fae he ii a i - be
ideified a a e deaied ee, ha eceia behai be cfied, ad ha a eaabe bac-
ic ae fae faie i acc.
2.3 THE TESTING AND QUALIFICATION PROCEDURES
The Figh C Se aificai f Aiae 5 f a adad cede ad i efed a he
fig ee :
1/14/12 ARIANE 5 Failure - Full Report
7/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
- Equipment qualiIication
- SoItware qualiIication (On-Board Computer soItware)
- Stage integration
- System validation tests.
The logic applied is to check at each level what could not be achieved at the previous level, thus eventually
providing complete test coverage oI each sub-system and oI the integrated system.
Testing at equipment level was in the case oI the SRI conducted rigorously with regard to all environmental
Iactors and in Iact beyond what was expected Ior Ariane 5. However, no test was perIormed to veriIy that
the SRI would behave correctly when being subjected to the count-down and Ilight time sequence and the
trajectory oI Ariane 5.
It should be noted that Ior reasons oI physical law, it is not Ieasible to test the SRI as a "black box" in the
Ilight environment, unless one makes a completely realistic Ilight test, but it is possible to do ground testing by
injecting simulated accelerometric signals in accordance with predicted Ilight parameters, while also using a
turntable to simulate launcher angular movements. Had such a test been perIormed by the supplier or as part
oI the acceptance test, the Iailure mechanism would have been exposed.
The main explanation Ior the absence oI this test has already been mentioned above, i.e. the SRI speciIication
(which is supposed to be a requirements document Ior the SRI) does not contain the Ariane 5 trajectory data
as a Iunctional requirement.
The Board has also noted that the systems speciIication oI the SRI does not indicate operational restrictions
that emerge Irom the chosen implementation. Such a declaration oI limitation, which should be mandatory Ior
every mission-critical device, would have served to identiIy any non-compliance with the trajectory oI Ariane
5.
The other principal opportunity to detect the Iailure mechanism beIorehand was during the numerous tests and
simulations carried out at the Functional Simulation Facility ISF, which is at the site oI the Industrial Architect.
The scope oI the ISF testing is to qualiIy :
- the guidance, navigation and control perIormance in the whole Ilight envelope,
- the sensors redundancy operation, - the dedicated Iunctions oI the stages,
- the Ilight soItware (On-Board Computer) compliance with all equipment oI the Flight Control
Electrical System.
A large number oI closed-loop simulations oI the complete Ilight simulating ground segment operation,
telemetry Ilow and launcher dynamics were run in order to veriIy :
- the nominal trajectory
- trajectories degraded with respect to internal launcher parameters
- trajectories degraded with respect to atmospheric parameters
- equipment Iailures and the subsequent Iailure isolation and recovery
In these tests many equipment items were physically present and exercised but not the two SRIs, which were
simulated by speciIically developed soItware modules. Some open-loop tests, to veriIy compliance oI the
On-Board Computer and the SRI, were perIormed with the actual SRI. It is understood that these were just
electrical integration tests and "low-level " (bus communication) compliance tests.
It is not mandatory, even iI preIerable, that all the parts oI the subsystem are present in all the tests at a given
1/14/12 ARIANE 5 Failure - Full Report
8/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
level. Sometimes this is not physically possible or it is not possible to exercise them completely or in a
representative way. In these cases it is logical to replace them with simulators but only aIter a careIul check
that the previous test levels have covered the scope completely.
This procedure is especially important Ior the Iinal system test beIore the system is operationally used (the
tests perIormed on the 501 launcher itselI are not addressed here since they are not speciIic to the Flight
Control Electrical System qualiIication).
In order to understand the explanations given Ior the decision not to have the SRIs in the closed-loop
simulation, it is necessary to describe the test conIigurations that might have been used.
Because it is not possible to simulate the large linear accelerations oI the launcher in all three axes on a test
bench (as discussed above), there are two ways to put the SRI in the loop:
A) To put it on a three-axis dynamic table (to stimulate the Ring Laser Gyros) and to substitute the
analog output oI the accelerometers (which can not be stimulated mechanically) by simulation via a
dedicated test input connector and an electronic board designed Ior this purpose. This is similar to the
method mentioned in connection with possible testing at equipment level.
B) To substitute both, the analog output oI the accelerometers and the Ring Laser Gyros via a
dedicated test input connector with signals produced by simulation.
The Iirst approach is likely to provide an accurate simulation (within the limits oI the three-axis dynamic table
bandwidth) and is quite expensive; the second is cheaper and its perIormance depends essentially on the
accuracy oI the simulation. In both cases a large part oI the electronics and the complete soItware are tested
in the real operating environment.
When the project test philosophy was deIined, the importance oI having the SRIs in the loop was recognized
and a decision was taken to select method B above. At a later stage oI the programme (in 1992), this
decision was changed. It was decided not to have the actual SRIs in the loop Ior the Iollowing reasons :
The SRIs should be considered to be Iully qualiIied at equipment level
The precision oI the navigation soItware in the On-Board Computer depends critically on the precision
oI the SRI measurements. In the ISF, this precision could not be achieved by the electronics creating
the test signals.
The simulation oI Iailure modes is not possible with real equipment, but only with a model.
The base period oI the SRI is 1 millisecond whilst that oI the simulation at the ISF is 6 milliseconds.
This adds to the complexity oI the interIacing electronics and may Iurther reduce the precision oI the
simulation.
The opinion oI the Board is that these arguments were technically valid, but since the purpose oI a system
simulation test is not only to veriIy the interIaces but also to veriIy the system as a whole Ior the particular
application, there was a deIinite risk in assuming that critical equipment such as the SRI had been validated by
qualiIication on its own, or by previous use on Ariane 4.
While high accuracy oI a simulation is desirable, in the ISF system tests it is clearly better to compromise on
accuracy but achieve all other objectives, amongst them to prove the proper system integration oI equipment
such as the SRI. The precision oI the guidance system can be eIIectively demonstrated by analysis and
computer simulation.
Under this heading it should be noted Iinally that the overriding means oI preventing Iailures are the reviews
1/14/12 ARIANE 5 Failure - Full Report
9/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
which are an integral part oI the design and qualiIication process, and which are carried out at all levels and
involve all major partners in the project (as well as external experts). In a programme oI this size, literally
thousands oI problems and potential Iailures are successIully handled in the review process and it is obviously
not easy to detect soItware design errors oI the type which were the primary technical cause oI the 501
Iailure. Nevertheless, it is evident that the limitations oI the SRI soItware were not Iully analysed in the
reviews, and it was not realised that the test coverage was inadequate to expose such limitations. Nor were
the possible implications oI allowing the alignment soItware to operate during Ilight realised. In these respects,
the review process was a contributory Iactor in the Iailure.
2.4 POSSIBLE OTHER WEAKNESSES OF SSTEMS INVOLVED
In accordance with its termes oI reIerence, the Board has examined possible other weaknesses, primarily in
the Flight Control System. No weaknesses were Iound which were related to the Iailure, but in spite oI the
short time available, the Board has conducted an extensive review oI the Flight Control System based on
experience gained during the Iailure analysis.
The review has covered the Iollowing areas :
- The design oI the electrical system,
- Embedded on-board soItware in subsystems other than the Inertial ReIerence System,
- The On-Board Computer and the Ilight program soItware.
In addition, the Board has made an analysis oI methods applied in the development programme, in particular
as regards soItware development methodology.
The results oI these eIIorts have been documented in the Technical Report and it is the hope oI the Board that
they will contribute to Iurther improvement oI the Ariane 5 Flight Control System and its soItware.
3. CONCLUSIONS
3.1 FINDINGS
The Board reached the Iollowing Iindings:
a) During the launch preparation campaign and the count-down no events occurred which were related
to the Iailure.
b) The meteorological conditions at the time oI the launch were acceptable and did not play any part in
the Iailure. No other external Iactors have been Iound to be oI relevance.
c) Engine ignition and liIt-oII were essentially nominal and the environmental eIIects (noise and
vibration) on the launcher and the payload were not Iound to be relevant to the Iailure. Propulsion
perIormance was within speciIication.
d) 22 seconds aIter H0 (command Ior main cryogenic engine ignition), variations oI 10 Hz Irequency
started to appear in the hydraulic pressure oI the actuators which control the nozzle oI the main engine.
This phenomenon is signiIicant and has not yet been Iully explained, but aIter consideration it has not
been Iound relevant to the Iailure.
e) At 36.7 seconds aIter H0 (approx. 30 seconds aIter liIt-oII) the computer within the back-up inertial
1/14/12 ARIANE 5 Failure - Full Report
10/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
reIerence system, which was working on stand-by Ior guidance and attitude control, became
inoperative. This was caused by an internal variable related to the horizontal velocity oI the launcher
exceeding a limit which existed in the soItware oI this computer.
I) Approx. 0.05 seconds later the active inertial reIerence system, identical to the back-up system in
hardware and soItware, Iailed Ior the same reason. Since the back-up inertial system was already
inoperative, correct guidance and attitude inIormation could no longer be obtained and loss oI the
mission was inevitable.
g) As a result oI its Iailure, the active inertial reIerence system transmitted essentially diagnostic
inIormation to the launcher's main computer, where it was interpreted as Ilight data and used Ior Ilight
control calculations.
h) On the basis oI those calculations the main computer commanded the booster nozzles, and
somewhat later the main engine nozzle also, to make a large correction Ior an attitude deviation that
had not occurred.
i) A rapid change oI attitude occurred which caused the launcher to disintegrate at 39 seconds aIter H0
due to aerodynamic Iorces.
j) Destruction was automatically initiated upon disintegration, as designed, at an altitude oI 4 km and a
distance oI 1 km Irom the launch pad.
k) The debris was spread over an area oI 5 x 2.5 km2. Amongst the equipment recovered were the
two inertial reIerence systems. They have been used Ior analysis.
l) The post-Ilight analysis oI telemetry data has listed a number oI additional anomalies which are being
investigated but are not considered signiIicant to the Iailure.
m) The inertial reIerence system oI Ariane 5 is essentially common to a system which is presently Ilying
on Ariane 4. The part oI the soItware which caused the interruption in the inertial system computers is
used beIore launch to align the inertial reIerence system and, in Ariane 4, also to enable a rapid
realignment oI the system in case oI a late hold in the countdown. This realignment Iunction, which does
not serve any purpose on Ariane 5, was nevertheless retained Ior commonality reasons and allowed,
as in Ariane 4, to operate Ior approx. 40 seconds aIter liIt-oII.
n) During design oI the soItware oI the inertial reIerence system used Ior Ariane 4 and Ariane 5, a
decision was taken that it was not necessary to protect the inertial system computer Irom being made
inoperative by an excessive value oI the variable related to the horizontal velocity, a protection which
was provided Ior several other variables oI the alignment soItware. When taking this design decision, it
was not analysed or Iully understood which values this particular variable might assume when the
alignment soItware was allowed to operate aIter liIt-oII.
o) In Ariane 4 Ilights using the same type oI inertial reIerence system there has been no such Iailure
because the trajectory during the Iirst 40 seconds oI Ilight is such that the particular variable related to
horizontal velocity cannot reach, with an adequate operational margin, a value beyond the limit present
in the soItware.
p) Ariane 5 has a high initial acceleration and a trajectory which leads to a build-up oI horizontal
velocity which is Iive times more rapid than Ior Ariane 4. The higher horizontal velocity oI Ariane 5
generated, within the 40-second timeIrame, the excessive value which caused the inertial system
1/14/12 ARIANE 5 Failure - Full Report
11/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
computers to cease operation.
q) The purpose oI the review process, which involves all major partners in the Ariane 5 programme, is
to validate design decisions and to obtain Ilight qualiIication. In this process, the limitations oI the
alignment soItware were not Iully analysed and the possible implications oI allowing it to continue to
Iunction during Ilight were not realised.
r) The speciIication oI the inertial reIerence system and the tests perIormed at equipment level did not
speciIically include the Ariane 5 trajectory data. Consequently the realignment Iunction was not tested
under simulated Ariane 5 Ilight conditions, and the design error was not discovered.
s) It would have been technically Ieasible to include almost the entire inertial reIerence system in the
overall system simulations which were perIormed. For a number oI reasons it was decided to use the
simulated output oI the inertial reIerence system, not the system itselI or its detailed simulation. Had the
system been included, the Iailure could have been detected.
t) Post-Ilight simulations have been carried out on a computer with soItware oI the inertial reIerence
system and with a simulated environment, including the actual trajectory data Irom the Ariane 501
Ilight. These simulations have IaithIully reproduced the chain oI events leading to the Iailure oI the
inertial reIerence systems.
3.2 CAE OF HE FAILE
The Iailure oI the Ariane 501 was caused by the complete loss oI guidance and attitude inIormation 37
seconds aIter start oI the main engine ignition sequence (30 seconds aIter liIt- oII). This loss oI inIormation
was due to speciIication and design errors in the soItware oI the inertial reIerence system.
The extensive reviews and tests carried out during the Ariane 5 Development Programme did not include
adequate analysis and testing oI the inertial reIerence system or oI the complete Ilight control system, which
could have detected the potential Iailure.
4. ECOMMENDAION
On the basis oI its analyses and conclusions, the Board makes the Iollowing recommendations.
1 Switch oII the alignment Iunction oI the inertial reIerence system immediately aIter liIt-oII. More generally,
no soItware Iunction should run during Ilight unless it is needed.
2 Prepare a test Iacility including as much real equipment as technically Ieasible, inject realistic input data,
and perIorm complete, closed-loop, system testing. Complete simulations must take place beIore any
mission. A high test coverage has to be obtained.
3 Do not allow any sensor, such as the inertial reIerence system, to stop sending best eIIort data.
4 Organize, Ior each item oI equipment incorporating soItware, a speciIic soItware qualiIication review. The
Industrial Architect shall take part in these reviews and report on complete system testing perIormed with the
equipment. All restrictions on use oI the equipment shall be made explicit Ior the Review Board. Make all
critical soItware a ConIiguration Controlled Item (CCI).
5 Review all Ilight soItware (including embedded soItware), and in particular :
1/14/12 ARIANE 5 Failure - Full Report
12/12 www.ima.umn.edu/arnold/disasters/ariane5rep.html
IdentiIy all implicit assumptions made by the code and its justiIication documents on the values oI
quantities provided by the equipment. Check these assumptions against the restrictions on use oI the
equipment.
VeriIy the range oI values taken by any internal or communication variables in the soItware.
Solutions to potential problems in the on-board computer soItware, paying particular attention to on-
board computer switch over, shall be proposed by the project team and reviewed by a group oI
external experts, who shall report to the on-board computer QualiIication Board.
6 Wherever technically Ieasible, consider conIining exceptions to tasks and devise backup capabilities.
7 Provide more data to the telemetry upon Iailure oI any component, so that recovering equipment will be
less essential.
8 Reconsider the deIinition oI critical components, taking Iailures oI soItware origin into account
(particularly single point Iailures).
9 Include external (to the project) participants when reviewing speciIications, code and justiIication
documents. Make sure that these reviews consider the substance oI arguments, rather than check that
veriIications have been made.
10 Include trajectory data in speciIications and test requirements.
11 Review the test coverage oI existing equipment and extend it where it is deemed necessary.
12 Give the justiIication documents the same attention as code. Improve the technique Ior keeping code
and its justiIications consistent.
13 Set up a team that will prepare the procedure Ior qualiIying soItware, propose stringent rules Ior
conIirming such qualiIication, and ascertain that speciIication, veriIication and testing oI soItware are oI a
consistently high quality in the Ariane 5 programme. Including external RAMS experts is to be considered.
14 A more transparent organisation oI the cooperation among the partners in the Ariane 5 programme must
be considered. Close engineering cooperation, with clear cut authority and responsibility, is needed to achieve
system coherence, with simple and clear interIaces between partners.
- END -