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.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Interresting thread in comp.lang.eiffel Date: 2000/07/14 Message-ID: #1/1 X-Deja-AN: 646167837 References: <8ipvnj$inc$1@wanadoo.fr> <8j67p8$afd$1@nnrp1.deja.com> <395886DA.CCE008D2@deepthought.com.au> <3958B07B.18A5BB8C@acm.com> <395A0ECA.940560D1@acm.com> <8jd4bb$na7$1@toralf.uib.no> <8jfabb$1d8$1@nnrp1.deja.com> <8jhq0m$30u5$1@toralf.uib.no> <8jt4j7$19hpk$1@ID-9852.news.cis.dfn.de> <3963CDDE.3E8FB644@earthlink.net> <8k5alv$1oogm$1@ID-9852.news.cis.dfn.de> <8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 963544054 216.215.65.127 (Thu, 13 Jul 2000 22:07:34 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Thu, 13 Jul 2000 22:07:34 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-07-14T00:00:00+00:00 List-Id: "Joachim Durchholz" wrote in message news:8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de... > Ken Garlington wrote: > > "Joachim Durchholz" wrote: > > > In other words: had DbC been applied not only to the software but > also > > > the the software-IRS interface, > > > > What do you mean by a software-IRS interface? > > The IRS is a piece of hardware from the point of view of the main > controlling software of the Ariane, right? If by "main controlling software" you mean the software in the On-Board Computer (the flight control computer, in my parlance), the IRS is a bit stream coming over a bus. If you're talking about the OBC detecting the invalid data that happened as a consequence of both IRSs going off-line, here are the likely contracts and their weaknesses: 1. Range check - As I note in my paper, this is typically a poor type of check for bus related data if the data is scaled. In other words, all possible bit patterns are in range. 2. Delta check - You can look to see if the value changes within a small time period at a much faster rate than physically possible. Sometimes works, but is prone to false alarms and is only valid in a statistical sense (a failure can easily generate a value that passes a delta check). 2. Redundant data comparison - The data from the active SRI could be compared with the hot standby SRI. If the data was different, you'd know there was a problem. This works well to isolate hardware errors (since two like devices rarely fail simultaneously, at least that's the usual assumption). However, if there's a common-mode failure (like in this case, with software), the data is wrong from both sources and this kind of contract can easily fail. 3. Comparison with unlike data source: We do this with fighter aircraft by doing sanity checks of IRS data with information derived from air data sensors, for example. Air data sensors aren't quite as feasible with rockets, however (something to do with vacuum :). In addition, of course, you get to pay for the extra hardware. 4. Comparison with internal model: You can write a predictive model that generates a rough estimate of the correct value, and use that as a sanity check of the input over time. It sorta works for mechanical devices such as actuators; I've never seen something like that work for an inertial system. The right answer, of course, would be for the SRI to set a bit saying it was off-line. Why this wasn't part of the spec, I don't know, unless they thought it was useless (see below). This wouldn't require a contract to use. So, unless you post a _real example_ of how a contact would have helped in this case, I remain skeptical. Of course, this may be a moot point. If you're going to wait to detect the error when it reaches the OBC, you've still got a problem. Now that the OBC knows it is receiving no data regarding the actual course of the rocket, what does it do? A slightly-inaccurate, but potentially illuminating example is: Suppose you're driving your car in rush-hour traffic, and someone suddenly throws black paint on the windshield, and all the windows. Putting aside such obvious fixes as breaking or rolling down a window (in other words, using an alternate sensor), what do you do? You could jam on the brakes (which a rocket or airplane can't do, unfortunately), or you could take your last known information and try to guess how to turn the wheel so that you get to the shoulder safely (what I usually call standby gains). I don't know how successful that is with a rocket; it works OK with an airplane, but it's a much more benign environment.