Re: Ariane 5 - not an exception?

[Steve O'Neill <smoneill@sanders.lockheed.com>]

++ robin wrote:
>         Steve O'Neill <smoneill@sanders.lockheed.com> writes:
>         >I disagree completely!  The language was not the
>         >problem the design decisions in how the language
>         >was used were.
> 
> ---The choice of language is indeed very relevant.
> What I wrote in an earlier posting on this topic is highly
> apt:
> 
> "A PL/I programmer
> experienced with real time systems, would have CHALLENGED
> such a stupid requirement that the computer be shut down by the
> error-handler in the event of a fixed-point overflow.  He would
> have had it changed.
> 
> "I'd go further to say that no experienced PL/I programmer
> would have shut down the system as a result of a fixed-point
> overflow.

Substitute Ada (or C or FORTRAN or Assembly) for PL/I here and you see my 
point.  It's not the language that makes the developer challange the 
ridiculous requirement to shut down it is the developer "experienced with 
real-time systems".  Just because I am programming in PL/I doesn't mean I 
am magically a better real-time developer.  As a real-time designer 
concerned with the system-wide aspects of completely shutting down any 
sensor I would question this approach regardless of the language in use. 
This has nothing to do with the fact that much of my experience is with 
Ada.

The (flawed) reasoning for why certain conversions were not protected was 
also covered in the report.  Invalid assumptions were made and we know 
what assuming does don't we (makes an ASS out of U and ME).  This was 
compounded by the requirement for 20% spare capacity.  Spare capacity for 
what we don't know.  Especially considering that the very software which 
failed didn't need to be and should not have been running at the time 
consuming some of that precious spare.

Certainly you and I would not have shut down the system but what about 
the vast majority of developers without as much experience or who thought 
that their job was to implement the requirements that they were given?

> 
> "Furthermore, he would have included a check that the value
> did not go out of range;"
> 
> ---But all it needed was a check that the value was in range.
> Such checks had been included on other similar conversions in
> the vicinity!
> 

Yes, and there was mention in the report that 'they' thought that this 
would violate that precious spare requirement.  So they set about picking 
and choosing which conversions to protect.  I find it extremely hard to 
believe that the (small) handful of instructions to do a range check 
would have been too much!  And, in hindsight, well worth it.

The issue of the OBC interpreting the 'essentially diagnostic data' as 
valid sensor data really makes me wonder.  In a system with a reasonable 
interface between the two devices this should *never* happen.  I am 
surprised that this misinterpretation didn't cause a similar overflow in 
the OBC and resulting shutdown! :(

I think that we agree in our assessment of the situation and the fact 
that these problems could have been avoided with a better overall system 
design and more extensive testing.  Essentially the same conclusions that 
the review board came to.  My only disagreement is with your _opinion_ 
that the simple choice of a different language would have saved the day. 
 And with this point I will continue to disagree. 

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai