From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5ac12f5a60b1bfe X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,5ac12f5a60b1bfe X-Google-Attributes: gidf43e6,public From: john@assen.demon.co.uk (John McCabe) Subject: Re: Ariane 5 - not an exception? Date: 1996/07/30 Message-ID: <838749361.12233.0@assen.demon.co.uk>#1/1 X-Deja-AN: 171063787 x-nntp-posting-host: assen.demon.co.uk references: <4tb8vv$bna@zeus.orl.mmc.com> <838637917snz@nezumi.demon.co.uk> newsgroups: comp.software-eng,comp.lang.ada Date: 1996-07-30T00:00:00+00:00 List-Id: Martin Tom Brown 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