> In a message dated 9/23/98 6:28:04 PM, [log in to unmask] wrote:
> >Absolutely not. PL/I provides error interception and recovery, as well
> >as facilities for testing with simulated error generation.
> >
> >A PL/I programmer experienced in real-time programming would
> >have routinely included an error handler.
> >(In particular, the SIGNAL statement is available to generate such things as
> >fixed-point overflow or any other condition.)
> >The SIGNAL statement enables checkout of the error-handling mechanism,
> >as well as of course that an error occurring in a given part of the program
> >in fact has a fall-back (fail-safe) position.
> >It is clear that no simulated testing of the procedure was carried out.
________________________
> Robin:
> We have had this argument before. Ada in this respect has exactly the same
> capabilities as PL/I.
>
> Ada provides error interception and recovery, and its implementations provide
> facilities for testing with simulated error generation.
While Ada has capability, it doesn't have the detailed identification of hardware
interrupts and the handling that PL/I has.
> An Ada programmer experienced in real-time programming would have routinely
> included an error handler.
If this were so, then it would have been included. But it was not.
> In fact for the code in question, about half of the
> identified possible occurences of overflow were provided with error handlers
> within the procedure that robustly corrected the error.
They were NOT provided with error handlers. This is clearly stated
in the Report.
They had used specific code to test for a possible overflow in
the protected conversions.
However, in three places protection was not
provided, even though several other conversions in the
vicinity were protected.
> About half were
> identified as not physically possible for the Ariane 4, indicating a system
> malfunction.
No, not for Ariane 5. The report was for Ariane 5, and the
analysis was done for Ariane 5. Protection (for the three
unprotected conversions) was not provided because it was
considered that there was a substantial safety margin --
which proved not to be the case.
> The team made the conscious decision that the only system
^^^^^^^
> component that could fail and had a backup was the computer and a reasonable
> response was to have the error handle in the main system shut off the
> computer.
Decision? The Report strongly criticized this attitude,
calling it a "mentality".
> (I believe the RAISE statement is available to generate such things as
> fixed-point overflow or any other condition.)
> The RAISE statement enables checkout of the error-handling mechanism,
> as well as of course that an error occurring in a given part of the program
> in fact has a fall-back (fail-safe) position.
>
> The original Ada team did enough testing to identify all possible sources of
> overflow
No, they didn't. The code was not tested with flight data relevant to
Ariane 5. Read the Report.
And they clearly did not include checks on the 3 data conversions
in question.
> which I understand to be the intent of your statement. An explicit
> high level decision was made that the code did not require testing and
> contractors were not provided (in fact I believe they were denied) access to
> simulated flight trajectory data and had no way of knowing that the horizontal
> velocity of the Ariane 5 was expected to more than four times that of the
> Ariane 4.
You didn't need to know what the data was to include the check.
It was -- after all -- a real-time system, and you couldn't afford
to have even a single interrupt).
If you read the Report, you will see that a single interrupt
would cause the computer to be shut down.
> Shutting down both computers was unexpected.
Only to those who wrote the code.
> Ken Garlington has an excellent discussion of this on the net.
|