Re: Is C++ used in life-critical systems?
On Dec 31, 9:55 am, Michael Doubez <michael.dou...@free.fr> wrote:
On 31 d=E9c, 10:21, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On Dec 30, 7:46 pm, James Kanze <james.ka...@gmail.com> wrote:
On Dec 30, 3:49 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote
On Dec 15, 10:10 pm, "Marc" <xmarc...@spot.net> wrote:
Read up on the Ariane bug its
quite enlightening (once you get past the pontificating ("if they'd
use Blub this would never have happened!")). The space shuttle
software development process is quite interesting as well.
Just a reminder: there was no bug in the Ariane's software.
I didn't say there was. But when a rocket falls from the sky we can
safely say there was a bug in something!
Actually, there was, a variable was supposed within reasonable range.
http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
Just a reminder. This report was commanded by the same
management which decided that the software from the Ariane
4 could be reused without validation, since it obviously worked
(or was commanded by the people who appointed those people).
Politicians (and this was a political issue) don't like
admitting their own mistakes, or those of their friends.
Descriptions of what technically occurred are probably valid,
but some of the conclusions don't actually follow from the
technical details presented.
<quote>
In the failure scenario, the primary technical causes are the Operand
Error when converting the horizontal bias variable BH, and the lack of
protection of this conversion which caused the SRI computer to stop.
</quote>
But the domain of Ariane 4 was small enough that this bug wasn't
triggered.
In the Ariane 4, this was the desired behavior. The values in
question weren't possible. The presence of the Operand Error
could only be due to a hardware failure upstream, and indicated
that the processor was not getting correct input.
Nonetheless, there was apparently a lack of validation of the module
for Ariane 5.
<quote>
Testing at equipment level was in the case of the SRI conducted
rigorously with regard to all environmental factors and in fact beyond
what was expected for Ariane 5. However, no test was performed to
verify that the SRI would behave correctly when being subjected to the
count-down and flight time sequence and the trajectory of Ariane 5.
</quote>
In order to test, you have to first specify what the behavior is
supposed to be. Not even considering that different behavior
might be required is the root cause of the problem. But of
course, that decision was made by people high enough up that the
report didn't bring them into question.
Management decided to just reuse it in a different context: the
software did what it was supposed to do, for the system it was
written for. (In other words, stating that there was a bug in
the software is like saying that your C++ compiler has a bug
because it doesn't correctly compile someone's Ada program.)
error: the system behaves in manner not expected by a reasonable user
Actually, it did. Upon detection of the error, the politic was to
shutdown the processor although (from the report), another scenario
could have been provided (an estimate from the SRI)
<quote>
Although the source of the Operand Error has been identified, this in
itself did not cause the mission to fail. The specification of the
exception-handling mechanism also contributed to the failure. In the
event of any kind of exception, the system specification stated that:
the failure should be indicated on the databus, the failure context
should be stored in an EEPROM memory (which was recovered and read out
for Ariane 501), and finally, the SRI processor should be shut down.
It was the decision to cease the processor operation which finally
proved fatal.
Note that this was the correct decision for the Ariane 4. It
was the decision to use the software from the Ariane 4 without
revalidation that is the ultimate cause of the accident.
Restart is not feasible since attitude is too difficult
to re-calculate after a processor shutdown; therefore the Inertial
Reference System becomes useless. The reason behind this drastic
action lies in the culture within the Ariane programme of only
addressing random hardware failures. From this point of view exception
- or error - handling mechanisms are designed for a random hardware
failure which can quite rationally be handled by a backup system.
</quote>
It is an interesting point with regards to the the question at
hand: at a larger level, the requirements of the system are to
auto-destruct if a bug is found. (The Ariane auto-destructed
because the software determined that the systems providing its
input were defective, since the values were impossible.)
I understood it was destroyed by the range safety officer
Yes but it could have had a different strategy.
<quote>
Although the failure was due to a systematic software design error,
mechanisms can be introduced to mitigate this type of problem. For
example the computers within the SRIs could have continued to provide
their best estimates of the required attitude information. There is
reason for concern that a software exception should be allowed, or
even required, to cause a processor to halt while handling mission-
critical equipment. Indeed, the loss of a proper software function is
hazardous because the same software runs in both SRI units. In the
case of Ariane 501, this resulted in the switch-off of two still
healthy critical units of equipment.
</quote>
And that is the conclusion which is totally unjustified. In the
Ariane 4, not shutting the system down in this condition would
have been a serious error.
If you
aren't sure that you have full control, better to auto-destruct
than to risk crashing into a populated city.
are there many near the Ariane launch site?
No but when you have this much tons of metals at this speed and
accelerating, you may reach inhabited locations quite quickly.
The palms goes to this citation
<quote>
Returning to the software error, the Board wishes to point out that
software is an expression of a highly detailed design and does not
fail in the same sense as a mechanical system. Furthermore software is
flexible and expressive and thus encourages highly demanding
requirements, which in turn lead to complex implementations which are
difficult to assess.
An underlying theme in the development of Ariane 5 is the bias towards
the mitigation of random failure. The supplier of the SRI was only
following the specification given to it, which stipulated that in the
event of any detected exception the processor was to be stopped. The
exception which occurred was not due to random failure but a design
error. The exception was detected, but inappropriately handled because
the view had been taken that software should be considered correct
until it is shown to be at fault. The Board has reason to believe that
this view is also accepted in other areas of Ariane 5 software design.
The Board is in favour of the opposite view, that software should be
assumed to be faulty until applying the currently accepted best
practice methods can demonstrate that it is correct.
This means that critical software - in the sense that failure of the
software puts the mission at risk - must be identified at a very
detailed level, that exceptional behaviour must be confined, and that
a reasonable back-up policy must take software failures into account.
</quote>
That is certainly the palm, since it shows that the committee
who wrote the report didn't understand the rational behind the
original design decisions. In this case, it would have saved
the Ariane 5. Had similar input occurred in the Ariane 4,
however, it could well have resulted in the missle crashing in
a highly populated area.
--
James Kanze