Re: *LONG* DRAFT - Critique of "The lessons of Ariane"

[Ken Garlington <kennieg@flash.net>]

Phlip C Plumlee wrote:
> 
> My essay is the only one I have read so far that ignores DBC and testing
> issues. It proposes a much simpler software design goal that might have
> prevented the crash and made DBC a moot point. Please take the time to
> read it, and you'll see what I mean.
> 
>   --  Phlip
> ====== http://users.deltanet.com/~tegan/home.html ======

Here's why the typecast occured:

Inside the IRS, many of the calculations need to be done at a fairly
high precision. Lower precision calculations cause the "drift" rate
(the rate at which the IRS measurements start to disagree with the
"real" system state) to be unacceptably large.

However, some of the users (and Flight Controls is typically in this
group) don't need all of that precision. So, the high-precision floating
point value is converted to a fixed-point value for transmission
purposes.

Why not just send the extra precision as a floating-point value
anyway? There are several potential reasons; here are a few common
ones...

1. Floating-point formats vary between processor types. For example,
the MIL-STD-1750 processor (very popular for spaceborne operations,
because of its ability to withstand adverse effects from solar
radiation) does not use the IEEE format popular with other types of
processors. Converting between the two formats is time-consuming
and error-prone. The only real problem with integer formats is
little-endian-ness.

2. Certain devices (microsequencers,  digital-to-analog converters)
don't support ANY type of floating-point format. In these cases,
you have to comply with the interface to these devices. (Your
note about "We are not talking about 4-bit Zilog chips here" is
interesting, because in fact we still have operational systems
using 4-bit and 8-bit Zilogs! Generally, high-speed CPUs are
different to use in airborne control systems due to power
utilization, thermal properties, board space, weight requirements,
cost, rad-hardness, and design maturity.)

3. For busses organized around 16-word message groups (such as the
MIL-STD-1553), there can be a problem sending values that don't
fit in a single word. Some hardware devices that deal with these
protocols can permit the software to read one word that was sent
in the current message block, and another word that was sent in
the previous message block. If this were to happen in the middle
of a floating-point value, then the value would be invalid. There
are several ways to avoid this, but keeping values limited to
a single word helps.

Usually, most of the typecasting in these systems is at the I/O
boundary, to match the interface of some other piece of equipment.
Scaling is a common requirement for that interface. Believe me,
no one does scaling for the fun of it! However, there are ways
to avoid the potential for an exception, such as saturation
arithmetic. Unfortunately, without explicit hardware support,
saturation arithmetic can add time. When a large amount of I/O
is being processed, this time can be significant. So, it is not
unusual to do what the Ariane 5 team did: analyze the system to
try to apply protection only where needed. Unfortunately, their
analysis was unable to take into account the future reuse, and
the system was not re-analyzed (or re-tested!) for the new
environment.