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,CP1252 X-Google-Thread: 103376,f039470e8f537101 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-07-23 15:58:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F1F12FB.2060901@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ariane5 FAQ References: <1058799152.775376@master.nyc.kbcfp.com> <1058810510.375902@master.nyc.kbcfp.com> <1058813341.841940@master.nyc.kbcfp.com> <1058816605.566685@master.nyc.kbcfp.com> <1058969472.350716@master.nyc.kbcfp.com> <1058982513.114816@master.nyc.kbcfp.com> <3F1ED712.2070405@attbi.com> <1058991539.971642@master.nyc.kbcfp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 66.31.71.243 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1059001085 66.31.71.243 (Wed, 23 Jul 2003 22:58:05 GMT) NNTP-Posting-Date: Wed, 23 Jul 2003 22:58:05 GMT Organization: Comcast Online Date: Wed, 23 Jul 2003 22:58:05 GMT Xref: archiver1.google.com comp.lang.ada:40735 Date: 2003-07-23T22:58:05+00:00 List-Id: Hyman Rosen wrote: >> As I said, this was not arbitrary behavior, it was required behavior. > > > *What* was required behavior? You have a piece of code that says > integer_BH = convert(float_BH) > The analysis and specification of the Ariane 4 gave a physical > upper limit to float_BH, and the code was written in the "don't > care" way - if for some reason float_BH does exceed the limit, > let the code go ahead and do whatever the consequences of > violating that limit imply. If float_BH is larger than the limit > but smaller than the overflow value, the code keeps going, > possibly failing at a later point or possibly not causing any > harm. If float_BH is larget than the overflow value, the > machine generates an operand fault. No, if the value to be assigned to BH is out of range (presumed to happen with the rocket on the ground, shut down THIS SRI and report the (presumed hardware) error and diagnostics via the only channel the SRI has for talking to the main computer. Remember this software ran for hours before launch and a few seconds after, and bad alignment data, for whatever reason, if detected before launch will have the effect of delaying the launch while the system engineers look at that diagnostic information to find out where the problem is. This must be what is confusing you. There are hundreds of opportunities for the SRI to detect hardware failures, loose wires, or whatever before launch. The special circumstances here were that this piece of "pre-launch" software ran for about 40 seconds after launch. For the Ariane 5, that was 40 seconds too long, and for Ariane 501, a 30 or 35 second limit would have averted the disaster--but the right limit was zero seconds. On Ariane 4 there were several times where this behavior (shutting down and supplying diagnostics) prevented launching with bad hardware, and one time where the feature of running after main engine ignition was needed. Detecting hardware faults before launch is not "don't care" it is very important. I won't go into the calculations, but reducing the time between when all hardware is "known good" and the time it is used increases the probability of a successful launch from microscopic to over 90%. All that hardware testing and checking just before launch is important. > There's nothing wrong with having code like that if the > situation warrants it, which was the case in Ariane 4, where > they were trying to save the machine cycles that a limit > check would have cost. It's just that this kind of code is > brittle, so these dependencies on the state of external > data need to be made very clear, otherwise future reuse > attempts will stumble. That whole discussion of "protecting" the value of BH is really a red herring in the Ariane 5 case. In the Ariane 4, if they had put in the "protection" what it would have done was to check whether or not this was a "critical" failure. Guess what? The answer was yes. If one of the computers has faulty accelerometer or gyro data? Shift to the backup. If both computers have bad input data that early in the flight? The conclusion would be that the mission will fail. Late in the boost phase, the SRI might try to do "dead reckoning" for the last few seconds of burn. But you have to understand this part of the discussion of the seven unprotected conversions of which four were changed to protected. The point is not "oops we missed this one." It is that very careful consideration was given by reviews at several levels in the context of the Ariane 4, and the conclusion was that for this failure, this was the right answer. It wasn't accidental, or "don't care." It was if you see this value something is bad wrong, and maybe it can be figured out from a data dump. Obviously if the same engineers had the Ariane 5 trajectory data, they WOULD have reached a different conclusion: exception when others => if Ariane_Model = 4 then raise; else null; end if; or more likely to insure that the alignment software shut down at T=+40 on the Ariane 4, and at T=0, or maybe even T=-3 on the Ariane 5. -- Robert I. Eachus �In an ally, considerations of house, clan, planet, race are insignificant beside two prime questions, which are: 1. Can he shoot? 2. Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and Steve Miller.