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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c617ae447ca32f2f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-04-11 05:28:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!195.238.2.15!skynet.be!skynet.be!transit.news.xs4all.nl!xs3.xs4all.nl!fdebruin From: fdebruin@xs3.xs4all.nl (fdebruin) Newsgroups: comp.lang.ada Subject: Re: Ariane Failure Date: 11 Apr 2002 12:12:16 GMT Organization: XS4ALL Internet BV Message-ID: References: <3CA50E9A.CBF24F1B@lanl.gov> <3CB3031A.26E08904@gbr.msd.ray.com> <3CB435A4.8A011DF1@gbr.msd.ray.com> NNTP-Posting-Host: xs3.xs4all.nl X-Trace: news1.xs4all.nl 1018527136 1390 194.109.6.44 (11 Apr 2002 12:12:16 GMT) X-Complaints-To: abuse@xs4all.nl NNTP-Posting-Date: 11 Apr 2002 12:12:16 GMT X-Newsreader: NN version 6.5.6 (NOV) Xref: archiver1.google.com comp.lang.ada:22355 Date: 2002-04-11T12:12:16+00:00 List-Id: Steve O'Neill writes: >John Roth wrote: >> >> "Steve O'Neill" wrote in message >> > And here was another of the fatal system design flaws that should never >> > have been made... it seems that this 'other channel' was an *identical* >> > system which, of course, reacted in the same manner. Leaving the poor >> > flight control computer with no valid data. Ooops! >> >> Not exactly. The assumption was that failures would be hardware, >> so dual coding the software wasn't an objective. >Well, no matter where you assume the failures will or will not occur you >should never design a dual-redundant system where both strings are >identical. The strings were not identical because they were using physically different hardware components. You could argue that the strings should have no commonalities at at all for maximum safety and robustness. This will only work if you have endless resources in terms of money and time. For example, in the case of Ariane 501 the IRS software in the two units could have been developed indepently by two different companies. Maybe the problem would have occurred in only one of them. This will immediately raise the issue of deciding which software is roviding you the correct data, in case they differ. This will lead to some kind of arbitrator (a new single point of failure) or a third software package to allow majority voting. You will easily tripple the cost of your software. In addition, I am not convinced that the added robustness makes up for the added complexity. Furthemore, you are still not fully covered because your software specification might contain an error that will be common to all indepently developed software. Redundancy is a vital concept but it is not *the* solution, it is just contributing to it. It all boils down to a tradeoff. To the extreme: the costs of your redunancy should not be higher than the recurrent costs for building a new launcher. Frank de Bruin