Re: Ariane 5 - not an exception?

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

Martin Tom Brown <Martin@nezumi.demon.co.uk> wrote:

<..snip..>

>Yes - one can argue about the reasonableness of killing the active SRI
>when the backup has already failed. And also about the decision made
>during s/w development that out of 7 variables at risk of overflow only
>4 were fully protected, and 3 unprotected which were felt not at risk
>to keep CPU load inside bounds <80% (for Ariane 4 flight trajectories).

I find it difficult to understand why the design and development team
even considered maintaining the CPU load at <80% for this particular
case. If they requested a waiver on that margin and were refused then
obviously their prime contractor (or whatever) is to blame, but there
is no way that CPU loadings with margins of 20% should have been
enforced at the risk of mission failure.

<..snip..>

>Again you can question the wisdom of shutting down the active IRS
>when the backup is already dead - continuing with best guess data
>would have been a marginally better option at that stage. 
>The defect is traceable back to the requirements specification, and
>the assumption that single point hardware failure is more likely 
>than systematic software error in a redundant system.

True, but it certainly surprises me that there are 2 _identical_
computers running _identical_ software on a piece of equipment that is
so important to the future of the European space industry, and that
has had so much taxpayers money invested in it.

I would have thought that a triplex system using a voting mechanism
would have been used at least. I know this wold have extra cost, but
how much extra in terms of what we have seen happen with the system as
provided on flight 501. $300M (or was it pounds) worth of experimental
satellite went up with that rocket, would it have cost that much to
add one extra computer and some more software? I don't think so!

>> The problem resulted in an oversight in the design limitations and
>> differences between the Ariane 4 and Ariane 5 systems.  I think the 
>> lessons to be learned here are about the reuse of software (especially
>> design and requirements) and testing.

>The report's recommendations seem generally applicable to a large
>number of systems engineering projects with a software component.

I have been working in the European space industry for 9 years now,
and, hopefully with no disrespect to my peers, I am convinced that
there is far too little analysis of requirements performed. Around 3
years ago I took over a job that had been running for ~1.5 years, and
had produced development model software. Shortly after that I was
involved in redesigning the software in Ada (originally in C) for a
different processor. When it actually came down to finding out what
was really required, we spent months in discussions with our customer
because they really had no idea what they wanted, and had provided us
with what can only be described as a very poor requirement
specification. The problem was that this interaction with the customer
had never before taken place despite how far the software development
had gone. Even now there is the odd bit where what we are doing is
incompatible with their requirements (but that is mainly because they
changed one end of a timing requirement on an interface without
bothering to change the other end!).

I am convinced that with more effort in that area we are likely to see
a great improvement in the quality and reliability of software in
spaceborne equipment.

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