Re: Ariane 5 - not an exception?

[john@assen.demon.co.uk (John McCabe)]

rav@goanna.cs.rmit.edu.au (++           robin) wrote:

>	>>	>     a) There is no PL/I compiler for the 1750A

>	>>---Not an obstacle.  How was an Ada compiler written for it?

>	>Because the US Military decided that their standard microprocessor
>	>(Mil-Std-1750A) should have a compiler for their standard language Ada
>	>(Mil-Std-1815).

>---One had to be written, no?

What do you mean "One had to be written"? There are a number of
commercially available Ada compilers for the MIL-STD-1750A processor
e.g. TLD, Tartan, EDS-Scicon XD-Ada, DDC-I all already produce a
1750/Ada compiler. If you are suggesting that one had to be written
especially for the Ariane project you are wrong. As far as PL/I is
concerned, it is clear that there is absolutely no demand for a
1750/PL/I compiler so in this case, if the Ariane developers had
wanted to use PL/I and 1750 it would have been necessary to develop a
completely new compiler rather than use one that could already be
purchased off the shelf.

>	>>	>     c) This failure was not a language issue.

>	>>---Isn't it?  One of the arguments put forward was that
>	>>an Ada condition couldn't be raised and leave a trace,
>	>>and that it would be argued that there was no guarantee
>	>>whether a piece of code was executed.

>	>Of course it isn't. How many people have to point out that no matter
>	>what language had been used the specification

>---No, the specification wasn't faulty.  The implementation
>was.  Because of a programming error, a data conversion from
>double precision floating-point to a 16-bit integer
>overflowed.  In the absence of a check, an exception occurred,
>the immediate action of which was to shut down the processor.
>That shutdown resulted in the inevitable and almost immediate
>destruction of the project.  Read the report.

Why was the processor shut down? Because that was the SPECIFIED action
of the exception handler. The programmer implemented the
specification. Why was there an overflow? Because the implementation
followed the specification which _failed_ to specify the Ariane 5
requirements correctly (especially inrelation to the commonality
between Ariane 4 and Ariane 5).

And BTW I have read the report, a number of times and every time I
read it, it tells me that the programmers were not at fault. Think
about it, how much authority on design decisions has a programmer on a
large project - very little! If they raise a query on the design it is
still someone else's responsibility to make the decision as to what to
do about it.

>	>and design was still faulty.

>---There was a number of design problems that needs to be
>addressed.

Yes, but by the designer, not necessarily by the programmer.

>	>Read the report - the lack of checks was the result of analysis done
>	>on the software and obviously was accepted at a higher level.

>---I had read the report ages ago, before making any
>posting on the issue, and was horrified to read of the
>cause being a simple overflow.

>   If you had read the report, you would have notected that
>the committee could not find any explanation in the code
>as to why this & 2 other conversions did not have checks,
>while all the other similar conversions in the vicinity
>did.  There is the suggestion that the checks were overlooked.

Don't talk rubbish! Read this - an excerpt from the report:

"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 
------NOTE  ^^^^^^^^^^^^^^^
deliberately, from any external review.

>	>The
>	>important point being that the analysis was done and the checks
>	>removed, _not_ that they weren't there in the first place.

>---On the contrary, if you read the report, it states
>clearly and unequivocally that the analysis was done
>and the checks *added* where they felt that they were 
Accepted, however the report goes on to say:

"The reason for the three remaining variables, including the one
denoting horizontal bias, being unprotected was that further reasoning
indicated that they were either physically limited or that there was a
large margin of safety, a reasoning which in the case of the variable
BH turned out to be faulty. 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"
------------ NOTE   ^^^^^^^^^^^^^^^^^^^^^^^^^^

******* IT WAS NOT A PROGRAMMING ERROR ********

>needed (NOT removed from ones that they felt did not
>need it).

>	>>---No it wouldn't.  The lack of a test for overflow was
>	>>the problem.  But even supposing for a moment that
>	>>all conversions were checked, then
>	>>an interrupt handler could be included for fixed-point
>	>>overflow.  This would have trapped any unchecked
>	>>overflow.  A R/T (and even non R/T) PL/I programmer
>	>>routinely puts in error control.

>	>Chances are that this is exactly how the Operand Error exception was
>	>raised.

>---This is how -- obviously -- the exception was raised.
>It is the *absence* of a specific check that caused this
>to happen (the report used the term "unchecked").

The absence of a specific check is what ultimately caused the failure,
however this was not the problem - the problem was far more
fundamental than that.

>You really should read the report.

I have read the report - a number of times - you should try it
sometime it is rather interesting.

>	>Why don't you find out about Ada and how it is implemented in
>	>embedded systems before stating rubbish like this. You may learn a
>	>lot.

>---BTW, it isn't rubbish.  You just haven't understood.
>What I said was that a belt-and braces method was
>needed.  All conversions should have been checked.

The excuse was that not all conversions were checked because there was
not enough processing power to do so. I would, however, have to agree
with you here as I believe that processor loading margin requirements
should NEVER be met at the expense of mission success.

>In addition, an interrupt handler should have been
>included for fixed-point overflow, just in case
>a check had been inadvertently omitted from any conversion.

The "interrupt handler" was added - it was the Operand Error excepion
handler.

>   These matters are routine for a PL/I programmer.

>   ANY kind of interrupt (even a trivial one) in Ariane 5
>would cause sudden death to the project (the shutdown
>of the processor).

That is probably completely untrue! The exception that occurred would
be tied to a specific interrupt - if MIL-STD-1750 processors were
used, they allow up to 16 different interrupts to be handled, this
exception handler would not be invoked for all interrupts.

>It was the programmer's job to ensure
>that such an error (number too large) never occurred under
>any circumstances.

No it wasn't - a programmers job is to implement a specification and
raise any queries regarding his implementation. If those queries end
up in incorrect decisions to proceed in a given direction "by project
partners at several different contractual levels", is it the
programmers job to ignore that? I don't think so.

Best Regards
John McCabe <john@assen.demon.co.uk>