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-Thread: 103376,7e8cebf09cf80560 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!weretis.net!feeder5.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.ada Subject: Re: How would Ariane 5 have behaved if overflow checking were notturned off? Date: Sat, 19 Mar 2011 10:55:40 -0700 Organization: None to speak of Message-ID: References: <4d80b13f$0$43832$c30e37c6@exi-reader.telstra.net> <4d8200ce$0$43837$c30e37c6@exi-reader.telstra.net> <4d820f84$0$6990$9b4e6d93@newsspool4.arcor-online.net> <4d835402$0$43840$c30e37c6@exi-reader.telstra.net> <4d8356e0$0$5764$882e7ee2@usenet-news.net> <05ec46e3-cc9c-406e-b4c9-3c1392726436@v31g2000vbs.googlegroups.com> <1nc34bs4fccnm.zkmhfmyk46ep$.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx01.eternal-september.org; posting-host="mytEQcPL+ceHcrnNa7VoaQ"; logging-data="11816"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/y0LtYbPfaSZnp/mKQXcs7" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:zs4nYUwiLOxJHsKUCd99AZ415+0= sha1:+KS0YLovC8/cU3bk5WfbOdV/5lk= Xref: g2news2.google.com comp.lang.ada:19290 Date: 2011-03-19T10:55:40-07:00 List-Id: "Dmitry A. Kazakov" writes: > On Fri, 18 Mar 2011 09:49:17 -0700 (PDT), KK6GM wrote: >> However, (and this is >> the case you and robin have been arguing, while ignoring the existence >> of the redundant hardware in the first place), the last control system >> in the chain (the 2nd one in this case) should obviously never shut >> down, but should fall back to a limp-along mode, which of course may >> or may not be good enough for the mission to succeed. > > I disagree. In the case of unrecoverable hardware malfunction you should > bring the system into a safe state and if there is no one to a least > damaging state. > > For an unmanned rocket self-destruction is likely such a procedure, because > you don't want it falling upon your head. That's a good point. For an unmanned rocket, blowing it up is not the worst-case outcome, to be avoided at all costs. The worst-case outcome is the rocket continuing to operate and crashing, intact and almost fully fuelled, into a populated area. If the software detects a condition that can only occur due to hardware failure (as determined by engineering analysis), attempting to continue operating with inaccurate information (say by storing 32767 rather than 33000 in a 16-bit signed integer) could conceivably lead to a worst-case outcome. (Imagine everything continuing to operate except the self-destruct mechanism.) Blowing up the rocket could be the safest course of action at that point. If the condition in question had shown up on the Ariane 4, it probably *would* have indicated a hardware failure. The real cause of the problem, of course, was taking software that works correctly on the Ariane 4 and running it on the Ariane 5 without modification. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"