Re: Boeing and Dreamliner

[Richard Riehle <richard@adaworks.com>]

Hyman Rosen wrote:

> Alexander Kopilovitch wrote:
> > This is a correct sentense, it conveys truth, but in such a way that you can't
> > dissect it or extract contiguous part of it without converting the truth to a
> > lie. Actually, the SRI software code for Ariane 4 was *perfectly good for
> > Ariane 4*, although it quite probably was not so good in general -- so your
> > sentense "It was not perfectly good code." is probably true also.
>
> The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.
> They wrote code that took advantage of limited input range, and sent it out
> into the world with insufficient protection against the future. It was
> perfectly good in the same way as two digit years.

A key difference between designing in Ada and  many other languages
is the use of problem-space constraints.   For example, a designer might
declare an integer type such as,

                   type Number is range 12..451;

if the problem under consideration called for that kind of constraint.  If,
at some later time, I decide to use the solution bounded by that constraint
to solve a problem that requires a different set of constraints, I will have
made a mistake.   The mistake, in that case, is mine, not that of the previous
designers.

What we often encourage, for Ada designs, is that the algorithmic details
be independent of some particular set of constraints.   Generic components
are sometimes useful for this.  For example,

                   generic
                       type Num is range <>;
                   function Compute(Data : Num) return Num;

where the internal algorithmic construct will behave exactly the
same way on every instantiation of Compute after associating the
generic formal parameter with a generic actual parameter.

Putting aside the option of designing with generics, since many in the
safety-critical community distrust this language feature,  the issue of
specifying constraints that precisely map the solution-space to the
problem-space continues to be a useful feature of the language.  If
I accept this constraint during development, many potential problems
will be identified early in my process.

If, on the other hand, I choose to bypass the language safeguards and
use  unchecked features of the language,  I am putting my entire design
at risk.   This is one aspect of the Ariane 4 software that contributed
to the Ariane 5 event.   The developers of the Ariane 4 software took
the trouble to ensure that the unchecked operations were appropriate.
The engineers on Ariane 5, many of who were the same people from
Ariane 4, failed to evaluate the potential consequences of those same
unchecked operations.

Is this a failure of the language.  One might suggest that the option of
unchecked operations in Ada is a language problem.  However, we
must also recognize that the language clearly specifies that unchecked
operations are "unchecked" by the compiler.   In most languages, such
unchecked operations are the default, not an option.   For  example, in
the C family of languages, automatic type promotions rarely present
any kind of warning to the programmer.   In Ada, the programmer must
bypass the normal rules of the language to achieve the same result.

So, the software design for Ariane 4 was exactly right for Ariane 4. It
was not designed for some future system.   To suggest that this is the
equivalent of Y2K is interesting.  It re-raises some issues related to the
original subject of this thread, that of the Boeing 7E7 and Boeing 777.
And those issues directly support the folly of even thinking about using
C++ for this aircraft.  They also indicate where caution should be the
watchword when transitioning 777 software to the 7E7.

As I indicated in an earlier posting, I am confident the Boeing engineers
will understand the lessons of Ariane 4/5 when re-using Ada code from
the 777 on the 7E7.  I am also confident that, pressures from resume-builders
notwithstanding, they will realize the value of using contemporary Ada,
with its excellent record for software safety, instead of a language so
characterized by unpredictability that they could never be sure that some
undetected behavior might manifest itself long after even the best of
testing has been completed.

Richard Riehle