How would Ariane 5 have behaved if overflow checking were not turned off?

How would Ariane 5 have behaved if overflow checking were not turned off?

[Elias Salomão Helou Neto]

I have followed the (quite lenghty) on a topic, IIRC, about bitwise
operators, which eventually lead to people mentioning the Ariane 5
case.

Since then I have been wondering. If compiler checking where actually
turned on, what would have happened? How could it avoid the disaster?

Right now I think of three possibilities, the two former seem very
unlikely to me.

a) It would, even if the problem went undetected during testing, have
made the developers actually develop code handling this exceptional
possibility.

b) The compiler default action for unhandled overflows have saved the
day;

c) Developers would probably ignore the exceptional flow path and the
disaster would happen anyway.

Which one, if any, is close to reality?

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[KK6GM]

On Mar 14, 8:49 am, Elias Salomão Helou Neto <eshn...@gmail.com>
wrote:
> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
> operators, which eventually lead to people mentioning the Ariane 5
> case.
>
> Since then I have been wondering. If compiler checking where actually
> turned on, what would have happened? How could it avoid the disaster?
>
> Right now I think of three possibilities, the two former seem very
> unlikely to me.
>
> a) It would, even if the problem went undetected during testing, have
> made the developers actually develop code handling this exceptional
> possibility.
>
> b) The compiler default action for unhandled overflows have saved the
> day;
>
> c) Developers would probably ignore the exceptional flow path and the
> disaster would happen anyway.
>
> Which one, if any, is close to reality?

To be clear, "overflow checking" was not turned off.  It was, rather,
left to the default handling for the conversion in question.  The
default handling was designed based on the assumption that anything
that triggered it was due to a hardware problem.  So the two other
options would have been (a) have the default handling ignore ALL range
errors (really?!!), or add custom exception handling to the conversion
in question.  In that case, what would the exception handling have
done differently, and by what justification?

It really all comes back to the essential question, if variable X is
known, PROVEN, to never exceed the range A..B, and suddenly it does
exceed that range, what is the correct action?  You can't just throw
it away and read it again, since in the Ariane 5 case it would have
continued to exceed its proven valid range.  So what do you do?

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Yannick Duchêne (Hibou57)]

Le Mon, 14 Mar 2011 17:17:10 +0100, KK6GM <mjsilva@scriptoriumdesigns.com>  
a écrit:
> It really all comes back to the essential question, if variable X is
> known, PROVEN, to never exceed the range A..B, and suddenly it does
> exceed that range, what is the correct action?  You can't just throw
> it away and read it again, since in the Ariane 5 case it would have
> continued to exceed its proven valid range.  So what do you do?
Seems the proof was rather weak there ;)

I suppose the “proven” here mean “physically proven” (by some physic  
properties of the engine) and not “logically proven” as impossible to  
happen in the driver software. Defensive programming may have been an  
option here; if there was something wrong in the input, may be that was  
because the engine behave unexpectedly. Such a case (just like erroneous  
human input would be) should be caught by defensive programming. What to  
do next ? Well, first raise an alarm (to the control center), then trigger  
some automatic urgency sequence.

Any way, the way this happened, that seems unlikely the ship could be  
saved (any urgency sequence could perhaps attempt to avoid collateral  
damages, no more)

Seems relevant or not ?

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

Yannick Duchêne (Hibou57) wrote:

> I suppose the “proven” here mean “physically proven” (by some physic
> properties of the engine) and not “logically proven” as impossible to
> happen in the driver software.

Precisely. The proof was just for the wrong engine.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[KK6GM]

On Mar 14, 12:25 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 14 Mar 2011 17:17:10 +0100, KK6GM <mjsi...@scriptoriumdesigns.com>  
> a écrit:> It really all comes back to the essential question, if variable X is
> > known, PROVEN, to never exceed the range A..B, and suddenly it does
> > exceed that range, what is the correct action?  You can't just throw
> > it away and read it again, since in the Ariane 5 case it would have
> > continued to exceed its proven valid range.  So what do you do?
>
> Seems the proof was rather weak there ;)

Well, if I "prove" that the length of an earth day can never be more
than 25 hours, and that if some sensor measures more than 25 hours I
must have a hardware failure, and then I run my system on venus and
the measured day is truly more than 25 hours, what should happen?

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Yannick Duchêne (Hibou57)]

Le Mon, 14 Mar 2011 21:28:17 +0100, KK6GM <mjsilva@scriptoriumdesigns.com>  
a écrit:
> Well, if I "prove" that the length of an earth day can never be more
> than 25 hours, and that if some sensor measures more than 25 hours I
> must have a hardware failure, and then I run my system on venus and
> the measured day is truly more than 25 hours, what should happen?
Vinzent solved the mystery, he says “Precisely. The proof was just for the  
wrong engine”. This explains both the funny fact with the proof and what  
cause the proof to be wrong in that case. If you use a proof made for  
Venus, on Earth, proof will be wrong.

Learned interesting things in that topic.

-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.

“I am fluent in ASCII” [Warren 2010]

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Shark8]

On Mar 14, 10:02 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 14 Mar 2011 21:28:17 +0100, KK6GM <mjsi...@scriptoriumdesigns.com>  
> a écrit:> Well, if I "prove" that the length of an earth day can never be more
> > than 25 hours, and that if some sensor measures more than 25 hours I
> > must have a hardware failure, and then I run my system on venus and
> > the measured day is truly more than 25 hours, what should happen?
>
> Vinzent solved the mystery, he says “Precisely. The proof was just for the  
> wrong engine”. This explains both the funny fact with the proof and what  
> cause the proof to be wrong in that case. If you use a proof made for  
> Venus, on Earth, proof will be wrong.
>
> Learned interesting things in that topic.
>
> --
> Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
> les chiens.
>
> “I am fluent in ASCII” [Warren 2010]

Another way to think of it is it would be like trying to use the
Pythagorean
theorem for some triangle which isn't guaranteed to be a right
triangle.
Since the theorem is only valid for right-triangles it is entirely
possible
to get a "wrong answer" even though there are many cases where
[because the
triangle is close to 90-degrees] its results will be "good enough"
such as
in wood-working where there is some amount of give.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

Elias Salomão Helou Neto wrote:

> Since then I have been wondering. If compiler checking where actually
> turned on, what would have happened?

The same, according to the specification.

> How could it avoid the disaster?

Not at all.

> Right now I think of three possibilities, the two former seem very
> unlikely to me.
>
> a) It would, even if the problem went undetected during testing, have
> made the developers actually develop code handling this exceptional
> possibility.

By handling it exactly the way it was supposed to be:

Assuming a hardware error and leave control to the redundant subsystem.

> Which one, if any, is close to reality?

As it has been mentioned here many times before, the software behaved
exactly as specified and it is very unlikely that _any_ error handling
could have avoided the problem - unless the error handler were buggy.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[robin]

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

Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>Elias Salomão Helou Neto wrote:

>> Since then I have been wondering. If compiler checking where actually
>> turned on, what would have happened?

>The same, according to the specification.

>> How could it avoid the disaster?

>Not at all.

On the contrary., an error handler would have performed
something useful.
The crux of the matter is that the data bus would not have been
loaded with an error number [which was then treated as guidance data].

>> Right now I think of three possibilities, the two former seem very
>> unlikely to me.
>
>> a) It would, even if the problem went undetected during testing, have
>> made the developers actually develop code handling this exceptional
>> possibility.

>By handling it exactly the way it was supposed to be:

>Assuming a hardware error and leave control to the redundant subsystem.

That was the major blunder that they made,
namely, treating a programming error as a hardware error.
By doing that, they guaranteed failure of the mission.

>> Which one, if any, is close to reality?

>As it has been mentioned here many times before, the software behaved
>exactly as specified and it is very unlikely that _any_ error handling
>could have avoided the problem

An error handler would have rescued the mission.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Simon Wright]

"robin" <robin51@dodo.com.au> writes:

> An error handler would have rescued the mission.

Errm - if the fixed-point type used for horizontal velocity was say

   delta 2.0**-14 range -2.0 .. 2.0

the compiler would almost certainly have packed it so that there were no
spare bits; 1.9999 would be represented as 16#3fff#. So if the value
that is to be fitted into this type is >= 2.0, there is no way to
represent it and any calculations based on the velocity over the ground
as stored would be garbage.

Mission almost certainly over, I think.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[robin]

Simon Wright wrote in message ...
>"robin" <robin51@dodo.com.au> writes:
>
>> An error handler would have rescued the mission.
>
>Errm - if the fixed-point type used for horizontal velocity was say
>
>   delta 2.0**-14 range -2.0 .. 2.0
>
>the compiler would almost certainly have packed it so that there were no
>spare bits; 1.9999 would be represented as 16#3fff#.

The value, presumably, in an integer word is, well, an integer.

> So if the value
>that is to be fitted into this type is >= 2.0, there is no way to
>represent it and any calculations based on the velocity over the ground
>as stored would be garbage.

Plenty of scope to substitute a signed value of max. magnitude.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Martin Krischik]

Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:

> That was the major blunder that they made,
> namely, treating a programming error as a hardware error.

Let me repeat: There was no programming error. The software was correct  
for the Ariane 4. If at all it was a deployment or management error in  
installing Ariane 4 software on the Ariane 5.

> By doing that, they guaranteed failure of the mission.

If you load 5 metric tons onto a pick up designed for a 300kg load then it  
is *NOT* the suspensions fault that the under vehicle kisses the ground  
and the vehicle won't move metre any more. And the suspensions engineers  
did not “guaranteed failure of the mission” but the idiot you ordered the  
cargo to be deployed.

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[robin]

Martin Krischik wrote in message ...
>Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>
>> That was the major blunder that they made,
>> namely, treating a programming error as a hardware error.
>
>Let me repeat: There was no programming error.

Let me repeat:  The major blunder made was in treating
a programming error as a hardware error.
The error was in assuming that there was no possibility of a
programming error, and therefore it must be hardware error.
This error was made in the Ariadne 4.

This attitide that "it can't happen" therefore there's no need to test for it
is responsible for run-time failures from the early days of programming.

Remember Robert's Law: "Even if it can't go wrong, it will".

In a real-time system, EVERY possibility must be tested for.

> The software was correct
>for the Ariane 4.

No it wasn't.
It had unchecked overflow.

> If at all it was a deployment or management error in
>installing Ariane 4 software on the Ariane 5.
>
>> By doing that, they guaranteed failure of the mission.

Quite so.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Vinzent Hoefler]

robin wrote:

> The error was in assuming that there was no possibility of a
> programming error, and therefore it must be hardware error.
> This error was made in the Ariadne 4.

If the sensor had read back a value that large for real, the Ariane 4
would have been disintegrated long before.

I'd call that "hardware failure".


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Alex R. Mosteo]

robin wrote:

> Martin Krischik wrote in message ...
>>Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>>
>>> That was the major blunder that they made,
>>> namely, treating a programming error as a hardware error.
>>
>>Let me repeat: There was no programming error.
> 
> Let me repeat:  The major blunder made was in treating
> a programming error as a hardware error.
> The error was in assuming that there was no possibility of a
> programming error, and therefore it must be hardware error.
> This error was made in the Ariadne 4.
> 
> This attitide that "it can't happen" therefore there's no need to test for
> it is responsible for run-time failures from the early days of
> programming.
> 
> Remember Robert's Law: "Even if it can't go wrong, it will".
> 
> In a real-time system, EVERY possibility must be tested for.

IIRC there was the extra factor of limited CPU budget; not checking this 
conversion (that, again, for Ariane IV would mean a hardware error) would be 
even more justified.

> 
>> The software was correct
>>for the Ariane 4.
> 
> No it wasn't.
> It had unchecked overflow.
> 
>> If at all it was a deployment or management error in
>>installing Ariane 4 software on the Ariane 5.
>>
>>> By doing that, they guaranteed failure of the mission.
> 
> Quite so.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

Alex R. Mosteo wrote in message ...
>robin wrote:

>> Martin Krischik wrote in message ...
>>>Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>>>
>>>> That was the major blunder that they made,
>>>> namely, treating a programming error as a hardware error.
>>
>>>Let me repeat: There was no programming error.
>
>> Let me repeat:  The major blunder made was in treating
>> a programming error as a hardware error.
>> The error was in assuming that there was no possibility of a
>> programming error, and therefore it must be hardware error.
>> This error was made in the Ariadne 4.
>
>> This attitide that "it can't happen" therefore there's no need to test for
>> it is responsible for run-time failures from the early days of
>> programming.
>
>> Remember Robert's Law: "Even if it can't go wrong, it will".
>
>> In a real-time system, EVERY possibility must be tested for.

>IIRC there was the extra factor of limited CPU budget; not checking this
>conversion (that, again, for Ariane IV would mean a hardware error) would be
>even more justified.

I don't recall seeing anything about that.
In any case it would be irrelevant.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

robin wrote:

> Alex R. Mosteo wrote in message ...
>
>> IIRC there was the extra factor of limited CPU budget; not checking this
>> conversion (that, again, for Ariane IV would mean a hardware error) would be
>> even more justified.
>
> I don't recall seeing anything about that.

|It has been stated to the Board that not all conversions were protected because a
|maximum workload target of 80% had been set for the SRI computer.

> In any case it would be irrelevant.

Right, requirements are completely irrelevant. Nice try.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Martin Krischik]

Am 17.03.2011, 00:39 Uhr, schrieb robin <robin51@dodo.com.au>:

> Martin Krischik wrote in message ...

> In a real-time system, EVERY possibility must be tested for.
>
>> The software was correct
>> for the Ariane 4.
>
> No it wasn't.
> It had unchecked overflow.

In my example (which you cut away): If you add a “overload” detector to  
the suspension and a “overload” lamp to the dashboard: Would it make the  
pickup truck dive any better when overloaded 16 time over?

So, if you had added an overflow detection: What would you have done in  
the exception handler?

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Martin Krischik]

Am 17.03.2011, 00:39 Uhr, schrieb robin <robin51@dodo.com.au>:

> In a real-time system, EVERY possibility must be tested for.

It is my upstanding that the test was (consciously) removed because the  
time needed to perform the check would have broken real time requirements.

Martin

-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Dmitry A. Kazakov]

On Sun, 20 Mar 2011 18:11:45 +0100, Martin Krischik wrote:

> Am 17.03.2011, 00:39 Uhr, schrieb robin <robin51@dodo.com.au>:
> 
>> In a real-time system, EVERY possibility must be tested for.
> 
> It is my upstanding that the test was (consciously) removed because the  
> time needed to perform the check would have broken real time requirements.

I would like to see a test for the possibility of the gravitational
constant G to become 4.12 10**5 N (m/kg)**2 at the 33-rd second of
flight...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Leif Roar Moldskred]

robin <robin51@dodo.com.au> wrote:

> Let me repeat:  The major blunder made was in treating
> a programming error as a hardware error.

Uh... how do you suggest to, automatically, at runtime, tell the
difference between hardware errors and programming errors? 

And how on Earth is strapping a piece of kit onto the _wrong type 
of engine_ not a hardware error?

-- 
Leif Roar Moldskred

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Florian Weimer]

* Martin Krischik:

> Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>
>> That was the major blunder that they made,
>> namely, treating a programming error as a hardware error.
>
> Let me repeat: There was no programming error. The software was
> correct for the Ariane 4. If at all it was a deployment or management
> error in  installing Ariane 4 software on the Ariane 5.

How many committee meetings do you need during the development of the
software that this is no longer considered programming error?

If I take a piece of code, say from a Stackoverflow discussion, and
paste it into the project I'm working on, and it later crashes, I
doubt anyone would *not* consider this a programming error.  Even if I
had a manager that told me to use that code, I would still consider it
my fault that I didn't integrate it properly.

If you take an extremely narrow view of programming, treating it as
the supposedly mechanical conversion from a (semi)formal specification
to input which can be processed by a given compiler, then this might
not be considered a programming error.  But programming is not a
mechanical activity, and programmers are expected to notice such
problems and address them before the code ships.  Of course, in large
systems, with compartmentalized design and development, it is
unreasonable to expect that they can do this in all cases, hence my
reference to committee meetings.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Martin Krischik]

Am 20.03.2011, 14:07 Uhr, schrieb Florian Weimer <fw@deneb.enyo.de>:

> * Martin Krischik:
>
>> Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>>
>>> That was the major blunder that they made,
>>> namely, treating a programming error as a hardware error.

> If I take a piece of code, say from a Stackoverflow discussion, and
> paste it into the project I'm working on, and it later crashes, I
> doubt anyone would *not* consider this a programming error.  Even if I
> had a manager that told me to use that code, I would still consider it
> my fault that I didn't integrate it properly.

That would only be correct if a programmer would do the copy paste job.  
But it is my understanding that no programmers and testers had been  
involved in the Ariane 5 disaster.  Just a deployer to install the  
software.

Regards

Martin
-- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Florian Weimer]

* Martin Krischik:

> Am 20.03.2011, 14:07 Uhr, schrieb Florian Weimer <fw@deneb.enyo.de>:
>
>> * Martin Krischik:
>>
>>> Am 16.03.2011, 11:41 Uhr, schrieb robin <robin51@dodo.com.au>:
>>>
>>>> That was the major blunder that they made,
>>>> namely, treating a programming error as a hardware error.
>
>> If I take a piece of code, say from a Stackoverflow discussion, and
>> paste it into the project I'm working on, and it later crashes, I
>> doubt anyone would *not* consider this a programming error.  Even if I
>> had a manager that told me to use that code, I would still consider it
>> my fault that I didn't integrate it properly.
>
> That would only be correct if a programmer would do the copy paste
> job. But it is my understanding that no programmers and testers had
> been  involved in the Ariane 5 disaster.  Just a deployer to install
> the  software.

The report isn't totally clear on this point ("practically the same"
can mean anything when applied to software).  If the SRI was literally
unchanged from Ariane 4, then you could indeed argue that this was a
deployment problem.  But if it was changed beyond mere recompilation,
there was new development, and the component should definitely have
been tested in an up-to-date simulation.  Apparently, that was the
plan, but then a test waiver was issued (in yet another committee
meeting).

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

Florian Weimer wrote:

> The report isn't totally clear on this point ("practically the same"
> can mean anything when applied to software).  If the SRI was literally
> unchanged from Ariane 4,

AFAIK that's exactly what was done.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

Florian Weimer wrote:

> not be considered a programming error.  But programming is not a
> mechanical activity, and programmers are expected to notice such
> problems and address them before the code ships.

They /did/ notice it. They reasoned it could not happen in Ariane 4.

What they didn't was to take into account that the same code was to
be reused in Ariane 5 without further reconsideration.

This hardly constitutes a programming error.

To construct an example, if I'd designed a speedometer for a car and I
know that the car can't be faster than 250 km/h, and so I reason,
a representable range for a speed delta for this car would definitely
fit within +-327.67 km/h, I did a programming error because someone came
along, put the same code into a Bugatti Veyron without even retesting,
where then the limit was exceeded and the airbag triggered at about
328 km/h due to a wraparound of the value which the code interpreted as
sudden decelaration?


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
       --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

robin wrote:

> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>> Elias Salomão Helou Neto wrote:
>
>>> Since then I have been wondering. If compiler checking where actually
>>> turned on, what would have happened?
>
>> The same, according to the specification.
>
>>> How could it avoid the disaster?
>
>> Not at all.
>
> On the contrary., an error handler would have performed
> something useful.

Precisely what? The _only_ reasonable action at that point was to assume
a hardware error and shutdown the computer. For Ariane 4, that is.

> The crux of the matter is that the data bus would not have been
> loaded with an error number [which was then treated as guidance data].

AFAIK this was required in case both systems died. And as we know, they
did exactly that. I'd assume the possibility of two hardware errors at
the same time were considered remote.

>> By handling it exactly the way it was supposed to be:
>
>> Assuming a hardware error and leave control to the redundant subsystem.
>
> That was the major blunder that they made,
> namely, treating a programming error as a hardware error.
> By doing that, they guaranteed failure of the mission.

Again. In the Ariane 4 it would have been exactly that. A hardware error.
There was no freaking way, Ariane 4 could have exceeded the safe range.

>>> Which one, if any, is close to reality?
>
>> As it has been mentioned here many times before, the software behaved
>> exactly as specified and it is very unlikely that _any_ error handling
>> could have avoided the problem
>
> An error handler would have rescued the mission.

Only if were not behaving according to the specification. That means if
it were buggy - and that's exactly what you snipped from my previous
response.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Hyman Rosen]

How about this for the essential flaw: Does it really make
sense to create data types in your program that are so closely
tied to external factors like rocket speed limits and angles?
Why not use data types that could handle the full range of
values from the sensor? The approach used seems incredibly
brittle, and in fact turned out to be so.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

Hyman Rosen wrote:

> How about this for the essential flaw: Does it really make
> sense to create data types in your program that are so closely
> tied to external factors like rocket speed limits and angles?
> Why not use data types that could handle the full range of
> values from the sensor?

Sure. So what is car supposed to do if the speed sensors read
about 200_000 miles per second? Flash a little light to warn you
about probably exceeding the current speed limit or presume a
hardware error?

Read: _Safe_ ranges are usually not operational limits.

But then, if even the safe range is exceeded, what shall we do?
Hope, the value wraps around and starts at zero again?


Vin"-327.68 :)"zent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[KK6GM]

On Mar 16, 11:29 am, Hyman Rosen <hyro...@mail.com> wrote:
> How about this for the essential flaw: Does it really make
> sense to create data types in your program that are so closely
> tied to external factors like rocket speed limits and angles?
> Why not use data types that could handle the full range of
> values from the sensor? The approach used seems incredibly
> brittle, and in fact turned out to be so.

Here's the alternative, for the Ariane situation.  A float value gets
converted to a 16-bit integer.  The float value is too big to fit
(let's say it's 33000).  What 16-bit int will that get converted to?
-31000?  Some random value?  How does continuing along with bogus data
make the situation better?  Will the control loops really work OK with
bogus feedback data?

If you have determined via thorough analysis that the variable in
question can only _ever_ have a valid range of e.g. -20000 to 20000,
and it goes to 33000, what _is_ the right action?

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Hyman Rosen]

On 3/16/2011 3:40 PM, KK6GM wrote:
> Here's the alternative, for the Ariane situation.  A float value gets
> converted to a 16-bit integer.  The float value is too big to fit
> (let's say it's 33000).  What 16-bit int will that get converted to?
> -31000?  Some random value?  How does continuing along with bogus data
> make the situation better?  Will the control loops really work OK with
> bogus feedback data?

Why are we converting floats to 16-bit integers? It's hard to tell
from the report, but was this a result of using an Ada fixed type?
Or the result of similar scaling based on knowing the range?

> If you have determined via thorough analysis that the variable in
> question can only _ever_ have a valid range of e.g. -20000 to 20000,
> and it goes to 33000, what _is_ the right action?

<http://web.archive.org/web/20000815230639/www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>
Recommendation R3 says "Do not allow any sensor, such as the inertial
reference system, to stop sending best effort data." So if your sensor
can report data over a certain range, you should probably not use a
restrictive subtype that represents what you believe the possible
observed range will be. Otherwise, when Scotty is trying to nudge a
fraction more warp factor out of the engines, the Enterprise is going
to shut down and doom the Federation.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[KK6GM]

On Mar 16, 1:52 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/16/2011 3:40 PM, KK6GM wrote:
>
> > Here's the alternative, for the Ariane situation.  A float value gets
> > converted to a 16-bit integer.  The float value is too big to fit
> > (let's say it's 33000).  What 16-bit int will that get converted to?
> > -31000?  Some random value?  How does continuing along with bogus data
> > make the situation better?  Will the control loops really work OK with
> > bogus feedback data?
>
> Why are we converting floats to 16-bit integers? It's hard to tell
> from the report, but was this a result of using an Ada fixed type?
> Or the result of similar scaling based on knowing the range?

I have no idea why they were doing that.
>
> > If you have determined via thorough analysis that the variable in
> > question can only _ever_ have a valid range of e.g. -20000 to 20000,
> > and it goes to 33000, what _is_ the right action?
>
> <http://web.archive.org/web/20000815230639/www.esrin.esa.it/htdocs/tid...>
> Recommendation R3 says "Do not allow any sensor, such as the inertial
> reference system, to stop sending best effort data." So if your sensor
> can report data over a certain range, you should probably not use a
> restrictive subtype that represents what you believe the possible
> observed range will be. Otherwise, when Scotty is trying to nudge a
> fraction more warp factor out of the engines, the Enterprise is going
> to shut down and doom the Federation.

You're still not seeing the issue.  You may have a 0-200psi
transducer, but if you have _proven_ that the actual pressure can
never be over 70psi, what are you supposed to _do_ with a reading of
150psi?  Is it a true reading?  If so, your control algorithm will
almost certainly choke on it.  Is it a hardware error?  Then do what
you would do in the event of a hardware error.  Which is what Ariane
did.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Shark8]

On Mar 16, 2:52 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/16/2011 3:40 PM, KK6GM wrote:
>
> > Here's the alternative, for the Ariane situation.  A float value gets
> > converted to a 16-bit integer.  The float value is too big to fit
> > (let's say it's 33000).  What 16-bit int will that get converted to?
> > -31000?  Some random value?  How does continuing along with bogus data
> > make the situation better?  Will the control loops really work OK with
> > bogus feedback data?
>
> Why are we converting floats to 16-bit integers? It's hard to tell
> from the report, but was this a result of using an Ada fixed type?
> Or the result of similar scaling based on knowing the range?
>
> > If you have determined via thorough analysis that the variable in
> > question can only _ever_ have a valid range of e.g. -20000 to 20000,
> > and it goes to 33000, what _is_ the right action?
>
> <http://web.archive.org/web/20000815230639/www.esrin.esa.it/htdocs/tid...>
> Recommendation R3 says "Do not allow any sensor, such as the inertial
> reference system, to stop sending best effort data." So if your sensor
> can report data over a certain range, you should probably not use a
> restrictive subtype that represents what you believe the possible
> observed range will be. Otherwise, when Scotty is trying to nudge a
> fraction more warp factor out of the engines, the Enterprise is going
> to shut down and doom the Federation.

Not quite.
In the "nudge a fraction more warp factor out of the engines" there is
indeed a valid range limitation: since we are talking about speeds*
there can NEVER be a negative value as "speed*" is an absolute-value."

*Velocity, to be more technically correct.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Hyman Rosen]

On 3/16/2011 5:09 PM, Shark8 wrote:
> Not quite.
> In the "nudge a fraction more warp factor out of the engines" there is
> indeed a valid range limitation: since we are talking about speeds*
> there can NEVER be a negative value as "speed*" is an absolute-value."
>
> *Velocity, to be more technically correct.

When they are sucked into a quantum singularity, their motion
is so odd with respect to the rest of the universe that the
equations make sense only if their speed is considered negative.
Fortunately, the Enterprise software is written in Forth :-)

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Shark8]

On Mar 16, 3:13 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/16/2011 5:09 PM, Shark8 wrote:
>
> > Not quite.
> > In the "nudge a fraction more warp factor out of the engines" there is
> > indeed a valid range limitation: since we are talking about speeds*
> > there can NEVER be a negative value as "speed*" is an absolute-value."
>
> > *Velocity, to be more technically correct.
>
> When they are sucked into a quantum singularity, their motion
> is so odd with respect to the rest of the universe that the
> equations make sense only if their speed is considered negative.
> Fortunately, the Enterprise software is written in Forth :-)

From Wikipedia:
In physics, velocity is the measurement of the rate and direction of
change in the position of an object. It is a vector physical quantity;
both magnitude and direction are required to define it. The scalar
absolute value (magnitude) of velocity is speed [...]

If you are going to 'redefine' something than ALL items which
are based upon that definition are subject to change. BTW, there
is no way with which a vector's magnitude can be negative, any
such "negation" would merely flip the point-and-tail of the
vector.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

Hyman Rosen wrote:

> Why are we converting floats to 16-bit integers?

Because the CPU can handle integer much faster than the co-processor
can handle double precision floating point data.

> <http://web.archive.org/web/20000815230639/www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>
> Recommendation R3 says "Do not allow any sensor, such as the inertial
> reference system, to stop sending best effort data." So if your sensor
> can report data over a certain range, you should probably not use a
> restrictive subtype that represents what you believe the possible
> observed range will be.

The question remains: What to do when you encounter an obviously fucked up value?


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Shark8]

On Mar 16, 1:40 pm, KK6GM <mjsi...@scriptoriumdesigns.com> wrote:

> If you have determined via thorough analysis that the variable in
> question can only _ever_ have a valid range of e.g. -20000 to 20000,
> and it goes to 33000, what _is_ the right action?

IMO, raise PROGRAM_ERROR and cease execution. (or similar)

"Ignore it and continue operation" is, in a word, WRONG.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Hyman Rosen]

On 3/16/2011 5:04 PM, Shark8 wrote:
> "Ignore it and continue operation" is, in a word, WRONG.

I hope this is implemented on the flight software of the
next airplane you fly on. On the contrary, ignore it and
continue operation may be exactly the right thing to do,
because the fault may be absorbed elsewhere and the system
will continue to carry out its intended purpose.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[KK6GM]

On Mar 16, 2:10 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/16/2011 5:04 PM, Shark8 wrote:
>
> > "Ignore it and continue operation" is, in a word, WRONG.
>
> I hope this is implemented on the flight software of the
> next airplane you fly on. On the contrary, ignore it and
> continue operation may be exactly the right thing to do,
> because the fault may be absorbed elsewhere and the system
> will continue to carry out its intended purpose.

You are suggesting that _maybe_ the fault will be "absorbed elsewhere"
is a better solution than turning off what is likely (based on your
comprehensive analysis, remember) to be faulty hardware and letting
the backup hardware take over.

In realtime control systems there is usually no such thing as "ignore
it".  To take my 150psi reading example, what if that "too high"
reading causes the coolant valve on your reactor (topical - maybe too
topical?) to go fully closed in attempting to compensate?  By ignoring
it you've lost your cooling.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Shark8]

On Mar 16, 3:10 pm, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/16/2011 5:04 PM, Shark8 wrote:
>
> > "Ignore it and continue operation" is, in a word, WRONG.
>
> I hope this is implemented on the flight software of the
> next airplane you fly on. On the contrary, ignore it and
> continue operation may be exactly the right thing to do,
> because the fault may be absorbed elsewhere and the system
> will continue to carry out its intended purpose.

Allowing some system to take care of it is, by definition,
not 'ignoring' it.

IOW, even in that case you are not absolving the
responsibility to handle the "funny" datum but merely moving
that responsibility to another place.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

Hyman Rosen wrote:

> On 3/16/2011 5:04 PM, Shark8 wrote:
>> "Ignore it and continue operation" is, in a word, WRONG.
>
> I hope this is implemented on the flight software of the
> next airplane you fly on.

It is.

> On the contrary, ignore it and
> continue operation may be exactly the right thing to do,
> because the fault may be absorbed elsewhere and the system
> will continue to carry out its intended purpose.

It _MAY_. Precisely. It also _MAY_ crash the plane, although
it was just a minor glitch, yet allowing the invalid value to
leave the sub-system resulted in the auto-pilot going haywire
and not even letting go back into manual mode, so the crew and
all passengers went down puking when the Jumbo tried to do some
rolls and loopings.

In hindsight you can always tell what should have been done to
avoid the mistake. That's called experience, BTW.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

KK6GM wrote in message ...
>On Mar 16, 11:29 am, Hyman Rosen <hyro...@mail.com> wrote:
>> How about this for the essential flaw: Does it really make
>> sense to create data types in your program that are so closely
>> tied to external factors like rocket speed limits and angles?
>> Why not use data types that could handle the full range of
>> values from the sensor? The approach used seems incredibly
>> brittle, and in fact turned out to be so.

>Here's the alternative, for the Ariane situation.  A float value gets
>converted to a 16-bit integer.  The float value is too big to fit
>(let's say it's 33000).  What 16-bit int will that get converted to?
>-31000?

Would you believe 32767 (with appropriate sign).
That keeps the processor running, and it's slightly less than the
actual value.

>  Some random value?  How does continuing along with bogus data
>make the situation better?

It keeps the processor running, and the mission going.

>  Will the control loops really work OK with
>bogus feedback data?

>If you have determined via thorough analysis that the variable in
>question can only _ever_ have a valid range of e.g. -20000 to 20000,
>and it goes to 33000, what _is_ the right action?

Set it to 32767 with sign.
Alterrnativelty, use floating-point.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[robin]

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

Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>robin wrote:

>> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>>> Elias Salomão Helou Neto wrote:
>
>>>> Since then I have been wondering. If compiler checking where actually
>>>> turned on, what would have happened?
>
>>> The same, according to the specification.
>
>>>> How could it avoid the disaster?
>
>>> Not at all.
>
>> On the contrary., an error handler would have performed
>> something useful.

>Precisely what? The _only_ reasonable action at that point was to assume
>a hardware error and shutdown the computer. For Ariane 4, that is.

Whether Ariane 4 or 5, it was not reasonable to assume that the
error was hardware.
See my post elsewhere.

>> The crux of the matter is that the data bus would not have been
>> loaded with an error number [which was then treated as guidance data].

>AFAIK this was required in case both systems died. And as we know, they
>did exactly that.

But only if the error was hardware, which it wasn't.

> I'd assume the possibility of two hardware errors at
>the same time were considered remote.

>>> By handling it exactly the way it was supposed to be:
>
>>> Assuming a hardware error and leave control to the redundant subsystem.
>
>> That was the major blunder that they made,
>> namely, treating a programming error as a hardware error.
>> By doing that, they guaranteed failure of the mission.

>Again. In the Ariane 4 it would have been exactly that. A hardware error.

Again, you are making a false assumption.

>There was no freaking way, Ariane 4 could have exceeded the safe range.

recall Murphy, "If anything can go wrong, it will".

>>> Which one, if any, is close to reality?
>
>>> As it has been mentioned here many times before, the software behaved
>>> exactly as specified and it is very unlikely that _any_ error handling
>>> could have avoided the problem
>
>> An error handler would have rescued the mission.

>Only if were not behaving according to the specification. That means if
>it were buggy -

It was buggy.  It didn't handle the overflow.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Simon Wright]

"robin" <robin51@dodo.com.au> writes:

> But only if the error was hardware, which it wasn't.

No, and it wasn't bloody software either!!! it was SYSTEM DESIGN!!! and
no amount of faffing about at the edges of software will ever fix that.

I'm out of this conversation.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Georg Bauhaus]

On 17.03.11 01:26, Simon Wright wrote:
> "robin" <robin51@dodo.com.au> writes:
> 
>> But only if the error was hardware, which it wasn't.
> 
> No, and it wasn't bloody software either!!! it was SYSTEM DESIGN!!! and
> no amount of faffing about at the edges of software will ever fix that.
> 
> I'm out of this conversation.

Logic is open to more twisting by generalizing robin's rules:
by assuming that a defective system that includes hardware
can support a software error handler.  Come on, let's have
some more FUD from the many system engineers in the know,
in particular the one's not building Ariane systems.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[robin]

Simon Wright wrote in message ...
>"robin" <robin51@dodo.com.au> writes:
>
>> But only if the error was hardware, which it wasn't.
>
>No, and it wasn't bloody software either!!!

I'm afraid that it was (software).
Consider this:  If just ONE unprotected overflow occurs,
the mission is lost.
Not a SINGLE unprotected conversion should have been included.

> it was SYSTEM DESIGN!!! and
>no amount of faffing about at the edges of software will ever fix that.

The fact remains that in that real-time system,
unprotected conversions were included.

No-one experienced in real-time programming
would have permitted those unprotected conversions.

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Niklas Holsti]

robin wrote:
> Simon Wright wrote in message ...
>> "robin" <robin51@dodo.com.au> writes:
>>
>>> But only if the error was hardware, which it wasn't.
>> No, and it wasn't bloody software either!!!
> 
> I'm afraid that it was (software).
> Consider this:  If just ONE unprotected overflow occurs,
> the mission is lost.

No. If the unprotected overflow occurs because of a hardware fault or 
noise in one computer only, the mission continues with the other computer.

> Not a SINGLE unprotected conversion should have been included.

You are being rather dogmatic about this, Robin...

>> it was SYSTEM DESIGN!!! and
>> no amount of faffing about at the edges of software will ever fix that.
> 
> The fact remains that in that real-time system,
> unprotected conversions were included.

After analysis of their possible causes and effects. In the Ariane 4.

> No-one experienced in real-time programming
> would have permitted those unprotected conversions.

Do you claim to know that the Ariane 4 software developers were 
inexperienced?

The designers analysed the situation, decided what the software should 
do in case of overflow at this point, and built the software 
accordingly. When the overflow happened in the Ariane 501 launch the 
software did exactly what the designers had decided it should do in this 
case.

The argument about what the software should have done instead can be 
endless, and perhaps useful for developing other programs, but does not 
make the Ariane 4 software incorrect.

The ESA report makes several recommendations to increase robustness, for 
example to activate only those software functions that are needed in 
each phase of a mission. The Ariane 5 designers instead followed the 
KISS principle "if it isn't broken, don't fix it". Unfortunately 
"broken" is relative and depends on the environment. The software wasn't 
broken for the Ariane 4, but was broken for the Ariane 5.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

Niklas Holsti wrote in message <8ueh3mF3rgU1@mid.individual.net>...
>robin wrote:
>> Simon Wright wrote in message ...
>>> "robin" <robin51@dodo.com.au> writes:
>>>
>>>> But only if the error was hardware, which it wasn't.
>>> No, and it wasn't bloody software either!!!
>>
>> I'm afraid that it was (software).
>> Consider this:  If just ONE unprotected overflow occurs,
>> the mission is lost.
>
>No. If the unprotected overflow occurs because of a hardware fault or
>noise in one computer only, the mission continues with the other computer.

If there is a problem with one computer,
the mission continues with the other computer, as you say.
However, if an unprotected overflow occurs at any of those 3 unprotected
conversions from float to integer, the mission is doomed.

>> Not a SINGLE unprotected conversion should have been included.
>
>You are being rather dogmatic about this, Robin...

Justifiably so, because it's a real time system.
One programming mistake is all it takes.

>>> it was SYSTEM DESIGN!!! and
>>> no amount of faffing about at the edges of software will ever fix that.
>>
>> The fact remains that in that real-time system,
>> unprotected conversions were included.
>
>After analysis of their possible causes and effects. In the Ariane 4.
>
>> No-one experienced in real-time programming
>> would have permitted those unprotected conversions.
>
>Do you claim to know that the Ariane 4 software developers were
>inexperienced?

Inexperienced in programming real time systems.

>The designers analysed the situation, decided what the software should
>do in case of overflow at this point, and built the software
>accordingly. When the overflow happened in the Ariane 501 launch the
>software did exactly what the designers had decided it should do in this
>case.

Not really;  They overlooked what would happen if overflow occurred.

>The argument about what the software should have done instead can be
>endless, and perhaps useful for developing other programs, but does not
>make the Ariane 4 software incorrect.

A bug is something that goes wrong when you don't expect or plan for it.

>The ESA report makes several recommendations to increase robustness, for
>example to activate only those software functions that are needed in
>each phase of a mission. The Ariane 5 designers instead followed the
>KISS principle "if it isn't broken, don't fix it".

The software contained a bug.  Just because it didn't fail in Ariane 4
doesn't mean there's not a bug.

> Unfortunately
>"broken" is relative and depends on the environment. The software wasn't
>broken for the Ariane 4, but was broken for the Ariane 5.

I claim that it was broken for both.

For real-time software, it was buggy for the Ariane 4.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Niklas Holsti]

robin wrote:
> Niklas Holsti wrote in message <8ueh3mF3rgU1@mid.individual.net>...
>> robin wrote:
>>> Simon Wright wrote in message ...
>>>> "robin" <robin51@dodo.com.au> writes:
>>>>
>>>>> But only if the error was hardware, which it wasn't.
>>>> No, and it wasn't bloody software either!!!
>>> I'm afraid that it was (software).
>>> Consider this:  If just ONE unprotected overflow occurs,
>>> the mission is lost.
>> No. If the unprotected overflow occurs because of a hardware fault or
>> noise in one computer only, the mission continues with the other computer.
> 
> If there is a problem with one computer,
> the mission continues with the other computer, as you say.

Ok.

> However, if an unprotected overflow occurs at any of those 3 unprotected
> conversions from float to integer, the mission is doomed.

Only if the overflow happens in both computers, which was my point, and 
which you, Robin, seemed to ignore. As I understand it, in the Ariane 4 
that would have been most unlikely, but it was a certainty in the Ariane 
501.

Robin, it seems to me that you are not trying to understand the 
arguments that other posters make against your position.

The rest of your reply to me just repeats your earlier claims, so I 
won't comment on it.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: How would Ariane 5 have behaved if overflow checking werenotturned off?

[Vinzent Hoefler]

robin wrote:

> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>> robin wrote:
>
>> Precisely what? The _only_ reasonable action at that point was to assume
>> a hardware error and shutdown the computer. For Ariane 4, that is.
>
> Whether Ariane 4 or 5, it was not reasonable to assume that the
> error was hardware.

For Ariane 4 it _was_ reasonable.

>> AFAIK this was required in case both systems died. And as we know, they
>> did exactly that.
>
> But only if the error was hardware, which it wasn't.

It was. The wrong hardware was connected to the system.

>> Again. In the Ariane 4 it would have been exactly that. A hardware error.
>
> Again, you are making a false assumption.

It's not an assumption.

>> There was no freaking way, Ariane 4 could have exceeded the safe range.
>
> recall Murphy, "If anything can go wrong, it will".

Yes, of course. That applies to all countermeasures, too. Murphy's Law
implies there will be more ways to screw you than there will be to prevent
just that.

I've heard of critical systems which read and write variables through a
driver layer doing the load and stores redundantly and checking for
possible memory corruption on the way. Still, even those can fail.

Well, at least they do it very slowly, because the performance drops
significantly. ;)

>>>> As it has been mentioned here many times before, the software behaved
>>>> exactly as specified and it is very unlikely that _any_ error handling
>>>> could have avoided the problem
>>
>>> An error handler would have rescued the mission.
>
>> Only if were not behaving according to the specification. That means if
>> it were buggy -
>
> It was buggy.  It didn't handle the overflow.

No. It handled it according to the specification.

Specwise the overflow could only be interpreted as a hardware fault
at that point. A reboot (what a lot of systems would try) would take
too long for the system, so the requirement was to cease operation.
And it did exactly that. _Any_ error handler would have been required
to do that - and the one in place (which was just the default handler)
did it quite as well as any other.

You're trying to blame the software for following its specification?


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>robin wrote:
>
>> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>>> robin wrote:
>>
>>> Precisely what? The _only_ reasonable action at that point was to assume
>>> a hardware error and shutdown the computer. For Ariane 4, that is.
>>
>> Whether Ariane 4 or 5, it was not reasonable to assume that the
>> error was hardware.
>
>For Ariane 4 it _was_ reasonable.
>
>>> AFAIK this was required in case both systems died. And as we know, they
>>> did exactly that.
>>
>> But only if the error was hardware, which it wasn't.
>
>It was. The wrong hardware was connected to the system.
>
>>> Again. In the Ariane 4 it would have been exactly that. A hardware error.
>>
>> Again, you are making a false assumption.
>
>It's not an assumption.
>
>>> There was no freaking way, Ariane 4 could have exceeded the safe range.
>>
>> recall Murphy, "If anything can go wrong, it will".
>
>Yes, of course. That applies to all countermeasures, too. Murphy's Law
>implies there will be more ways to screw you than there will be to prevent
>just that.
>
>I've heard of critical systems which read and write variables through a
>driver layer doing the load and stores redundantly and checking for
>possible memory corruption on the way. Still, even those can fail.
>
>Well, at least they do it very slowly, because the performance drops
>significantly. ;)
>
>>>>> As it has been mentioned here many times before, the software behaved
>>>>> exactly as specified and it is very unlikely that _any_ error handling
>>>>> could have avoided the problem
>>>
>>>> An error handler would have rescued the mission.
>>
>>> Only if were not behaving according to the specification. That means if
>>> it were buggy -
>>
>> It was buggy.  It didn't handle the overflow.
>
>No. It handled it according to the specification.


So the specification was to guarantee failure?

They chose not to protect three data conversions, thinking that it [overflow]
couldn't happen.  They set protection up for four other similar conversions,
but not for the one in question (nor for two others).
Because those three data conversions [from floating-point to 16-bit signed integer]
were not protected, they could raise an overflow exception.
One of them did, and thus guaranteed failure of the mission.

>Specwise the overflow could only be interpreted as a hardware fault
>at that point. A reboot (what a lot of systems would try) would take
>too long for the system, so the requirement was to cease operation.
>And it did exactly that. _Any_ error handler would have been required
>to do that -


The job of the programmer was to prevent such an error occurring.
The four other similar conversions HAD protection,
so it wasn't as you say, namely, that "overflow could only be
interpreted as a hardware fault".

> and the one in place (which was just the default handler)
>did it quite as well as any other.
>
>You're trying to blame the software for following its specification?

It wasn't following the specification.  It was important that
such a conversion error be protected, and not to shut down the system.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

robin wrote:

> So the specification was to guarantee failure?

If you want to put it that way, yes. If Ariane 4 would have encountered
such a value in _both_ SRIs, the safest assumption at this point would
have been a complete failure. Mission aborted, all doomed.

> They chose not to protect three data conversions, thinking that it [overflow]
> couldn't happen.

NO. They did not protect it, because they knew if the overflow happened,
it must have been a hardware problem.

> Because those three data conversions [from floating-point to 16-bit signed integer]
> were not protected, they could raise an overflow exception.
> One of them did, and thus guaranteed failure of the mission.

Yes. What's your point?

>> Specwise the overflow could only be interpreted as a hardware fault
>> at that point. A reboot (what a lot of systems would try) would take
>> too long for the system, so the requirement was to cease operation.
>> And it did exactly that. _Any_ error handler would have been required
>> to do that -
>
> The job of the programmer was to prevent such an error occurring.
> The four other similar conversions HAD protection,

Because they were more likely to happen under certain circumstances.

> so it wasn't as you say, namely, that "overflow could only be
> interpreted as a hardware fault".

It was precisely that. If the digital speedometer in your car suddenly
jumps from say 100 mph to 32767 mph, what would you assume? A hardware
fault (in the sensor preferrably) or a real reading?

>> and the one in place (which was just the default handler)
>> did it quite as well as any other.
>>
>> You're trying to blame the software for following its specification?
>
> It wasn't following the specification.  It was important that
> such a conversion error be protected, and not to shut down the system.

On the contrary. It was not specified to continue flight beyond operation
limits.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Stephen Leake]

Elias Salomão Helou Neto <eshneto@gmail.com> writes:

> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
> operators, which eventually lead to people mentioning the Ariane 5
> case.
>
> Since then I have been wondering. If compiler checking where actually
> turned on, what would have happened? How could it avoid the disaster?

Just to remind people; the real problem was that Ariane 4 code was
reused on Ariane 5, without carefully considering the design, also
without adequate testing.

Ariane 5 is a bigger rocket; it has bigger accelerations. The range for
accelerations in the code, which was correct for Ariane 4, was incorrect
for Ariane 5.

No amount of "defensive programming" can handle such a fundamental
design error.

-- 
-- Stephe

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Keith Thompson]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Elias Salomão Helou Neto <eshneto@gmail.com> writes:
>> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
>> operators, which eventually lead to people mentioning the Ariane 5
>> case.
>>
>> Since then I have been wondering. If compiler checking where actually
>> turned on, what would have happened? How could it avoid the disaster?
>
> Just to remind people; the real problem was that Ariane 4 code was
> reused on Ariane 5, without carefully considering the design, also
> without adequate testing.
>
> Ariane 5 is a bigger rocket; it has bigger accelerations. The range for
> accelerations in the code, which was correct for Ariane 4, was incorrect
> for Ariane 5.
>
> No amount of "defensive programming" can handle such a fundamental
> design error.

As I recall, the problem was that an exception message was sent
and interpreted as binary data, because it was incorrectly assumed
that the exception could never happen.  The exception occurred in
a subsystem that wasn't even needed at the time.  (It's entirely
possible I've got this wrong.)

What if the subsystem had handled the exception and quietly
terminated?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[KK6GM]

On Mar 15, 10:32 am, Keith Thompson <ks...@mib.org> wrote:
> Stephen Leake <stephen_le...@stephe-leake.org> writes:
> > Elias Salomão Helou Neto <eshn...@gmail.com> writes:
> >> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
> >> operators, which eventually lead to people mentioning the Ariane 5
> >> case.
>
> >> Since then I have been wondering. If compiler checking where actually
> >> turned on, what would have happened? How could it avoid the disaster?
>
> > Just to remind people; the real problem was that Ariane 4 code was
> > reused on Ariane 5, without carefully considering the design, also
> > without adequate testing.
>
> > Ariane 5 is a bigger rocket; it has bigger accelerations. The range for
> > accelerations in the code, which was correct for Ariane 4, was incorrect
> > for Ariane 5.
>
> > No amount of "defensive programming" can handle such a fundamental
> > design error.
>
> As I recall, the problem was that an exception message was sent
> and interpreted as binary data, because it was incorrectly assumed
> that the exception could never happen.  The exception occurred in
> a subsystem that wasn't even needed at the time.  (It's entirely
> possible I've got this wrong.)
>
> What if the subsystem had handled the exception and quietly
> terminated?

That was only after both primary and secondary guidance computers had
shut down, according to spec, upon having received "impossible" data.
Once both computers stopped running the rocket was doomed.  The
diagnostic data being interpreted as nozzle deflection data (IIRC)
just made that doom more spectacular than it might otherwise have been.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Robert A Duff]

(Sorry for emailing this, Keith.  I meant to post.  Oops.)

Keith Thompson <kst-u@mib.org> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>> Just to remind people; the real problem was that Ariane 4 code was
>> reused on Ariane 5, without carefully considering the design, also
>> without adequate testing.
>>
>> Ariane 5 is a bigger rocket; it has bigger accelerations. The range for
>> accelerations in the code, which was correct for Ariane 4, was incorrect
>> for Ariane 5.
>>
>> No amount of "defensive programming" can handle such a fundamental
>> design error.
>
> As I recall, the problem was that an exception message was sent
> and interpreted as binary data, because it was incorrectly assumed
> that the exception could never happen.  The exception occurred in
> a subsystem that wasn't even needed at the time.

I wouldn't call that "the problem" -- I'd call it a symptom of
the problem.  The problem was using (correct!) Ariane 4 software
to control an Ariane 5 rocket, as Stephen Leake says above.

The assumption you mention above was correct!  For Ariane 4,
of course -- that's what they analyzed the assumption for.

>...  (It's entirely
> possible I've got this wrong.)

I don't think so -- your memory (of the symptom!) matches mine.

> What if the subsystem had handled the exception and quietly
> terminated?

I've no idea.  Maybe it would have worked, but that would have
been purely accidental.  All the details of how the exception
or whatever led to the crash seem irrelevant, to me.  You can't
expect software designed for one rocket to work for another
rocket without changing it to meet the new specs.  Apparently,
they didn't even bother to look at it to see if it needed changing.

- Bob

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Florian Weimer]

* Stephen Leake:

> Elias Salom�o Helou Neto <eshneto@gmail.com> writes:
>
>> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
>> operators, which eventually lead to people mentioning the Ariane 5
>> case.
>>
>> Since then I have been wondering. If compiler checking where actually
>> turned on, what would have happened? How could it avoid the disaster?
>
> Just to remind people; the real problem was that Ariane 4 code was
> reused on Ariane 5, without carefully considering the design, also
> without adequate testing.

It's odd that after all those years, little hard data is available on
the defect.  The published report uses terminology which is a slightly
bit off in the Ada context, so it led only to further speculation.
There is alleged source code floating around, but it is an obvious
fabrication by someone who is not an Ada programmer (there are syntax
errors).

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[KK6GM]

On Mar 15, 12:12 pm, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Stephen Leake:
>
> > Elias Salom o Helou Neto <eshn...@gmail.com> writes:
>
> >> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
> >> operators, which eventually lead to people mentioning the Ariane 5
> >> case.
>
> >> Since then I have been wondering. If compiler checking where actually
> >> turned on, what would have happened? How could it avoid the disaster?
>
> > Just to remind people; the real problem was that Ariane 4 code was
> > reused on Ariane 5, without carefully considering the design, also
> > without adequate testing.
>
> It's odd that after all those years, little hard data is available on
> the defect.  The published report uses terminology which is a slightly
> bit off in the Ada context, so it led only to further speculation.
> There is alleged source code floating around, but it is an obvious
> fabrication by someone who is not an Ada programmer (there are syntax
> errors).

The Ariane computers were based on the MC68020 with MC68882 FPU.
"Operand Error", as mentioned in the report, is apparently an FPU
error, generated when, among other reasons, a floating point to
integer conversion is attempted and the value will not fit into the
integer.  That's exactly what happened in the Ariane 501.

Since the error was apparently a hardware (FPU) trap, that makes it
even harder to claim that it was somehow Ada's fault, since presumably
all error traps generated by the hardware would have been handled the
same regardless of the language.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

Florian Weimer wrote:

> It's odd that after all those years, little hard data is available on
> the defect.  The published report uses terminology which is a slightly
> bit off in the Ada context, so it led only to further speculation.

Hmm? From the report:

|The internal SRI software exception was caused during execution of a
|data conversion from 64-bit floating point to 16-bit signed integer
|value. The floating point number which was converted had a value greater
|than what could be represented by a 16-bit signed integer. This resulted
|in an Operand Error. The data conversion instructions (in Ada code) were
|not protected from causing an Operand Error, although other conversions
|of comparable variables in the same place in the code were protected.

"Operand Error" is what Motorola (now Freescale) just calls it in their
CPU manual.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Florian Weimer]

* Vinzent Hoefler:

> Florian Weimer wrote:
>
>> It's odd that after all those years, little hard data is available on
>> the defect.  The published report uses terminology which is a slightly
>> bit off in the Ada context, so it led only to further speculation.
>
> Hmm? From the report:
>
> |The internal SRI software exception was caused during execution of a
> |data conversion from 64-bit floating point to 16-bit signed integer
> |value. The floating point number which was converted had a value greater
> |than what could be represented by a 16-bit signed integer. This resulted
> |in an Operand Error. The data conversion instructions (in Ada code) were
> |not protected from causing an Operand Error, although other conversions
> |of comparable variables in the same place in the code were protected.
>
> "Operand Error" is what Motorola (now Freescale) just calls it in their
> CPU manual.

"Operand Error" is not the only odd thing.  "Protected" operations
which are subject to exception handling are used in Lisp (and, based
on that, Lua).  And I think we wouldn't call an expression an
"instruction", either.  Without the explicit reference to Ada, I
wouldn't think that this paragraph describes something related to an
Ada program.  That's why I think it uses odd language.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

Florian Weimer wrote:

> * Vinzent Hoefler:
>
>> Florian Weimer wrote:
>>
>>> It's odd that after all those years, little hard data is available on
>>> the defect.  The published report uses terminology which is a slightly
>>> bit off in the Ada context, so it led only to further speculation.
>>
[...]
>
> "Operand Error" is not the only odd thing.  "Protected" operations
> which are subject to exception handling are used in Lisp (and, based
> on that, Lua).  And I think we wouldn't call an expression an
> "instruction", either.  Without the explicit reference to Ada, I
> wouldn't think that this paragraph describes something related to an
> Ada program.  That's why I think it uses odd language.

Ok, yes, my impression is that they simply talk about the the code at
processor level.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
     --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[John B. Matthews]

In article <82d3lsvqw7.fsf@stephe-leake.org>,
 Stephen Leake <stephen_leake@stephe-leake.org> wrote:

> Elias Salomão Helou Neto <eshneto@gmail.com> writes:
> 
> > I have followed the (quite lenghty) on a topic, IIRC, about bitwise
> > operators, which eventually lead to people mentioning the Ariane 5
> > case.
> >
> > Since then I have been wondering. If compiler checking where actually
> > turned on, what would have happened? How could it avoid the disaster?
> 
> Just to remind people; the real problem was that Ariane 4 code was 
> reused on Ariane 5, without carefully considering the design, also 
> without adequate testing.
> 
> Ariane 5 is a bigger rocket; it has bigger accelerations. The range 
> for accelerations in the code, which was correct for Ariane 4, was 
> incorrect for Ariane 5.
> 
> No amount of "defensive programming" can handle such a fundamental 
> design error.

This comports with my understanding, based on this report:

ARIANE 5
Flight 501 Failure
Report by the Inquiry Board

<http://web.archive.org/web/20000815230639/www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

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

Stephen Leake wrote in message <82d3lsvqw7.fsf@stephe-leake.org>...
>Elias Salomão Helou Neto <eshneto@gmail.com> writes:
>
>> I have followed the (quite lenghty) on a topic, IIRC, about bitwise
>> operators, which eventually lead to people mentioning the Ariane 5
>> case.
>>
>> Since then I have been wondering. If compiler checking where actually
>> turned on, what would have happened? How could it avoid the disaster?
>
>Just to remind people; the real problem was that Ariane 4 code was
>reused on Ariane 5, without carefully considering the design, also
>without adequate testing.
>
>Ariane 5 is a bigger rocket; it has bigger accelerations.

It does?  The Report doesn't say anything about that.
What it *does* say is that the horizontal velocity was greater
in Ariane 5 than Ariane 4.
That doesn't mean that the acceleration upwards was greater.

> The range for
>accelerations in the code, which was correct for Ariane 4, was incorrect
>for Ariane 5.
>
>No amount of "defensive programming" can handle such a fundamental
>design error.

The remedy could have been as simple as substituting the
largest magnitude integer (with appropriate sign).

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

robin wrote:

> The remedy could have been as simple as substituting the
> largest magnitude integer (with appropriate sign).

And if _that_ would have caused the rocket to crash, you would
blame the software again and just suggest another fix, I suppose.

So, what are you going to do? Reel back your time machine and try
again until you found a suitable solution for all kind of problems?

Mankind will certainly thank you.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[robin]

Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>robin wrote:
>
>> The remedy could have been as simple as substituting the
>> largest magnitude integer (with appropriate sign).
>
>And if _that_ would have caused the rocket to crash, you would
>blame the software again and just suggest another fix, I suppose.

I suggest that you read the Full Report: "... the computers within the SRIs could
have continued to provide their best estimates of the required attitide information."

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Vinzent Hoefler]

robin wrote:

> Vinzent Hoefler <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> wrote in message ...
>> robin wrote:
>>
>>> The remedy could have been as simple as substituting the
>>> largest magnitude integer (with appropriate sign).
>>
>> And if _that_ would have caused the rocket to crash, you would
>> blame the software again and just suggest another fix, I suppose.
>
> I suggest that you read the Full Report:

Yeah, right. As if I hadn't done that more than once before.

> "... the computers within the SRIs could
> have continued to provide their best estimates of the required attitide information."

Did they test that their assumption would have been correct?

Advice is just like experience. You get a lot of, right after you needed it.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
    --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

robin wrote:

> Stephen Leake wrote in message <82d3lsvqw7.fsf@stephe-leake.org>...
>>
>> Ariane 5 is a bigger rocket; it has bigger accelerations.
>
> It does?  The Report doesn't say anything about that.
> What it *does* say is that the horizontal velocity was greater
> in Ariane 5 than Ariane 4.
> That doesn't mean that the acceleration upwards was greater.

It *does* say it on page 12:

|p) Ariane 5 has a high initial acceleration [...] which leads to a
|   build-up of horizontal velocity which is five times more rapid
|   than for Ariane 4. The higher horizontal velocity [...] generated,
|   within the 40-second timeframe, the excessive value which caused
|   the inertial system computers to cease operation.

"build-up of horizontal velocity [...] five times more rapid"
"higher horizontal velocity [...] within the 40-second timeframe"

I read that as "the acceleration is bigger". But maybe I remember
my physics classes wrong and there are other ways to reach a higher
velocity within the same time than just by increasing the acceleration.

And for the "bigger rocket", you can simply compare the thrust data:

<http://en.wikipedia.org/wiki/Ariane_4>
<http://en.wikipedia.org/wiki/Ariane_5>

You might notice some minor differences in the numbers. ;)


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

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

Elias Salom�o Helou Neto wrote in message ...
>I have followed the (quite lenghty) on a topic, IIRC, about bitwise
>operators, which eventually lead to people mentioning the Ariane 5
>case.
>
>Since then I have been wondering. If compiler checking where actually
>turned on, what would have happened? How could it avoid the disaster?

You mean, what if a user-supplied error handler had been provided?

To understand what that might have done, it is necessary to look at what happened.

An integer overflow occurred.
It was not caught by a user-written error handler.
For such an event, the OS was required to place the
error number on the data bus, and shut down the computer.
The assumption was that any such error was a hardware error,
and that the backup computer would then continue correctly.
Because the backup computer was programmed to do exactly
the same thing, a very short time later, it also shut down
[because the error was not a hardware error].
The error number on the data bus was then taken as guidance data,
and the result was catastrophic change of direction.

Thus, had an error handler been provided, the data bus would not have
had an error number placed on it, and that error number would
not have been taken as guidance data.

>Right now I think of three possibilities, the two former seem very
>unlikely to me.
>
>a) It would, even if the problem went undetected during testing, have
>made the developers actually develop code handling this exceptional
>possibility.
>
>b) The compiler default action for unhandled overflows have saved the
>day;

It didn't and couldn't.
What was required was an error handler.

>c) Developers would probably ignore the exceptional flow path and the
>disaster would happen anyway.

Anyone competent in real-time programming would never have
let the software go with unhandled overflow, because such an event
would result in failure of the mission.

>Which one, if any, is close to reality?

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Simon Wright]

"robin" <robin51@dodo.com.au> writes:

> Anyone competent in real-time programming would never have let the
> software go with unhandled overflow, because such an event would
> result in failure of the mission.

The engineers, being competent in tightly-constrained real-time
programming, found that installing exception handlers cost cpu cycles
they could not afford, so looked at all the potential overflow sites and
found that _this_ one could only occur if there was a hardware
failure. Even if they had installed an exception handler, the only
proper response would have been to shutdown this node and hand over to
the alternate; and this was the action that would result from not having
an exception handler in the first place. So, after considerable thought,
they decided against having an exception handler.

Sounds like good engineering to me. 

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[robin]

Simon Wright wrote in message ...
>"robin" <robin51@dodo.com.au> writes:
>
>> Anyone competent in real-time programming would never have let the
>> software go with unhandled overflow, because such an event would
>> result in failure of the mission.
>
>The engineers, being competent in tightly-constrained real-time
>programming, found that installing exception handlers cost cpu cycles
>they could not afford, so looked at all the potential overflow sites and
>found that _this_ one could only occur if there was a hardware
>failure.

Nonsense.  The Full Report says nothing of the kind.

> Even if they had installed an exception handler, the only
>proper response would have been to shutdown this node and hand over to
>the alternate;

No, the exception handler could have done something sensible,
such as using the maximum integer value, thus allowing the trajectory to continue.
Better still would have been to include a magnitude test in the code that avoided
the need for an error handler.

> and this was the action that would result from not having
>an exception handler in the first place. So, after considerable thought,
>they decided against having an exception handler.

There were 7 places in the code in the vicinity where overflow could occur.
Four were chosen for protection, but three were not.
That was the fatal flaw.

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Georg Bauhaus]

On 17.03.11 13:39, robin wrote:
> Simon Wright wrote in message ...

>> Even if they had installed an exception handler, the only
>> proper response would have been to shutdown this node and hand over to
>> the alternate;
> 
> No, the exception handler could have done something sensible,
> such as using the maximum integer value, thus allowing the trajectory to continue.

Does the report say so?

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[robin]

Georg Bauhaus wrote in message <4d820f84$0$6990$9b4e6d93@newsspool4.arcor-online.net>...
>On 17.03.11 13:39, robin wrote:
>> Simon Wright wrote in message ...
>
>>> Even if they had installed an exception handler, the only
>>> proper response would have been to shutdown this node and hand over to
>>> the alternate;
>>
>> No, the exception handler could have done something sensible,
>> such as using the maximum integer value, thus allowing the trajectory to continue.
>
>Does the report say so?

No, that's just a suggestion of mine.  However, see what the Report says:
"... the computers within the SRIs could have continued to provide
their best estimates of the required attitide information."

Provided that the two SRI computers remained switched on, the mission was safe.
Switching off "two still healthy critical units of equipment" guaranteed failure.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Hyman Rosen]

On 3/17/2011 7:34 PM, robin wrote:
> Provided that the two SRI computers remained switched on, the mission was safe.
> Switching off "two still healthy critical units of equipment" guaranteed failure.

To quote Douglas Adams: <http://en.wikiquote.org/wiki/Douglas_Adams>
     The difference between something that can go wrong and something
     that can't possibly go wrong is that when something that can't
     possibly go wrong goes wrong it usually turns out to be impossible
     to get at or repair.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[KK6GM]

On Mar 18, 5:57 am, Hyman Rosen <hyro...@mail.com> wrote:
> On 3/17/2011 7:34 PM, robin wrote:
>
> > Provided that the two SRI computers remained switched on, the mission was safe.
> > Switching off "two still healthy critical units of equipment" guaranteed failure.

I realize now that we have been having two separate discussions, and
I'd say that we're _all_ right.  That is, it makes much more sense,
when encountering a value that has been proven to be impossible to
encounter, that the encountering system should fall back to the
redundant hardware than to try and "fake it".  However, (and this is
the case you and robin have been arguing, while ignoring the existence
of the redundant hardware in the first place), the last control system
in the chain (the 2nd one in this case) should obviously never shut
down, but should fall back to a limp-along mode, which of course may
or may not be good enough for the mission to succeed.

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Dmitry A. Kazakov]

On Fri, 18 Mar 2011 09:49:17 -0700 (PDT), KK6GM wrote:

> However, (and this is
> the case you and robin have been arguing, while ignoring the existence
> of the redundant hardware in the first place), the last control system
> in the chain (the 2nd one in this case) should obviously never shut
> down, but should fall back to a limp-along mode, which of course may
> or may not be good enough for the mission to succeed.

I disagree. In the case of unrecoverable hardware malfunction you should
bring the system into a safe state and if there is no one to a least
damaging state.

For an unmanned rocket self-destruction is likely such a procedure, because
you don't want it falling upon your head.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Keith Thompson]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> On Fri, 18 Mar 2011 09:49:17 -0700 (PDT), KK6GM wrote:
>> However, (and this is
>> the case you and robin have been arguing, while ignoring the existence
>> of the redundant hardware in the first place), the last control system
>> in the chain (the 2nd one in this case) should obviously never shut
>> down, but should fall back to a limp-along mode, which of course may
>> or may not be good enough for the mission to succeed.
>
> I disagree. In the case of unrecoverable hardware malfunction you should
> bring the system into a safe state and if there is no one to a least
> damaging state.
>
> For an unmanned rocket self-destruction is likely such a procedure, because
> you don't want it falling upon your head.

That's a good point.  For an unmanned rocket, blowing it up is not
the worst-case outcome, to be avoided at all costs.  The worst-case
outcome is the rocket continuing to operate and crashing, intact
and almost fully fuelled, into a populated area.

If the software detects a condition that can only occur due to
hardware failure (as determined by engineering analysis), attempting
to continue operating with inaccurate information (say by storing
32767 rather than 33000 in a 16-bit signed integer) could conceivably
lead to a worst-case outcome.  (Imagine everything continuing to
operate except the self-destruct mechanism.)  Blowing up the rocket
could be the safest course of action at that point.

If the condition in question had shown up on the Ariane 4, it
probably *would* have indicated a hardware failure.  The real cause
of the problem, of course, was taking software that works correctly
on the Ariane 4 and running it on the Ariane 5 without modification.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: How would Ariane 5 have behaved if overflow checking were notturned off?

[Robert A Duff]

Keith Thompson <kst-u@mib.org> writes:

>...  The real cause
> of the problem, of course, was taking software that works correctly
> on the Ariane 4 and running it on the Ariane 5 without modification.

That matches my understanding exactly.  Without modification, and
without even having some programmers check whether modifications were
necessary.

So it seems that all discussion of the proximate cause of failure
is irrelevant.  If the software had been different, it might have
worked in Ariane 5, or it might not.  If it worked, it would
have been purely by accident, since the programmers had never heard
of an Ariane 5 at the time they wrote the software.

- Bob

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Vinzent Hoefler]

robin wrote:

> Simon Wright wrote in message ...
>> "robin" <robin51@dodo.com.au> writes:
>>
>>> Anyone competent in real-time programming would never have let the
>>> software go with unhandled overflow, because such an event would
>>> result in failure of the mission.
>>
>> The engineers, being competent in tightly-constrained real-time
>> programming, found that installing exception handlers cost cpu cycles
>> they could not afford, so looked at all the potential overflow sites and
>> found that _this_ one could only occur if there was a hardware
>> failure.
>
> Nonsense.  The Full Report says nothing of the kind.

But the documentation does. :P

> No, the exception handler could have done something sensible,
> such as using the maximum integer value, thus allowing the trajectory to continue.
> Better still would have been to include a magnitude test in the code that avoided
> the need for an error handler.

And then what? Using a bogus value to continue the flight? Admitted,
it might even have been worked for Ariane 5, but the system was designed
for Ariane 4 and I DO NOT think that using such a large value to continue
the calculation would have done anything good there, because using flight
parameters well outside of any operational limits simply can't be a
good idea. If it was, you could just get rid of all sensors and replace
them by random generators.

> There were 7 places in the code in the vicinity where overflow could occur.
> Four were chosen for protection, but three were not.
> That was the fatal flaw.

If they had protected all theoretically possible overflows, the software
wouldn't have been able to fulfill the mission due to missing its deadline.

I don't see how _this_ could possibly be considered flawless.


Vinzent.

-- 
A C program is like a fast dance on a newly waxed dance floor by people carrying
razors.
   --  Waldi Ravens

Re: How would Ariane 5 have behaved if overflow checking were not turned off?

[Simon Wright]

"robin" <robin51@dodo.com.au> writes:

> Simon Wright wrote in message ...
>>"robin" <robin51@dodo.com.au> writes:
>>
>>> Anyone competent in real-time programming would never have let the
>>> software go with unhandled overflow, because such an event would
>>> result in failure of the mission.
>>
>>The engineers, being competent in tightly-constrained real-time
>>programming, found that installing exception handlers cost cpu cycles
>>they could not afford, so looked at all the potential overflow sites and
>>found that _this_ one could only occur if there was a hardware
>>failure.
>
> Nonsense.  The Full Report says nothing of the kind.

Oh yes it does. Well, very very nearly. See
http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf page 5 second
para. Especially note the last sentence.

>> Even if they had installed an exception handler, the only proper
>>response would have been to shutdown this node and hand over to the
>>alternate;
>
> No, the exception handler could have done something sensible, such as
> using the maximum integer value, thus allowing the trajectory to
> continue.  Better still would have been to include a magnitude test in
> the code that avoided the need for an error handler.
>
>> and this was the action that would result from not having an
>>exception handler in the first place. So, after considerable thought,
>>they decided against having an exception handler.
>
> There were 7 places in the code in the vicinity where overflow could
> occur.  Four were chosen for protection, but three were not.  That was
> the fatal flaw.

I know that the last but one paragraph on that page (5) starts "Although
the failure was due to a systematic software design error..." but
.. where I come from there are system designers and software
designers. The system people work out the requirements and the software
people - after making sure that the requirements appear sensible and
questioning them if they don't - just get on and do what has been agreed
by people probably on a higher pay grade and certainly with the assigned
responsibility. So I don't agree that it was a software design
error. You may say that it makes no difference; I say it affects who
should get fired (or sued). Of course, for Ariane 4 it wasn't even a
system design error.

I remember a Kalman-filter-based target motion analysis for passive
sonar (which only gives you bearings, of course). At one point, there
was a value named Range_Squared. The programmer used a natural float
(ie, not allowed to go negative) and, when tests revealed to him that it
sometimes did go negative, he decided to limit the value to >= 0.0.

Unfortunately the underlying quantity was actually complex at this
point, and the result of this well-intentioned change was that the
algorithm could become very very unstable. The mathematician responsible
was not pleased.

Reverting to the Report, the last paragraph on page 6 says "This means
that critical software - in the sense that failure of the software puts
the mission at risk - must be identified at a very detailed level, that
exceptional behaviour must be confined, and that a reasonable back-up
policy must take software failures into account."

It seems obvious to me that you cannot take software failures into
account by having two identical systems. You might get away with it for
some tight race conditions, but for processing input data I just don't
see it. You really need diversity.