Ariane5 FAQ

Ariane5 FAQ

[Alexandre E. Kopilovitch]

Recently there was proposition to create FAQ for Ariane 5 case. I even started
to do that that time. And today I got the final impulse: my daughter told me
that she just watched TV program "Discovery" where the crash of Ariane 5 was
explained - yes, as you may expect, there was software error, human factor,
one programmer mistakenly wrote something, and the rocket explodes. Now I
took the case personally -;) , and completed the first draft of the FAQ.
Here it is:

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

Q. Was Ada language somehow related to Ariane 5 crash in 1996?

A. Yes, at least some components of the Ariane 5 software was written
in Ada language.

Q. Did that software cause the crash?

A. Yes and No. They simply put the software written for previous model --
Ariane 4 (where it worked well) -- to new Ariane 5, and did not bother
themselves with testing it on the new rocket before the launch. So, when
the Ariane 4 software appeared (in the flight) incompatible with new Ariane 5
they became very surprised -- and blamed the software.

Q. But media told us that there was an error in the software that caused
that crash. Is it right?

A. No, it is wrong. There was no such an error in the software. The software
worked perfectly for the purpose, for which it was created, that is, for
Ariane 4. The software was not created for Ariane 5, and there were no reasons
to expect that it should work for this new rocket. So, the error, which caused
the crash was blinded use of a software created for another job. And this
error was severely aggravated by subsequent error -- skipping mandatory test
procedure before the first flight.

Q. Where I can find official report for the investigation of the Ariane 5
crash?

A. At the moment of writing this FAQ this report was, for example. at:
 http://www.dcs.ed.ac.uk/home/pxs/Book/ariane5rep.html
But read it to the end, because your overall impression will probably be
different (and wrong) if you stop in the middle of it, deciding that you
got it all clear enough.

Q. Where this topic was discussed in depth?

A. For example, in comp.lang.ada newsgroup (several times). Search that
newsgroup for "Ariane 5", and you'll find several threads discussing this
topic (most recent at the moment of writing this FAQ was quite long thread
with subject line "Boeing and Dreamliner").

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

Re: Ariane5 FAQ

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
 > there were no reasons to expect that it should work for this new rocket

That is a nonsensical remark. The Ariane 5 designers obviously
expected that it should work for their rocket, and work without
any changes, so to claim that there were no reasons to expect it
to work is silly.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Alexandre E. Kopilovitch wrote:
> > there were no reasons to expect that it should work for this new rocket
>
>That is a nonsensical remark. The Ariane 5 designers obviously
>expected that it should work for their rocket, and work without
>any changes, so to claim that there were no reasons to expect it
>to work is silly.

Obviously you are saying there were any reasons. So could you please
explain what they were?


Vinzent.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> Obviously you are saying there were any reasons. So could you please
> explain what they were?

The OP said that there was no reason to assume that the software
used in the Ariane 4 would work in the Ariane 5. But the designers
of the Ariane 5 chose to use the hardware and software unchanged,
so they obviously believed that it would work.

The OP seems to be saying that just because I can drive my car
from my house to the supermarket, I have no reason to believe
that I can drive my car from my house to the video store.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Obviously you are saying there were any reasons. So could you please
>> explain what they were?
>
>The OP said that there was no reason to assume that the software
>used in the Ariane 4 would work in the Ariane 5. But the designers
>of the Ariane 5 chose to use the hardware and software unchanged,
>so they obviously believed that it would work.

They might have been *believed* that, yes. But for what reasons?

>The OP seems to be saying that just because I can drive my car
>from my house to the supermarket, I have no reason to believe
>that I can drive my car from my house to the video store.

Wrong analogy. They didn't believe that Ariane X would come back from
the supermarket at all. They knew it wouldn't. :-)

Let me try an analogy: If you take the brake controller software from
one car and put it in a different one, what *reason* makes you believe
it would work properly?


Vinzent.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> Let me try an analogy: If you take the brake controller software from
> one car and put it in a different one, what *reason* makes you believe
> it would work properly?

But it wasn't just the software. The inertial reference system
hardware was taken unchanged from the Ariane 4 to the Ariane 5.
While it turned out in retrospect that there were reasons why
the software which worked in the Ariane 4 did not work in the
Ariane 5, that is a far, far cry from saying that "there were
no reasons to expect that it should work for this new rocket."

Re: Ariane5 FAQ

[Francisco Malpartida]

Hi folks

just one little incision on the SW "failure" for Ariane 5.

As mentioned in the thread, the SW was indeed written and tested for Ariane
4.
There are several points which are different from both launchers, one of
which
was instrumental to the events:

Ariane 4 is a vertical launch vehicle where as Ariane 5 is slightly tilted.
Ariane 4
SW was developed to tolerate certain amount of inclination but not as much
as required by Ariane 5. The chain of events are as follows:

    - The on-board SW detects that one of the accelerometers is out of range
        - This causes the redundant CPU to take over.
    - The redundant CPU also detects that one of the accelerometers is out
of range
    which causes the system to advice an auto destruction.

Therefore, the SW behaved as it was supposed to under the conditions it was
designed for.

Cheers


"Vinzent Hoefler" <ada.rocks@jlfencey.com> wrote in message
news:bfhaed$e786b$1@ID-175126.news.uni-berlin.de...
Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Obviously you are saying there were any reasons. So could you please
>> explain what they were?
>
>The OP said that there was no reason to assume that the software
>used in the Ariane 4 would work in the Ariane 5. But the designers
>of the Ariane 5 chose to use the hardware and software unchanged,
>so they obviously believed that it would work.

They might have been *believed* that, yes. But for what reasons?

>The OP seems to be saying that just because I can drive my car
>from my house to the supermarket, I have no reason to believe
>that I can drive my car from my house to the video store.

Wrong analogy. They didn't believe that Ariane X would come back from
the supermarket at all. They knew it wouldn't. :-)

Let me try an analogy: If you take the brake controller software from
one car and put it in a different one, what *reason* makes you believe
it would work properly?


Vinzent.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Let me try an analogy: If you take the brake controller software from
>> one car and put it in a different one, what *reason* makes you believe
>> it would work properly?
>
>But it wasn't just the software. The inertial reference system
>hardware was taken unchanged from the Ariane 4 to the Ariane 5.

Ok, so change the entire brake controller. ;-) What reason makes you
think, it will work?

>While it turned out in retrospect that there were reasons why
>the software which worked in the Ariane 4 did not work in the
>Ariane 5, that is a far, far cry from saying that "there were
>no reasons to expect that it should work for this new rocket."

Well, so I ask again, *which* reasons were that? I see none, besides
the good belief, it won't go wrong.


Vinzent.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> Well, so I ask again, *which* reasons were that? I see none, besides
> the good belief, it won't go wrong.

They took a piece of self-contained hardware and moved it
from one rocket to another. They thought the software would
work. We have to assume that the Ariane 5 folks were not
complete blithering idiots, so they must have has readsons
to assume it would work.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Well, so I ask again, *which* reasons were that? I see none, besides
>> the good belief, it won't go wrong.
>
>They took a piece of self-contained hardware and moved it
>from one rocket to another. They thought the software would
>work.

Well, one way or another - it did. It did exactly what is was supposed
to do.

>We have to assume that the Ariane 5 folks were not
>complete blithering idiots,

Dangerous assumption. ;)

>so they must have has readsons
>to assume it would work.

So what you're trying to say is that they must have reasons just
because they did it? Sorry, but I wouldn't consider this a strong
argument.

Alas, people do a lot of things for no apparent reason. This is
sometimes ok if we are talking about "normal" life, but if there is a
technical background, doing so can become very dangerous.
In that area we should usually try to prove our beliefs (and
obviously, this wasn't done in the Ariane 5 case). This proving
process usually involves some reasons for this or that. So what
reasons had they and could they prove the correctness? Obviously the
answer is "No, they couldn't, because they didn't.".
A reason like "it worked on the Ariane 4" is not really a reason, as I
have already tried to point out. Personally for me it looks like they
just *assumed* the IRS would work. This might have been the reason for
the decision to just reuse it, right. But if you look deeper, they
didn't seem have a reason for assuming that, they simply just believed
it.

What I mean is, you can probably not prove that somebody really loves
his wife (BTW, does he have a reason for doing so?[0]) but you can
tell that the candle on the table will shed some fancy light on her,
because there is a reason for that it is doing so (something with high
temperature, gases, electrons, molecular movements and photons and
such stuff, I guess ;). Well, bad example, try to go into detail and
predict the exact movement of the flame...


Vinzent.

[0] Because he just does? :-)

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Mon, 21 Jul 2003 14:01:50 -0400, Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> Obviously you are saying there were any reasons. So could you please
>> explain what they were?
> 
> The OP said that there was no reason to assume that the software
> used in the Ariane 4 would work in the Ariane 5. But the designers
> of the Ariane 5 chose to use the hardware and software unchanged,
> so they obviously believed that it would work.

You are merely restating the fact that they _did_ assume it, not giving a
reason for assuming it.


> The OP seems to be saying that just because I can drive my car
> from my house to the supermarket, I have no reason to believe
> that I can drive my car from my house to the video store.

No, it's more like saying that just because my Kia fits in my parking
space I have no reason to believe my new Ranchero will also fit there.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Mon, 21 Jul 2003 14:49:01 -0400, Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> Let me try an analogy: If you take the brake controller software from
>> one car and put it in a different one, what *reason* makes you believe
>> it would work properly?
> 
> But it wasn't just the software. The inertial reference system hardware
> was taken unchanged from the Ariane 4 to the Ariane 5. While it turned
> out in retrospect that there were reasons why the software which worked
> in the Ariane 4 did not work in the Ariane 5, that is a far, far cry
> from saying that "there were no reasons to expect that it should work
> for this new rocket."

The new rocket had more thrust.  There's absolutely no reason to suppose
that such a part and its software will work in one mission envelope just
because it worked perfectly in a different one.

And it didn't "turn out in retrospect".  The error was _discovered_ in
retrospect, but the error was made up front and was avoidable.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Hyman Rosen wrote:

> > there were no reasons to expect that it should work for this new rocket
>
>That is a nonsensical remark.

Why? It is "refutable" statement, so please tell me the possible reasons --
knowing that the specifications for Ariane 5 definitely weren't compared
against the specifications for Ariane 4 SRI.

> The Ariane 5 designers obviously
>expected that it should work for their rocket, and work without
>any changes,

We know nothing about what Ariane 5 designers thought on this matter,
but we certainly know that their management expected that. So what?
Yes, they expected that, but still without valid reasons. Nobody compared
the specifications, and there wasn't a claim in SRI documentation that it is
intended for some general use, other then for Ariane 4.

Note that although the Report rebukes the SRI documentation for insufficiently
clear (or insufficiently visible) statement of limitations, nevertheless there
is no single remark in the Report from which you may conclude that there was
an overstatement of the SRI capabilities in its documentation.

> so to claim that there were no reasons to expect it to work is silly.

Well, I don't follow you logic here: it seems that you imply presence of
reasons from the fact that some group of people apparently expected something.

(Note also, that this group of people actually proved it as either faulty or
sabotaging body, by skipping the test procedure. So why do you think that the
same body can't expect anything without good reasons?)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Hyman Rosen wrote:

>The OP said that there was no reason to assume that the software
>used in the Ariane 4 would work in the Ariane 5. But the designers
>of the Ariane 5 chose to use the hardware and software unchanged,
>so they obviously believed that it would work.

You apparently count high managers of the project along with real designers.
Actually there are no signs that real designers were even asked about the
matter. All we know is that some high managers of the project decided that
the SRI from Ariane 4 will be used for Ariane 5 without any change. Yes, those
managers apparently believed that it would work, and this implies only that
they think of SRI as of a commodity, something like a tourist's compass, but
perhaps bigger and certainly much more expensive.

>The OP seems to be saying that just because I can drive my car
>from my house to the supermarket, I have no reason to believe
>that I can drive my car from my house to the video store.

Well, just because you can drive you car from your house to the supermarket,
you have no reason to believe that you can drive my heavy truck from your
house to the video store. You may only *hope* that you can.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Hyman Rosen]

Alexander Kopilovitch wrote:
> You apparently count high managers of the project along with real designers.

Those same high managers got the Ariane 5 flying.
They made one mistake.

Re: Ariane5 FAQ

[Hyman Rosen]

Alexander Kopilovitch wrote:
> We know nothing about what Ariane 5 designers thought on this matter,
> but we certainly know that their management expected that. So what?

So it seems to me that you would rather believe that project managers
could be complete morons rather than believe that Ada programmers could
fail to properly document their code. I know which I think is more likely,
but feel free to believe as you like. It's a free country.

Re: Ariane5 FAQ

[Hyman Rosen]

Bobby D. Bryant wrote:
> The new rocket had more thrust.  There's absolutely no reason to suppose
> that such a part and its software will work in one mission envelope just
> because it worked perfectly in a different one.

Why not? And in fact, the error occurred in a calibration routine that
was unnecessary at the time it was running, and the bad code was in place
as an implementation shortcut, not a design necessity.

Re: Ariane5 FAQ

[Hyman Rosen]

Bobby D. Bryant wrote:
> You are merely restating the fact that they _did_ assume it, not giving a
> reason for assuming it.

Because I'm not a rocket scientist. But they are. I tend to assume
that people who are in charge of rockets know something about waht
they're doing, even if they occasionally make a mistake. Just like
I assume that Ada programmers know what the're doing, but sometimes
fail to properly document the design assumptions of their code.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> Well, one way or another - it did. It did exactly what is was supposed
> to do.

No matter how many times people on this newsgroup repeat this,
it will not become true. The code was written on the assumption
that a certain parameter would never reach a particular value.
Its behavior under the contrary assumption was left unspecified.
It certainly did not do "what it was supposed to do" once the
assumption was violated. The system pretended that a hardware
error had happened.

Re: Ariane5 FAQ

[Hyman Rosen]

Francisco Malpartida wrote:
>     - The on-board SW detects that one of the accelerometers is out of range

In much the same sense that your car detects that it's on the
railroad tracks when the train hits it.

The Ariane 4 code had a deliberately unprotected conversion from
floating point to 16-bit integer, under the assumption that overflow
could not happen. When the overflow did happen, the computer generated
an Operand Fault.

Re: Ariane5 FAQ

[Robert I. Eachus]

Vinzent Hoefler wrote:

> Ok, so change the entire brake controller. ;-) What reason makes you
> think, it will work?

A better example would be to take a brake system from a car and put it 
into a truck.  But the box for the brake system was labeled "for MVW up 
to 5,000 pounds," and it is a 2 1/2 ton truck.

This is what you have to keep the focus on.  The problem was not that 
the engineers for the Ariane 4 inertial guidance system didn't do their 
job perfectly, or that the engineers for the Ariane 5 didn't do their 
jobs correctly.  Management put a box on the org chart and the 
engineering test plan which said that these people will make sure that 
the Ariane 4 inertial guidance software will work on the Ariane 5.  Then 
they literally erased the box without staffing it, with the intent of 
saving money.

So as things worked out no engineer was ever in a position to give an 
opinion on whether the inertial guidance software was suitable for the 
Ariane 5.  It really happened that (if you read Dilbert) a pointy haired 
boss took the software out of the box and handed it to the Arine 5 
construction team saying it had been throughly tested for this job.

But no engineer ever saw both the Ariane 5 requirements and the Ariane 4 
inertial guidance software documentation until after the crash.  And the 
elimination of the "full-up" engineering tests of the inertial guidance 
software with the engine controls was cancelled for lack of funds and 
lack of time after all the engine system design engineers had gone on to 
other projects.

It would be nice if there was a particular culprit who knew that the 
reason the full-up guidance system tests were behind schedule because 
the guidance software didn't work.  But in reality, the testing was so 
far behind schedule when it was cancelled that they never got as far as 
running with the computers the software ran on integrated into the test 
stand.  (And the test platform was being done as "black box" testing, so 
the test developers had access to the Ariane 5 requirements--but not the 
actual software documentation, just the interfaces.)

I would love to be able to say that "it could never happen here."  But I 
can't, it takes constant vigilance on a project to ensure that there are 
no loose ends, missed requirements or requirements that have changed 
since the original analysis.  So in the end it comes down to the fact 
that we are all only human.

-- 

                                                Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Richard Riehle]

Vinzent Hoefler wrote:

> Hyman Rosen wrote:
>
>
>
> >We have to assume that the Ariane 5 folks were not
> >complete blithering idiots,

Bertrand Meyer published a controversial article suggesting
that, had they used design by contract ( a la Eiffel) this could
not have happened.  While I don't agree that Eiffel would have
been better for the job, a contract model such as that found in
SPARK might have been successful in detecting the design
error early on.

It is not the blithering idiots who make the kind of mistake
that  triggered the Ariane V event.   Rather, it is usually a
series of decisions, not well-managed or coordinated, by
competent engineers.   I am probably not the only person
who has seen perfectly good software turn to fecal matter
due to poor configuration management.

In the end, the Ariane V event was a failure of engineering
management, not of  individual engineers.  No amount of
DbC, more careful design, better languages,  whatever, can
compensate for incompetent engineering management.

Richard Riehle

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> No matter how many times people on this newsgroup repeat this,
> it will not become true. The code was written on the assumption
> that a certain parameter would never reach a particular value.
> Its behavior under the contrary assumption was left unspecified.

Incorrect.  The behavior was specified.  Shutdown the SRI and dump 
diagnostic information, because this situation could only occur (in the 
Ariane 4 at least) due to hardware failure.

> It certainly did not do "what it was supposed to do" once the
> assumption was violated. The system pretended that a hardware
> error had happened.

The system treated the error as a hardware error because, during the 
Ariane 4 SRI software development, it was concluded that a hardware 
error was the only way to get such a reading.  The Ariane 4 simply could 
not move that fast off the pad.  Now if an Ariane 4 exploded during 
takeoff, it might send the SRI and its accelerometers flying fast enough 
to trigger that hardware diagnostic.  But that certainly would have been 
a hardware failure.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Tarjei T. Jensen]

"Hyman Rosen" wrote:
> The Ariane 4 code had a deliberately unprotected conversion from
> floating point to 16-bit integer, under the assumption that overflow
> could not happen. When the overflow did happen, the computer generated
> an Operand Fault.


You seem to be unable to grasp that for the Ariane 4 that was a sound
decision.

What you are want is for random software to work the same in two different
system.

Try moving an engine controller from one engine to another and se how well
that works.

Even better, ask somebody who are into aircraft if it would be a good idea
to move software from one airplane to another without testing whether it
works.


greetings,

Re: Ariane5 FAQ

[Tarjei T. Jensen]

Hyman Rosen wrote:
> Those same high managers got the Ariane 5 flying.

How do you know?

Re: Ariane5 FAQ

[Leif Roar Moldskred]

Hyman Rosen <hyrosen@mail.com> writes:

> Vinzent Hoefler wrote:
> > Well, one way or another - it did. It did exactly what is was supposed
> > to do.
> 
> No matter how many times people on this newsgroup repeat this,
> it will not become true. The code was written on the assumption
> that a certain parameter would never reach a particular value.

That's not quite correct. It was a limit, not an assumption. The
programmers didn't just assume that the argument would never exceed
the limit, they verified that this was in fact a real limit.

> Its behavior under the contrary assumption was left unspecified.
> It certainly did not do "what it was supposed to do" once the
> assumption was violated. The system pretended that a hardware
> error had happened.

When the fundamental boundaries of your software's design
specification is violated, there's no way it can "do what it's
supposed to do." By the definition of design specification, anything a
software is "supposed to do" lies within the boundaries of the
specification. The software performed to spec, which is the only
sensible way of saying it "did what it was supposed to do."

If a tank drives onto an ordinary road-bridge and the bridge collapses
under it, nobody is going to say that the bridge was flawed, or that
the engineers who built the bridge had made an error. The bridge was
completely fine - it just wasn't built to carry a tank. It is the tank
commander's fault for driving out on the bridge without making sure it
would bear.

-- 
Leif Roar Moldskred

Re: Ariane5 FAQ

[Vinzent Hoefler]

Richard Riehle wrote:

>Vinzent Hoefler wrote:
>
>Bertrand Meyer published a controversial article suggesting
>that, had they used design by contract ( a la Eiffel) this could
>not have happened.

Probably you also read
<URL:http://www.flash.net/~kennieg/ariane.html>?

>  While I don't agree that Eiffel would have
>been better for the job, a contract model such as that found in
>SPARK might have been successful in detecting the design
>error early on.

I would even doubt that, because the design was based on the
assumption that certain values would not exceed their range. The
programmers knew it wouldn't happen in normal operation, so I think it
is very likely they would have told the prover, it won't do that. So
it would have changed exactly nothing at this point.
But, *perhaps* it would have been slightly better documented because
someone should justify such a decision in the proof-process and so
some people might have taken a closer look at these assumptions and
then concluded "Houston, we've got a problem." ;) But that's just a
guess. Nobody seemed to check the requirements changes between the IRS
for Ariane 4 and 5 anyway...


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> Well, one way or another - it did. It did exactly what is was supposed
>> to do.
>
>No matter how many times people on this newsgroup repeat this,
>it will not become true.

It doesn't have to become true because it already is. :-P
 
>The code was written on the assumption
>that a certain parameter would never reach a particular value.

And that this would not happen in normal operation was perfectly true
for the Ariane 4.

>Its behavior under the contrary assumption was left unspecified.

No, AFAIK it wasn't. IIRC the system was specified to shut down and
send diagnostic data in this case. And that's what it did.

>It certainly did not do "what it was supposed to do" once the
>assumption was violated.

It did *exactly* what it was designed to do.

>The system pretended that a hardware
>error had happened.

Yes and if this would have happened on the Ariane 4 system, it would
have been exactly that - a hardware error.
And that's the whole point: The system was never designed for the
Ariane 5.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ariane5 FAQ

[John McCabe]

On Mon, 21 Jul 2003 21:57:40 -0700, Richard Riehle
<richard@adaworks.com> wrote:

>> >We have to assume that the Ariane 5 folks were not
>> >complete blithering idiots,
>
>Bertrand Meyer published a controversial article suggesting
>that, had they used design by contract ( a la Eiffel) this could
>not have happened.  While I don't agree that Eiffel would have
>been better for the job, a contract model such as that found in
>SPARK might have been successful in detecting the design
>error early on.

I doubt it.

>It is not the blithering idiots who make the kind of mistake
>that  triggered the Ariane V event.   Rather, it is usually a
>series of decisions, not well-managed or coordinated, by
>competent engineers.

Not even competent engineers. This descision was, according to the
report, "agreed at all levels". This includes managers who were
probably more interested in saving a few francs by not having to
re-develop the SRI than any technical reasons.

>In the end, the Ariane V event was a failure of engineering
>management, not of  individual engineers.  No amount of
>DbC, more careful design, better languages,  whatever, can
>compensate for incompetent engineering management.

Agreed.


Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: Ariane5 FAQ

[John McCabe]

On Tue, 22 Jul 2003 03:11:10 GMT, "Robert I. Eachus"
<rieachus@attbi.com> wrote:

>Vinzent Hoefler wrote:
>
>> Ok, so change the entire brake controller. ;-) What reason makes you
>> think, it will work?
>
>A better example would be to take a brake system from a car and put it 
>into a truck.  But the box for the brake system was labeled "for MVW up 
>to 5,000 pounds," and it is a 2 1/2 ton truck.

Or take the braking system for a Citroen 2CV and put it in a Ferrari
and see how safe it is there.



Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: Ariane5 FAQ

[John McCabe]

On Tue, 22 Jul 2003 01:59:29 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Bobby D. Bryant wrote:
>> You are merely restating the fact that they _did_ assume it, not giving a
>> reason for assuming it.
>
>Because I'm not a rocket scientist. But they are. I tend to assume
>that people who are in charge of rockets know something about waht
>they're doing, even if they occasionally make a mistake.

That's an unreasonable assumption. The people who are 'in charge' know
very little about rockets - they know about pounds/dollars/euros!




Best Regards
John McCabe

To reply by email replace 'nospam' with 'assen'

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Tue, 22 Jul 2003 09:05:22 +0000, John McCabe wrote:

> On Tue, 22 Jul 2003 03:11:10 GMT, "Robert I. Eachus"
> <rieachus@attbi.com> wrote:
> 
>>Vinzent Hoefler wrote:
>>
>>> Ok, so change the entire brake controller. ;-) What reason makes you
>>> think, it will work?
>>
>> A better example would be to take a brake system from a car and put it 
>> into a truck.  But the box for the brake system was labeled "for MVW up 
>> to 5,000 pounds," and it is a 2 1/2 ton truck.
> 
> Or take the braking system for a Citroen 2CV and put it in a Ferrari
> and see how safe it is there.

Or take a controller from a medium-sized rocket and put it in a big
rocket...

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Marin David Condic]

As a designer of realtime embedded systems that use sensors in a similar 
manner, I'd dispute that it was a "design error". It was a deliberate 
decision based on analysis of the flight path, etc., that arrived at a 
conclusion that any data big enough to trigger the overflow would most 
likely be caused by a bad sensor. We do this *all*the*time* when looking 
at data coming across an A/D or F/D converter - we range check it and if 
it is outside some expected range, we declare the sensor failed and 
transfer to the other channel. Hence, it was working exactly as designed 
- it detected what it thought was a bad sensor and took its 
pre-programmed accommodation.

On systems with a little more compute horsepower and better data 
communication links, it may have been possible to design alternative 
detection/accommodation schemes that would have avoided a false-detect. 
One might have cross-channeled the data and determined that *both* sides 
were seeing the same thing - but what accommodation would you take for a 
dual sensor failure? Shut down both units? It was built on a relatively 
slow 1750a microprocessor and they had to live within the limits of the 
compute power they had, so they devised a reasonable FDA scheme that 
would work well in the context for which it was designed.

At the end of the day the only logical conclusion to come to is that the 
software was properly designed for the Ariane 4 because it worked 
successfully there and in that context *would*have* done the proper 
thing had it seen the same data. (A ten amp fuse is *supposed* to blow 
when it sees more than ten amps. If you plug it into a twenty amp 
circuit, are you going to call that "bad design" on the part of the fuse 
engineers because it didn't do what it was "supposed to do" in this 
different application?) Putting it *untested* into the Ariane 5 was 
wherein the fault originated.

MDC


Richard Riehle wrote:
> not have happened.  While I don't agree that Eiffel would have
> been better for the job, a contract model such as that found in
> SPARK might have been successful in detecting the design
> error early on.



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Ariane5 FAQ

[Hyman Rosen]

John McCabe wrote:
> That's an unreasonable assumption. The people who are 'in charge' know
> very little about rockets - they know about pounds/dollars/euros!

If you reflect for a moment, you will realize that this
is exactly the attitude that the "meatball programming"
community had toward Ada when it first came out. It's
always tempting to believe that the people who are telling
you what to do are acting out of ignorance. My three-year
old does that all the time.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> So it seems to me that you would rather believe that project managers
> could be complete morons rather than believe that Ada programmers could
> fail to properly document their code. I know which I think is more likely,
> but feel free to believe as you like. It's a free country.

Both are possible.  But in this case, the (Ariane 4) Ada programmers not 
only documented their code correctly, they raised the issue of whether 
or not this was the correct behavior for this particular situation with 
their management, and the design engineers.

So was the final decision for the Ariane 4 correct?  I think so.  But to 
indicate that it wasn't carefully thought out, or documented, is specious.

As for the project managers on Ariane 5 being morons, I think that is 
also incorrect.  The key decision that doomed Ariane 501 was a political 
one.  (Not allowing the Ariane 4 SRI software designers access to the 
Ariane 5 requirements specs.)  So if you want to take away the idea that 
politicians do not make good system engineers, I can give you dozens of 
other, better examples.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Robert I. Eachus]

I wrote:

> A better example would be to take a brake system from a car and put it 
> into a truck.  But the box for the brake system was labeled "for MVW up 
> to 5,000 pounds," and it is a 2 1/2 ton truck.

For those unfamiliar with the terminology, a "deuce and a half" 2 1/2 
ton truck can carry 5000 pounds of cargo.  Actual MVW (maximum vehicle 
weight) including cargo passengers and fuel is around 10,000 pounds.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<AY0Ta.14787$0F4.7550@nwrdny02.gnilink.net>...
> Vinzent Hoefler wrote:
> > Well, one way or another - it did. It did exactly what is was supposed
> > to do.
> 
> No matter how many times people on this newsgroup repeat this,
> it will not become true. The code was written on the assumption
> that a certain parameter would never reach a particular value.
> Its behavior under the contrary assumption was left unspecified.
> It certainly did not do "what it was supposed to do" once the
> assumption was violated. The system pretended that a hardware
> error had happened.

No matter how many times you repeat this, it will not become true. 
The code was written to handle every possible value of the parameter
properly.  Why you refuse to acknowledge this is a mystery.  The only
problem was the the proper handling of the parameter, over a certain
range of values, for the Ariane 4 was not the proper handling of the
parameter for Ariane 5.

As yet another analogy (YAA?), consider a piston engine controller
designed for an engine with a redline of 5000 RPM, and assume the
controller has been designed to shut down the engine when 5000 RPM is
exceeded.  Put this controller on an engine with a redline of 8000 RPM
because "there's no reason not to think it will work" and watch what
happens in normal operation of that engine.  And then tell me it's the
fault of the engine controller software.

BTW, I don't know how software can "pretend" something.  The software
simply implemented the actions that the designers determined were
correct for that design.  Are you suggesting that the software really
knew, down deep in its heart of hearts, that there was no hardware
failure?

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<MO0Ta.14734$0F4.2752@nwrdny02.gnilink.net>...
> Alexander Kopilovitch wrote:
> > We know nothing about what Ariane 5 designers thought on this matter,
> > but we certainly know that their management expected that. So what?
> 
> So it seems to me that you would rather believe that project managers
> could be complete morons rather than believe that Ada programmers could
> fail to properly document their code. I know which I think is more likely,
> but feel free to believe as you like. It's a free country.

What evidence do you have that if the behavior (I refuse to call it a
limitation) had been better documented, anybody would have noticed,
and realized that it would be a problem for the Ariane 5?

Re: Ariane5 FAQ

[Hyman Rosen]

Mike Silva wrote:
> The code was written to handle every possible value of the parameter
> properly.  Why you refuse to acknowledge this is a mystery.

Because this was not the case. The code was written to handle the
limited range of parameters correctly, by doing a conversion from
floating-point to 16-bit integer without any guard against overflow.

When the Ariane 5 data caused an overflow, this same unprotected
conversion caused an operand fault, which the rest of the system
then interpreted as the computer itself being broken.

Notice that it's extremely unlikely that the top range of the
Ariane 4 value exactly corresponded to the maximum integer value
of the conversion output. That means that there was a range from
the top Ariane 4 value to the top non-overflowing value where the
software would have behaved one way, and a range above the
overflowing value where it would have behaved a different way.

The software worked as specified when the input was limited to
the specified range. Out of that range, the software worked in a
random, undefined manner.

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Tue, 22 Jul 2003 14:50:26 -0400, Hyman Rosen wrote:

> The software worked as specified when the input was limited to
> the specified range. Out of that range, the software worked in a
> random, undefined manner.

No, the software was designed to spill debug data in those circumstances. 
That data may have been garbage as far as the Ariane 5 was concerned, but
it was the intended behavior for the part.

The problem wasn't the software; the problem was an attempt to use the
software in an application that it wasn't spec'd to work for.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Hyman Rosen]

Tarjei T. Jensen wrote:
> What you are want is for random software to work
 > the same in two different system.

They didn't just move the software, they moved the hardware too.
I don't "want" anything. The investigatory report says that the
Ariane 4 SRI software and documentation failed to make obviously
clear its dependence on the details of the Ariane 4 flight path,
which helped lead to the assumption by the Ariane 5 people that
it would "just work". The failure to check for overflow in the
Ariane 4 code was not an essential part of its operation, but a
shortcut taken in order to reduce CPU usage. Software which has
such sensitive dependency on input is brittle and fragile, and
should accordingly come plastered with warning stickers.

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
> Incorrect.  The behavior was specified.  Shutdown the SRI and dump 
> diagnostic information, because this situation could only occur (in the 
> Ariane 4 at least) due to hardware failure.

Incorrect. For values between the top legal Ariane 4 value and the
maximum non-overflowing value, the SRI would not have shut down.
The behavior at the conversion point was undefined for values over
the Ariane 4 maximum, not specified.

Re: Ariane5 FAQ

[Hyman Rosen]

Mike Silva wrote:
> What evidence do you have that if the behavior (I refuse to call it a
> limitation) had been better documented, anybody would have noticed,
> and realized that it would be a problem for the Ariane 5?

The findings of the investigatory board, which say that.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1058899826.878512@master.nyc.kbcfp.com>...
> Mike Silva wrote:
> > The code was written to handle every possible value of the parameter
> > properly.  Why you refuse to acknowledge this is a mystery.
> 
> Because this was not the case. The code was written to handle the
> limited range of parameters correctly, by doing a conversion from
> floating-point to 16-bit integer without any guard against overflow.
> 
> When the Ariane 5 data caused an overflow, this same unprotected
> conversion caused an operand fault, which the rest of the system
> then interpreted as the computer itself being broken.

Which was the intended behavior.  There was a project bias that any
unhandled errors were presumed to indicate hardware failure.
> 
> Notice that it's extremely unlikely that the top range of the
> Ariane 4 value exactly corresponded to the maximum integer value
> of the conversion output. That means that there was a range from
> the top Ariane 4 value to the top non-overflowing value where the
> software would have behaved one way, and a range above the
> overflowing value where it would have behaved a different way.

That's right, but it doesn't change anything.  Maybe the Ariane 4
developers were perfectly happy to let those particular "impossible"
values pass through the system, or maybe they should have caught them
as well.  That doesn't change the fact that the system behaved as
designed and intended for the overflowing values.
> 
> The software worked as specified when the input was limited to
> the specified range. Out of that range, the software worked in a
> random, undefined manner.

The behavior of the module over the entire possible range of inputs
was neither random nor undefined.

Re: Ariane5 FAQ

[Hyman Rosen]

Mike Silva wrote:
> The behavior of the module over the entire possible range of inputs
> was neither random nor undefined.

Sure it was. It entered what digital circuit designers call
a "don't care" state. The designers of the code didn't need
to specify the behavior above the Ariane 4 limit, and didn't.
The code behaved in the same arbitrary way that a C program
does when presented with the same sort of overflow. It happened
to be running on a processor which faulted on overflow, and so
the overflow caused the subsequent events, but in no way is that
a designed property of the code.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> They didn't just move the software, they moved the hardware too.
> I don't "want" anything. The investigatory report says that the
> Ariane 4 SRI software and documentation failed to make obviously
> clear its dependence on the details of the Ariane 4 flight path,
> which helped lead to the assumption by the Ariane 5 people that
> it would "just work". The failure to check for overflow in the
> Ariane 4 code was not an essential part of its operation, but a
> shortcut taken in order to reduce CPU usage. Software which has
> such sensitive dependency on input is brittle and fragile, and
> should accordingly come plastered with warning stickers.

Why, why, do you keep spouting this nonsense?  The documentation for the 
SRI software not only showed a dependence on the Ariane 4 flight path, 
but it explicitly stated that it had not been checked against the Ariane 
5 requirements.

The massive failure was the direct result of the political and 
management decisions which prevented the (Ariane 4 project) SRI 
engineers from seeing the Ariane 5 requirements, and prevented all the 
engineers, software, hardware, and test employed on the Ariane 5 
development from ever seeing the Ariane 4 SRI documentation.

Now I could go on long and loud about a contract situation where the 
Ariane 4 SRI upgrade was performened under those circumstances.  But I 
wouldn't expect it to have these consequences.  It was the combination 
of several separate management decisions, each of which can be 
criticised in hindsight, but all with the same engineering consequence, 
the Ariane 5 REQUIREMENTS were never compared to the Ariane 4 SRI 
SPECIFICATION.  If that had happened several major problems INCLUDING 
this one would have been discovered.

In fact, the actual failure was caused by another of these mismatches. 
The software for the engine controllers was set to take the data from 
the SRI, compare it to the (current) stack limits then pass either the 
maximum permitted deflection or the requested deflection to the servos.

So what happened when the engine controllers got junk data?  The engines 
were deflected to the structural limit for the Ariane 4 stack at this 
point in its flight profile.  Of course, the Ariane 5 stack was bigger, 
the aerodynamic stresses greater, and it disintegrated.  Then the range 
safety officer triggered the self-destruct.  The same thing could have 
happened if Ariane 501 had hit wind shear.

Also the SRI software used the Ariane 4 moments of inertia in its 
control laws.  The report seems to indicate that there was a 10 Hz 
ocillation building up due to this.  If it had gone on would that have 
been sufficient to destroy Ariane 501?  Probably.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Tue, 22 Jul 2003 17:11:05 -0400, Hyman Rosen wrote:

> Mike Silva wrote:
>> The behavior of the module over the entire possible range of inputs was
>> neither random nor undefined.
> 
> Sure it was. It entered what digital circuit designers call a "don't
> care" state. The designers of the code didn't need to specify the
> behavior above the Ariane 4 limit, and didn't. The code behaved in the
> same arbitrary way that a C program does when presented with the same
> sort of overflow. It happened to be running on a processor which faulted
> on overflow, and so the overflow caused the subsequent events, but in no
> way is that a designed property of the code.

Actually it was -- if I understand the report correctly.  CPU time was an
issue, so they _deliberately_ left in some don't-care states for numbers
not physically obtainable, rather than adding the small overhead of a
check.

But you are picking nits that fall far from your original objection to
Alexandre's claim that "there were no reasons to expect that it should
work for this new rocket".  The simple fact is that the project completely
skipped over the steps of asking whether it should be expected to work and
then looking to see what the answer was.  Merely assuming that software
(or other rocket components) will work is neither sensible nor safe: you
need good engineering to give you a _reason_ to expect it to work.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:
> Mike Silva wrote:
> 
>> What evidence do you have that if the behavior (I refuse to call it a
>> limitation) had been better documented, anybody would have noticed,
>> and realized that it would be a problem for the Ariane 5?
> 
> 
> The findings of the investigatory board, which say that.


Where? As far as I can tell there are no FINDINGS like that. Especially 
in an accident investigation, finding has a limited and well defined 
meaning. The findings (section 3.1) related to the failure are:

13. The inertial reference system of Ariane 5 is essentially common to a 
system which is presently flying on Ariane 4. The part of the software 
which caused the interruption in the inertial system computers is used 
before launch to align the inertial reference system and, in Ariane 4, 
also to enable a rapid realignment of the system in case of a late hold 
in the countdown. This realignment function, which does not serve any 
purpose on Ariane 5, was nevertheless retained for commonality reasons 
and allowed, as in Ariane 4, to operate for approx. 40 seconds after 
lift-off.
14. During design of the software of the inertial reference system used 
for Ariane 4 and Ariane 5, a decision was taken that it was not 
necessary to protect the inertial system computer from being made 
inoperative by an excessive value of the variable related to the 
horizontal velocity, a protection which was provided for several other 
variables of the alignment software. When taking this design decision, 
it was not analysed or fully understood which values this particular 
variable might assume when the alignment software was allowed to operate 
after lift-off.
15. In Ariane 4 flights using the same type of inertial reference system 
there has been no such failure because the trajectory during the first 
40 seconds of flight is such that the particular variable related to 
horizontal velocity cannot reach, with an adequate operational margin, a 
value beyond the limit present in the software.
16. Ariane 5 has a high initial acceleration and a trajectory which 
leads to a build-up of horizontal velocity which is five times more 
rapid than for Ariane 4. The higher horizontal velocity of Ariane 5 
generated, within the 40-second timeframe, the excessive value which 
caused the inertial system computers to cease operation.
17. The purpose of the review process, which involves all major partners 
in the Ariane 5 programme, is to validate design decisions and to obtain 
flight qualification. In this process, the limitations of the alignment 
software were not fully analysed and the possible implications of 
allowing it to continue to function during flight were not realised.
18. The specification of the inertial reference system and the tests 
performed at equipment level did not specifically include the Ariane 5 
trajectory data. Consequently the realignment function was not tested 
under simulated Ariane 5 flight conditions, and the design error was not 
discovered.
19. It would have been technically feasible to include almost the entire 
inertial reference system in the overall system simulations which were 
performed. For a number of reasons it was decided to use the simulated 
output of the inertial reference system, not the system itself or its 
detailed simulation. Had the system been included, the failure could 
have been detected.

Incidently, note that in finding 17, it only speaks about Ariane 5 
programme reviews, not the ones done for Ariane 4.  Similarly findings 
14-16 should be considered as a group, or you get the wrong impression.

-- 

                                            Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Larry Elmore]

Hyman Rosen wrote:
> Vinzent Hoefler wrote:
> 
>> Well, one way or another - it did. It did exactly what is was supposed
>> to do.
> 
> 
> No matter how many times people on this newsgroup repeat this,
> it will not become true. The code was written on the assumption
> that a certain parameter would never reach a particular value.
> Its behavior under the contrary assumption was left unspecified.
> It certainly did not do "what it was supposed to do" once the
> assumption was violated. The system pretended that a hardware
> error had happened.

Hardware failure was considered to be the only way that that parameter 
could go out of range on the Ariane 4. It was a design decision that in 
that case, there was no point in handling that exception in software. It 
was not an oversight. It did what it was supposed to do -- if it was 
flying on an Ariane 4.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> No, AFAIK it wasn't. IIRC the system was specified to shut down and
> send diagnostic data in this case. And that's what it did.

The system was designed to treat any exception as a hardware fault
and shut down. The overlow in the BH paramater caused an exception
which led to a shutdown, but it's too much of a stretch to say that
this was part of the specified behavior, since the overflow was not
supposed to happen.

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Wed, 23 Jul 2003 00:13:16 +0000, Hyman Rosen wrote:

> Vinzent Hoefler wrote:
>> No, AFAIK it wasn't. IIRC the system was specified to shut down and
>> send diagnostic data in this case. And that's what it did.
> 
> The system was designed to treat any exception as a hardware fault and
> shut down. The overlow in the BH paramater caused an exception which led
> to a shutdown, but it's too much of a stretch to say that this was part
> of the specified behavior, since the overflow was not supposed to
> happen.

Which brings us directly back to Alexandre's "there were no reasons to
expect that it should work for this new rocket", which you objected to so
strenuously at the start of this tread.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Tarjei T. Jensen]

Robert I. Eachus  wrote:
> Also the SRI software used the Ariane 4 moments of inertia in its
> control laws.  The report seems to indicate that there was a 10 Hz
> ocillation building up due to this.  If it had gone on would that have
> been sufficient to destroy Ariane 501?  Probably.

I believe that I saw a program on Discovery in which it was claimed that the
oscilations would eventually have destroyed the rocket.


greetings,

Re: Ariane5 FAQ

[Hyman Rosen]

Bobby D. Bryant wrote:
> Which brings us directly back to Alexandre's "there were no reasons to
> expect that it should work for this new rocket", which you objected to so
> strenuously at the start of this tread.

No, because there is a great deal of difference between the statements
     "there were no reasons to expect that this would work"
and
     "there were reasons why it did not work".

Re: Ariane5 FAQ

[Hyman Rosen]

Bobby D. Bryant wrote:
> But you are picking nits that fall far from your original objection to
> Alexandre's claim that "there were no reasons to expect that it should
> work for this new rocket".  The simple fact is that the project completely
> skipped over the steps of asking whether it should be expected to work and
> then looking to see what the answer was.  Merely assuming that software
> (or other rocket components) will work is neither sensible nor safe: you
> need good engineering to give you a _reason_ to expect it to work.

They are certainly at fault for not having done the proper testing,
but had they done so, it would have revealed that the good reasons
they had for expecting things to just work were in fact not true,
not that they had no reason to expect it to work.

Re: Ariane5 FAQ

[Hyman Rosen]

Larry Elmore wrote:
> It was a design decision that in that case, there was no point in
 > handling that exception in software. It was not an oversight. It
 > did what it was supposed to do -- if it was flying on an Ariane 4.

If the value of the parameter had exceeded the Ariane 4 maximum but
was less than the 16-bit maximum, there would have been no exception
at all at the conversion point, and the too-high value would have
gone through the rest of the system, doing something else. There was
nothing in the code to handle a too-large value. The code would simply
barge ahead, either working or causing exceptions depending on the
exact number. You may wish to call that behavior "doing what it was
supposed to do" but I think that's a mischaracterization.

I'm not saying that the Ariane 4 people did anything unsuitable for
the Ariane 4. But doing it this way made the code brittle.
The investigation board said
    "No reference to justification of this decision was found
     directly in the source code. Given the large amount of
     documentation associated with any industrial application,
     the assumption, although agreed, was essentially obscured,
     though not deliberately, from any external review."

This is exactly the kind of coding practice that leads to problems
like integer overflow, buffer overflow, and Y2K issues. Shortcuts
are taken in order to optimize a program for local conditions, but
the dependencies are not communicated properly to people who then
go on to use the code in situations where the local conditions no
longer apply.

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
> Where? As far as I can tell there are no FINDINGS like that.

Sigh. We're down do niggling on section titles now.

     2.2 COMMENTS ON THE FAILURE SCENARIO
     ... No reference to justification of this decision was found
         directly in the source code. Given the large amount of
         documentation associated with any industrial application,
         the assumption, although agreed, was essentially obscured,
         though not deliberately, from any external review.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>If the value of the parameter had exceeded the Ariane 4 maximum but
>was less than the 16-bit maximum, there would have been no exception
>at all at the conversion point, and the too-high value would have
>gone through the rest of the system, doing something else.

It would have handled that value as correct reading from the sensor.

I don't see, how someone can avoid such problem. I mean, if, for
instance, I read an indoor-temperature sensor, it might be reasonable
to assume, that the read value will always be below 128 degrees
(Celsius) if the sensor is working, so that I can use a 8-bit-value to
store the reading. Now what, if we want to protect against a possible
overflow? How would you handle that?
Personally I think, just reading the value and calculating with it,
even if the reading says 95 degrees is a quite reasonable decision.
And it is also a very reasonable decision to say: If *that* reading
overflows my 8 bits within I can handle it, *then* the sensor must
definitely be broken. The room cannot get that warm. [Except in case
of fire perhaps... ;)].
So even if you specify an arbitrary lower limit (let's say, 60 degrees
Celsius) as reasonable maximum reading, you will *always* get some
sort of grey range, where you cannot really tell if the sensor is
broken or its reading is indeed correct. So what do you do, if you set
the reasonable limit to 60 and you read 59? Assume that the value read
is ok or already assume that the sensor must be broken? What, if you
then lower this "reasonable" limit accordingly?

Another example: If I count the flying time of an aircraft in a 32 Bit
value in seconds, I can tell with a very high probability, if that
counter overflows it *must* be an error, because no plane would be
able to fly 130+ years in a single session. But the decision for a
certain point when a particular flying time (24 hours?, 48 hours?,
three weeks?) makes sense or not is indefinitely harder to make.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> I don't see, how someone can avoid such problem.

By having lots of meetings, and coming up with a
definite specification for what to do. The result
will be some hard numbers - if the reading is less
than this, it's good, otherwise it's suspect. Then
the code is written to implement the decision.

It's also perfectly valid to say "go ahead and write
this code as if this variable will never exceed this
value". The first way detects the problem at the
point where the bad value is noticed, while the second
way propogates the bad value through the program, so
that it will behave in some arbitrary way.

Now, often that arbitrary way will in retrospect be
exactly what you wanted, while the range check could
cause an entire abort, so it's not a given which
approach to use. In the Ariane 5 case, it turned out
that this approach caused an unhappy outcome.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> By having lots of meetings, and coming up with a
> definite specification for what to do. The result
> will be some hard numbers - if the reading is less
> than this, it's good, otherwise it's suspect. Then
> the code is written to implement the decision.

WHICH IS EXACTLY WHAT HAPPENED.  I don't know why you keep running 
around trying to defend the indefensible.  But since you don't seem to 
know what went on, let me tell you, from the Ariane 4 point of view.

The software module involved was used for aligning the gyroscopes, etc. 
before launch.  It took over an hour of data to do its job.  When it was 
finished BH was set equal to zero, and was reset to zero continously 
until launch.

In the Ariane 4, there was a possibility that the launch could be 
aborted within 6 seconds of engine ignition.  In such a case, the 
problem that caused the abort could be corrected and the launch 
countdown restarted quickly.  But then it would have to delay until the 
alignment software had been restarted and realigned the guidance system. 
    So the decision was made to run the alignment software for a period 
after T=0, but not too long.  Lots of calculations were done, and the 
decision was made to run it until T = +40 seconds.  This allowed time 
for the guidance system to reset after an abort, and also insured that, 
for physical reasons BH would never overflow.

This (late abort) actually happened on at least one Ariane 4 launch with 
this guidance system. The guidance system was reset and launch proceeded 
with minimal delay.  All of this was well documented--in the Ariane 4 
REQUIREMENTS.  This was clearly a requirement, and was documented as such.

> It's also perfectly valid to say "go ahead and write
> this code as if this variable will never exceed this
> value". The first way detects the problem at the
> point where the bad value is noticed, while the second
> way propogates the bad value through the program, so
> that it will behave in some arbitrary way.

As I said, this was not arbitrary behavior, it was required behavior.

> Now, often that arbitrary way will in retrospect be
> exactly what you wanted, while the range check could
> cause an entire abort, so it's not a given which
> approach to use. In the Ariane 5 case, it turned out
> that this approach caused an unhappy outcome.

Because the Ariane 5 first stange engines were more powerful with regard 
to the weight of the total system, this was definitely not a requirement 
for Ariane 5.  In fact a late abort would probably spatter rocket and 
payload all over the launch pad.  So compared to the Ariane 4, the 
Ariane 5 was committed to launch at the same point in the countdown. 
(After engine ignition but before full thrust.)

It all comes back to the same issue and the real failure.  The (SRI) 
hardware was the same, but the engines and the rest of the Ariane 5 were 
significantly different from the Ariane 4.  This resulted in different 
REQUIREMENTS.  The SRI and its software were never checked to see if 
they met the Ariane 5 requirements.  That was the major and sole cause 
of the disaster.

Technically the bounds checking on the engine deflections was expected 
to be done in the main computer.  But if the requirements check had been 
done, the potential for the SRI to command engine deflections too 
extreme for the Ariane 5 would have been noticed.  Whether the limiting 
was done in the SRI or the main computer, a requirements review would 
insure that the requirement for limiting the engine deflections was met.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Robert I. Eachus]

Tarjei T. Jensen wrote:
> Robert I. Eachus  wrote:
> 
>>Also the SRI software used the Ariane 4 moments of inertia in its
>>control laws.  The report seems to indicate that there was a 10 Hz
>>ocillation building up due to this.  If it had gone on would that have
>>been sufficient to destroy Ariane 501?  Probably.

> I believe that I saw a program on Discovery in which it was claimed that the
> oscilations would eventually have destroyed the rocket.

As I said, probably.  But if it didn't, the oscillations would result in 
the Ariane 5 not reaching the expected orbit.  Less dramatic, but just 
as fatal for the payload.

And that is why I keep posting on this topic, hoping that everyone will 
"get it."  The actual failure scenario is interesting, but the fact that 
there were two others waiting to happen means that you should look at 
what they all have in commmon:  The missing "scrub" of the SRI 
specifications against the Ariane 5 requirements.  We are talking about 
something that should have taken about a week for three or four people, 
if there were no major discrepancies.  Of course, in this case, the bill 
would have been higher, but a lot less than the bill for the failure.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Simon Wright]

Hyman Rosen <hyrosen@mail.com> writes:

> They took a piece of self-contained hardware and moved it
> from one rocket to another. They thought the software would
> work. We have to assume that the Ariane 5 folks were not
> complete blithering idiots, so they must have has readsons
> to assume it would work.

So what if it had been a hardware problem? (say, an op amp going
unstable because of inputs exceeding design parameters).

You have had pointed out to you many, many times that the Ariane 5
people who would have been expected to do the checking were not
permitted to -- by blithering idiots, one has to assume -- and you
can't seem to get the point. you are plainly a troll. *plonk*

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> Sigh. We're down do niggling on section titles now.
> 
>     2.2 COMMENTS ON THE FAILURE SCENARIO
>     ... No reference to justification of this decision was found
>         directly in the source code. Given the large amount of
>         documentation associated with any industrial application,
>         the assumption, although agreed, was essentially obscured,
>         though not deliberately, from any external review.

No, I am trying to explain the difference to you, and why you need to 
read the report carefully.  First, read the next two paragraphs:

"...It is important to note that the decision to protect certain 
variables but not others was taken jointly by project partners at 
several contractual levels.

"There is no evidence that any trajectory data were used to analyse the 
behaviour of the unprotected variables, and it is even more important to 
note that it was jointly agreed not to include the Ariane 5 trajectory 
data in the SRI requirements and specification."

It should be clear to you from the above that it WAS well documented in 
the SRI specifications.  However, no one, prior to the failure, ever had 
access to both the SRI specification and the Ariane 5 requirements.

What the part that you quoted is pointing out, is that there were 
people, those who wrote the software for the guidance system testing 
that simulated the SRI, who might have noticed the problem if it had 
been documented in the source code.

Yes, this is an important point to include in the report because it 
shows another group of engineers, in this case test engineers, should be 
held blameless.  If the "full up" tests using that software had been 
run, yes, the that problem would have shown up.  As for that matter 
would the oscillations.  But the decision to cancel those tests was not 
made by the engineers, it was made for financial reasons.

But as I said, you should look at the findings.  And the key finding 
IMHO are 18 and 20:

"18. The specification of the inertial reference system and the tests 
performed at equipment level did not specifically include the Ariane 5 
trajectory data...

(The SRI specification did not include any Ariane 5 requirements.)

"19. It would have been technically feasible to include almost the 
entire inertial reference system in the overall system simulations which 
were performed. For a number of reasons it was decided to use the 
simulated output of the inertial reference system, not the system itself 
or its detailed simulation. Had the system been included, the failure 
could have been detected.

(IMHO, this is more important for the oscillation problem.  But the key 
part in there is: "...not the system itself or its detailed simulation." 
   There are technical reasons that argue against including the actual 
SRI.  But the Ariane 4 project used a detailed simulation of the SRI in 
their group, and this detailed simulation was NOT reused in the Ariane 5 
testing.)

"20. Post-flight simulations have been carried out on a computer with 
software of the inertial reference system and with a simulated 
environment, including the actual trajectory data from the Ariane 501 
flight. These simulations have faithfully reproduced the chain of events 
leading to the failure of the inertial reference systems."

(In other words, if the tests in the original test plan had been run, 
the actual failure mode would have been detected before launch.)

So three chances to catch the problem--ALL of which should have been 
done--and all missed due to the structure of the project management and 
its financing.  Even though when the upgraded SRI for the Ariane 4 was 
contracted, it was known that it would be reused by the Ariane 5, the 
decision was to budget the development as Ariane 4 only.  This is why 
the SRI developers did not have access to the Ariane 5 performance data, 
and the Ariane 5 project did not have access to the test software 
developed for the Ariane 4.

-- 

                                             Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
> As I said, this was not arbitrary behavior, it was required behavior.

*What* was required behavior? You have a piece of code that says
     integer_BH = convert(float_BH)
The analysis and specification of the Ariane 4 gave a physical
upper limit to float_BH, and the code was written in the "don't
care" way - if for some reason float_BH does exceed the limit,
let the code go ahead and do whatever the consequences of
violating that limit imply. If float_BH is larger than the limit
but smaller than the overflow value, the code keeps going,
possibly failing at a later point or possibly not causing any
harm. If float_BH is larget than the overflow value, the
machine generates an operand fault.

There's nothing wrong with having code like that if the
situation warrants it, which was the case in Ariane 4, where
they were trying to save the machine cycles that a limit
check would have cost. It's just that this kind of code is
brittle, so these dependencies on the state of external
data need to be made very clear, otherwise future reuse
attempts will stumble.

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
 > Even though when the upgraded SRI for the Ariane 4 was
> contracted, it was known that it would be reused by the
 > Ariane 5, the decision was to budget the development as
 > Ariane 4 only.

That's all the more reason that the statement "there was
no reason to assume that it would work in the Ariane 5"
is false.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1058969472.350716@master.nyc.kbcfp.com>...
> 
> I'm not saying that the Ariane 4 people did anything unsuitable for
> the Ariane 4. But doing it this way made the code brittle.
> The investigation board said
>     "No reference to justification of this decision was found
>      directly in the source code. Given the large amount of
>      documentation associated with any industrial application,
>      the assumption, although agreed, was essentially obscured,
>      though not deliberately, from any external review."
> 
> This is exactly the kind of coding practice that leads to problems
> like integer overflow, buffer overflow, and Y2K issues. Shortcuts
> are taken in order to optimize a program for local conditions, but
> the dependencies are not communicated properly to people who then
> go on to use the code in situations where the local conditions no
> longer apply.

So you are arguing that, lacking written documentation to the
contrary, any piece of code should be assumed capable of handling all
possible input values in a way that is appropriate to all possible
systems in which the code is employed.  Tell me, honestly, would you
fly in a rocket designed under such assumptions?

No matter how many times you argue your case (and you do get points
for tenaciousness!) the fact is that the code did the right thing for
the Ariane-4 system, and the Ariane-5 people had no legitimate reason
to assume that what the code did would also be right in the Ariane-5
system.  As has been pointed out, there were other portions of the
(correct) Ariane-4 software which were also used without legitimate
justification in the -5, and would probably also, in their turn, have
destroyed the -5.

Re: Ariane5 FAQ

[Hyman Rosen]

Mike Silva wrote:
> So you are arguing that, lacking written documentation to the
> contrary, any piece of code should be assumed capable of handling all
> possible input values in a way that is appropriate to all possible
> systems in which the code is employed.  Tell me, honestly, would you
> fly in a rocket designed under such assumptions?

But we're not talking about "any-all". This was a combined
hardware and software module being moved from one rocket
version to the next.

> the Ariane-5 people had no legitimate reason to assume that what
 > the code did would also be right in the Ariane-5 system.

And yet they acted that way. That argues that they did have
a legitimate reason. Even though it turned out to be wrong
in retrospect. As I keep saying, there is a difference between
"no reason to assume it will work" and "reasons why it will
not work".

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

>> As I said, this was not arbitrary behavior, it was required behavior.
> 
> 
> *What* was required behavior? You have a piece of code that says
>     integer_BH = convert(float_BH)
> The analysis and specification of the Ariane 4 gave a physical
> upper limit to float_BH, and the code was written in the "don't
> care" way - if for some reason float_BH does exceed the limit,
> let the code go ahead and do whatever the consequences of
> violating that limit imply. If float_BH is larger than the limit
> but smaller than the overflow value, the code keeps going,
> possibly failing at a later point or possibly not causing any
> harm. If float_BH is larget than the overflow value, the
> machine generates an operand fault.

No, if the value to be assigned to BH is out of range (presumed to 
happen with the rocket on the ground, shut down THIS SRI and report the 
(presumed hardware) error and diagnostics via the only channel the SRI 
has for talking to the main computer. Remember this software ran for 
hours before launch and a few seconds after, and bad alignment data, for 
whatever reason, if detected before launch will have the effect of 
delaying the launch while the system engineers look at that diagnostic 
information to find out where the problem is.

This must be what is confusing you.  There are hundreds of opportunities 
for the SRI to detect hardware failures, loose wires, or whatever before 
launch.  The special circumstances here were that this piece of 
"pre-launch" software ran for about 40 seconds after launch.  For the 
Ariane 5, that was 40 seconds too long, and for Ariane 501, a 30 or 35 
second limit would have averted the disaster--but the right limit was 
zero seconds.  On Ariane 4 there were several times where this behavior 
(shutting down and supplying diagnostics) prevented launching with bad 
hardware, and one time where the feature of running after main engine 
ignition was needed.

Detecting hardware faults before launch is not "don't care" it is very 
important.  I won't go into the calculations, but reducing the time 
between when all hardware is "known good" and the time it is used 
increases the probability of a successful launch from microscopic to 
over 90%.  All that hardware testing and checking just before launch is 
important.

> There's nothing wrong with having code like that if the
> situation warrants it, which was the case in Ariane 4, where
> they were trying to save the machine cycles that a limit
> check would have cost. It's just that this kind of code is
> brittle, so these dependencies on the state of external
> data need to be made very clear, otherwise future reuse
> attempts will stumble.

That whole discussion of "protecting" the value of BH is really a red 
herring in the Ariane 5 case.  In the Ariane 4, if they had put in the 
"protection" what it would have done was to check whether or not this 
was a "critical" failure.  Guess what?  The answer was yes.  If one of 
the computers has faulty accelerometer or gyro data?  Shift to the 
backup.  If both computers have bad input data that early in the flight? 
  The conclusion would be that the mission will fail.  Late in the boost 
phase, the SRI might try to do "dead reckoning" for the last few seconds 
of burn.

But you have to understand this part of the discussion of the seven 
unprotected conversions of which four were changed to protected.  The 
point is not "oops we missed this one."  It is that very careful 
consideration was given by reviews at several levels in the context of 
the Ariane 4, and the conclusion was that for this failure, this was the 
right answer.  It wasn't accidental, or "don't care."  It was if you see 
this value something is bad wrong, and maybe it can be figured out from 
a data dump.

Obviously if the same engineers had the Ariane 5 trajectory data, they 
WOULD have reached a different conclusion:

exception
   when others => if Ariane_Model = 4 then raise; else null; end if;

or more likely to insure that the alignment software shut down at T=+40 
on the Ariane 4, and at T=0, or maybe even T=-3 on the Ariane 5.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:
> Mike Silva wrote:
> 
>> So you are arguing that, lacking written documentation to the
>> contrary, any piece of code should be assumed capable of handling all
>> possible input values in a way that is appropriate to all possible
>> systems in which the code is employed.  Tell me, honestly, would you
>> fly in a rocket designed under such assumptions?
> 
> 
> But we're not talking about "any-all". This was a combined
> hardware and software module being moved from one rocket
> version to the next.
> 
>> the Ariane-5 people had no legitimate reason to assume that what
> 
>  > the code did would also be right in the Ariane-5 system.
> 
> And yet they acted that way. That argues that they did have
> a legitimate reason. Even though it turned out to be wrong
> in retrospect. As I keep saying, there is a difference between
> "no reason to assume it will work" and "reasons why it will
> not work".

Yes, several someones assumed that the software HAD been designed with 
the Ariane 4 and Ariane 5 requirements in mind.  But a 
political/financial decision was made not to allow the team developing 
the SRI to have access to the Ariane 5 performance data.

The reasoning behind that decision was that it would give them a leg up 
on other bidders for portions of the Ariane 5 software development. 
This was probably true.  So the requirements scrub should have been done 
by the Ariane 5 developers.  But that never got done because they did 
not have access to the SRI documentation, just the source code.  THAT 
was the monumental stupid blunder.  Eliminating (for financial reasons) 
the scheduled tests in which the guidance system would be ground tested 
with Ariane 5 trajectory data was the (third) shoe.  It took all three 
pieces to make a disaster, and there is (fairly obviously) no evidence 
of collusion.

-- 

                                           Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
>  > ...the decision was to budget the development as
>  > Ariane 4 only.
> 
> That's all the more reason that the statement "there was
> no reason to assume that it would work in the Ariane 5"
> is false.

No, the last part of what I said is exactly why it was true.  The SRI 
upgrade project had no access to the Ariane 5 performance data, and this 
was a decision made by Arianespace, not by any contractor.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Bobby D. Bryant]

On Wed, 23 Jul 2003 19:24:17 +0000, Robert I. Eachus wrote:

> Tarjei T. Jensen wrote:
>> Robert I. Eachus  wrote:
>> 
>>>Also the SRI software used the Ariane 4 moments of inertia in its
>>>control laws.  The report seems to indicate that there was a 10 Hz
>>>ocillation building up due to this.  If it had gone on would that have
>>>been sufficient to destroy Ariane 501?  Probably.
> 
>> I believe that I saw a program on Discovery in which it was claimed
>> that the oscilations would eventually have destroyed the rocket.
> 
> As I said, probably.  But if it didn't, the oscillations would result in
> the Ariane 5 not reaching the expected orbit.  Less dramatic, but just
> as fatal for the payload.
> 
> And that is why I keep posting on this topic, hoping that everyone will
> "get it."  The actual failure scenario is interesting, but the fact that
> there were two others waiting to happen means that you should look at
> what they all have in commmon:  The missing "scrub" of the SRI
> specifications against the Ariane 5 requirements.  We are talking about
> something that should have taken about a week for three or four people,
> if there were no major discrepancies.

And of course, if there *were* major discrepancies it becomes even more
important to have done it.

> Of course, in this case, the bill would have been higher, but a lot less
> than the bill for the failure.

-- 
Bobby Bryant
Austin, Texas

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
> It was if you see this value something is bad wrong,
 > and maybe it can be figured out from a data dump.

But the Ariane 4 code was not written such that a value
exceeding the assumed Ariane 4 range would cause such a
dump. The code was written to assume that the value would
not be exceeded, and to let the code do whatever it might
if the value was exceeded. A value between the spec max
and the overflow min would (probably) not have caused such
a dump.

The code did "what it was designed to do" only on an Ariane 4.
On the Ariane 5, it did not do "what it was designed to do"
because the design did not cover out of range values. If the
design had covered such values, it would not have specified
one behavior for small large values and a different behavior
for large large values.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1058996131.223000@master.nyc.kbcfp.com>...
> Mike Silva wrote:
> > So you are arguing that, lacking written documentation to the
> > contrary, any piece of code should be assumed capable of handling all
> > possible input values in a way that is appropriate to all possible
> > systems in which the code is employed.  Tell me, honestly, would you
> > fly in a rocket designed under such assumptions?
> 
> But we're not talking about "any-all". This was a combined
> hardware and software module being moved from one rocket
> version to the next.

Rocket versions are almost certainly "all possible systems in which
the code is employed."  Change it to "all possible systems in which
the subsystem is employed" if you want.  You are still demanding that
the Ariane-4 people look into the future, rather than demanding that
the Ariane-5 people look into the past.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<cQGTa.22160$0F4.6803@nwrdny02.gnilink.net>...
> Robert I. Eachus wrote:
> > It was if you see this value something is bad wrong,
>  > and maybe it can be figured out from a data dump.
> 
> But the Ariane 4 code was not written such that a value
> exceeding the assumed Ariane 4 range would cause such a
> dump. The code was written to assume that the value would
> not be exceeded, and to let the code do whatever it might
> if the value was exceeded. A value between the spec max
> and the overflow min would (probably) not have caused such
> a dump.
> 
> The code did "what it was designed to do" only on an Ariane 4.
> On the Ariane 5, it did not do "what it was designed to do"
> because the design did not cover out of range values. If the
> design had covered such values, it would not have specified
> one behavior for small large values and a different behavior
> for large large values.

It's perfectly normal to leave a margin of error, so that values
"near" the calculated allowable values are treated in a different and
less drastic way than values "far" from the calculated allowable
values (and a 64-bit float can range very very "far" from +/-32767). 
The tradeoff between OTOH rejecting a value that is in reality good,
and accepting a value that is in reality bad, is always one that has
to be made.  The Ariane-4 people were presumably happy with the
tradeoff that resulted from the natural buffer which existed between
their max calculated value of BH and the inherent range of a 16-bit
integer.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> I don't see, how someone can avoid such problem.
>
>By having lots of meetings, and coming up with a
>definite specification for what to do. The result
>will be some hard numbers - if the reading is less
>than this, it's good, otherwise it's suspect.

It is supect. And what to do, if you *suspect* a wrong value? Pop up a
window and let a human operator confirm, everything is still good?
Please also take limited CPU-time into your considerations.

>Then
>the code is written to implement the decision.

I got code here that controls a DAC and the maximum value is (of
course) 255. I *know* that this will never be reached in real world
cases, so if someone comes up with the 255 or even larger it *must* be
wrong.

But to decide when exactly a particular value is really wrong or not
is indefinitely harder to make. There is a gray area and you really
don't want to implement some fuzzy logic in such CPUs.

>It's also perfectly valid to say "go ahead and write
>this code as if this variable will never exceed this
>value".

Yes. But you should ask, what are the results of the rest of the code,
if it exceeds the limit? They don't make sense anymore.

>Now, often that arbitrary way will in retrospect be
>exactly what you wanted, while the range check could
>cause an entire abort, so it's not a given which
>approach to use.

You don't understand. If the DAC value overflows, I definitely *don't*
want to calculate with a modulo value, because this is absolutely
wrong. Definitely. But the calculation will be still *correct* with
255, even if it *might* make not much /sense/ in real world.

>In the Ariane 5 case, it turned out
>that this approach caused an unhappy outcome.

Well, and in my case I almost got a screwed up machine, because
another value underflowed below zero, this underflow was not catched,
and so the result was interpreted as very large unsigned value later
then in the embedded system, because negative values can be considered
plainly impossible there. And you know what? Under certain other
circumstance such a large value could have made sense.


Vinzent.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> It is supect. And what to do, if you *suspect* a wrong value? Pop up a
> window and let a human operator confirm, everything is still good?
> Please also take limited CPU-time into your considerations.

I don't understand your point. It's a computer program - it's going
to do *something* under these circumstances. The people who specify
the program behavior must decide what it is going to do. The decision
may be difficult, but it must be made nevertheless.

> But to decide when exactly a particular value is really wrong or not
> is indefinitely harder to make. There is a gray area and you really
> don't want to implement some fuzzy logic in such CPUs.

It may be hard, but that does not absolve the designer from
deciding what it should do. If you choose not to decide, you
still have made a choice.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> It is supect. And what to do, if you *suspect* a wrong value? Pop up a
>> window and let a human operator confirm, everything is still good?
>> Please also take limited CPU-time into your considerations.
>
>I don't understand your point. It's a computer program - it's going
>to do *something* under these circumstances.

Yes, but it's still going to calculate a value that's at least
mathematically ok, even *if* sometimes it might be out of the
reasonable limits someone could think of at the time of this writing.

I just cannot do a lot of decision graphs and perhaps keeping a
history of previously read values if I don't have the horse-power to
do that. What I mean is that: in the example of a temperature sensor,
if I can keep a history, and the sensor says, the last five minutes
the temperature raised 5 degrees, I can assume that this is still ok
(even if the temperature is outside of the expected limits already),
but if it suddenly jumps up from zero to hundred in just a matter of
seconds it *must* be wrong. If you've got enough CPU-(and
development-)time to implement such rather complex logic (it should
work in *all* cases we could think of and even in those we could *not*
think of, shouldn't it?) - that's fine. But in most cases I don't have
this. My 8 MHz machine for instance is rather restricted to just do
what it is supposed to do. Anything else is luxury, I simply can't
afford. Oh, and yes, sometimes I'd really like to do a little bit more
sanity checking than I actually can.

>> But to decide when exactly a particular value is really wrong or not
>> is indefinitely harder to make. There is a gray area and you really
>> don't want to implement some fuzzy logic in such CPUs.
>
>It may be hard, but that does not absolve the designer from
>deciding what it should do.

Noone said this.

>If you choose not to decide, you still have made a choice.

I decide to say, *every* value that still results in mathematically
correct results is useable in some particular algorithm. Any other
value should be rejected, just because it is plain wrong, no matter
how you look at it. What's left is the decision, *how* to do this then
(exception, clamp to maximum, crash, ...). And that's what they did in
Ariane 4. Perfectly reasonable, IMO.

And please don't tell me, I'm doing something wrong if I say, my
machine can drive a stepper motor about a distance of only 16 meters
(an arbitrary limit of a 24-bit counter), anything more results in an
error message. This is IMO absolutely reasonable and you know why?
Because the largest machine is not longer than about 6 meters and if
they later should decide to build another one with a length of twenty
meters or so, I *have* to reconsider my decision and the
implementation, of course.
But until then *nobody* should have *any* fucking reason to expect
that the old software simply works on a new machine, just because it
worked well on the old one.

Call me ignorant, but if I'd do what you seem to say, they could use
my software at NASA to put it into a new space shuttle with expecting
it to work properly, just because I thought of about "everything"
someone could think of, even the possibility that someone puts a
rocket booster on a 2-ton engraving machine just to send it into
orbit.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Ariane5 FAQ

[Richard Riehle]

Hyman Rosen wrote:

> Bobby D. Bryant wrote:
> > Which brings us directly back to Alexandre's "there were no reasons to
> > expect that it should work for this new rocket", which you objected to so
> > strenuously at the start of this tread.
>
> No, because there is a great deal of difference between the statements
>      "there were no reasons to expect that this would work"

I agree with Hyman on this one.  The phrasing is awkward and fails
to convey what I suspect is the original intent of the writer.  There are
no reasons why someone reading it would expect it to be correct.  A
slightly modified phrasing would eliminate the Usenet overflow that
seems to have occurred.   More careful design of the FAQ, though it
works perfectly well for the Ada-enthusiast audience for which it
was intended,  seems to raise an exception when read by others who
parse such statements differently, and whose intellectual trajectory
is a bit less vertical.

Richard Riehle

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Richard Riehle wrote:

>Hyman Rosen wrote:
>
> > Bobby D. Bryant wrote:
> > > Which brings us directly back to Alexandre's "there were no reasons to
> > > expect that it should work for this new rocket", which you objected to so
> > > strenuously at the start of this tread.
> >
> > No, because there is a great deal of difference between the statements
> >      "there were no reasons to expect that this would work"
>
>I agree with Hyman on this one.  The phrasing is awkward

Well, the prhasing may be somehow awkward, I know well that my English is far
from perfect.

> and fails
> to convey what I suspect is the original intent of the writer.

As far as I can see from this thread, all (yes, all, without exceptions)
readers that responded to that phrase understood my intent correctly.

>  There are
>no reasons why someone reading it would expect it to be correct.

Perhaps. But nevertheless the actual testing confirmed that it was understood
-- all responses were in proper range.

> A slightly modified phrasing would eliminate the Usenet overflow that
>seems to have occurred.

But why didn't you propose a modification?

>   More careful design of the FAQ, though it
>works perfectly well for the Ada-enthusiast audience for which it
>was intended,  seems to raise an exception when read by others who
>parse such statements differently, and whose intellectual trajectory
>is a bit less vertical.

Well, I believe in your good intentions, but I don't see you concrete
propositions.

I know that my writing may need language corrections, and that it surely
does not satisfy high standards of political correctness. For drawbacks of
the first kind I'll be happy to make amendments - just point me at my wrongs
and propose appropriate modifications. As for political correctness... well,
I have nothing against it, but only if it does not obscure essential things.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Richard Riehle]

Alexander Kopilovitch wrote:

> Richard Riehle wrote:
>
>
> >I agree with Hyman on this one.  The phrasing is awkward
>
> Well, the prhasing may be somehow awkward, I know well that my English is far
> from perfect.

Ponyumaio.  Moya  po-Russki tozhe nekoroshoa.  Ochen davno, Ya oocheelcya
Russkomy yazikoo.  Tepyehr,  maya grammatica plocha, proeeznashenya uuzhacneeya,
ee ya nye pomnio mnoga slov.

Eezveneetya, paizhalsta.

Richard Riehle

Re: Ariane5 FAQ

[Hyman Rosen]

Alexander Kopilovitch wrote:
 > As for political correctness... well, I have nothing against it,
 > but only if it does not obscure essential things.

The entire point of your FAQ is political correctness.
In this order, you are urgently campaigning that Ada,
Ada programmers, and technical people have absolutely
no blame in the Ariane 5 crash. In order to do this
you make unsubstantiated claims which are designed to
appeal to the egos and biases of Ada programmers and
other technical people.

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> The entire point of your FAQ is political correctness.
> In this order, you are urgently campaigning that Ada,
> Ada programmers, and technical people have absolutely
> no blame in the Ariane 5 crash.

This is true, and the findings of the report emphsize this.  The failure 
was in the process that Arianespace set up, not in the work of any 
contractor, and certainly not in the work of any employee of those 
contractors.  The process that Arianespace set up delegated requirements 
to individual subcontracts, which is fine.  But there was no process for 
checking that changes in the subcontracts did not result in failure to 
test some requirements, or a final pre-launch validation that all 
requirements had been tested.

The scope of one of the subcontracts was reduced, and as a result 
certain tests that were part of the original test plan did not get 
performed.  However, Arianespace's project management process equated 
completion of all subcontracts with completion of all testing.  As 
became obvious, this was not a good idea.

 >                                  In order to do this
> you make unsubstantiated claims which are designed to
> appeal to the egos and biases of Ada programmers and
> other technical people.

This is not a very constructive comment.  Alexander Kopilovitch is not 
writing a technical report, but an FAQ.  It would be nice if those of us 
who have studied the disaster could trace every allegation in the FAQ to 
documentation.  But those references don't really belong in the FAQ, 
other than as a "to learn more" URL.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
> This is not a very constructive comment.

He claims that actions were taken without any reason
to assume that they would be correct.

He ascribes motivations and makes assumptions about
the background and mindset of people involved in the
project.

I would like to know if he has any evidence for either
of these claims, and if so, what it is.

As a simple counterexample, technical people are often
the ones who choose to use C or C++ instead of Ada and
who leave things like buffer overflows in the code or
take other ill-advised shortcuts or fail to properly
document the code they write. So it's disingenuous to
assume that the Ariane 5 crash could only be the fault
of non-technical people.

You seem to know more about the Ariane 5 project than what
is found in the accident report. It would be kind if you can
provide links that would give us more information, aside from
the accident report which we already have.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<7u9Ua.13412$634.10307@nwrdny03.gnilink.net>...
> Alexander Kopilovitch wrote:
>  > As for political correctness... well, I have nothing against it,
>  > but only if it does not obscure essential things.
> 
> The entire point of your FAQ is political correctness.
> In this order, you are urgently campaigning that Ada,
> Ada programmers, and technical people have absolutely
> no blame in the Ariane 5 crash. In order to do this
> you make unsubstantiated claims which are designed to
> appeal to the egos and biases of Ada programmers and
> other technical people.

Well, Alexander certainly appealed to my ego and biases, and for that I thank him!

Re: Ariane5 FAQ

[Robert I. Eachus]

Hyman Rosen wrote:

> You seem to know more about the Ariane 5 project than what
> is found in the accident report. It would be kind if you can
> provide links that would give us more information, aside from
> the accident report which we already have.

How about another accident report, on the upper stage this time which 
reveals that the same process problems existed throughout the Ariane 5 
program: http://www.arianespace.com/site/news/releases/presrel01_8_07.html

As you can see, the base problem is the same as in the 501 failure. 
Inadequate testing of the upper stage propulsion system under Ariane 5 
conditions.

But the reasons that I got involved in a close scrutiny of the Ariane 
501 failure was that Arianespace was in the same position on that 
project as MITRE is on many DoD and other government projects.  MITRE 
acts as the system engineer for the government while contractors build 
individual portions of the system.  At the time of the Ariane 501 
disaster I was in that role with respect to GEODSS and CMU.

A group from MITRE did a review of the project to see if we would have 
caught the problem.  And as I said the glaring hole in Arianespace's 
process on Ariane 5 was this issue of distributing the overall project 
requirements but having no process for insuring that all the original 
requirements were met.

This is managing of several interlocking contracts is something that 
MITRE often goes through.  Using the old nomenclature the A spec 
requirements would be distributed by the individual contractors to the 
B5, and they would want MITRE to certify that meeting the B5 
requirements would satisfy the A-spec requirements.  We would always 
refuse, and instead certify that they were contracted to meet the B5 
requirements.  Many contractors never understood the difference, but as 
you can see from the Ariane 5, there is a difference and it is major.

For example on the SCIS contract I was actually the one to "pull the 
trigger" and tell US Space Command after a particular performance 
review, that they as the using customer had to bite the bullet and 
accept that the system currently under contract would be of no use to 
them.  I won't go into gory details, but the Goldwater-Nichols 
reorganization meant that the system under contract no longer met their 
(A level) requirements.  Obviously this was in no way the fault of the 
contractor--or for that matter the government.  But we needed 
renegotiate the contract to reflect the changed requirements.

The changes caused by Goldwater-Nichols were not deployed in time for 
the first Gulf War, but workarounds were used with Scud launch data. 
The changes were there for the recent fighting in Afganistan and Iraq, 
and were an improvement over the Gulf War situation.  So 
Goldwater-Nichols was a significant improvement in the way large scale 
joint combat was run, and some of those changes had cost consequences. 
Fine, as long as you go in with your eyes open--and continue to compare 
the overall system to the overall system requirements not just the 
detailed requirements.

-- 

                                                Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Simon Wright]

"Robert I. Eachus" <rieachus@attbi.com> writes:

> This is managing of several interlocking contracts is something that
> MITRE often goes through.  Using the old nomenclature the A spec
> requirements would be distributed by the individual contractors to the
> B5, and they would want MITRE to certify that meeting the B5
> requirements would satisfy the A-spec requirements.  We would always
> refuse, and instead certify that they were contracted to meet the B5
                                                                    ^^
should that be A? (I don't know the nomenclature)
> requirements.  Many contractors never understood the difference, but
> as you can see from the Ariane 5, there is a difference and it is
> major.

Re: Ariane5 FAQ

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:7u9Ua.13412$634.10307@nwrdny03.gnilink.net...
> Alexander Kopilovitch wrote:
>  > As for political correctness... well, I have nothing against it,
>  > but only if it does not obscure essential things.
>
> The entire point of your FAQ is political correctness.
> In this order, you are urgently campaigning that Ada,
> Ada programmers, and technical people have absolutely
> no blame in the Ariane 5 crash. In order to do this
> you make unsubstantiated claims which are designed to
> appeal to the egos and biases of Ada programmers and
> other technical people.

This has been building up for a LOOOONG time.

Hyman, between this, and various other things you have said, I just drew the
conclusion that you cannot possibly have anything whatsoever to say that
will ever possibly be the slightest bit interesting to me.

*Plonk.*

Re: Ariane5 FAQ

[Robert I. Eachus]

Simon Wright wrote:
> "Robert I. Eachus" <rieachus@attbi.com> writes:
> 
> 
>>This is managing of several interlocking contracts is something that
>>MITRE often goes through.  Using the old nomenclature the A spec
>>requirements would be distributed by the individual contractors to the
>>B5, and they would want MITRE to certify that meeting the B5
>>requirements would satisfy the A-spec requirements.  We would always
>>refuse, and instead certify that they were contracted to meet the B5
> 
>                                                                     ^^
> should that be A? (I don't know the nomenclature)
> 
>>requirements.  Many contractors never understood the difference, but
>>as you can see from the Ariane 5, there is a difference and it is
>>major.

No that was correct.  The various contractors were building parts of the 
system, and the B-level specs became part of their SOW (statement of 
work).  But MITRE would never commit to saying that satisfying all the 
B-level requirements would meet the A-level spec, until the jigsaw 
puzzle was assembled.

The contractors, I think always pretended to be confused by this, but it 
was understandable.  The individual contractors could not necessarily 
know how other parts of the overall project was being done.  Making sure 
that all the pieces fit together was MITRE's job.  But we could, and 
occasionally did say, "The SoW (statement of work) needs to be changed." 
  The individual contractor would object, pro forma, until we (the 
government side) assigned a change order number and started to negotiate 
pricing.

Then they would scream again if "the government" held up completion of a 
major milestone until those negotiations were complete. So the contract 
dance recognized that changes to the SoW due to external events could 
entitle the contractor to additional compensation. But the government 
NEED was for a system that could satisfy the A-spec.  (Change orders did 
not necessarily result in extra cost to the government, because a single 
change order could fold in getting rid of requirements the contractor 
found onerous, and adding requirements the government needed.  This is 
engineering driving finance which is the way it has to work.  Meeting 
the "new" B-level requirements could be either cheaper or more 
expensive, but it was necessary.)

-- 

                                              Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Hyman Rosen wrote:

>He claims that actions were taken without any reason
>to assume that they would be correct.
>
>He ascribes motivations and makes assumptions about
>the background and mindset of people involved in the
>project.
>
>I would like to know if he has any evidence for either
>of these claims, and if so, what it is.

I became surprised why are you so interested in attacking my points (in Ariane
FAQ) in particular, and (in other threads) Ada language in general. Why are
you spending your efforts and your time for those (apparently foreign to you)
purposes, without any chances for success? So I took a brief look around, and
found something really nice.

Are you the same Hyman Rosen, whose phrase is quoted as epigraph before
Appendix E, Standard-Library Exception Safety in Bjarne Stroustrup's book
"The C++ Programming Language",  Special Edition (ISBN 0-201-70073-5) ?
The epigraph reads:

  Everything will work just as you expect it to,
       unless your expectations are incorrect.
                              - Hyman Rosen


Don't you think that my point about the role of expectations (within the FAQ)
nicely aligns with that epigraph? So, what makes you unhappy and even (apparently)
angry?


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Hyman Rosen]

Alexander Kopilovitch wrote:
> I became surprised why are you so interested in attacking my points (in Ariane
> FAQ) in particular, and (in other threads) Ada language in general.

It's a discussion group. I like to dicuss. Since I'm quite good at C++,
one of the things I do is correct misstatements about that language.
Another thing I like to do is to point out places where Ada afficionados
have, in my opinion, too high an opinion of themselves or their language.

> Why are you spending your efforts and your time for those
 > (apparently foreign to you) purposes, without any chances
 > for success?

For one, because it's fun. Consider it a light form of trolling if you
like. I don't consider it real trolling because I do believe the things
I write, even when I know that it will tick off some newsgroup members.
And I'm a member of SigADA, so I have at least slight credentials to be
here. I suppose future discussions will be less intense since some folks
here appear to have decided to add me to their kill file :-)

> Are you the same Hyman Rosen

Yep, that's me. It came from a C++ newsgroup posting that he noticed.

> Don't you think that my point about the role of expectations
 > (within the FAQ) nicely aligns with that epigraph? So, what
 > makes you unhappy and even (apparently) angry?

That epigraph is just a funny tautology. In the Ariane 5 case,
the discussion is about who had the expectations, whether they
were justified, and where the responsibility lies for having
been wrong. I'm not especially unhappy or angry - it's just a
usenet discussion.

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Hyman Rosen wrote:

>one of the things I do is correct misstatements about that language.
>Another thing I like to do is to point out places where Ada afficionados
>have, in my opinion, too high an opinion of themselves or their language.

Well, so why didn't you exploit a direct oppotunity for that in Ariane 5
crash case?

You must know well that one thing Ada advocates are proud of is Ada's
capability to carry more information about programmer's intentions
and decisions directly in  source code than other general-purpose
programming languages. It means that with Ada lesser part of such 
information need comments to be expressed clearly.

At the same time both official report and c.l.a. discussions tell you that
the critical point from which the actual low-level chain of events started
was that the limitations for some variables that were not reflected in
comments (although were described in documentation). And that this
misled the developers of the simulator which was used for rocket's
testing instead of real device.

But those limitations should be very simple and fundamental kind of
information about programmer's intentions and decisions. So, if the
above claims are right then that information must be in source code,
not in comments, and if it were there then the simulator's developers
had no chance to miss it. There should be something like RANGE qualifier,
no more. Yes, one can say that RANGE will imply unwanted check, but
once more, there should be a pragma, which suppresses that check.
So, combination of RANGE and pragma will clearly convey the intentions,
both to compiler and to another programmer.

With those statements you can conclude that either Ada language is not
so greate in this aspect as some people claim or there was some
programmer's fault -- if the present language feature was not used properly.
(Only possible escape is that it was Ada 83, and the missed feature was
added later - for Ada 95 or even later).

Good opportunity, isn't it? -:)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Berend de Boer]

>>>>> "Alexander" == Alexander Kopilovitch <aek@vib.usr.pu.ru> writes:

    Alexander> You must know well that one thing Ada advocates are
    Alexander> proud of is Ada's capability to carry more information
    Alexander> about programmer's intentions and decisions directly in
    Alexander> source code than other general-purpose programming
    Alexander> languages. 

Except requirements it seems. And I think you should have a look at
Design By Contract and in particular Eiffel.

-- 
Regards,

Berend. (-:

Re: Ariane5 FAQ

[Hyman Rosen]

Alexander Kopilovitch wrote:
> Good opportunity, isn't it? -:)

I suppose you're right, but as a C++ programmer, naturally
I wouldn't have thought of it :-)

I've said before that one of the things I believe is that
writing the specifications and constraints for a program
in precise detail is equivalent to writing the program
itself. Most real constraints aren't as simple as having
a variable fall into one fixed range, so I think after a
while you can't rely on built-in language elements to
express them. It can all get very complicated very fast.

Re: Ariane5 FAQ

[Robert I. Eachus]

Berend de Boer wrote:

> Except requirements it seems. And I think you should have a look at
> Design By Contract and in particular Eiffel.

No.  And that is what all the sound and fury has been about.  The 
mapping from requirements to actual code was perfectly done.  The 
problem was that the requirements which were perfectly filled were for 
the Ariane 4, not the Ariane 5.

The nature of the political/management problem at Arianespace was such 
that no one ever saw both the Ariane 5 requirements and the SRI 
documentation until after the disaster.  The red herring dragged about 
of documenting requirements in the source code is just that, a red 
herring.  The programmers simulating the SRI for the flight guidance 
simulator did not see the alignment function code--because simulating it 
was not part of their contract.

Of course, if anyone involved in letting that contract had known that 
the alignment function on the Ariane 4 was required to run for 40 
seconds after engine start, simulation of it might have been included in 
the simulator.  Or something else might have happened that resulted in 
an engineer learing of this requirements mismatch.

But as we know, no one was ever in a position to do a diff between the 
Ariane 4 and Ariane 5 requirements, and then apply that to reused 
subsystems.  Did everyone miss the point of the SECOND Ariane 5 failure 
investigation?  Diffferent launch, different subsystem, very different 
failure mode. But the thing both failures had in common was systems 
reused from Ariane 4 without checking that they met the new requirements.

If you missed it, here it is again.  The failure didn't get nearly the 
press that the first one did, but the result was the same, a launch 
failure: http://spaceflightnow.com/ariane/v142/010713followup.html and
http://www.arianespace.com/site/news/03_06_19_release_index.html

There was also a FOURTH Ariane 5 failure (out of 14 tries) on flight 
157: http://www.esa.int/export/esaCP/ESA7198708D_index_0.html  This was 
due to failure of the cooling of the Vulcain 2 engine, new to the Ariane 
5 ECA.  Although this failue had nothing to do with Ariane 4 reuse, or 
Ada, what do we find under contributing factors?  "non-exhaustive 
definition of the loads to which the Vulcain 2 engine is subjected 
during flight"

Translation, ANOTHER requirements definition failure.  The first three 
launch failures were all due to the failure of change mananagement and 
requirements tracking during the original Ariane 5 development.  But 
this latest failure involves a design subsequent to the first two Ariane 
5 failures.  You have to wonder...

In any case, focusing on the particular details of the first failure and 
not the overall programmatic issues is a mistake.  In Arianespace's 
case, so far a multi-billion Euro mistake.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Ariane5 FAQ

[Hyman Rosen]

Robert I. Eachus wrote:
 > The mapping from requirements to actual code was perfectly done.

The people who talk about this generally mean that specifications
which place limits on externally provided data should be reflected
in the code. In the Ariane 4 case, that would have meant that the
BH conversion code would have checked its floating value against
the specified maximum and complained if it was out of range.

Whether or not you agree that such a thing is necessary, it wasn't
done that way.

Re: Ariane5 FAQ

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<Wz0Va.9164$AO6.1522@nwrdny02.gnilink.net>...
> Robert I. Eachus wrote:
>  > The mapping from requirements to actual code was perfectly done.
> 
> The people who talk about this generally mean that specifications
> which place limits on externally provided data should be reflected
> in the code. In the Ariane 4 case, that would have meant that the
> BH conversion code would have checked its floating value against
> the specified maximum and complained if it was out of range.
> 
> Whether or not you agree that such a thing is necessary, it wasn't
> done that way.

And, besides "complaining," what action should the code have taken?  I
doubt "complaining" alone is an adequate solution!

Non-philosophical definition of Eiffel? (was: Re: Ariane5 FAQ)

[Alexander Kopilovitch]

Berend de Boer wrote:

>    Alexander> You must know well that one thing Ada advocates are
>    Alexander> proud of is Ada's capability to carry more information
>    Alexander> about programmer's intentions and decisions directly in
>    Alexander> source code than other general-purpose programming
>    Alexander> languages.
>
>Except requirements it seems. And I think you should have a look at
>Design By Contract and in particular Eiffel.

Can you tell me where can I read about Eiffel *without* being fed with several
hundred pages about that Design By Contract? I simply can't read that things,
all I saw about it seemed trivial for me (at least as it was presented), and
I almost fell asleep after several pages. I'm willing to read about the Eiffel
programming language just because several definitely competent people have
said good words about it, but not the philosophy of its author, so far.
  So, is there a definitive book about Eiffel programming language, but without
too many pages about Design By Contract?



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Hyman Rosen]

Mike Silva wrote:
> And, besides "complaining," what action should the code have taken?  I
> doubt "complaining" alone is an adequate solution!

Well, I'm not necessarily a proponent of this view,
but I assume that those who are would expect that the
code signals a violation in some fashion, perhaps by
throwing an exception, or some other mechanism.

The key here is that an external datum has violated a
constraint of the design. By definition, the code is
not prepared to deal with such a value, and yet it must
do something. That something must be specified in some
fashion, even if that specification is simply to let
the code proceed as if the value were legal.

By inserting such checks into the code, protection is
provided against potential future misuse by verifying
that assumed constraints still hold. When they do not,
the error is signalled at the first place that the
violation is noticed instead of somewhere later down
the road.

It's really no different than using the various forms
of range checking that Ada provides. Some constraints
can't be specified purely through the Ada type system,
but that doesn't mean that they shouldn't be expressed
in the code.

As counter arguments, such checks might be expensive
in terms of time and space, and they add execution paths
which can never be exercised in the normal course of events.
And it's possible that for erroneous data to get damped out
in the course of normal processing, while detecting the error
could abort the system. I don't think there's a unique good
answer to the dilemma.

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Alexander Kopilovitch wrote:
>   So, is there a definitive book about Eiffel programming language, but without
> too many pages about Design By Contract?

Go right to the horse's mouth, _Object Oriented Software Construction_
by Bertrand Meyer. In my opinion, the huge error made by Eiffel is to
have covariant argument types for inherited methods, and this as an
error from which the language has never recovered.

For those unfamiliar with the concept, Eiffel allows a derived class
to override an inherited method with a method whiach takes a more
restricted argument type. This obviously causes huge correctness
issues, since at any call using a base object you may be committing
a type violation that you are not even aware of! The Eiffel people
have spent years trying to figure out ways around the problem while
still keeping the original design.

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>The programmers simulating the SRI for the flight guidance 
>simulator did not see the alignment function code--because simulating it 
>was not part of their contract.

This is very serious and interesting allegation. Are you sure of that fact,
or it is just good guess? I'm not asking for a reference, just say that you
*know* that this is true fact.

I think that this fact deserves particular attention also because, if true,
it means that somebody knew in advance about the differences between Ariane 4
and Ariane 5 relative to SRI software functionality, and specifically excludes
from the contract the part, which is irrelevant to Ariane 5. So, they did not
ask for simulation of the SRI as a whole, naively thinking that there should
be no differences -- on the contrary, they *knew* that there is significant
difference and deliberately ordered to exclude from simulation the part, which
deals with that difference.

>Of course, if anyone involved in letting that contract had known that 
>the alignment function on the Ariane 4 was required to run for 40 
>seconds after engine start, simulation of it might have been included in 
>the simulator.  Or something else might have happened that resulted in 
>an engineer learing of this requirements mismatch.

Just after the above two paragraphs I understand, at last, all the meaning
of those unfortunate 40 seconds. Yes, you told about that earlier, and perhaps
several times, but still it did not seem essential -- until you said that this
part was deliberately excluded from the simulator at the contract level.

>But as we know, no one was ever in a position to do a diff between the 
>Ariane 4 and Ariane 5 requirements, and then apply that to reused 
>subsystems.

No, this contradicts (although indirectly) your previous statement. How can
one exclude anything from the simulator's contract if nobody can see differences
between the Ariane 4 and Ariane 5?



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Richard Riehle]

"Robert I. Eachus" wrote:

> Berend de Boer wrote:
>
> > Except requirements it seems. And I think you should have a look at
> > Design By Contract and in particular Eiffel.
>
> No.  And that is what all the sound and fury has been about.  The
> mapping from requirements to actual code was perfectly done.  The
> problem was that the requirements which were perfectly filled were for
> the Ariane 4, not the Ariane 5.

I suspect Berend was referring to the concept of including the requirements
as assertions in the code.   DbC is a technique for doing this.  However,
there are other approaches to DbC that are more effective for safety-critical

systems than that found in Eiffel.  I am thinking here of SPARK.

In general, the safety-critical community does not like the Eiffel model
because it relies on assertion-errors at run-time.   While this is just
fine for non-safety-critical software, it is not appropriate for a system
such as Ariane V, or any other similar system.

Also, assertions themselves require that someone declare the appropriate
assertions.  In the case of Ariane V, if anyone had felt the need to do that,

even thought about it, they would also have made the same mistake they
made in Ada because the assumptions were wrong from the start.

I favor the DbC model and admire the work done by Bertrand Meyer in
refining this idea.  However, it is all too easily over-simplify this kind of

thing after the fact and suggest that, "If you had simply done things my way,

you would not have had this problem."    DbC and Eiffel would not have
made a whit of difference in this engineering problem, articles and arguments

to the contrary notwithstanding.    Ada use correctly would have been OK.
C++ used wisely would have been OK.  Eiffel and DbC   used carefully
would have been OK.  Java, of course, would not have been OK under
any circumstances.

In the final analysis, Arianne V was not a function of programming language,
or design method, or development tools.  It was an engineering mistake that
began with poor management making incorrect assumptions.   That same
engineering mistake would have occurred regardless of tools, languages,
and systems.

Richard Riehle

Re: Ariane5 FAQ

[Hyman Rosen]

Richard Riehle wrote:
> I am thinking here of SPARK.

The Ariane 4/5 problem had nothing to do with proving the
correctness of a program. Had they used SPARK, they would
have informed the verifier of the presumed limits of the
input, and the verifier would have happily verified that the
program was correct.

But if the Ariane 4 code had carried the specification limits
within it, as DbC, or as SPARK assertions, or as range checks,
perhaps someone might have noticed that the Ariane 5 failed to
meet those constraints.

And if they had tested it properly, such checks would have
served to pinpoint where the problem lay.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Richard Riehle wrote:
>> I am thinking here of SPARK.
>
>The Ariane 4/5 problem had nothing to do with proving the
>correctness of a program. Had they used SPARK, they would
>have informed the verifier of the presumed limits of the
>input, and the verifier would have happily verified that the
>program was correct.

Yes, that's probably true.

>But if the Ariane 4 code had carried the specification limits
>within it, as DbC, or as SPARK assertions, or as range checks,
>perhaps someone might have noticed that the Ariane 5 failed to
>meet those constraints.

That isn't much different from SPARK where you should justify such
decisions for the verifier. I don't think either method would have
helped, because nobody seemed to look at the requirements at all.


Vinzent.

-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov]

On Mon, 28 Jul 2003 14:18:17 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Alexander Kopilovitch wrote:
>>   So, is there a definitive book about Eiffel programming language, but without
>> too many pages about Design By Contract?
>
>Go right to the horse's mouth, _Object Oriented Software Construction_
>by Bertrand Meyer. In my opinion, the huge error made by Eiffel is to
>have covariant argument types for inherited methods, and this as an
>error from which the language has never recovered.

How could it be otherwise?

[If the argument type is contravariant, then the subroutine is not a
method in this argument => it is not inherited.]

>For those unfamiliar with the concept, Eiffel allows a derived class
>to override an inherited method with a method whiach takes a more
>restricted argument type. This obviously causes huge correctness
>issues, since at any call using a base object you may be committing
>a type violation that you are not even aware of! The Eiffel people
>have spent years trying to figure out ways around the problem while
>still keeping the original design.

That's not Effel's problem. This a problem of type specialization
which inevitably breaks out-methods. Nothing can be done about it.
BTW, generalization breaks in-methods. In short, the notion of
absolute substitutability (the way many are treating LSP) is useless
absolutely.

   subtype Positive is Integer range 1..Integer'Last;

is a specialization, and it breaks LSP, and we do not care.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> How could it be otherwise?
> [If the argument type is contravariant, then the subroutine is not a
> method in this argument => it is not inherited.]

It could be, in some other language. You could explicitly designate
which method was being overridden, and allow contravariant arguments.

> That's not Effel's problem. This a problem of type specialization
> which inevitably breaks out-methods. Nothing can be done about it.

You can disallow it! Eiffel's problem is that it allowed such things
without a good way of avoiding errors at the call sites, short of
whole-program verification or runtime type checks.

> BTW, generalization breaks in-methods. In short, the notion of
> absolute substitutability (the way many are treating LSP) is useless
> absolutely.

OO programming in its most mechanical sense involves derived classes
overriding base methods, and allowing those methods to be invoked by
things which know only the base. You can break that paradigm if you
want, but then you should probably call it something else, so you don't
confuse people.

Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov]

On Tue, 29 Jul 2003 09:43:43 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> How could it be otherwise?
>> [If the argument type is contravariant, then the subroutine is not a
>> method in this argument => it is not inherited.]
>
>It could be, in some other language. You could explicitly designate
>which method was being overridden, and allow contravariant arguments.

There is little sense in contravariant arguments, because they are too
dangerous. Probably you mean class-wide arguments. But it is another
case then. Anyway, the point is: you can only inherit through a
covariant argument.

>> That's not Effel's problem. This a problem of type specialization
>> which inevitably breaks out-methods. Nothing can be done about it.
>
>You can disallow it!

What? To disallow specialization?

Carefully observe that already "const Thing" is a specialization and,
how wonderful, it is not a LSP-subtype of Thing. Yet each and every
language has an equivalent of const.

Probably you want to disallow methods? Fine, but this also breaks LSP.

In fact, anything reasonable would break LSP. Substitutability is kind
of incompatible with reasonability. (:-))

> Eiffel's problem is that it allowed such things
>without a good way of avoiding errors at the call sites, short of
>whole-program verification or runtime type checks.

You cannot map *all* substitutability semantics into [sub-]types. It
does not work for many reasons.

>> BTW, generalization breaks in-methods. In short, the notion of
>> absolute substitutability (the way many are treating LSP) is useless
>> absolutely.
>
>OO programming in its most mechanical sense involves derived classes
>overriding base methods, and allowing those methods to be invoked by
>things which know only the base. You can break that paradigm if you
>want, but then you should probably call it something else, so you don't
>confuse people.

I would recommend you to read recent dicussions in comp.object
concerning LSP. Actually there is always a new discussion each pair
months. People like this idea. I would say, it is second popular to
life-after-death. (:-))

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ariane5 FAQ

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Just after the above two paragraphs I understand, at last, all the meaning
> of those unfortunate 40 seconds. Yes, you told about that earlier, and perhaps
> several times, but still it did not seem essential -- until you said that this
> part was deliberately excluded from the simulator at the contract level.
> 
> 
>>But as we know, no one was ever in a position to do a diff between the 
>>Ariane 4 and Ariane 5 requirements, and then apply that to reused 
>>subsystems.
> 
> 
> No, this contradicts (although indirectly) your previous statement. How can
> one exclude anything from the simulator's contract if nobody can see differences
> between the Ariane 4 and Ariane 5?

No knowledge of the difference between the Ariane 4 and Ariane 5 was 
involved.  The perfectly reasonable assumption was made that there was 
no need to simulate the alignment functions which ran before takeoff, 
because there was nothing to be learned there.  (This is a case where 
the Araine 4 and 5 really were identical.  Sitting on the pad, the 
accelerometers and gyros were identical and the launch site was 
identical.)  Again what slipped through was that there was a requirement 
in the Ariane 4 to continue running the alignment software after MEI 
(main engine ignition), even though those results were "thrown away" if 
MEI resulted in a launch.

This is one of those very hard to understand things until you have that 
Aha! moment.  On some launchers, such as the Space Shuttle MEI occurs 
several seconds before liftoff.  In the shuttle, and Ariane 4, SRB 
(solid rocket booster) ignition is the point of no return, where you 
can't stop the takeoff.  In Ariane 5, as I understand it, MEI is the 
commit point.

Oh, and as an aside to Hyman:  You keep harping on the fact that the 
overflow for BH wasn't a computed limit.  But you are wrong.  What was 
computed as that limit was the T plus forty second shutdown of the 
alignment process.  That number was chosen so that BH and several other 
variables would not overflow on any mission which the Ariane 4 was 
capable of flying.  It was chosen longer than "necessary" to reset the 
SRI after an expected abort, but short enough that no further checking 
was required.

It is that calculation in the SRI documentation for the Ariane 4 that is 
the smoking gun in the whole incident.

But as I say, this is all irrelevant.  There have now been FIVE Ariane 5 
launch failures out of 14 attempts.  All except the most recent one were 
indirectly due to the flaws in managing the requirements process during 
the Ariane 5 development process. And only the first one involved 
software.  That is because after the Ariane 501 disaster the necessary 
review of all the software was done.  However there were other 
engineering decisions where failure to track requirements resulted in 
failure.  (You could argue that the most recent Ariane 5 failure was 
also due to poor requirements tracking, and I wouldn't disagree.  But it 
is better to say that it resulted from poor requirements generation 
rather than tracking.)


-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> There is little sense in contravariant arguments

OK, I just want to make sure that we're talking about
the same thing, so let me give specific examples. I'll
write in C++ terms, just because.

     struct B1 { };
     struct D1 : B1 { };

     struct B2
     {
         virtual B1 &f1();
         virtual B1 &f2();
         virtual void f3(B1 &);
         virtual void f4(D1 &);
         virtual void f5(B1 &);
     };

     struct D2 : B2
     {
         B1 &f1();
         D1 &f2();
         void f3(B1 &);
         void f4(B1 &);
         void f5(D1 &);
     };

     D2 d2;
     B2 *b2 = &d2;

f1) This is ordinary overriding, with same return type.
     Pretty much legal in every language.
f2) This is covariant return type. Legal in C++. This
     preserves LSP, since a call b2->f2() must return a
     B1 &, and a D1 & is a B1 &.
f3) Again, ordinary overriding, with the same argument
     types in base and derived. Legal everywhere.
f4) Contravariant argument types. This also preserves
     LSP, but I don't know of a language which implements
     it. LSP is preserved because a call of b2->f4() can
     only pass a D1 & argument, and a D1 & is a B1 &.
f5) Covariant argument types. This is Eiffel's model.
     LSP is not preserved, because a call to b2->f5()
     may pass any B1 &, while d2.f5() wants only a D1 &.

Re: Ariane5 FAQ

[Berend de Boer]

>>>>> "Robert" == Robert I Eachus <rieachus@attbi.com> writes:

    Robert> Berend de Boer wrote:
    >> Except requirements it seems. And I think you should have a
    >> look at Design By Contract and in particular Eiffel.

    Robert> No.  And that is what all the sound and fury has been
    Robert> about.  The mapping from requirements to actual code was
    Robert> perfectly done.  The problem was that the requirements
    Robert> which were perfectly filled were for the Ariane 4, not the
    Robert> Ariane 5.

    Robert> The nature of the political/management problem at
    Robert> Arianespace was such that no one ever saw both the Ariane
    Robert> 5 requirements and the SRI documentation until after the
    Robert> disaster.

The point is that the requirements should be *in the code*. That's
where they belong. Not sure if this would have made a difference, but
if you want to reuse code, you should now the conditions under which
it should work. If programmers just grab code and reuse it without
looking at those preconditions, well, you're not doing your job right.

And for those preconditions: use comments, DbC, whatever. And Ada has
even Spark (that's something we need in the Eiffel world!).

-- 
Regards,

Berend. (-:

Re: Ariane5 FAQ

[Berend de Boer]

>>>>> "Vinzent" == Vinzent Hoefler <ada.rocks@jlfencey.com> writes:

    Vinzent> That isn't much different from SPARK where you should
    Vinzent> justify such decisions for the verifier. I don't think
    Vinzent> either method would have helped, because nobody seemed to
    Vinzent> look at the requirements at all.

True. Didn't they have a system in place where people have to sign
certain things? I.e. a software engineer can sign that use of this
software is ok.

Ultimately someone decided to include a piece of Ariadne 4
software. And that someone didn't check the requirements. Either
because a software engineer recommended it (in which case he should
have checked it), or he was the software engineer.

And if people didn't know about the importance of requirements, it's a
telling sign at what state software engineering in general really
is. It just reminds me at the education in software engineering I got.

But fortunately, at the moment I'm really shocked when I see code that
has absolutely no conditions under which it is supposed to operate
(just trial and error, and looking at the source if you have it). But
unfortunately, most code/specs is still written this way.

-- 
Regards,

Berend. (-:

Re: Ariane5 FAQ

[Berend de Boer]

>>>>> "Richard" == Richard Riehle <richard@adaworks.com> writes:

    Richard> systems than that found in Eiffel.  I am thinking here of
    Richard> SPARK.

    Richard> In general, the safety-critical community does not like
    Richard> the Eiffel model because it relies on assertion-errors at
    Richard> run-time.  While this is just fine for
    Richard> non-safety-critical software, it is not appropriate for a
    Richard> system such as Ariane V, or any other similar system.

Nothing (perhaps some annoying mathematical proofs :-) ) precludes
checking at compile time. I'm really hoping (probably have to write it
myself it seems if I want to have it ))-: ) for SPARK for Eiffel. That
would be a real step forward.

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Alexander" == Alexander Kopilovitch <aek@vib.usr.pu.ru> writes:

    Alexander> Can you tell me where can I read about Eiffel *without*
    Alexander> being fed with several hundred pages about that Design
    Alexander> By Contract? 

Try:

  http://www.cetus-links.org/oo_eiffel.html

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> For those unfamiliar with the concept, Eiffel allows a
    Hyman> derived class to override an inherited method with a method
    Hyman> whiach takes a more restricted argument type. This
    Hyman> obviously causes huge correctness issues, since at any call
    Hyman> using a base object you may be committing a type violation
    Hyman> that you are not even aware of! The Eiffel people have
    Hyman> spent years trying to figure out ways around the problem
    Hyman> while still keeping the original design.

Well:

1. No one needs to use the facility if you don't want it.

2. Contravariance in arguments is not of much practical use.

3. Covariance does not only occur in arguments but in other cases as
   well (generic types).

4. Covariance is of practical use. I think it's a good decision to
   spend time trying to solve it. But if it can't be done, it should
   be removed.

There is a too long paper on this subject:

  http://www.stud.tu-ilmenau.de/~robertw/headings.cgi/~robertw/eiffel/covariance3.htm

  (just read appendix B) 


It seems that the Eiffel world is moving to accept the fact that the
issue must be solved now and that perhaps contravariance must go in
cases where the compiler cannot verify it is used correctly.

There also is a much more elaborate attempt to solve it:

  http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf

But it seems fairly complex. But for people wanting an introduction to
the issue, this last paper is the one to read.

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
> 1. No one needs to use the facility if you don't want it.

Unfortunately, I believe this facility is heavily
intertwined with generics and container classes in
Eiffel. I think they adopted the notion that if D
is a subclass of B, then container-of-D should be
a subclass of container-of-B.

Re: Ariane5 FAQ

[Simon Wright]

Berend de Boer <berend@xsol.com> writes:

> The point is that the requirements should be *in the code*. That's
> where they belong. Not sure if this would have made a difference,
> but if you want to reuse code, you should now the conditions under
> which it should work. If programmers just grab code and reuse it
> without looking at those preconditions, well, you're not doing your
> job right.
> 
> And for those preconditions: use comments, DbC, whatever. And Ada
> has even Spark (that's something we need in the Eiffel world!).

I thought the SRI was a subsystem? if so, the software in it may have
been effectively "embedded"? (ie, not linked with Ariane 5-specific
code, just talked to over a comms channel). In which case you wouldn't
see the code at all, just the IDD.

Re: Ariane5 FAQ

[Robert I. Eachus]

Berend de Boer wrote:

> True. Didn't they have a system in place where people have to sign
> certain things? I.e. a software engineer can sign that use of this
> software is ok.
> 
> Ultimately someone decided to include a piece of Ariadne 4
> software. And that someone didn't check the requirements. Either
> because a software engineer recommended it (in which case he should
> have checked it), or he was the software engineer.
> 
> And if people didn't know about the importance of requirements, it's a
> telling sign at what state software engineering in general really
> is. It just reminds me at the education in software engineering I got.

Sigh.  There was initially a requirements allocation for the Ariane 5. 
That allocation assigned validation of the SRI under Ariane 5 conditions 
  to a "full-up" flight systems test using a three-axis gimbelled table.

But Arianespace did not have a process for managing and tracking 
requirements, this was assigned to the individual contractors.  The 
result was that some requirements testing "fell through the cracks" due 
to design changes, or in the case of the BH bug, changes in the scope of 
a contract.

In other words when the flight test simulation contract was changed, 
there was nothing in place to map the requirements tested by the new 
version of the contract back to the original system requirements.

At MITRE we are very familiar with the issue, because it keeps coming 
up.  You need to map the original system requirements into detailed 
requirements against lower level subsystems.  That is part of the 
engineering process.  But you must maintain the original system 
requirements, track changes to the SYSTEM reqirements whether caused by 
external events or by the process of developing the subsystems, and see 
to it that the final system "as delivered" meets the final version of 
the requirements document.

That isn't quite the first rule of systems engineering but it is close. 
  Hmmm. I guess the first rule is actually, "The requirements will 
change, plan for it."  And the need for and ongoing requirements 
tracking process is one derived requirement. ;-)

And all of the Ariane 5 failures so far have involved failures in this 
process.  In the recent engine failure it was "only" a contributing 
factor, but in the other four it was the primary cause of failure.  Is 
this an indication that reuse is difficult?  Not really, but it does 
indicate something that the software engineering community has by now 
had beaten into them:  Software and hardware may be reusable, 
documentation may be reusable, even unit testing data can be reused 
sometimes.  But you CANNOT reuse system tests, and you CANNOT skimp on 
the requirements process.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Non-philosophical definition of Eiffel?

[Jim Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<1059496557.747795@master.nyc.kbcfp.com>...
> Dmitry A. Kazakov wrote:
> > There is little sense in contravariant arguments
> 
> OK, I just want to make sure that we're talking about
> the same thing, so let me give specific examples. I'll
> write in C++ terms, just because.
> 
>      struct B1 { };
>      struct D1 : B1 { };
> 
>      struct B2
>      {
>          virtual B1 &f1();
>          virtual B1 &f2();
>          virtual void f3(B1 &);
>          virtual void f4(D1 &);
>          virtual void f5(B1 &);
>      };
> 
>      struct D2 : B2
>      {
>          B1 &f1();
>          D1 &f2();
>          void f3(B1 &);
>          void f4(B1 &);
>          void f5(D1 &);
>      };
> 
>      D2 d2;
>      B2 *b2 = &d2;
> 
> f1) This is ordinary overriding, with same return type.
>      Pretty much legal in every language.
> f2) This is covariant return type. Legal in C++. This
>      preserves LSP, since a call b2->f2() must return a
>      B1 &, and a D1 & is a B1 &.

The equivalent in Ada would require that f2 return a class
wide access type. In one case it would be an access to
b2'class, in the other case it would be to d2'class.

In general, neither C++ nor Java consider the function
return type as part of the signature of a function. This
means that a function in C++ or Java cannot be overriden
with only a change in the return type.

Compare this with Ada:

package foo
   type foo_array is array(1..10) of float;
   function total(Item : foo_array) return float;
   function total(Item : foo_array) return integer;
end foo;

Ada allows the overloading of the "total" function based
upon the return type of the function.


Jim Rogers

Re: Ariane5 FAQ

[Robert I. Eachus]

Berend de Boer wrote:

> The point is that the requirements should be *in the code*. That's
> where they belong. Not sure if this would have made a difference, but
> if you want to reuse code, you should now the conditions under which
> it should work. If programmers just grab code and reuse it without
> looking at those preconditions, well, you're not doing your job right.

Software requirements may belong in the software, but I don't buy the 
idea that the SYSTEM requirements belong in the software.  Managing 
system requirements is a process similar to managing software 
development, which often, as Dave Emery says, makes software engineers 
the system engineers of last resort.

But system requirements belong in the system spec.  There also needs to 
be a mapping from those requirements to subcomponents and subsystems 
(including software).  There also needs to be a mapping from the system 
requirements to how testing to meet each requirement will be done.

I am a big believer in designing software to not only meet requirements, 
but to make it easy to test/validate that those requirements are met. 
But putting hardware requirements in the software is a waste of time and 
effort.  Since most often SYSTEM requirements are met by a combination 
of software and hardware, the requirements in the software are usually 
derived requirements.

But I don't think the mapping from system requirements to software 
requirements belongs in the code.  And that was where the disconnect was 
here.  Even if every software module had a block comment that 
indentified the requirements it met, in this case the disconnect still 
would have occurred.  The software requirement for the alignment 
software to run for 40 seconds after MEI could have been perfectly 
documented in the software.  But only by accident would someone notice 
that the requirement it was derived from only applied to the Ariane 
4--unless someone who had the overall systems engineering responsibility
found that the software did not match the (actual Ariane 5) system 
requirements.

As it was, the fact that the alignment software did run for 40 seconds 
after MEI was noted, but the decision was made not to change it as it 
would require revalidating the software.  Duh!  See my previous posts. 
You can never reuse system level tests, so the testing should have been 
done whether or not the software was modified.  It is this retest that 
would have discovered that the control laws did not match the Ariane 5, 
and probably that the alignment software running after MEI was no longer 
required.  (But whether that was noticed or not, the NEED to actually do 
the "hardware in the loop" full-up flight systems simulation would have 
found it.)
-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Non-philosophical definition of Eiffel?

[Matthew Woodcraft]

Hyman Rosen wrote:
>f4) Contravariant argument types. This also preserves
>     LSP, but I don't know of a language which implements
>     it.

Sather.

-M-

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Jim Rogers wrote:
 > This means that a function in C++ or Java cannot
 > be overriden with only a change in the return type.

You mean overloaded, not overridden.

> Compare this with Ada:
> package foo
>    type foo_array is array(1..10) of float;
>    function total(Item : foo_array) return float;
>    function total(Item : foo_array) return integer;
> end foo;

You can do it in C++ these days with templates:

     typedef float (&foo_array)[10];
     template <typename T> T total(foo_array);

     template <> float total<>(foo_array);
     template <> int   total<>(foo_array);

     float (*pf)(foo_array) = total;
     int   (*pi)(foo_array) = total;

If you just call total(Item), it still can't use
the return type to overload, but you can play
tricks with pointers to functions, as shown.

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Robert I. Eachus wrote:

> > How can
> > one exclude anything from the simulator's contract if nobody can see differences
> > between the Ariane 4 and Ariane 5?
>
>No knowledge of the difference between the Ariane 4 and Ariane 5 was
>involved.  The perfectly reasonable assumption was made that there was
>no need to simulate the alignment functions which ran before takeoff,
>because there was nothing to be learned there.  (This is a case where
>the Araine 4 and 5 really were identical.  Sitting on the pad, the
>accelerometers and gyros were identical and the launch site was
>identical.)  Again what slipped through was that there was a requirement
>in the Ariane 4 to continue running the alignment software after MEI
>(main engine ignition), even though those results were "thrown away" if
>MEI resulted in a launch.

Ok, I agree, I recognize that kind of logic (I think I have seen it several
times, when I contacted with high-position managers). And I think that too
high concentration of this kind of logic within a project is a smoking gun
by itself. Well, I downgrade the seriouseness of the allegation (in some
non-technical sense -;), but I'm still not sure enough that not giving the
part of the source code to the simulator's developers is true fact and not
just good guess.

Anyway, assuming that that is a true fact,  I'm going to include into the next
draft of FAQ the following Q-A pair:

----------------------------------------------------------------------------
Q. So, if the limitations were clearly reflected in comments within the source
code then most probably they would be seen by the simulator's developers and
the disaster would be averted?

A. Probably NO. Because that part of the source code (aligment function),
where the limitations were violated in the flight, was not given to the
simulator's developers. That happened because simulation of that function
of real device was excluded from the contract for the simulator development.

The reason for that omission was that for Ariane 5 that function is not needed
after takeoff, and that before takeoff that function was really identical for
the Ariane 4 and Ariane 5. What was overlooked is that for the Ariane 4 that
function WAS executed after takeoff (about 40 seconds), so the unchanged real
device will execute that function for the Ariane 5 despite the absence of any
need for it there.
----------------------------------------------------------------------------

>This is one of those very hard to understand things until you have that
>Aha! moment.

Just because of that I'm going to include that Q-A pair into the FAQ even
being not sure enough that it is really true, but have only good probability
of that.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Ariane5 FAQ

[Berend de Boer]

>>>>> "Robert" == Robert I Eachus <rieachus@attbi.com> writes:

    Robert> But Arianespace did not have a process for managing and
    Robert> tracking requirements, this was assigned to the individual
    Robert> contractors.  

Thanks for the extensive explanation.


    Robert> -- "As far as I'm concerned, war always means failure." --
    Robert> Jacques Chirac, President of France "As far as France is
    Robert> concerned, you're right." -- Rush Limbaugh

And this is really funny :-)

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> Berend de Boer wrote:
    >> 1. No one needs to use the facility if you don't want it.

    Hyman> Unfortunately, I believe this facility is heavily
    Hyman> intertwined with generics and container classes in
    Hyman> Eiffel. I think they adopted the notion that if D is a
    Hyman> subclass of B, then container-of-D should be a subclass of
    Hyman> container-of-B.

Yes and no: 

1. The situation only occurs if you have a routine that actually has
   the generic type as argument.

2. There are no "container classes in Eiffel". It's not part of the
   language. There are several popular ones though.

3. And let me tell you that a container-of-D is a subclass of
   container-of-B is very useful in practice. Other languages might
   say they don't this "type-hole", but if you look at the code
   they're riddled with typecasts to workaround it. So essentially,
   it's a nonsen argument if you look at actual code.

I prefer a language that has a known hole above a language where I
must use type casts all over the place, any day every day.

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
> 3. And let me tell you that a container-of-D is a subclass of
>    container-of-B is very useful in practice. Other languages might
>    say they don't this "type-hole", but if you look at the code
>    they're riddled with typecasts to workaround it. So essentially,
>    it's a nonsen argument if you look at actual code.
> 
> I prefer a language that has a known hole above a language where I
> must use type casts all over the place, any day every day.

Huh? I have no idea what you're talking about. Both C++'s STL
containers and Matthew Heaney's equivalent Charles library in
Ada have typesafe containers which involve no casting, and have
no wrong-way bag-of-apples is a subclass of bag-of-fruit issues.

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> Huh? I have no idea what you're talking about. Both C++'s
    Hyman> STL containers and Matthew Heaney's equivalent Charles
    Hyman> library in Ada have typesafe containers which involve no
    Hyman> casting, and have no wrong-way bag-of-apples is a subclass
    Hyman> of bag-of-fruit issues.

What about this statement:

  "In general, in the design of Charles I have been willing to trade
  type-safety for flexibility and efficiency."

Telling, isn't it?

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> Huh? I have no idea what you're talking about. Both C++'s
    Hyman> STL containers and Matthew Heaney's equivalent Charles
    Hyman> library in Ada have typesafe containers which involve no
    Hyman> casting, and have no wrong-way bag-of-apples is a subclass
    Hyman> of bag-of-fruit issues.

As I wasn't sure about STL, I just looked at C++ support for
covariance. Low and behold I found this:

   Covariance of Virtual Member Functions

  The implementation of virtual constructors relies on a recent
  modification to C++, namely virtual functions' covariance. An
  overriding virtual function has to match the signature and the
  return type of the function it overrides. This restriction was
  recently relaxed to enable the return type of an overriding virtual
  function to co-vary with its class type. Thus, the return type of a
  public base can be changed to the type of a derived class. The
  covariance applies only to pointers and references.

  http://documentation.captis.com/files/c++/handbook/ch04/ch04.htm#Heading18


Fortunately I'm not a C++ expert so I can't really asses your claim
that the STL container libray offers the same functionality as an
Eiffel generic container library. But I really doubt it.

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
>   The implementation of virtual constructors relies on a recent
>   modification to C++, namely virtual functions' covariance.

There's no such thing as a virtual constructor in C++.
Covariant return types are not a "recent" modification
of C++ - they're in the Standard.

> Fortunately I'm not a C++ expert so I can't really asses your claim
> that the STL container libray offers the same functionality as an
> Eiffel generic container library. But I really doubt it.

Same functionality? They're containers. You put things in,
you take things out. They come out with the same type they
were put in with. The container holds things of exactly one
type, so there's no casting. If you want a polymorphic
container, you use a regular container of pointers to a
common base type.

If you're not a C++ expert but you know Ada, look up
Matthew Heaney's Charles library, which does the same kind
of thing in Ada.

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
>   "In general, in the design of Charles I have been willing to trade
>   type-safety for flexibility and efficiency."
> 
> Telling, isn't it?

Not without more context describing the situation where
he has done so.

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
>   "In general, in the design of Charles I have been willing to trade
>   type-safety for flexibility and efficiency."
> 
> Telling, isn't it?

OK, I looked up the context, and he mentions this where he's talking
about iterators not watching out for their own validity while they
are being operated upon. I know some C++ implementations come with
checked iterators that can be enabled in debug builds, so I assume
that Charles could (and maybe already does) have the same.

Re: Ariane5 FAQ

[Richard Riehle]

Berend de Boer wrote:

> >>>>> "Richard" == Richard Riehle <richard@adaworks.com> writes:
>
>     Richard> systems than that found in Eiffel.  I am thinking here of
>     Richard> SPARK.
>
>     Richard> In general, the safety-critical community does not like
>     Richard> the Eiffel model because it relies on assertion-errors at
>     Richard> run-time.  While this is just fine for
>     Richard> non-safety-critical software, it is not appropriate for a
>     Richard> system such as Ariane V, or any other similar system.
>
> Nothing (perhaps some annoying mathematical proofs :-) ) precludes
> checking at compile time. I'm really hoping (probably have to write it
> myself it seems if I want to have it ))-: ) for SPARK for Eiffel. That
> would be a real step forward.

It would be a difficult step to take.  Eiffel includes some features that
are incompatible with the level of checking done by SPARK.   When
checking Ada code, SPARK is more conservative than Ada itself. I
suspect that SPARK would disallow some of the most interesting and
useful features of Eiffel.

Eiffel is, in its present form, an excellent language for a wide range
of applications.  I like it for anything not safety-critical.  It is
certainly
better  than C++ (sorry Hyman) in my opinion.   However, niether
C++ nor Eiffel quite meet the level one would require of safety-critical
software -- unless one emasculates the most interesting aspects of each
of those languages.   Although SPARK permits only a subset of Ada,
it leaves the essential features of Ada intact, even after its rigorous
checking.  This would not be true of C++ or Eiffel.

Richard Riehle

Re: Ariane5 FAQ

[Hyman Rosen]

Richard Riehle wrote:
 > It is certainly better  than C++ (sorry Hyman) in my opinion.

S'OK :-)

C++ is a collection of many good ideas awaiting a brilliant
integrationist who can draw them together into a coherent
whole (unlike the many wannabees whose first step is to get
rid of the best parts). But I like it anyway.

Re: Non-philosophical definition of Eiffel?

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> If you just call total(Item), it still can't use
> the return type to overload, but you can play
> tricks with pointers to functions, as shown.

This is not equivalent to the Ada version :( As you said
it is a trick and as for all tricks the safety of the
code is really affacted, not to speak about the readability !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov]

On Tue, 29 Jul 2003 12:35:57 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> There is little sense in contravariant arguments
>
>OK, I just want to make sure that we're talking about
>the same thing, so let me give specific examples. I'll
>write in C++ terms, just because.
>
>     struct B1 { };
>     struct D1 : B1 { };
>
>     struct B2
>     {
>         virtual B1 &f1();
>         virtual B1 &f2();
>         virtual void f3(B1 &);
>         virtual void f4(D1 &);
>         virtual void f5(B1 &);
>     };
>
>     struct D2 : B2
>     {
>         B1 &f1();
>         D1 &f2();
>         void f3(B1 &);
>         void f4(B1 &);
>         void f5(D1 &);
>     };
>
>     D2 d2;
>     B2 *b2 = &d2;
>
>f1) This is ordinary overriding, with same return type.
>     Pretty much legal in every language.
>f2) This is covariant return type. Legal in C++. This
>     preserves LSP, since a call b2->f2() must return a
>     B1 &, and a D1 & is a B1 &.

Covariant return type does not preserve LSP. There is no thing which
does. Everything depends on the concrete situation. Here is a famous
example where covariant result breaks LSP:

type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse;
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Circle;
   -- Breaks LSP, not every circle, being resized yields a circle.

Typical solutions are:

----- Contravariant result
type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse'Class;
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Ellipse'Class;

----- Exceptions
Resize_Error : exception;
type Ellipse is ...;
function Resize (X : Ellipse;...) return Ellipse;
   -- May raise Resize_Error, but will not
type Circle is new Ellipse ...;
function Resize (X : Circle;...) return Circle;
   -- May raise Resize_Error, and will

---- LSP-abstinence-syndrome
Hey, "computer circles" are not "computer ellipses"!

The mentioned and all other "solutions" have various disadvantages.
The real problem is that it is fundametally unsolvable. One could
easily see that LSP is mathematically unsound, should one try to
define it formally.

>f3) Again, ordinary overriding, with the same argument
>     types in base and derived. Legal everywhere.
>f4) Contravariant argument types. This also preserves
>     LSP, but I don't know of a language which implements
>     it. LSP is preserved because a call of b2->f4() can
>     only pass a D1 & argument, and a D1 & is a B1 &.

Ada does this. It is a class-wide argument.

>f5) Covariant argument types. This is Eiffel's model.
>     LSP is not preserved, because a call to b2->f5()
>     may pass any B1 &, while d2.f5() wants only a D1 &.

Yes, but again, you cannot solve this. It is mother nature which
decided that no positive number have an inverse. So subtype Postive is
Integer ...; inevitable breaks LSP. You just have to decide what do
you want, [an absolute] LSP or positive numbers. I vote for positive
numbers.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ariane5 FAQ

[Richard Riehle]

Hyman Rosen wrote:

> But if the Ariane 4 code had carried the specification limits
> within it, as DbC, or as SPARK assertions, or as range checks,
> perhaps someone might have noticed that the Ariane 5 failed to
> meet those constraints.

Yet  they did design the Ariane  4 within those limits.  They would
have had to anticipate some yet unknown information regarding
future projects.

There is  limit to how much checking one can do in any system.
Industrial
Engineers raise the question of 100% checking for 0.0001 % probability
of error.   This becomes a risk management problem  as  well as a
problem in engineering economics.   Every software product carries
a certain amount of risk.   As we weight the consequences of a risk
against the cost of mitigation/prevention and the probability it will
occur, we make choices.   In the case of Ariane 4, the risk was deemed
inconsequential -- a  correct deeming, it seems.   For Ariane 5,  the
risk was significant, but the engineers failed to recognize it.

Richard Riehle

Re: Ariane5 FAQ

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
>  > It is certainly better  than C++ (sorry Hyman) in my opinion.
>
> S'OK :-)
>
> C++ is a collection of many good ideas awaiting a brilliant
> integrationist who can draw them together into a coherent
> whole (unlike the many wannabees whose first step is to get
> rid of the best parts). But I like it anyway.

There are some things for which I like in C++.  My concern is its
use in safety-critical software, a domain for which I believe
it is not well-suited.  Even Ada includes features that are
of questionable value in safety-critical software.  That is one
reason for  the  existence of SPARK.

I think it would be much more difficult to write a version of SPARK
for C++ than for Ada.   In the process, one would lose too much of
what is useful in C++.

Richard Riehle

Re: Non-philosophical definition of Eiffel?

[Matthew Heaney]

"Berend de Boer" <berend@xsol.com> wrote in message
news:un0ewiv53.fsf@xsol.com...
> >>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:
>
> What about this statement:
>
>   "In general, in the design of Charles I have been willing to trade
>   type-safety for flexibility and efficiency."
>
> Telling, isn't it?

What that refers to specifically is the case of "dangling iterators."  If I
do this:

procedure Op (C : in out Container_Type; E : in out Element_Type) is
  I : Iterator_Type;
begin
  Insert (C, E, I);
  Delete (C, I);
  E := Element (I); -- dangling reference
end;

The model in Charles is that an iterator is implemented as a pointer to an
internal node of storage, and it therefore confers no safety benefits beyond
what a plain access type gives you.

To get a completely safe iterator -- one that prevents a dangling reference
from ever occurring-- it is necessary to either reduce flexibility or reduce
efficiency.  But as a library designer, I am an no position to decide how
best to make that trade-off -- only the application developer can know that.
Therefore, my philosophy has been to provide the most flexible and efficient
primitives possible, which can then be combined as desired by the library
user.

We are in agreement that all this business in Java where you have to perform
a downcast when you extract an element is not type safe.  But this is hardly
the case in the STL and in Charles, which provide containers that really are
type safe, unlike Java.

As for a container-of-D being a subclass of container-of-B, this model
doesn't apply to STL or Charles, because those libraries eschew inheritance
in favor of alternate (and simpler) mechanisms.

By using an iterator and a generic algorithm, the container itself
disappears.  So instead of a container-of-D, you have a sequence-of-D, which
is a sequence-of-B, which is the equivalent of a container-of-B.  No
inheritance is necessary, thank you very much.

I'll have another release of Charles ready in the next few days.

http://home.earthlink.net/~matthewjheaney/charles/

Re: Ariane5 FAQ

[Vinzent Hoefler]

Richard Riehle wrote:

>I think it would be much more difficult to write a version of SPARK
>for C++ than for Ada.

Well, I guess so. :) Something similar is tried in Germany:
<URL:http://os.inf.tu-dresden.de/vfiasco/index.html>.

>   In the process, one would lose too much of
>what is useful in C++.

Well, the FAQ at <URL:http://os.inf.tu-dresden.de/vfiasco/faq.html>
isn't very verbose about it, but after what I have read in some German
newsgroups from one of the involved developers, it seems they (have
to) try a different approach than SPARK takes. For instance you cannot
have C++ without pointers like you can have Ada without access types.

So I guess, trying to get a "Safe C++" how they call it, is *much*
more work if you want to ensure software integrity at the same level
SPARK already can.


Vinzent.

Re: Ariane5 FAQ

[Hyman Rosen]

Richard Riehle wrote:
> Yet  they did design the Ariane  4 within those limits.
 > They would have had to anticipate some yet unknown
 > information regarding future projects.

There are two different things here which you are mixing up.

The first is making a program work within the limits specified
for its external inputs. As you say, Ariane 4 was designed that
way, and worked fine.

The second is making a program verify that its external inputs
actually lie within the specified limits. This was not done in
the Ariane 4 case. In general, this is a popular feature to omit,
since in a properly functioning overall system, these checks will
never trigger. But such programming protects the code against
"some yet unknown information regarding future projects" by
noticing when specified constraints on external inputs are violated.

> There is  limit to how much checking one can do in any system.

Sure. If the tradeoff was clearly in favor of one side or the
other, these discussions woudn't arise as much. It's the same
issue as deciding whether to leave range checks turned on in
deployed code.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
 > For instance you cannot have C++ without pointers
 > like you can have Ada without access types.

Why not?

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
> > For instance you cannot have C++ without pointers
> > like you can have Ada without access types.
>
>Why not?

Hmm, good question. :) I forgot that C++ introduced this reference
operator(?) "&" for function parameters, so someone wouldn't need that
indeed.
But doesn't most C++-code rely on pointers? Or is that just bad C-like
style?

Just to mention that, I guess my C++ is worse than your Ada. ;)


Vinzent.

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Pascal Obry wrote:
> This is not equivalent to the Ada version :(

Well, as I said, C++ does not the return value to
overload in expressions, so you have to ask to get
the right type:
     int   n = total<int>  (Item);
     float f = total<float>(Item);

Often, such code will be located inside templates
where the desired return type is known, so this may
not be much of a burden.

> As you said it is a trick

Perhaps I should have said "technique" instead.

> the safety of the code is really affacted,

No, this code is perfectly type safe.
Unless you mean something else?

> not to speak about the readability !

We don't :-)

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> type Ellipse is ...;
> function Resize (X : Ellipse;...) return Ellipse;
> type Circle is new Ellipse ...;
> function Resize (X : Circle;...) return Circle;
>    -- Breaks LSP, not every circle, being resized yields a circle.

We need to look at this without using common English words
that will cause confusion:

     type Base is ...;
     function Affect(X : Base) return Base;
     type Derived is new Base ...;
     function Affect(X : Derived) return Derived;

Now if I have a Derived object attached to a Base'Class
reference, and I make a dispatching call, the Derived
Affect will be called, will return a Derived object, and
since a Derived object is a Base object, substitutability
is satisfied. If the Derived type, or the Base type, is
supposed to maintain certain invariants but the methods
fail to do that, then the methods are in error, but that
has nothing to do with LSP.

> ---- LSP-abstinence-syndrome
> Hey, "computer circles" are not "computer ellipses"!

This is the correct answer.

> The real problem is that it is fundametally unsolvable. One could
> easily see that LSP is mathematically unsound, should one try to
> define it formally.

Nonsense. The only unsoundness here is the confusion between
abstract notions and and how they map into computer code. Your
use of the words "Ellipse" and "Circle" and "Resize" demonstrates
this. What is the computer-ellipse? If it is an object which has
independently resizable axes, and a computer-circle does not, then
a computer-circle is not a computer-ellipse, and can't be used in
places where computer-ellipses are expected. On the other hand, if
a computer-ellipse is an immutable object with a pair of axis sizes,
then a computer-circle can be written to fit that interface as well,
and can be used where a computer-ellipse is expected.

This is all perfectly obvious and has been talked about over and
over again. It's simply a matter of asking what operations a base
type supports, and whether a derived type can support all of the
same operations. Any notion that derivation within computer code
must somehow model abstract notions of the real world is wrong,
and leads into confusion and error.

> Ada does this. It is a class-wide argument.

Does it? Do you have an example? I'm not sure that it's the
same thing, but we'll see.

>>f5) Covariant argument types.
> 
> Yes, but again, you cannot solve this.

You "solve" it by not doing it.

 > So subtype Postive is Integer ...; inevitable breaks LSP.
 > You just have to decide what do you want, [an absolute]
 > LSP or positive numbers. I vote for positive numbers.

I forget. Does Ada let you pass a Positive object to a
procedure expecting an Integer out parameter, and range
check the assignment, or does it forbid such a call? If
it's the former, then LSP is in fact preserved, in that
the same set of operations are permitted. The operation
may throw an exception, but it's present. That's the same
thing as implementing Circle.Resize and having it throw
if the two axes are not specified to bethe same size.

Re: Ariane5 FAQ

[Hyman Rosen]

Vinzent Hoefler wrote:
> But doesn't most C++-code rely on pointers?
 > Or is that just bad C-like style?

Yes and no. A lot of use of pointers goes away with
STL containers, since std::vector replaces plain arrays
in typical cases. The remaining use for pointers is in
polymorphism, where you have a pointer to a base class
which may point to some derived object. Does SPARK
allow OO? If so, how? If not, you can also avoid it in
C++ in the same way.

Re: Ariane5 FAQ

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> But doesn't most C++-code rely on pointers?
> > Or is that just bad C-like style?
>
>Yes and no. A lot of use of pointers goes away with
>STL containers, since std::vector replaces plain arrays
>in typical cases.

Ok.

>The remaining use for pointers is in
>polymorphism, where you have a pointer to a base class
>which may point to some derived object. Does SPARK
>allow OO?

It does, but...

>If so, how?

... only statically. There is no dynamic dispatching, so there's no
need for access types there.

>If not, you can also avoid it in
>C++ in the same way.

Probably, yes.


Vinzent.

Re: Non-philosophical definition of Eiffel?

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1059578357.691797@master.nyc.kbcfp.com...
> Pascal Obry wrote:
> > As you said it is a trick
>
> Perhaps I should have said "technique" instead.

Can you clarify the difference between the terms "trick" and "technique"? Is
"technique" necessarily something else other than a dressed-up trick?

This reminds me of a cartoon I saw at the Alsys Waltham office. The top part
of this cartoon has an anthropomorphized, fat, ugly insect wearing grubby
clothes and a bowler, and smoking a cigar. Beneath this unappealing
anthropod is the caption "BUG". The bottom part of the cartoon shows exactly
the same insect, but with a few vital differences. In place of the bowler,
he is wearing a top hat. In place of the cigar, he now has a cigarette
holder. In place of the grubby clothes, the anthropod is wearing a tuxedo.
The caption under this second insect drawing reads "FEATURE".

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Frank J. Lhota wrote:
> Can you clarify the difference between the terms "trick" and "technique"? Is
> "technique" necessarily something else other than a dressed-up trick?

A trick becomes a technique once it's found to be generally
useful in some way and becomes part of the established way
of doing things.

One of the best C++ examples is the Barton & Nackman inheritance
trick, which has achieved wide use and goes under the name of
"curiously recurring template pattern"

     template <typename T> struct Base { /*...*/ };
     struct MyClass : Base<MyClass> { /*...*/ };

where a class inherits from a template parameterized with the
class itself.

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Matthew" == Matthew Heaney <matthewjheaney@earthlink.net> writes:

    Matthew> By using an iterator and a generic algorithm, the
    Matthew> container itself disappears.  So instead of a
    Matthew> container-of-D, you have a sequence-of-D, which is a
    Matthew> sequence-of-B, which is the equivalent of a
    Matthew> container-of-B.  No inheritance is necessary, thank you
    Matthew> very much.

Thanks for the explanation Matthew.

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Berend de Boer]

>>>>> "Hyman" == Hyman Rosen <hyrosen@mail.com> writes:

    Hyman> Same functionality? They're containers. You put things in,
    Hyman> you take things out. They come out with the same type they
    Hyman> were put in with. The container holds things of exactly one
    Hyman> type, so there's no casting. If you want a polymorphic
    Hyman> container, you use a regular container of pointers to a
    Hyman> common base type.

Are two such container of pointers to the same base type assignment
compatible?

And they're not when the common base type is not exactly equal (but
one is a parent of the other for example)?

-- 
Regards,

Berend. (-:

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Berend de Boer wrote:
> Are two such container of pointers to the same base type assignment
> compatible?

In C++ at least, you can assign containers of the same type
to each other. The target container will wind up with copies
of the elements of the source container.

> And they're not when the common base type is not exactly equal (but
> one is a parent of the other for example)?

Not by direct assignment. However, all the containers have a
templated assign(InputIterator begin, InputIterator end) method,
and you can assign any sequence whose elements are compatible
with the elements of the container, including derived to base
pointers.

Re: Ariane5 FAQ

[Dmitry A. Kazakov]

On Wed, 30 Jul 2003 18:54:43 +0200, Vinzent Hoefler
<ada.rocks@jlfencey.com> wrote:

>Hyman Rosen wrote:
>
>>If so, how?
>
>... only statically. There is no dynamic dispatching, so there's no
>need for access types there.

You can have dynamic dispatching without access types.

If the target type is statically known, then static dispatch might
well occur on an access parameter.

>>If not, you can also avoid it in
>>C++ in the same way.
>
>Probably, yes.

Very difficult. C++ is unable to return unconstrained objects on the
stack.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Ariane5 FAQ

[Vinzent Hoefler]

Dmitry A. Kazakov wrote:

>On Wed, 30 Jul 2003 18:54:43 +0200, Vinzent Hoefler
><ada.rocks@jlfencey.com> wrote:
>
>>Hyman Rosen wrote:
>>
>>>If so, how?
>>
>>... only statically. There is no dynamic dispatching, so there's no
>>need for access types there.
>
>You can have dynamic dispatching without access types.

Well, SPARK still has no dynamic dispatching. All types of tagged
objects are known at compile time.

>If the target type is statically known, then static dispatch might
>well occur on an access parameter.

Yes, but SPARK doesn't know about access at all.

>>>If not, you can also avoid it in
>>>C++ in the same way.
>>
>>Probably, yes.
>
>Very difficult. C++ is unable to return unconstrained objects on the
>stack.

SPARK can't do that neither.


Vinzent.

Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov]

On Wed, 30 Jul 2003 12:38:35 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> type Ellipse is ...;
>> function Resize (X : Ellipse;...) return Ellipse;
>> type Circle is new Ellipse ...;
>> function Resize (X : Circle;...) return Circle;
>>    -- Breaks LSP, not every circle, being resized yields a circle.
>
>We need to look at this without using common English words
>that will cause confusion:
>
>     type Base is ...;
>     function Affect(X : Base) return Base;
>     type Derived is new Base ...;
>     function Affect(X : Derived) return Derived;
>
>Now if I have a Derived object attached to a Base'Class
>reference, and I make a dispatching call, the Derived
>Affect will be called, will return a Derived object, and
>since a Derived object is a Base object, substitutability
>is satisfied.

No it isn't. You forgot semantics. LSP is all about semantics. The
problem is that Affect returning Derived just cannot be implemented in
Cricle/Ellipse case. This problem appears each time a derived type is
a specialization of the base. Specialization breaks out-methods.
Covariant result is a case of out-method. Period.

> If the Derived type, or the Base type, is
>supposed to maintain certain invariants but the methods
>fail to do that, then the methods are in error, but that
>has nothing to do with LSP.

What does it mean to "be in error"? The contract of Base does not
mention "being in error". So it violates the contract and thus LSP.

>> ---- LSP-abstinence-syndrome
>> Hey, "computer circles" are not "computer ellipses"!
>
>This is the correct answer.

Yes, but it does not imply that Circle shall not be a subtype of
Ellipse. In a real system it will, because code reuse is more
important than far-fetched absolute LSP. It is clear that an absolute
substitutability cannot be enfoced by any means. The real solution is
a context-dependent substitutability and type systems helping in
checking it as much as possible.

>> The real problem is that it is fundametally unsolvable. One could
>> easily see that LSP is mathematically unsound, should one try to
>> define it formally.
>
>Nonsense. The only unsoundness here is the confusion between
>abstract notions and and how they map into computer code. Your
>use of the words "Ellipse" and "Circle" and "Resize" demonstrates
>this. What is the computer-ellipse? If it is an object which has
>independently resizable axes, and a computer-circle does not, then
>a computer-circle is not a computer-ellipse, and can't be used in
>places where computer-ellipses are expected. On the other hand, if
>a computer-ellipse is an immutable object with a pair of axis sizes,
>then a computer-circle can be written to fit that interface as well,
>and can be used where a computer-ellipse is expected.

This is one of many ways of defending [absolute] LSP. Surely if you
are dealing with something so airy which cannot be expressed
mathematically, then you simply cannot disprove it mathematically.
(:-))

>This is all perfectly obvious and has been talked about over and
>over again. It's simply a matter of asking what operations a base
>type supports, and whether a derived type can support all of the
>same operations. Any notion that derivation within computer code
>must somehow model abstract notions of the real world is wrong,
>and leads into confusion and error.

This exactly means to be mathematically unsound.

>> Ada does this. It is a class-wide argument.
>
>Does it? Do you have an example? I'm not sure that it's the
>same thing, but we'll see.

Class-wide arguments are not controlled, they are not inherited when
you derive. Because a class-wide argument is a closure of the set of
all derived types.

type Base is tagged ...;
procedure Foo (X : Base'Class);
type Derived is new Base ...;
   -- Foo is same for Derived and it is not inherited

One could say that class-wide arguments are contravariant, but this
would be imprecise, because no type conversion to the base type
happens. However, the effect is same [as long as redispatch supported
through an embedded type tag] 

> > So subtype Postive is Integer ...; inevitable breaks LSP.
> > You just have to decide what do you want, [an absolute]
> > LSP or positive numbers. I vote for positive numbers.
>
>I forget. Does Ada let you pass a Positive object to a
>procedure expecting an Integer out parameter,

Yes.

> and range
>check the assignment, or does it forbid such a call? If
>it's the former, then LSP is in fact preserved, in that
>the same set of operations are permitted.

It is so:

1. if Constraint_Error is a part of the contract of the procedure then
LSP is preserved with this regard. As I said to add all imaginable
exceptions to all contracts is a possible way. Unfortunately it is
great burden and it erodes the idea of checkability.

2. if Constraint_Error is not in the contract. then LSP is violated.

>The operation
>may throw an exception, but it's present. That's the same
>thing as implementing Circle.Resize and having it throw
>if the two axes are not specified to bethe same size.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> No it isn't. You forgot semantics. LSP is all about semantics.

Maybe it is to you. To me, LSP is all about programming.
I don't worry my head about pretty little semantic notions.

> This problem appears each time a derived type is
> a specialization of the base.

In OO, derived types are supposed to be able to do
whatever their base can do, and optionally more. If
you want a derived type to do less, don't make it a
(public) child of the Base. The formal expression of
this in many OO languages is that the parameter types
of overriding functions are the same as their base
function parameter types.

Now, it is true that many people use a technique of
having a wide base interface, and then implementing
derived methods which do nothing but throw exceptions.
Contravariant parameter types could be looked at in
the same way - as if the overriding function took the
wider type, but immediately did a type test and threw
an exception if the result was not of the narrower
type. I don't happen to like this way of doing things,
because I favor static polymorphism, but for some
people, this floats their boat.

Re: Ariane5 FAQ

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Wed, 30 Jul 2003 18:54:43 +0200, Vinzent Hoefler
> <ada.rocks@jlfencey.com> wrote:
>>Hyman Rosen wrote:
...
>>>If not, you can also avoid it in
>>>C++ in the same way.
>>
>>Probably, yes.
> 
> Very difficult. C++ is unable to return unconstrained objects on the
> stack.

If you ever need to qualify a member, you'll want to
use "this", which is by definition a pointer.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Ariane5 FAQ

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> Ok, I agree, I recognize that kind of logic (I think I have seen it several
> times, when I contacted with high-position managers). And I think that too
> high concentration of this kind of logic within a project is a smoking gun
> by itself. Well, I downgrade the seriouseness of the allegation (in some
> non-technical sense -;), but I'm still not sure enough that not giving the
> part of the source code to the simulator's developers is true fact and not
> just good guess.
> 
> Anyway, assuming that that is a true fact,  I'm going to include into the next
> draft of FAQ the following Q-A pair:
> 
> ----------------------------------------------------------------------------
> Q. So, if the limitations were clearly reflected in comments within the source
> code then most probably they would be seen by the simulator's developers and
> the disaster would be averted?
> 
> A. Probably NO. Because that part of the source code (aligment function),
> where the limitations were violated in the flight, was not given to the
> simulator's developers. That happened because simulation of that function
> of real device was excluded from the contract for the simulator development.
> 
> The reason for that omission was that for Ariane 5 that function is not needed
> after takeoff, and that before takeoff that function was really identical for
> the Ariane 4 and Ariane 5. What was overlooked is that for the Ariane 4 that
> function WAS executed after takeoff (about 40 seconds), so the unchanged real
> device will execute that function for the Ariane 5 despite the absence of any
> need for it there.
> ----------------------------------------------------------------------------

As far as I know the simulation developers did have ACCESS to all of the 
source code.  It was the documentation that they didn't have.  So some 
programmer might have noticed that the alignment code ran for 40 seconds 
after ignition, but without the documentation the hypothetical 
simulation programmer had no reason to doubt that it was done for valid 
reasons.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Non-philosophical definition of Eiffel?

[Dmitry A. Kazakov]

On Thu, 31 Jul 2003 11:49:43 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> No it isn't. You forgot semantics. LSP is all about semantics.
>
>Maybe it is to you. To me, LSP is all about programming.
>I don't worry my head about pretty little semantic notions.

Barbara's (+ rarely mentioned Wing) paper was called "A Behavioral
Notion of Subtyping". Now tell me that behavior is not about
semantics.

>> This problem appears each time a derived type is
>> a specialization of the base.
>
>In OO, derived types are supposed to be able to do
>whatever their base can do, and optionally more.

This is a vague narration of LSP-subtyping, not OO. There could be
other notions as well. For instance, both C++, and Ada implement
subtypings of other kinds. This was probably the reason why OO-people
invented the term "subclassing", to stress a nasty truth that almost
everything we are doing is not LSP conform. (:-))

>If you want a derived type to do less, don't make it a
>(public) child of the Base.

"to do" less vs. more vs. something other is again semantics. And
inspect your sentence carefully, you will find that any polymorphic
behaviour contradicts LSP. In fact, an ability for a callee to detect
the actual type is enough to break substitutability.

> The formal expression of
>this in many OO languages is that the parameter types
>of overriding functions are the same as their base
>function parameter types.

There are many ways. 

>Now, it is true that many people use a technique of
>having a wide base interface, and then implementing
>derived methods which do nothing but throw exceptions.
>Contravariant parameter types could be looked at in
>the same way - as if the overriding function took the
>wider type, but immediately did a type test and threw
>an exception if the result was not of the narrower
>type. I don't happen to like this way of doing things,
>because I favor static polymorphism, but for some
>people, this floats their boat.

You contradict yourself. If (according to LSP) a derived type is
always substitutable for the base, why should it throw an exception in
a contravariant parameter? It is not so, either in C++ where all
arguments instead of the hidden one are contravariant, or in Ada
(class-wide arguments).

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de

Re: Non-philosophical definition of Eiffel?

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> You contradict yourself.

I keep my mind firmly focussed on the Shape base class,
its Draw method, and the Square, Circle, and Tangle
derived classes. All else follows.

Re: Ariane5 FAQ

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>As far as I know the simulation developers did have ACCESS to all of the
>source code.  It was the documentation that they didn't have.  So some
>programmer might have noticed that the alignment code ran for 40 seconds
>after ignition, but without the documentation the hypothetical
>simulation programmer had no reason to doubt that it was done for valid
>reasons.

Thank you for clarification of this point. So, I'm going to change the answer
(the "Q" remains unchanged) in the next draft of the FAQ, to the following:

----------------------------------------------------------------------------
Q. So, if the limitations were clearly reflected in comments within the source
code then most probably they would be seen by the simulator's developers and
the disaster would be averted?

A. Probably No. Because simulation of the alignment function of real device
was excluded from the contract for the simulator development. Consequently,
the simulator's developers have no stimulus (without the documentation, which
was not given to them) to look into the part of the source code where the
limitations were violated in the flight. (They may look there out of curiosity,
but time pressure and general stress surrounding the project left too little
room for curiosity.)

The reason for omission of the alignment function from the simulator was that
for Ariane 5 that function is not needed after takeoff, and that before
takeoff that function was really identical for the Ariane 4 and Ariane 5.
What was overlooked is that for the Ariane 4 that function WAS executed after
takeoff (about 40 seconds), so the unchanged real device will execute that
function for the Ariane 5 despite the absence of any need for it there.
----------------------------------------------------------------------------



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: Non-philosophical definition of Eiffel?

[Robert Spooner]

Frank J. Lhota wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote in message
> news:1059578357.691797@master.nyc.kbcfp.com...
> 
>>Pascal Obry wrote:
>>
>>>As you said it is a trick
>>
>>Perhaps I should have said "technique" instead.
> 
> 
> Can you clarify the difference between the terms "trick" and "technique"? Is
> "technique" necessarily something else other than a dressed-up trick?
> 
A technique is a trick that works at least twice? :)

-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu