ARIANE-5 Failure

ARIANE-5 Failure

[John McCabe]

I have heard that the failure of the Ariane 5 rocket's first launch on
Tuesday was caused by a software fault in the attitude control system.


Does anyone know whether Ada was used on that system, and if so, who
designed and built the software, and which compiler and target were
used.

Thanks in advance for any information you might have.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: ARIANE-5 Failure

[Tronche Ch. le pitre]

John McCabe wrote:
> 
> I have heard that the failure of the Ariane 5 rocket's first launch on
> Tuesday was caused by a software fault in the attitude control system.

French media have presented several successive explanations but always
invoking software failure.
 
> Does anyone know whether Ada was used on that system, and if so, who
> designed and built the software, and which compiler and target were
> used.

Sad to say, but the software is entirely written in Ada, with a few
parts in assembler. It has been described by Jean-Noel Montfort and
Vinh Qui Ribal, from Aerospatiale, in the 2nd Eurospace-Ada in Europe
conf. (1995). Quoted from their paper, the computer boards are Motorola
68020/68881 with 512 kb of RAM, and the Alsys compiler. The software
has been designed using the HOOD methodology.


The launch was broadcast on TV. The greatest time (if I can say that)
was just before the rocket was destroyed. After 40 seconds or so of a
nice launch, it became obvious that it was on a bad trajectory.
Then someone say (the operational director or a journalist, I
don't know) "trajectory and all flying parameters are okay", and just
then BOOOM, someone had noticed that parameters weren't OK at all
and made the rocket exploded...

It would have been very nice if everything had worked well, but
frankly, you take a big risk when you change something on a rocket,
and everything was new on this one, from the engine to the computers.
Thus I'm not surprised. I don't think one has never see number 1 of
any rocket succeeded in the aerospace industry history.


-- 
+--------------------------+------------------------------------+
|                          |                                    |
|    Christophe TRONCHE    |    E-mail : tronche@lri.fr         |
|                          |                                    |
|        +-=-+-=-+         |    Phone  : 33 - 1 - 69 41 66 25   |
|                          |    Fax    : 33 - 1 - 69 41 65 86   |
+--------------------------+------------------------------------+
|      ######      **                                           |
|     ##     #         Laboratoire de Recherche en Informatique |
|    ##       #   ##   Batiment 490                             |
|   ##       #   ##    Universite de Paris-Sud                  |
|  ##    ####   ##     91405 ORSAY CEDEX                        |
| ######    ## ##      FRANCE                                   |
|######      ###                                                |
+---------------------------------------------------------------+

Re: ARIANE-5 Failure

[Bert Peers]

>Sad to say, but the software is entirely written in Ada, 

 Particularly unfortunate since the moment I saw the news about
the software cause on TV I immediately cheered "Should have used
Ada !!!" 

 ! :(


Cya, Bert                               -=<www.cs.kuleuven.ac.be/~peers>=-
[ You know you're in CGI too long when... you think "ota" is Japanese for "story"  ]
OPGELET: Deze Email negeert de nieuwe spelling.  (Mogelijks ook de oude).

Re: ARIANE-5 Failure

[David Weller]

In article <31B7A88D.446B@lri.fr>, Tronche Ch. le pitre <tronche@lri.fr> wrote:
>Thus I'm not surprised. I don't think one has never see number 1 of
>any rocket succeeded in the aerospace industry history.
>

The "Delta Clipper" has done very well so far, with no disastrous
failures.  Most of the software, by the way, is written in Ada
(automatically generated, so it is claimed, from the MatrixX software
application)


-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: ARIANE-5 Failure

[Ken Garlington]

David Weller wrote:
> 
> The "Delta Clipper" has done very well so far, with no disastrous
> failures.

Didn't DC-X have a pad fire?
-- 
LMTAS - "Our Brand Means Quality"

Re: ARIANE-5 Failure

[Samuel Mize]

In article <31B84662.7930@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>David Weller wrote:
>> 
>> The "Delta Clipper" has done very well so far, with no disastrous
>> failures.
>
>Didn't DC-X have a pad fire?

As I recall from Aviation Leak, venting hydrogen built up under the
"skirt" around the engines.  I *think* it happened in flight, and
they landed it.  It may have been on the ground.

The working components were intact, and I believe it was flyable, but
they (sensibly) were going to check it over and replace the blown-out
skin panels before flying it again.

So, (1) it's a judgement call whether that was a "disastrous" failure,
and (2) it wasn't a software failure anyway.

But yes, they did have a fire.

Samuel Mize

Re: ARIANE-5 Failure (DC-X works)

[Eugene W.P. Bingue]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]


In <4pd540$rl2@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel
Mize) writes: 
>
>In article <31B84662.7930@lmtas.lmco.com>,
>Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>>David Weller wrote:
>>> 
>>> The "Delta Clipper" has done very well so far, with no disastrous
>>> failures.
>>
>>Didn't DC-X have a pad fire?
>
>As I recall from Aviation Leak, venting hydrogen built up under the
>"skirt" around the engines.  I *think* it happened in flight, and
>they landed it.  It may have been on the ground.
>
>The working components were intact, and I believe it was flyable, but
>they (sensibly) were going to check it over and replace the blown-out
>skin panels before flying it again.
>
>So, (1) it's a judgement call whether that was a "disastrous" failure,
>and (2) it wasn't a software failure anyway.
>
>But yes, they did have a fire.
>
>Samuel Mize
>
>
>
What�s the point?  The X in DC-X stands for experimental.  Experimental
vehicles have problems.  The DC-X flight control software is in Ada and
is all computer generated.  You would not want to maintain this code by
hand.
  The DC-X was flying in 18month from concept to the pad at white
sands.  This is the first craft of its type in the world.  Even after a
onboard explosion the flight control system remain stable and the
flight controller
 was able to land the DC-X.  That the point!  The system works.

Mahalo
Eugene

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

Eugene says

"vehicles have problems.  The DC-X flight control software is in Ada and
is all computer generated.  You would not want to maintain this code by
hand."

Sounds bogus, ultimately the code is maintained by humans, we do not yet
have robots that can write and maintain code. Sure the code may be in
some other language than Ada and then generate Ada (if the Ada is not
maintained, but is just used as an intermediate language, it is 
essentially irrelevant that it is Ada). So the question is: what
language WAS the software written in? And what is the argument that
this code is easier to maintain than properly written Ada?

I am always running into the vague notion that someone program generators
and CASE tools eliminate programming completely. All too often what is
really happening is that the code is being written in some poorly designed
and poorly defined and poorly maintained language.

Re: ARIANE-5 Failure (DC-X works)

[Samuel Mize]

In article <dewar.834287759@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Eugene says
>
>"vehicles have problems.  The DC-X flight control software is in Ada and
>is all computer generated.  You would not want to maintain this code by
>hand."
>
>Sounds bogus, ultimately the code is maintained by humans, we do not yet
>have robots that can write and maintain code. Sure the code may be in
>some other language than Ada and then generate Ada (if the Ada is not
>maintained, but is just used as an intermediate language, it is 
>essentially irrelevant that it is Ada). So the question is: what
>language WAS the software written in? And what is the argument that
>this code is easier to maintain than properly written Ada?

Other posts have said the code was generated with MatrixX.  I haven't
used MatrixX, but others at my company have, so I'll try to describe it.

MatrixX isn't a language.

It's a tool that uses a graphical notation, including some standard
graphical notation for math.  You can think of it as a 4GL for
scientific calculation.

Its application area is limited, but within that area, its graphic
notation is closer to what a mathematician would use, so a domain
expert can work with it and validate it more easily.

I'm sure a MatrixX marketeer would plotz at this definition, but it
lets you see why it's easier (in this case) to maintain than properly
written Ada.  The maintainers aren't programmers, and they aren't
maintaining the program.  They're maintaining their mathematical
specifications.  The tool regenerates the program to match new specs.
Nobody maintains (this part of) the program.

>I am always running into the vague notion that someone program generators
>and CASE tools eliminate programming completely. All too often what is
>really happening is that the code is being written in some poorly designed
>and poorly defined and poorly maintained language.

No argument there.  However, MatrixX seems to be a fairly solid tool
for its appropriate application areas.  I say this from outside
observation, not from personal experience.  Your mileage with it may
vary; your particular car may not even start with it.

But since Ada is a general language, there will always be tools that
are easier for specific, limited application domains.

Samuel Mize

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

Samuel says

"Other posts have said the code was generated with MatrixX.  I haven't
used MatrixX, but others at my company have, so I'll try to describe it.

MatrixX isn't a language.

It's a tool that uses a graphical notation, including some standard
graphical notation for math.  You can think of it as a 4GL for
scientific calculation."

Of course it is a language, any notation is a language. Yes, it is reasonable
to think of it as a 4GL for scientific calculation. What do you think the
L in 4GL stands for.

The people writing this *are* programmers, they are programming. There is
no difference between a program and an executable specification. In fact
that's all a program is -- a specification of what needs to be done with
a method for automatic translation into a machine that does the task.

And if the people who write the MatrixX code don't maintain it, who does?

Samuel's post is a perfect companion to mine, because it shows how 
widespread the confusion is about the use of high level programming
tools.

In particular, people often thing the Ada mandate is being obeyed if the
generated code from such a tool is Ada. In fact if this generated code
is not maintained or looked at, there is absolutely no reason for it
to be in Ada, and no particular advantage in it being in Ada. The
policy of using Ada applies to the INPUT, not the OUTPUT of the programming
effort, so in this particular case, if the Ada policy applies, a waiver is
needed to program part of the aplication in MatrixX instead of in Ada.

Assuming that MatrixX is being appropriately used, and the application 
really is taking advantage of the leverage that can be obtained from the
use of such high level tools, and that the tool itself meets requirements
for reliability and maintainability, then this is undoubtedly a clear case
for a waiver.

The trouble is that the assumption tends to be that the mere fact that
something is written in a 4GL means that these criteria are met, when
the reality is that a lot of 4GL code is low level junk written in
totally inappropriate, ill-though out languages.

The use of very high level languages is a very important advance in
proramming technology, one that has been very slow in coming, but the
notion that somehow this eliminates the need for programming of
programmers is absurd and likely to lead to bad decisions.

Lambert Meertens once introduced the notion of VHLANOS, "very high
level abstract non-operational specifications", and pointed out that
one of the ways in which programming progresses is that yesterdays
VHLANOS becomes today's progrmming language.

For example, in the days of machine language programing, a simple 
algebraic expression like (a * b) + (c * d) seems like VHLANOS, but
when Fortran came along, it became programming. The rhetoric about
not needing programmers or programming any more was common as Fortran
was introduced -- at last we don't need to rely on programmers (where
the image of programming is messing with machine language), now our
scientists can do the job themselve without programming).

Yes of course, the people programming in MatrixX are not Ada programmers,
and are operating at a different level of abstraction, but they are still
programming! To describe it otherwise is confusing and damaging.

Re: ARIANE-5 Failure (DC-X works)

[Samuel Mize]

** I have extracted and rearranged some of Mr. Dewar's paragraphs **
** to fit my response.                                            **

In article <dewar.834410609@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Samuel says
>
>MatrixX isn't a language.
>
>It's a tool that uses a graphical notation, including some standard
>graphical notation for math.  You can think of it as a 4GL for
>scientific calculation."
>
>Of course it is a language, any notation is a language.

OK, get happy.  I should have said that it isn't a general-purpose
programming language.

Strictly speaking, MatrixX isn't a language, it RUNS the language.

>The people writing this *are* programmers, they are programming.

I'll concede this point for the DC-X.  It's irrelevant to my point
whether we say that MatrixX generates a program from a math notation,
or wheter we say that writing the math notation is programming.

It's relevant to your point, which I'll address below.

My point was just to describe the flavor of MatrixX.  Using MatrixX
is more alien to programming in a third-generation language than
using Ada is to programming in Assembly.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>The use of very high level languages is a very important advance in
>proramming technology, one that has been very slow in coming, but the
>notion that somehow this eliminates the need for programming of
>programmers is absurd and likely to lead to bad decisions.
>...The rhetoric about
>not needing programmers or programming any more was common as Fortran
>was introduced

And was equally stupid at the time.  I agree with you.

MatrixX does not obviate programmers or programming.

In a limited domain, it can generate a program from a description of a
desired result -- a description that I wouldn't consider a program, and
that perhaps you would (see next point).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>The people writing this *are* programmers, they are programming. There is
>no difference between a program and an executable specification. In fact
>that's all a program is -- a specification of what needs to be done with
>a method for automatic translation into a machine that does the task.

Your definition misses a subtle distinction.  I can't define it
formally.  I think most of us view programmers as people who tell a
system HOW to do something.  The MatrixX user identifies WHAT to
compute, but not HOW.

This distinction is a lot clearer in word-processing.  Computer-based
word processing was once a form of programming.  Remember nroff/troff?
You had statements to change margins, turn bold text on/off, etc.
I don't think anyone would say that using MacWrite is programming,
but you're certainly entering a specification of what needs to be done
-- in this case, what needs to be printed -- and giving it to a
"compiler" to translate it into a machine (program+hardware+data)
that does the task.  In fact, on the typical Mac, it translates this
user "language" into a postscript program, to be run on the LaserWriter.

You can call that programming, but it isn't a useful definition, and
it isn't the way most people define programming.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>And if the people who write the MatrixX code don't maintain it, who does?

The people who write the MatrixX (math specifications) maintain them.
They just don't maintain the generated Ada.  They regenerate it as needed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>In fact if this generated code
>is not maintained or looked at, there is absolutely no reason for it
>to be in Ada, and no particular advantage in it being in Ada.

UNLESS your generated code will be integrated into a larger system, and
the larger system is written in Ada.  (As we're doing where I work.)  In
this case, it's easier to combine everything if it's all Ada, and the Ada
can be used on several platforms without modification.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>In particular, people often thing the Ada mandate is being obeyed if the
>generated code from such a tool is Ada.

I don't recall anyone saying that DC-X used MatrixX due to the Mandate.

I agree that such an attitude is stupid.  I would never suggest using
MatrixX just to stay within the Mandate.

Depending on what you're doing with it, I'd argue that a code-generator
requires a waiver, even if it spits out Ada

If you want to start a discussion about idiotic code generator ideas,
you will find me on your side.  I'm thinking in particular of some of
the "AI in Ada" presentations I've seen, where an expert system engine
is built in Ada, then the expert system is coded in the expert system
engine's source language.  They claim they're doing AI work in Ada.  Feh.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>The trouble is that the assumption tends to be that the mere fact that
>something is written in a 4GL means that these criteria are met, when
>the reality is that a lot of 4GL code is low level junk written in
>totally inappropriate, ill-though out languages.

I feel this is an inappropriate statement in this thread, unless you
have some evidence that the use of MatrixX in the DC-X program is one
of those cases.

It's as if we were specifically discussing Ada, and someone said that
the problem with most third-generation languages is that they don't
including tasking and strong typing.

Please start a new thread on this topic, so I can agree with you.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Samuel Mize

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

Samuel said

"Your definition misses a subtle distinction.  I can't define it
formally.  I think most of us view programmers as people who tell a
system HOW to do something.  The MatrixX user identifies WHAT to
compute, but not HOW."

The reason you cannot define this discinction formally is that it is
a meaningless one. That was the whole point of Lambert's point about
VHLANOS. One person's program is another persons abstract specification.

If I write:

  A := B * C + D * E;

that is (with minor notational differences) just a description of WHAT
should be done (compute a formula and put the result in A), not HOW
it should be done (i.e. I don't care about what instructions or
registers are used).

Sure the use of very high level languages like MatrixX raises this
to a higher level of abstraction, but you still cannot make any
meaningful discinction.

Now there are some related issues, e.g. whether you write in a procedural
style, but non-procedural languages have been around for at least 30
years (e.g. RPG!) and no one would claim that the use of a non-procedural
language means that you are not programming.

In Setl, if I say

  primes := { n in [2..100] | not exists d in [2 .. N - 1] | n mod d = 0};

that's essentially a mathematical definition of the set of primes from
2 to 100. If I look at it as an Ada programmer, it sure looks like a
specification and not a program, but it is in fact an executable Setl
program.

I simply don't believe you can succeed in drawing any meaningful
distinction between a program and an executable specification.

Re: ARIANE-5 Failure (DC-X works)

[David Zink]

In article <dewar.834643137@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>Samuel said
>
>"Your definition misses a subtle distinction.  I can't define it
>formally.  I think most of us view programmers as people who tell a
>system HOW to do something.  The MatrixX user identifies WHAT to
>compute, but not HOW."
>
>The reason you cannot define this discinction formally is that it is
>a meaningless one. That was the whole point of Lambert's point about
>VHLANOS. One person's program is another persons abstract specification.

I agree that only micro-code or assembly language programmers tell the
machine HOW to compute instead of just WHAT.  However I have been
wrestling with the question of how to distinguish between Pascal
Programmers and Data-Entry operators.

You see, the Data-Entry operator enters a bunch of symbols (programs
the database) so that it will print out a specific set of values
(behave in a certain way).  I compare them to Pascal programmers
because of your phrase 'executable specification'.  Pascal compilers
produce not executable code but data (P-code) which the pascal
database engine massages to generate the reports I've requested.

I next thought, "Ah, but the Pascal Programmers manipulates the data
he enters in order to produce more desirable output."  Having worked
in the financial industry for some time, I quickly remembered that this
was no different than Data-Entry.  However it does qualify the Pascal
Data-Entry crew as 'engineers', so if we label them 'Software
Engineers' instead of programmers, at least we have believable
nomenclature.

But it still leaves me wondering what a 'Programmer' is.  Obviously
those mathematicians using Matrix-X are not, as anyone can see (formal
distinctions being a bit of a joke when they cannot distinguish things
people can easily distinguish).

Your points about whether the code is delivered in ADA seem equally
meaningless.  Either ADA is a language in which a team of fools cannot
create a dysfunctional program, or it is not.  It hardly matters to
me or any thinking person whether the team of fools is biological or
cybernetic.

The only value to programming in ADA or any other high-level language
is that it allows competent programmers to significantly reduce their
accidental error rate.  Its value is not that it forces a wise choice
of algorithms, or that it forces the program specification to bear a
meaningful relation to the actual problem to be solved, though it
=can= help the program specification bear a meaningful relationship to
the program behavior.  These last issues are the proper domain of
programmers.  The first is the proper domain of tools.

If the mathematicians entered equations into a database and the
runtime code retrieved those equations and evaluated them using
validated ADA code/methods, would they be programmers or (as I
suspect) data-entry operators?  If, the (equation) data being constant
for individual runs of the program, the data was extracted from the
database and transformed into executable/compilable code, does that
transform the mathematicians into programmers?

In which case I've transformed an awful lot of data-entry operators
into programmers over the years.  I should tell them they're
underpaid.

Perhaps you see why I'm confused.

				--David

PS (a few passing thoughts):

If I were accepting machine generated code for a project of mine, I
would want awfully iron-clad proof that the code-generator's output
implemented the input.

Until we eliminate documentation and specification altogether, until
the program *is* its documentation and specification, I doubt that
we'll have reliable programs.

The main advantage of assembly language programming is that it kept
incompetent programmers from ever completing a project.  Unfortunately
the cost was that even competent programmers were hard put to avoid
subtle errors.

What I'd like is a language with no subtle errors.

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

David said:

"But it still leaves me wondering what a 'Programmer' is.  Obviously
those mathematicians using Matrix-X are not, as anyone can see (formal
distinctions being a bit of a joke when they cannot distinguish things
people can easily distinguish)."


Sorry, the mathematicians using Matrix-X are definitely programmers, just
as scientists who use Fortran to encode their equations are programmers.
I cannot distinguish any fundamental difference. You seem to think that
programming must mean writing low level code in a procedural language.
I do not consider this to be a useful distinction. 

Re: ARIANE-5 Failure (DC-X works)

[Theodore E. Dennison]

Robert Dewar wrote:
> generated code from such a tool is Ada. In fact if this generated code
> is not maintained or looked at, there is absolutely no reason for it
> to be in Ada, and no particular advantage in it being in Ada. The

I can't really fault your logic in this post, with the exception of the
above statement. Given the reams of well-nigh unreadable code generated
by tools such as a GUI builder, I'd much prefer the generation is done
into a language with safety features like array bounds checking. For me,
this is reason enough to have the code generated in Ada.

And no, this doesn't really dillute your overall argument much. Its just
a nit.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

T.E.D. said

"I can't really fault your logic in this post, with the exception of the
above statement. Given the reams of well-nigh unreadable code generated
by tools such as a GUI builder, I'd much prefer the generation is done
into a language with safety features like array bounds checking. For me,
this is reason enough to have the code generated in Ada.
"

Sure, Ted, I agree with this, there are many reasons for choosing an
intermediate language (portability, redundancy of checking etc.) and
it may well me that on the tecnical merits, Ada is a good choice.

Re: ARIANE-5 Failure (DC-X works)

[Ken Garlington]

Robert Dewar wrote:
> 
> The people writing this [MatrixX] *are* programmers, they are programming. There is
> no difference between a program and an executable specification. In fact
> that's all a program is -- a specification of what needs to be done with
> a method for automatic translation into a machine that does the task.

I can't find fault with the technical accuracy of your statement. However, when I
say "the people who use MatrixX usually aren't programmers," I mean that they
are not always acquainted with knowledge which most people would expect
software engineers to know. For example, although MatrixX permits the decomposition
of diagrams into modules, the average MatrixX user would probably not think too
much about the long-term maintenance effects of their choice of module interfaces.
Also, they usually don't consider the effects of algorithm choices on throughput
or memory. Therefore, they may not be fully equipped to make decisions about the
best language to use when generating code. This decision might -- and I emphasize
might -- make a difference in the quality of the final product, however.

> The
> policy of using Ada applies to the INPUT, not the OUTPUT of the programming
> effort, so in this particular case, if the Ada policy applies, a waiver is
> needed to program part of the aplication in MatrixX instead of in Ada.

Actually, I'm not sure I agree with this. If I deliver the output to the depot,
I don't know if I need a waiver or not. When I've asked this question in the
past, I've always been told that a waiver is not required. Could you cite
where you think the policy excludes the output from consideration? This is
pretty important, since some F-22 Ada code is auto-generated, and by your
definition I would need a waiver for all these cases!

> The use of very high level languages is a very important advance in
> proramming technology, one that has been very slow in coming, but the
> notion that somehow this eliminates the need for programming of
> programmers is absurd and likely to lead to bad decisions.

I certainly agree with this! However, if the 4GL decomposes into Ada code,
and that Ada code is delivered, I think right now the policy assumes that
no waiver is required. (Note that the policy also allows Ada to be written
by people who have no business writing programs!)

-- 
LMTAS - "Our Brand Means Quality"

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

Ken asks

"I don't know if I need a waiver or not. When I've asked this question in the
past, I've always been told that a waiver is not required. Could you cite
where you think the policy excludes the output from consideration? This is
pretty important, since some F-22 Ada code is auto-generated, and by your
definition I would need a waiver for all these cases!"

To me, the issue is quite clear. If the Ada code is delivered and will be
maintained at the Ada level, then the method used in generating it is
irrelevant, and certainly the Ada policy is complied with.

If what is delivered is the 4GL code, and Ada acts merely as an intermediate
language which will never be looked at by a person, let alone maintained,
then the program really is written in another language, and a waiver really
is required (though, if a very hgh level language is being used appropriately),
such a waiver is certainly reasonable (and in fact I may be wrong, but I think
there is some kind of blanket permission to use high level tools of the 4GL
type).

Re: ARIANE-5 Failure (DC-X works)

[Ken Garlington]

Robert Dewar wrote:
> 
> If what is delivered is the 4GL code, and Ada acts merely as an intermediate
> language which will never be looked at by a person, let alone maintained,
> then the program really is written in another language, and a waiver really
> is required (though, if a very hgh level language is being used appropriately),
> such a waiver is certainly reasonable (and in fact I may be wrong, but I think
> there is some kind of blanket permission to use high level tools of the 4GL
> type).

The current DoD policy, as I recall, says that it is preferable to use 4GLs where
Ada is not possible, although a specific waiver is still required. However, it doesn't
say anything about needing a waiver to use tools that generate Ada code, including 4GL
tools. There is no distiction drawn between writing (and maintaining) Ada code manually,
and auto-generating Ada code (and maintaining some higher-level representation of the code). 
If you can find something specific in the DoDD or DoDI set that says this, I would like to 
know.

If you're saying the Ada policy _should_ be this way, that's fine, but I find nothing that
claims it _is_ this way. Certainly, the instructions I've received as a contractor do
not require a waiver in these cases, even though our customer knows that we auto-generate
Ada code, and use it as an intermediate language, in some cases.

I've copied Joan McGarity on this question, perhaps she can give us the AJPO interpretation
of Ada policy with respect to automatically-generated Ada code.

-- 
LMTAS - "Our Brand Means Quality"

4GL code in a deliverable (was: ARIANE-5 Failure)

[Arthur Evans Jr]

In article <31C57C5B.6C63@lmtas.lmco.com>, Ken Garlington
<garlingtonke@lmtas.lmco.com> wrote:

> The current DoD policy, as I recall, says that it is preferable to use
> 4GLs where Ada is not possible, although a specific waiver is still
> required. However, it doesn't say anything about needing a waiver to
> use tools that generate Ada code, including 4GL tools. There is no
> distiction drawn between writing (and maintaining) Ada code manually,
> and auto-generating Ada code (and maintaining some higher-level
> representation of the code).  If you can find something specific in
> the DoDD or DoDI set that says this, I would like to know.
>
> If you're saying the Ada policy _should_ be this way, that's fine, but
> I find nothing that claims it _is_ this way. Certainly, the
> instructions I've received as a contractor do not require a waiver in
> these cases, even though our customer knows that we auto-generate Ada
> code, and use it as an intermediate language, in some cases.

Suggested here and in previous notes in this thread is the idea that a
contractor may without obtaining a waiver use a 4GL tool (such as
MatrixX) that generates Ada code, and then submit that Ada code as part
of its contract deliverable.  While this strategy may be legal, in my
opinion it circumvents the intent of the Ada mandate and should not be
permitted.  Why?

A major motivation for the Ada design, starting more than 20 years ago,
is to reduce the cost of software maintenance.  One of the important
motivations for the mandate is that code written in Ada with use of
proper software engineering provides important ease of maintenance.
There is (supposed to be) a clear trail from design to final code, and
_all_ _tools_ _that_ _participate_ _in_ _that_ _trail_ are delivered
with the product for use by the maintainers.

It seems fair to assume that there is a clear trail from design, through
system equations, through MatrixX code (or whatever we call it), to Ada,
to the final product.  My question, then, is this: Are both the source
code for the 4GL and the 4GL product itself delivered?  There are of
course two possibilities:

  - The 4GL source is not delivered.  In that case the maintainer has no
    recourse in modifying the code except to do so in Ada.  I think
    we'll all agree that this code is essentially unmaintainable, in the
    sense that it can be modified with the same danger present in
    modifying aswsembler code produced by a compiler.  The maintainer
    _must_ have access to the 4GL source code and the 4GL tool.

  - The 4GL code is delivered.  But in that case the contractor is
    admitting (the truth) that the algorithm was expressed in this
    notation (that is, programmed in it), even though no waiver was
    obtained permitting use of other than Ada.

Now, I fully support using a 4GL such as MatrixX where appropriate to
express complex algorithms.  My point is only that there must be an
up-front acceptance that this is happening so that the final product is
properly maintainable.  To do otherwise is to compromise Ada's laudable
goal of improved maintainability.  If current DoD policy is inconsistent
here, I suggest that the policy needs to be modified.

Art Evans

Arthur Evans Jr, PhD        Phone: 412-963-0839
Ada Consulting              FAX:   412-963-0927
461 Fairview Road
Pittsburgh PA  15238-1933
evans@evans.pgh.pa.us

Re: 4GL code in a deliverable (was: ARIANE-5 Failure)

[Ken Garlington]

Arthur Evans Jr wrote:
> 
> There is (supposed to be) a clear trail from design to final code, and
> _all_ _tools_ _that_ _participate_ _in_ _that_ _trail_ are delivered
> with the product for use by the maintainers.

This would also imply that Ada code cannot be reused, without having access
to all of the tools and databases used to create the code and associated 
documentation. Do you really believe this?

Certainly, a Government agency can require that the software engineering
environment, databases, and documentation, be delivered with a
software application, particularly if the Government agency intends to
maintain the code. To suggest that this is a consequence of current Ada
policy is, to my thinking, more than a little bizarre. Ada source code can be
delivered without the tools/databases (e.g. MatrixX) used to develop it,
just as non-Ada source code may have to be delivered with such support. This
decision should be based on the expected maintenance strategy. Similarly,
the decision to use Ada may be influenced by the expected maintenance strategy. 
However, this doesn't mean that the deliverables are based on Ada policy!

> It seems fair to assume that there is a clear trail from design, through
> system equations, through MatrixX code (or whatever we call it), to Ada,
> to the final product.  My question, then, is this: Are both the source
> code for the 4GL and the 4GL product itself delivered?

MatrixX does not have textual "source code" per se. It has a database of
information which is represented graphically. In some respects, it is similar
to tools such as Teamwork or Statemate (although MatrixX is designed for a
specific domain).

>   - The 4GL source is not delivered.  In that case the maintainer has no
>     recourse in modifying the code except to do so in Ada.  I think
>     we'll all agree that this code is essentially unmaintainable

I think I'll disagree, having seen several examples of source code generated
by auto-generation systems and later maintained manually with success.

>   - The 4GL code is delivered.  But in that case the contractor is
>     admitting (the truth) that the algorithm was expressed in this
>     notation (that is, programmed in it), even though no waiver was
>     obtained permitting use of other than Ada.

Would this "truth" also exist if the device used to generate the Ada code
from the database was a human being, rather than a machine? It seems to
me the consequence of this interpretation of Ada policy is that all requirements
and design artifacts must be generated without the use of tools, else an
Ada waiver is required!

Fortunately, Ada waiver policy is interpreted more rationally, at least by
my customer...

-- 
LMTAS - "Our Brand Means Quality"

Re: 4GL code in a deliverable (was: ARIANE-5 Failure)

[Robert Dewar]

Ken said

"
Would this "truth" also exist if the device used to generate the Ada code
from the database was a human being, rather than a machine? It seems to
me the consequence of this interpretation of Ada policy is that all requirements
and design artifacts must be generated without the use of tools, else an
Ada waiver is required!"

nonsense, no one is saying that! What is being said is that the critical
point is what level the code will be maintained at. If the code is to be
maintained at the Ada source level, then it matters not a whit how it
was developed, by humans, clever tools, or friendly martians. 

If on the other hand, the maintenance is to be done on the "original" source
code (which may of course be in the form of a database and not a text in the
normal sense -- that makes no difference), then indeed it is important to
be sure that this source code is written in an appropritae language, which
is properly supported, preferably standardized, and preferably avoids
the danger of single sourced tools.

Ken, do you really disagree with this? If so, I am surprised, and would
appreciate you making the source of your disagreement clear!

Re: 4GL code in a deliverable (was: ARIANE-5 Failure)

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken said
> 
> "
> Would this "truth" also exist if the device used to generate the Ada code
> from the database was a human being, rather than a machine? It seems to
> me the consequence of this interpretation of Ada policy is that all requirements
> and design artifacts must be generated without the use of tools, else an
> Ada waiver is required!"
> 
> nonsense, no one is saying that! What is being said is that the critical
> point is what level the code will be maintained at. If the code is to be
> maintained at the Ada source level, then it matters not a whit how it
> was developed, by humans, clever tools, or friendly martians.
> 
> If on the other hand, the maintenance is to be done on the "original" source
> code (which may of course be in the form of a database and not a text in the
> normal sense -- that makes no difference), then indeed it is important to
> be sure that this source code is written in an appropritae language, which
> is properly supported, preferably standardized, and preferably avoids
> the danger of single sourced tools.
> 
> Ken, do you really disagree with this? If so, I am surprised, and would
> appreciate you making the source of your disagreement clear!

I do not disagree that this makes sense, and that in general (never mind the 4GL
issue), that a contracting agency should ask for both the implementation of the
software, and also the data/documentation/tools associated with that software, if
the contracting agency intends to provide post-deployment support (directly or
through a third party). Such a request should be written into the contract, and in
fact, such requirements are part of many programs.

However, you raised a much narrower issue. If a code generator is used to generate
Ada source code (specifically, a code generator whose inputs are a graphical 
representation of the algorithms and interfaces a la MatrixX), does such an approach 
violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 
5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of 
creating an application, then it's an Ada application, independent of the process used 
to maintain that application. The only change introduced in 5000.2 is that, if the 
Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ 
required.

If someone can quote something from 5000.2, 3405.1, or a service policy that states 
conditions under which a software application is built from "only" Ada source code as 
part of the process, but still requires an Ada waiver, I would be interested in seeing 
this analysis. You might argue that words should be added to these directives, but in 
their current form, I think they bear out my position.

As to whether they _should_ have words about requiring Ada waivers for code 
generators, I'm ambivalent. As I said before, I agree that a system maintained at a 
"4GL" level should continue to be maintained at that level. (I also think that 
requirements databases should continue to be maintained during maintenance, for that 
matter). However, requiring extra paperwork to use innovative approaches to reduce the 
cost of generating Ada source code seems counter-productive, particularly since (a) 
the maintenance site may choose to maintain the software differently from the 
developing site, and (b) even automatically-generating Ada code can still accrue many 
of the benefits of the Ada policy, such as a common implementation notation, fewer 
tools, etc.

Note that this discussion points out a well-known (at least, I _thought_ it was a 
well-known) flaw in the Ada policy as written. Just requiring software to be written 
in Ada does not, by itself, cause fundamental improvements in depot costs. Other 
issues, such as the number of different tools required, the number of documentation 
and data formats/conventions used, etc. also have large effects. Ada policy may 
indirectly improve some of these other factors, but it has to be coupled with other 
initiatives (e.g. electronic data exchange standards) to provide large-scale returns.

-- 
LMTAS - "Our Brand Means Quality"

Re: 4GL code in a deliverable (was: ARIANE-5 Failure)

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken said
> 
> "
> Would this "truth" also exist if the device used to generate the Ada code
> from the database was a human being, rather than a machine? It seems to
> me the consequence of this interpretation of Ada policy is that all requirements
> and design artifacts must be generated without the use of tools, else an
> Ada waiver is required!"
> 
> nonsense, no one is saying that! What is being said is that the critical
> point is what level the code will be maintained at. If the code is to be
> maintained at the Ada source level, then it matters not a whit how it
> was developed, by humans, clever tools, or friendly martians.
> 
> If on the other hand, the maintenance is to be done on the "original" source
> code (which may of course be in the form of a database and not a text in the
> normal sense -- that makes no difference), then indeed it is important to
> be sure that this source code is written in an appropritae language, which
> is properly supported, preferably standardized, and preferably avoids
> the danger of single sourced tools.
> 
> Ken, do you really disagree with this? If so, I am surprised, and would
> appreciate you making the source of your disagreement clear!

I do not disagree that this makes sense, and that in general (never mind the 4GL
issue), that a contracting agency should ask for both the implementation of the
software, and also the data/documentation/tools associated with that software, if
the contracting agency intends to provide post-deployment support (directly or
through a third party). Such a request should be written into the contract, and in
fact, such requirements are part of many programs.

However, you raised a much narrower issue. If a code generator is used to generate
Ada source code (specifically, a code generator whose inputs are a graphical 
representation of the algorithms and interfaces a la MatrixX), does such an approach 
violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 
5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of 
creating an application, then it's an Ada application, independent of the process used 
to maintain that application. The only change introduced in 5000.2 is that, if the 
Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ 
required.

If someone can quote something from 5000.2, 3405.1, or a service policy that states 
conditions under which a software application is built from "only" Ada source code as 
part of the process, but still requires an Ada waiver, I would be interested in seeing 
this analysis. You might argue that words should be added to these directives, but in 
their current form, I think they bear out my position.

As to whether they _should_ have words about requiring Ada waivers for code 
generators, I'm ambivalent. As I said before, I agree that a system maintained at a 
"4GL" level should continue to be maintained at that level. (I also think that 
requirements databases should continue to be maintained during maintenance, for that 
matter). However, requiring extra paperwork to use innovative approaches to reduce the 
cost of generating Ada source code seems counter-productive, particularly since (a) 
the maintenance site may choose to maintain the software differently from the 
developing site, and (b) even automatically-generating Ada code can still accrue many 
of the benefits of the Ada policy, such as a common implementation notation, fewer 
tools, etc.

Note that this discussion points out a well-known (at least, I _thought_ it was a 
well-known) flaw in the Ada policy as written. Just requiring software to be written 
in Ada does not, by itself, cause fundamental improvements in depot costs. Other 
issues, such as the number of different tools required, the number of documentation 
and data formats/conventions used, etc. also have large effects. Ada policy may 
indirectly improve some of these other factors, but it has to be coupled with other 
initiatives (e.g. electronic data exchange standards) to provide large-scale returns.

-- 
LMTAS - "Our Brand Means Quality"

Re: ARIANE-5 Failure

[Dale Stanbrough]

Robert Dewar writes:
But it would be nice to find out, anyone on this list have a REALLY
AUTHORITATIVE first-hand source for the truth on this one (it is one
that many people "know" the answer to, but as Jim pointed out, they
disagree and can't all be right!)


Robert Eachus posted this one a few years back now. Although it doesn't
quote anyone, its level of detail lends an air of credibility. Maybe
we should ask Mr Eachus where he got his info from...

Dale

----------------------------------------------------
Subject: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?)
From: Robert I. Eachus, eachus@oddjob.mitre.org
Date: Mon, 7 Dec 1992 23:47:34 GMT

     Nice to get some facts in here.  As I remember it, there were two
bugs involving Venus probes.  One was code that assumed that an
uninitialized variable always start life equal to zero. When this code
was rerun after several months in space... The FORTRAN bug which
resulted in the destruction of the first Venus probe was that in:

     DO 20 I = 1,10
 
the comma was replaced by a period:

    DO 20 I = 1.10

of course in FORTRAN (in particular FORTRAN 66) the spaces are
ignored, and this was interpreted as:

    DO20I = 1.10

    (Implicitly declaring a real variable DO20I and assigning to it.)
This had not caused a problem on earlier launches as the loop was to
refine the amount of correction for wind, and a single repetition was
usually enough.  But when a gust hit, the inaccurate calculation
resulted in an oscillation, and the RSO destroyed the missile.

Re: ARIANE-5 Failure

[Dale Stanbrough]

Robert Dewar writes:
"Sounds bogus, ultimately the code is maintained by humans, we do not yet
 have robots that can write and maintain code. Sure the code may be in
 some other language than Ada and then generate Ada (if the Ada is not
 maintained, but is just used as an intermediate language, it is 
 essentially irrelevant that it is Ada). So the question is: what
 language WAS the software written in? And what is the argument that
 this code is easier to maintain than properly written Ada?"


I'm not sure this really answers Robert's questions. Nonetheless, here
they are...a few postings from previous years. 

I think I may have displaced David Weller as the ultimate posting hoarder! :-).

Dale
------------------------------------------------------
From: berman@umbc.edu (Mike Berman)
Newsgroups: comp.lang.ada
Subject: DC-X use of Ada
Date: 15 Sep 1993 17:45:40 -0400
Organization: University of Maryland, Baltimore County Campus


In its September 13 "Filter Center", Aviation Week and Space Technology
mentions that McDonnell Douglas developed software for guidance and
control of the DC-X Single-Stage-to_Orbit (SSTO) launch vehicle using
the MATRIXx toolset from Integrated Systems, Inc. Use of the tool saved
an estimated 50% of normal development costs and "produced very reliable
code". The article mentions that there are more than 30,000 lines of Ada
code, but does not say how much was hand crafted vs. tool generated.

A recent posting summarized the successful first flight of the DC-X test
vehicle. An Ada success story? Could be...

-- 
Mike Berman
University of Maryland, Baltimore County     Fastrak Training, Inc.
berman@umbc.edu                              (301)924-0050
       The views represented in the above post are my own.
---------------------------------------------------------------------------

Also posted... (and note info on the "explosion" later on).

Dale
---------------------------------------------------------------------------
Newsgroups: comp.lang.ada
Subject: DC-X Test Flight
Date: 8 Sep 1993 13:10:45 -0500
Organization: Washington University in Saint Louis, MO
Summary: DC-X, whose software is in Ada, flew successfully in late August


Several months ago, Jerry Pournelle started his User's Column in Byte
with a description of the DC-X and its software.  Jerry
added that he spoke with the lead of the software development team and
found that, for the first time in the team's experience, software came
in on time and schedule.  The software for DC-X (Douglas Clipper -
Experimental) was written in Ada using MatrixX.

More information on DC-X can be found in the August 30 issue of Time,
page 47.

Thought this group might be interested.

-- Rick Conn

The following is from the posting to sci.space.news on 8/28/93. 

|> DC-X Post-Flight Condition
|> 
|> The worst thing that happened to DC-X during this first flight was that one
|> side of the fiberglass nose cone was scorched.  It will have to be replaced,
|> no big deal as there are several spares.  This probably happened right after
|> engine start, when the cloud of vented hydrogen around the vehicle ignited.
|> 
|> This looked scary, but is a routine part of operating DC-X, albeit one
|> that turned out to be a bit more spectacular than planned.  Liquid hydrogen
|> is run through the engines to precool them before startup, then vented to
the
|> air, producing the vapor clouds visible before engine start in the flight
test
|> video footage.  When the engines start, unless there's a strong breeze the
|> hydrogen concentration neaby is high enough to ignite, producing a
half-second
|> fireball around the bottom of the vehicle.
|> 
|> This is how DC-X lost its McDonnell-Douglas and SDIO decals and had its
white
|> factory paint job turned to mottled gray during the test stand engine
|> firings back in May and June.  Everything below the nose cone is designed to
|> stand the heat, and of course in any spaceworthy descendant of DC-X the nose
|> cone would not be made from fiberglass, since it would have to stand up to
|> far worse heat during reentry.  
|> 
|> Outside of that, DC-X's base suffered some minor dings from bits of concrete
|> sent flying around by the rocket blast during landing.  Nothing unexpected;
|> the base was designed to stand a fair amount of this.  

------------------------------------------------------------------------------

Re: ARIANE-5 Failure (DC-X works)

[Ken Garlington]

Robert Dewar wrote:
> 
> Eugene says
> 
> "vehicles have problems.  The DC-X flight control software is in Ada and
> is all computer generated.  You would not want to maintain this code by
> hand."
> 
> Sounds bogus, ultimately the code is maintained by humans, we do not yet
> have robots that can write and maintain code. Sure the code may be in
> some other language than Ada and then generate Ada (if the Ada is not
> maintained, but is just used as an intermediate language, it is
> essentially irrelevant that it is Ada). So the question is: what
> language WAS the software written in? And what is the argument that
> this code is easier to maintain than properly written Ada?

Based on various reports, MatrixX was used to develop the DC-X flight control
laws using standard control law notation, and then the System Build module
was used to generate Ada code for the control laws. MatrixX has had the
ability to generate Ada and C code for some time.

The main reason this code could be considered easier to maintain is that,
usually, control law engineers have limited experience coding software.
So, being able to "program" with control law notation makes it easier for
them. Also, by eliminating the manual translation of the control laws to
code, there would presumably be fewer errors in the final product.

I don't know if it is fair to say that generating code in Ada vs. C is
"irrelevant" in this context, since you will still get the benefits of
strong typing, etc. when the code is compiled. On the other hand, assuming
that MatrixX eliminates some of these errors during the control law design,
perhaps this extra support is less important.

I've noticed that a lot of flight control system (and engine control
system) developers are going to this approach of auto-generating code from
the control law design. Some generate FORTRAN, some C, and some Ada. It
would be interesting to find out if there are any inherent advantages in auto-
generating in one language vs. the others.

Anyway, with respect to the Ariane 5, I'm not ready to say that this was a
software failure yet. If it is, it will be interesting to see if the language
choice was a factor in the failure.

Re: ARIANE-5 Failure (DC-X works)

[Robert Dewar]

Ken Garlington said

"I don't know if it is fair to say that generating code in Ada vs. C is
"irrelevant" in this context, since you will still get the benefits of
strong typing, etc. when the code is compiled. On the other hand, assuming
that MatrixX eliminates some of these errors during the control law design,"

Surely MatrixX cannot generate type incorrect code -- I can't see that
this comment is relevant. When generating code, many of the features that
are critical for normal programming become irrelevant or at any rate
much less important.

Re: ARIANE-5 Failure (DC-X works)

[Ken Garlington]

Robert Dewar wrote:
> 
> Surely MatrixX cannot generate type incorrect code...

You have more confidence than I do in MatrixX!

However, I was thinking more in terms of trapping invalid values at execution time.
Certainly, a user can generate a control law diagram that generates out-of-bounds
results under certain conditions. If this software is used to drive a system 
simulation, then the Ada might fail in an obvious manner (and so the error would be 
detected), while some other language might fail in a subtle way -- or not at all, 
for the particular initial conditions.

-- 
LMTAS - "Our Brand Means Quality"

4THGL code

[Warren Taylor]

As a subcontractor to Boeing on ISS (aka ISSA aka SSF), we (Orbital Sciences) 
have been mandated by Boeing to use the MatrixX (ISI) system for all of our 
deliverable software, and have been working with the system for the last 5 or 
6 years.  In our case, the generated ADA code is not the deliverable, and in 
fact we don't even CM it.  The MatrixX diagrams, along with some human coded 
Ada and a very small amount of assembler (IPL and boot code) are the "source" 
code for this system.  As far as I know, all space station software from all 
subcontractors is to be developed under this environment.  As far as the 
choice of intermediate language goes, I can only relate that MatrixX does 
sometimes produce buggy Ada code, which is usually caught by the compiler.  I 
vote for Ada as the intermediate language for this reason.  All of our I/O and 
self test code with hardware interfaces was coded in Ada, including interrupt 
handlers.  By the way, the system is very far along in testing at this point, 
and no "show stoppers" have developed in any part of the system.

Warren Taylor
Senior Principal Engineer, OSC

Automatic code generation (was ARIANE-5 Failure (DC-X works))

[Steve Vestal]

MATRIXx is one of a number of toolsets that allow feed-back control
engineers to specify both control algorithms and models of physical systems
in what some call a domain-specific language (MATLAB, BEACON, ACSL, and our
own ControlH are other examples).  Such languages are used to model plants
(e.g. aircraft) as well as specify control algorithms.  The tools typically
support simulation and mathematical analysis as well as automatic
generation of code.  I think computer scientists would catalog them as data
flow languages, although they have a precise semantics based on dynamical
systems theory (the meaning of a specification is a system of differential
or difference equations, at least until the control engineer starts
throwing in discrete event or procedural constructs :-)

There are several reasons why we think the nature of the code produced by
such tools is a consideration, and we favor generation of well-structured
code where there is good traceability between specification and code (a
principle we try to follow in our tools):

  - Some bugs first manifest themselves at the "object" code level.  For
    example, on several occasions I have been given a specification that
    was debugged in simulation (using C code generation), flipped the
    translator switch to generate Ada code for a real-time target, and
    discovered the algorithm was dividing by zero (something C seems to
    allow and Ada seems to think objectionable).  It is helpful to be able to
    read the generated code and trace bugs found at that level back to the
    originating constructs in the control specification.

  - Safety-critical software requires various certification steps,
    typically including unit testing that achieves full path coverage
    (according to a particular definition of path) on the target hardware.
    It is helpful if the generated code is broken into units as that term is
    used by the software testers, and it is helpful if localized changes in
    the control specification cause only a few units to be re-generated and
    re-unit-tested.

  - There are other kinds of domain-specific languages and generators used
    by other kinds of engineers for other purposes, e.g. generators of
    display management code.  A complex system (such as an avionics system)
    consists of many kinds of functions, only some of which are candidates
    for automatic generation from feed-back control specifications.  In
    general, automatically generated code produced by various tools will
    need to be integrated with each other, with hand-written modules, and
    with modules re-engineered/re-used from previous systems. (Software and
    (computer) systems analysis and integration is a problem area in its
    own right, we have another language and toolset for that task called
    MetaH.)

We generate both Ada and C.  Unconstrained arrays were certainly a
convenience when generating code from a language where matrices are a
fundamental data type.  Discriminant records were also a convenience.

Our web pages contain some more information, although not about Ada
issues specifically:
        http://www.htc.honeywell.com/projects/dssa

Steve Vestal
Mail: Honeywell Technology Center, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 951-7049      Fax: 7438     Email: vestal_steve@htc.honeywell.com

Re: ARIANE-5 Failure

[Ken Garlington]

Tronche Ch. le pitre wrote:
> 
> John McCabe wrote:
> >
> > I have heard that the failure of the Ariane 5 rocket's first launch on
> > Tuesday was caused by a software fault in the attitude control system.
> 
> French media have presented several successive explanations but always
> invoking software failure.

Aerospace Daily said that the current explanation was an erroneous command
from the flight control computers to the nozzles, driving them all hard over.
Such a command could be due to software, or to interface electronics failure,
or possibly noise on the wire connecting the two. I wouldn't be ready to
blame the software just yet.

Of course, assuming that the root cause is traced to the software, what of
it? Using Ada certainly doesn't ensure proper operation of a software system!

-- 
LMTAS - "Our Brand Means Quality"

Re: ARIANE-5 Failure

[John McCabe]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

>Of course, assuming that the root cause is traced to the software, what of
>it? Using Ada certainly doesn't ensure proper operation of a software system!

You're quite right and I didn't intend to imply anything by my
original message.

According to ESA/CNES press release 20.96,

"Preliminary analysis of the telemetry data confirms that the
propulsion stages (solid boosters and cryogenic main stage) functioned
correctly. The direction of inquiry is tending towards the launcher's
"electrical and software system""

I find it strange that they have mentioned "software" system rather
than "computer" system. They seem to have pointed the finger already.
It'll be interesting to see what the outcome is. It could so easily
just have been a sensor fault but I would have thought there would
have been adequate sensors to overcome/reduce the possibility of
single point failures.

My main interest in this matter is due to the fact that I work for the
UK part of the company that built the attitude control system and we
are actually using some of the equipment that was developed on the
Ariane 5 programme in the project I am currently working on.

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: ARIANE-5 Failure

[Robert Dewar]

Ken said

"Of course, assuming that the root cause is traced to the software, what of
it? Using Ada certainly doesn't ensure proper operation of a software system!
"

Certainly not, on the other hand, it will be interesting to know more details.
You can certainly ask whether a language could have helped when you now
consider the exact cause of the problem narrowed down to source code.

For instance, I think the Fortran language design bears at least a piece
of responsibility for the Venus probe bug.

Re: ARIANE-5 Failure

[Jim Kingdon]

> > I have heard that the failure of the Ariane 5 rocket's first launch on
> > Tuesday was caused by a software fault in the attitude control system.

There is a variety of information on this at
http://www.flatoday.com/today/ and http://www.esrin.esa.it/.  The 6
Jun press release says they are loking at software, but as nearly as I
could tell there are also other causes which are being considered.

So if anyone wants to post solid information, great, but IMHO, there
isn't much point in speculating.

> I don't think one has never see number 1 of any rocket succeeded in
> the aerospace industry history.

Check out Jonathan's space report #289 at
http://hea-www.harvard.edu/QEDT/jcm/space/jsr/jsr.html.  He has a list
of the first flights of new (not upgraded) first stages.  Maybe half
of them have succeeded (whether the upper stages, if any, succeeded
also he doesn't list).

Re: ARIANE-5 Failure

[Jim Kingdon]

> Didn't DC-X have a pad fire?

I'm not sure I should keep answering space questions on
*comp.lang.ada*, but the latest details on DC-XA, including the
(minor, May 18, 1996) fire which you mention, can be found at
http://cc.usu.edu/~slfn6/dcxa/.

Re: ARIANE-5 Failure

[Jim Kingdon]

> For instance, I think the Fortran language design bears at least a piece
> of responsibility for the Venus probe bug.

You mean the one which gets blamed on DO I=1.20 (where DO I=1,20 is meant)?

Do you happen to have a reference for this?  My (very vague)
recollection is that some people have said this story is true and
others have said it apocryphal, and I don't think I've seen anything
authoritative either way.

Re: ARIANE-5 Failure

[Robert Dewar]

Jim asked:

"Do you happen to have a reference for this?  My (very vague)
recollection is that some people have said this story is true and
others have said it apocryphal, and I don't think I've seen anything
authoritative either way."

Nope, I don't know if it is true or apocryphal. It is widely enough known
to use as a good example anyway, even if it is not true :-)

But it would be nice to find out, anyone on this list have a REALLY
AUTHORITATIVE first-hand source for the truth on this one (it is one
that many people "know" the answer to, but as Jim pointed out, they
disagree and can't all be right!)

Re: ARIANE-5 Failure

[Keith Thompson]

In <dewar.834362765@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
[...]
> But it would be nice to find out, anyone on this list have a REALLY
> AUTHORITATIVE first-hand source for the truth on this one (it is one
> that many people "know" the answer to, but as Jim pointed out, they
> disagree and can't all be right!)

Perhaps this isn't "REALLY AUTHORITATIVE", but it seems to be within
two or three steps of being first-hand knowledge.

According to Paul Ceruzzi's book "Beyond the Limits -- Flight Enters
the Computer Age", the loss of the Mariner I Venus probe was due not to
a Fortran error, but to a missing bar in a hand-written equation.

For details, see RISKS Digest 8.75, available at
<http://catless.ncl.ac.uk/Risks/8.75.html>.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
This sig uses the word "Exon" in violation of the Communications Decency Act.

Re: ARIANE-5 Failure

[Dewi Daniels]

dewar@cs.nyu.edu (Robert Dewar) wrote:

>Jim asked:
>
>"Do you happen to have a reference for this?  My (very vague)
>recollection is that some people have said this story is true and
>others have said it apocryphal, and I don't think I've seen anything
>authoritative either way."
>
>Nope, I don't know if it is true or apocryphal. It is widely enough known
>to use as a good example anyway, even if it is not true :-)
>
>But it would be nice to find out, anyone on this list have a REALLY
>AUTHORITATIVE first-hand source for the truth on this one (it is one
>that many people "know" the answer to, but as Jim pointed out, they
>disagree and can't all be right!)
>
From the alt.folklore.computers FAQ at
http://www.best.com/~wilson/faq:

III.1 - I heard that one of the NASA space probes went off course and
had to be destroyed
because of a typo in a FORTRAN DO loop. Is there any truth to this
rumor?

This answer by Mark Brader . Quoted items in it have been reformatted
but not abridged.

As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other
newsgroups, this turns out to be a confusion of two separate events.

The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not
Mars). Several incorrect or partially correct versions of what really
happened were posted in comp.risks; the best of these
cited a NASA publication called "Far Travelers" by Oran W. Nicks, but
still did not have the whole story.

Then in issue 8.75 we found out what really happened...

|  Date: Sat, 27 May 1989 15:34:33 PDT
|  From: Peter Neumann 
|  Subject: Mariner I -- no holds BARred
|  
|  Paul Ceruzzi has written a truly outstanding book for the new show
|  that opened two weeks ago at the Smithsonian National Air and Space
|  Museum.  The exhibit and the book are both entitled "Beyond the Limits
|  -- Flight Enters the Computer Age".  Both are superb.  Go for it (them).
|  
|  Paul has dug into several cases treated previously in RISKS and in
|  issues of the ACM Software Engineering Notes, and has been able to
|  resolve several mysteries.  In particular he considers the case of
|  Mariner I, about which various inaccurate stories have been told.
|  Intended to be the first US spacecraft to visit another planet, it was
|  destroyed by a range officer on 22 July 1962 when it behaved
|  erratically four minutes after launch.  The alleged missing `hyphen'
|  was really a missing `bar'.  I quote from Paul's book, pp. 202-203:
|  
| #  During the launch the Atlas booster rocket was guided with the help
| #  of two radar systems.  One, the Rate System, measured the velocity of
| #  the rocket as it ascended through the atmosphere.  The other, the
| #  Track System, measured its distance and angle from a tracking
| #  antenna near the launch site.  At the Cape a guidance computer
| #  processed these signals and sent control signals back to the
| #  tracking system, which in turn sent signals to the rocket.  Its
| #  primary function was to ensure a proper separation from the Atlas
| #  booster and ignition of the Agena upper stage, which was to carry
| #  the Mariner Spacecraft to Venus.
| #  
| #  Timing for the two radar systems was separated by a difference of
| #  forty-three milliseconds.  To compensate, the computer was instructed
| #  to add forty-three milliseconds to the data from the Rate System
| #  during the launch.  This action, which set both systems to the same
| #  sampling time base, required smoothed, or averaged, track data,
| #  obtained by an earlier computation, not the raw velocity data
| #  relayed directly from the track radar.  The symbol for this smoothed
| #  data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n],
| #  where R stands for the radius, the dot for the first derivative
| #  (i.e., the velocity), the bar for smoothed data, and n for the
| #  increment.
| #  
| #  The bar was left out of the hand-written guidance equations.  [A
| #  footnote cites interviews with John Norton and General Jack Albert.]
| #  Then during launch the on-board Rate System hardware failed.  That in
| #  itself should not have jeopardized the mission, as the Track System
| #  radar was working and could have handled the ascent.  But because of
| #  the missing bar in the guidance equations, the computer was
| #  processing the track data incorrectly.  [Paul's EndNote amplifies:
| #  The Mariner I failure was thus a {\it combination} of a hardware
| #  failure and the software bug.  The same flawed program had been used
| #  in several earlier Ranger launches with no ill effects.]  The result
| #  was erroneous information that velocity was fluctuating in an
| #  erratic and unpredictable manner, for which the computer tried to
| #  compensate by sending correction signals back to the rocket.  In fact
| #  the rocket was ascending smoothly and needed no such correction.  The
| #  result was {\it genuine} instead of phantom erratic behavior, which
| #  led the range safety officer to destroy the missile, and with it the
| #  Mariner spacecraft.  Mariner I, its systems functioning normally,
| #  plunged into the Atlantic.

The DO-loop incident did happen at NASA, and at about the same time.
As told by Fred Webb in alt.folklore.computers in
1990:

|  I worked at Nasa during the summer of 1963.  The group I was working
|  in was doing preliminary work on the Mission Control Center computer
|  systems and programs.  My office mate had the job of testing out an
|  orbit computation program which had been used during the Mercury
|  flights.  Running some test data with known answers through it, he was
|  getting answers that were close, but not accurate enough.  So, he
|  started looking for numerical problems in the algorithm, checking to
|  make sure his tests data was really correct, etc.
|
|  After a couple of weeks with no results, he came across a DO
|  statement, in the form:
|       DO 10 I=1.10
|  This statement was interpreted by the compiler (correctly) as:
|       DO10I = 1.10
|  The programmer had clearly intended:
|       DO 10 I = 1, 10
|
|  After changing the `.' to a `,' the program results were correct to
|  the desired accuracy.  Apparently, the program's answers had been
|  "good enough" for the sub-orbital Mercury flights, so no one suspected
|  a bug until they tried to get greater accuracy, in anticipation of
|  later orbital and moon flights.  As far as I know, this particular bug
|  was never blamed for any actual failure of a space flight, but the
|  other details here seem close enough that I'm sure this incident is the
|  source of the DO story.

Project Mercury's sub-orbital flights were in 1961, and its orbital
flights began in 1962. I forwarded the above to comp.risks,
slightly abridged, and it appeared there in issue 9.54.

The erroneous claim that the DO-loop bug was the bug that killed
Mariner I apparently originated with, and certainly was
propagated by, the book "Software Reliability: Principles and
Practices" by G(lenford) J. Myers (John Wiley & Sons, 1976). I
haven't read it myself; I've seen the page numbers 7 and 275
attributed to the assertion. I expect both are right. This book also
describes the bug as a "billion-dollar error", which is too large by a
factor of about 50.

In some earlier postings it was suggested that Myers be located and
asked about his sources (the book gives none), but
nobody successfully did this; his employer at the time of publication
didn't have his current address. My guess is that he simply
made an error or more likely accepted someone else's wrong
recollection, and didn't feel it necessary to go to original sources
to verify what was only an illustrative point anyway.
-- 
Dewi Daniels
Guildford, England

Re: ARIANE-5 Failure

[Theodore E. Dennison]

Dewi Daniels wrote:
> From the alt.folklore.computers FAQ at
> http://www.best.com/~wilson/faq:
> 
> Then in issue 8.75 we found out what really happened...
> 
> |  erratically four minutes after launch.  The alleged missing `hyphen'
> |  was really a missing `bar'.  I quote from Paul's book, pp. 202-203:
> |
> | #  relayed directly from the track radar.  The symbol for this smoothed
> | #  data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n],
> | #  where R stands for the radius, the dot for the first derivative
> | #  (i.e., the velocity), the bar for smoothed data, and n for the
> | #  increment.

Still, if thy had named their variables Radius.Velocity_Smoothed_N and
Radius.Velocity_N (their language probably didn't even allow this), the 
odds of this error being discovered by someone before the failure would 
have been MUCH greater.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: ARIANE-5 Failure

[Ken Garlington]

Theodore E. Dennison wrote:
> 
> Still, if thy had named their variables Radius.Velocity_Smoothed_N and
> Radius.Velocity_N (their language probably didn't even allow this), the
> odds of this error being discovered by someone before the failure would
> have been MUCH greater.

Well, this notation would have to have been used in the requirements to be
meaningful, and I don't think most systems engineers want to write
math equations in Ada!

There was a study a few years back by a Dr. Avezziani [sp] attempting to
show the worth of N-version programming. He had several teams use a high-quality
software development process to build a subset of a flight control system.
There was only one common-mode error found. Each team had been given a photocopy 
of the control law diagrams to implement. There was a number, something like
5.122, on one of the gains. However, the smudged photocopy made it look like 
5,122. Each team used the constant 5,122 in their code. (I'm not sure how this
proved the use of N-version programming, but that's another issue).

It's amazing how tiny changes in dense notations add up to big errors. Maybe the 
real lesson learned is to use better equation editors, and avoid the Xerox 
machine!

> 
> --
> T.E.D.
>                 |  Work - mailto:dennison@escmail.orl.mmc.com  |
>                 |  Home - mailto:dennison@iag.net              |
>                 |  URL  - http://www.iag.net/~dennison         |

-- 
LMTAS - "Our Brand Means Quality"

Re: ARIANE-5 Failure

[Theodore E. Dennison]

Ken Garlington wrote:
> 
> Theodore E. Dennison wrote:
> >
> > Still, if thy had named their variables Radius.Velocity_Smoothed_N and
> > Radius.Velocity_N (their language probably didn't even allow this), the
> > odds of this error being discovered by someone before the failure would
> > have been MUCH greater.
> 
> Well, this notation would have to have been used in the requirements to be
> meaningful, and I don't think most systems engineers want to write
> math equations in Ada!

Well, the general idea was that someone "in the know" would look at the code,
perhaps at a walkthough, and notice the error. Given my general experience
with walkthoughs, I'll have to admit that I'm treading in la-la land here...

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: ARIANE-5 Failure

[Jan Kok]

In article <31bc75ed.1932371@news.cableol.net> dewi@mail.cableol.net (Dewi Daniels) writes:
...
>The erroneous claim that the DO-loop bug was the bug that killed
>Mariner I apparently originated with, and certainly was
>propagated by, the book "Software Reliability: Principles and
>Practices" by G(lenford) J. Myers (John Wiley & Sons, 1976). I
>haven't read it myself; I've seen the page numbers 7 and 275
>attributed to the assertion. I expect both are right. This book also
>describes the bug as a "billion-dollar error", which is too large by a
>factor of about 50.

Even in these modern times books can still be retrieved from
old-fashioned libraries. I looked up Myers. The reference and the page
numbers are correct. Myers actually speaks about destination Venus
(not important as the legend has that it did not arrive). I cannot find
a reference that supports Myers' story.

-- 
 --Jan Kok           E-mail: Jan.Kok@cwi.nl |    =#===-=========##=
                     Address: CWI (dpt. NW) |    --   ,___@
         P.O. Box 94079 / 1090 GB Amsterdam |  --   __/\
             URL: http://www.cwi.nl/~jankok |      '   /_

Re: ARIANE-5 Failure

[William Clodius]

The association of the Venus probe failure with Fortran has long been
identified as an urban myth.  The Venus probe software that failed was
not written in Fortran and the softare failure had nothing to do with
misreading a statement of the form

DO 10 I=1. 10

as is commonly reported.  The Venus probe failure was caused by a
typographical error that caused the instantaneous velocity to be used
in the guidance system (rather than the required running average
velocity) resulting in an instability in the system.  The language
used in the software allowed the use of special typographical symbols,
and the person who entered the code failed to notice that the quantity
should be entered with a "bar" above it, which indicated that it was
an average quantity.

On the other hand a (non-fatal) software failure in the Mercury flight
system was identified with the misreading of a statement of the form

DO 10 I=1. 10

as the assignment

DO10I = 1.10

For short orbits this error had no observed effects, but on longer
orbits a consistent error in the reentry position was discovered to be
due to this error.





-- 
William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

Re: ARIANE-5 Failure

[Theodore E. Dennison]

John McCabe wrote:
> 
> I have heard that the failure of the Ariane 5 rocket's first launch on
> Tuesday was caused by a software fault in the attitude control system.
> 
> Does anyone know whether Ada was used on that system, and if so, who
> designed and built the software, and which compiler and target were
> used.

I was wondering the same thing.

They said that the crash was caused by the rocket recieving
an "false computer command", which caused it to make a hard left
at full thrust (a BAD thing). They don't know the source of the
command yet, other than it happened somewhere on-board the rocket.
So its a bit early to try and blame any individual component, much 
less the compiler used for the software on any individual component.

Here's the full story as I read it:

 False computer command blamed in Ariane V failure

      A spurious computer command sent the first Ariane V booster heeling
 over sideways only 37 seconds into its inaugural flight, wrecking what
 had been shaping up to be a textbook flight and throwing Europe's civil
 and commercial space program into uncertainty over the long-term.
      But loss of the $500 million vehicle Tuesday should not impact the
 lucrative commercial launch program managed by Arianespace in the near
 term. The European launch services consortium has enough Ariane IV
 boosters in stock or on order to keep up its pace through 1998, and
 could order more of the veteran launch vehicles if necessary.
      European space officials told reporters at the Ariane V launch
 complex in Kourou, French Guiana, yesterday that the main task of the
 inquiry board probing the failure will be to learn the source of the
 command, which sent all three of the huge rocket's nozzles swiveling as
 far to the side as they would go.
      The abrupt pitchover sheared off the vehicle's upper stage and
 short- version fairing with the European Space Agency's four Cluster
 scientific satellites inside, triggering an automatic on-board
 self-destruct command that was quickly followed with a command-destruct
 signal from controllers on the ground. The flight that was to have
 placed the Cluster satellites in elliptical orbits as far as 125,000
 kilometers from Earth ended at an altitude of about four kilometers
 (DAILY, June 5).
      Jean-Marie Luton, head of the European Space Agency, said in Kourou
 that the inquiry board will be established by the end of this week, with
 orders to issue at least an interim report by July 15. Although even
 before the launch failure European press reports were questioning the
 high cost of the program - 20% over budget at $8 billion to date - Luton
 said ESA member nations remained committed to the program after the
 explosion.
      Daniel Mugnier, launch operations director for the French Space
 Agency (CNES), which manages the Ariane V program for ESA, told
 reporters in Kourou that the false signal from the On-Board Computer
 caused hydraulic nozzle actuators for the twin solid rocket boosters
 that provide 95% of the rocket's power on ascent to hit their hard
 stops, flipping the vehicle on its side. The nozzle on the Vulcain main
 engine also swivelled, Mugnier said, even though it normally is
 activated only if the solid booster nozzles are unable to make a course
 correction.
                       Pre-flight testing found no problems
      The source of the false command was unclear based on preliminary
 analysis of telemetry tapes, Mugnier said. Both the primary and backup
 on- board inertial reference systems were producing the same readings,
 he said, allaying suspicion that they were the source of the error.
 Guidance software and hardware all checked out on the ground, and Luton
 said the inquiry board will try to determine why the testing did not
 detect the fatal problem.
      ESA had planned a second Ariane V qualification flight in October
 or November, but that schedule will slip until the cause of the failure
 is pinpointed and fixed. Although the primary payload on that flight is
 ESA's Atmospheric Reentry Demonstrator, Arianespace is trying to market
 3.5 tons in unused geostationary transfer payload capability at a
 $20-$25 million discount, according to Doug Heydon, president of
 Arianespace Inc., the U.S. subsidiary of the European consortium.
      Heydon said the payload for the third Ariane V flight, originally
 targeted for March 1997, is also unclear. PanAmSat, the original
 customer, was already looking for a different launcher for scheduling
 reasons, he said, while officials in Kourou said there is a remote
 chance ESA will want to dedicate the third flight qualification rather
 than commercial purposes. Arianespace will continue to offer a free
 reflight to early Ariane V customers in the event of another launch
 failure, Heydon said.
      Charles Bigot, the Arianespace chairman, said from Kourou that the
 consortium will have enough Ariane IVs to maintain its launch rate of
 17.5 satellites a year through 1998, and could continue beyond that with
 another Ariane IV order. That decision is at least a year in the future,
 and will depend on the outcome of the inquiry board investigation and
 future Ariane V developments, he said.

  Copyright 1996 The McGraw-Hill Companies, Inc.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: ARIANE-5 Failure

[William Clodius]

Here's a posting of a posting that I consider more authorative.

----------------------- Begin Included Message -------------------------

From: turner@lanl.gov (John A. Turner)
Date: 28 Feb 1995 23:31:39 GMT
Organization: Los Alamos National Laboratory
In article <1995Feb27.143252.2189@driftwood.cray.com> jjd@cray.com (Jeff Drummond) writes:

 > The oft-repeated myth of the Venus probe lost due to a missing Fortran
 > comma been debunked in alt.folklore.computers and elsewhere.

Here's something Dan Pop posted back in September (yeah, I'm an e-mail
packrat).  I hope he won't mind me re-posting it (maybe it'll save him
the trouble)...

----------------------- Begin Included Message -------------------------

Newsgroups: comp.lang.fortran
From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Re: Urban myth?
Organization: CERN European Lab for Particle Physics
Date: Mon, 19 Sep 1994 10:56:50 GMT

In <kemidb.779968115@aau> kemidb@aau.dk (Dieter Britz) writes:

>Over the years, I have several times seen reference to this piece of code:
>
>      DO 10 I = 1.10
>      ...
>10    CONTINUE
>
>It is said that this error (which the compiler, of course, interprets as
>the assignment statement DO10I=1.10) was made in a space program program,
>and led to a rocket crash. Is this factual, or is this an urban myth in
>the computer world? 

>From the alt.folklore.computers FAQ:

III.1 - I heard that one of the NASA space probes went off course and
        had to be destroyed because of a typo in a FORTRAN DO loop.
        Is there any truth to this rumor?

As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other newsgroups, this turns
out to be a confusion of two separate events.

The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not Mars).  Several
incorrect or partially correct versions of what really happened were
posted in comp.risks; the best of these cited a NASA publication called
"Far Travelers" by Oran W. Nicks, but still did not have the whole story.

Then in issue 8.75 we found out what really happened...

|  Date: Sat, 27 May 1989 15:34:33 PDT
|  From: Peter Neumann <neumann@csl.sri.com>
|  Subject: Mariner I -- no holds BARred
|  
|  Paul Ceruzzi has written a truly outstanding book for the new show
|  that opened two weeks ago at the Smithsonian National Air and Space
|  Museum.  The exhibit and the book are both entitled "Beyond the Limits
|  -- Flight Enters the Computer Age".  Both are superb.  Go for it (them).
|  
|  Paul has dug into several cases treated previously in RISKS and in
|  issues of the ACM Software Engineering Notes, and has been able to
|  resolve several mysteries.  In particular he considers the case of
|  Mariner I, about which various inaccurate stories have been told.
|  Intended to be the first US spacecraft to visit another planet, it was
|  destroyed by a range officer on 22 July 1962 when it behaved
|  erratically four minutes after launch.  The alleged missing `hyphen'
|  was really a missing `bar'.  I quote from Paul's book, pp. 202-203:
|  
| #  During the launch the Atlas booster rocket was guided with the help
| #  of two radar systems.  One, the Rate System, measured the velocity of
| #  the rocket as it ascended through the atmosphere.  The other, the
| #  Track System, measured its distance and angle from a tracking
| #  antenna near the launch site.  At the Cape a guidance computer
| #  processed these signals and sent control signals back to the
| #  tracking system, which in turn sent signals to the rocket.  Its
| #  primary function was to ensure a proper separation from the Atlas
| #  booster and ignition of the Agena upper stage, which was to carry
| #  the Mariner Spacecraft to Venus.
| #  
| #  Timing for the two radar systems was separated by a difference of
| #  forty-three milliseconds.  To compensate, the computer was instructed
| #  to add forty-three milliseconds to the data from the Rate System
| #  during the launch.  This action, which set both systems to the same
| #  sampling time base, required smoothed, or averaged, track data,
| #  obtained by an earlier computation, not the raw velocity data
| #  relayed directly from the track radar.  The symbol for this smoothed
| #  data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n],
| #  where R stands for the radius, the dot for the first derivative
| #  (i.e., the velocity), the bar for smoothed data, and n for the
| #  increment.
| #  
| #  The bar was left out of the hand-written guidance equations.  [A
| #  footnote cites interviews with John Norton and General Jack Albert.]
| #  Then during launch the on-board Rate System hardware failed.  That in
| #  itself should not have jeopardized the mission, as the Track System
| #  radar was working and could have handled the ascent.  But because of
| #  the missing bar in the guidance equations, the computer was
| #  processing the track data incorrectly.  [Paul's EndNote amplifies:
| #  The Mariner I failure was thus a {\it combination} of a hardware
| #  failure and the software bug.  The same flawed program had been used
| #  in several earlier Ranger launches with no ill effects.]  The result
| #  was erroneous information that velocity was fluctuating in an
| #  erratic and unpredictable manner, for which the computer tried to
| #  compensate by sending correction signals back to the rocket.  In fact
| #  the rocket was ascending smoothly and needed no such correction.  The
| #  result was {\it genuine} instead of phantom erratic behavior, which
| #  led the range safety officer to destroy the missile, and with it the
| #  Mariner spacecraft.  Mariner I, its systems functioning normally,
| #  plunged into the Atlantic.

The DO-loop incident did happen at NASA, and at about the same time.
As told by Fred Webb in alt.folklore.computers in 1990:

|  I worked at Nasa during the summer of 1963.  The group I was working
|  in was doing preliminary work on the Mission Control Center computer
|  systems and programs.  My office mate had the job of testing out an
|  orbit computation program which had been used during the Mercury
|  flights.  Running some test data with known answers through it, he was
|  getting answers that were close, but not accurate enough.  So, he
|  started looking for numerical problems in the algorithm, checking to
|  make sure his tests data was really correct, etc.
|
|  After a couple of weeks with no results, he came across a DO
|  statement, in the form:
|       DO 10 I=1.10
|  This statement was interpreted by the compiler (correctly) as:
|       DO10I = 1.10
|  The programmer had clearly intended:
|       DO 10 I = 1, 10
|
|  After changing the `.' to a `,' the program results were correct to
|  the desired accuracy.  Apparently, the program's answers had been
|  "good enough" for the sub-orbital Mercury flights, so no one suspected
|  a bug until they tried to get greater accuracy, in anticipation of
|  later orbital and moon flights.  As far as I know, this particular bug
|  was never blamed for any actual failure of a space flight, but the
|  other details here seem close enough that I'm sure this incident is the
|  source of the DO story.

Project Mercury's sub-orbital flights were in 1961, and its orbital
flights began in 1962.  I forwarded the above to comp.risks, slightly
abridged, and it appeared there in issue 9.54.

The erroneous claim that the DO-loop bug was the bug that killed Mariner I
apparently originated with, and certainly was propagated by, the book
"Software Reliability: Principles and Practices" by G(lenford) J. Myers
(John Wiley & Sons, 1976).  I haven't read it myself; I've seen the page
numbers 7 and 275 attributed to the assertion.  I expect both are right.
This book also describes the bug as a "billion-dollar error", which is
too large by a factor of about 50.

In some earlier postings it was suggested that Myers be located and
asked about his sources (the book gives none), but nobody successfully
did this; his employer at the time of publication didn't have his
current address.  My guess is that he simply made an error or more
likely accepted someone else's wrong recollection, and didn't feel
it necessary to go to original sources to verify what was only an
illustrative point anyway.

This answer by Mark Brader <msb@sq.com>.  Quoted items in it have been
reformatted but not abridged.

--
Dan Pop 
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

----------------------- Begin Included Message -------------------------

+---------------------------------------------------------------+
| John A. Turner                                                |
| Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 |
| Group: X-6 (Radiation Transport)                              |
| Location: TA-3, Bldg. 43, Rm. D263                            |
| Phone: 505-665-1303                   e-mail: turner@lanl.gov |
+---------------------------------------------------------------+

----------------------- Begin Included Message -------------------------
-- 
William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545