On Tue, 22 Sep 1998, Clive Page wrote:
> Indeed. And even then its safety features aren't proof against human
> ingenuity or stupidity.
>
> In case anyone had forgotten, it was use, or misuse, of the Ada exception
> handling mechanism which was one of the most significant factors in
> the crash of the first Ariane-5 rocket.
Actually the causes for the failure of Ariane-5 are a bit more complicated
and awere less a language feature but rather of a software engineering, i.e.
human, nature. In order to judge Ada correctly in the light of the Ariane-5
accident it is well worth to read the relevant parts of the official report.
>From the official Ariane-5 accident report
(see http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html):
-----------BEGIN OF QUOTATION------------------
Based on the extensive documentation and data on the Ariane 501 failure made
available to the Board, the following chain of events, their inter-relations
and causes have been established, starting with the destruction of
the launcher and tracing back in time towards the primary cause.
1) The launcher started to disintegrate at about H0 + 39 seconds because of
high aerodynamic loads due to an angle of attack of more than 20 degrees
that led to separation of the boosters from the main stage, in turn
triggering the self-destruct system of the launcher.
2) This angle of attack was caused by full nozzle deflections of the solid
boosters and the Vulcain main engine.
3) These nozzle deflections were commanded by the On-Board Computer (OBC)
software on the basis of data transmitted by the active Inertial Reference
System (SRI 2). Part of these data at that time did not contain proper
flight data, but showed a diagnostic bit pattern of the computer of the
SRI 2, which was interpreted as flight data.
4) The reason why the active SRI 2 did not send correct attitude data was
that the unit had declared a failure due to a software exception.
5) The OBC could not switch to the back-up SRI 1 because that unit had
already ceased to function during the previous data cycle (72 milliseconds
period) for the same reason as SRI 2.
6) The internal SRI software exception was caused during execution of a data
conversion from 64-bit floating point to 16-bit signed integer value.
The floating 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 from causing an Operand Error, although other conversions of
comparable variables in the same place in the code were protected.
7) The error occurred in a part of the software that only performs alignment
of the strap-down inertial platform.
8) This software module computes meaningful results only before lift-off.
As soon as the launcher lifts off, this function serves no purpose.
9) The alignment function is operative for 50 seconds after starting of
the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5.
Consequently, when lift-off occurs, the function continues for approx. 40
seconds of flight. This time sequence is based on a requirement of Ariane 4
and is not required for Ariane 5.
10) The Operand Error occurred due to an unexpected high value of an internal
alignment function result called BH, Horizontal Bias, related to the horizontal
velocity sensed by the platform. This value is calculated as an indicator for
alignment precision over time.
11) The value of BH was much higher than expected because the early part of the
trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably
higher horizontal velocity values.
-----------END OF QUOTATION------------------
The chain of events was confirmed by later simulation calculations!
See items 9 and 11: Ariane-5 contained code that was written for Ariane-4
and NOT changed for the different requirements of Ariane-5. The relevant
segment of code was also not as well protected (item 6) as other parts of
the code. Why?
Again the report:
It has been stated to the Board that not all the conversions were protected because
a maximum workload target of 80% had been set for the SRI computer. To determine
the vulnerability of unprotected code, an analysis was performed on every operation
which could give rise to an exception, including an Operand Error. In particular,
the conversion of floating point values to integers was analysed and operations
involving seven variables were at risk of leading to an Operand Error. This led to
protection being added to four of the variables, evidence of which appears in the
Ada code. However, three of the variables were left unprotected. No reference to
justification of this decision was found directly in the source code. Given the
large amount of documentation associated with any industrial application, the
assumption, although agreed, was essentially obscured, though not deliberately,
from any external review.
(The following paragraphs are also worth reading but I leave this to the
individual reader.)
So, the failure of Ariane-5 was mostly due to an incorrect analysis and
(re/mis)use of old code in a new situation. This is not particularly limited
to Ada but could have happened in any other language as well.
As to Ada and Fortran:
Ada is a quite consistent language with many (too many?) features which is
certainly overwhelming for anyone new to programming or coming from another
language.
Ada (that is Ada95), as far as I know, has all the features that Fortran
has but more, esp.
bindings to other languages
object-oriented programming (though I don't like the Ada version)
generic programming (certain aspects are more complicated then need to be)
support for parallel programming (tasks)
Good aspects of Ada are usually a rather safe language, that enforces and
supports good programming, but Ada is also a very large and complicated
language whose elements can interact at many levels which make for a
difficult learning curve.
I wish that certain design principles (safety/consistency) would make it
into Fortran but certain constructs are done better in other languages
(OOP, generics).
Cheers,
WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
