Re: Interresting thread in comp.lang.eiffel

["Ken Garlington" <Ken.Garlington@computer.org>]

"Joachim Durchholz" <joachim dot durchholz@halstenbach.com> wrote in message
news:8kl25k$2q7k0$1@ID-9852.news.cis.dfn.de...
> Ken Garlington <Ken.Garlington@computer.org> wrote:
> > "Joachim Durchholz" <joachim dot durchholz@halstenbach.com> 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.