comp.lang.ada
 help / color / mirror / Atom feed
* Ariane5 FAQ, Observer's version, 8th draft
@ 2004-11-27 22:17 Alexander E. Kopilovich
  2004-11-28  0:06 ` Brian May
  0 siblings, 1 reply; 5+ messages in thread
From: Alexander E. Kopilovich @ 2004-11-27 22:17 UTC (permalink / raw)
  To: comp.lang.ada

In this 8th draft of the Observer's version of the FAQ, 1 minor addition was
made in one "A" (FPU exception was explicitly mentioned); also 1 slight 
(almost editorial) elaboration was added to another sub-point of the same "A".

No other changes were made relative to the previous (7th) draft, which was
posted in August 2003.

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

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

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

Q. Did that software cause the crash?

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

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

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

Q. But why on earth they expected that it should work if they have no reasons
for it? Are you implying that they were idiots? (No conspiracy theories please.)

A. No. There was an unfortunate collision of popular expectations about modern
high-tech devices with real difficult issues of international collaboration
in sensitive technologies.
  Ariane 5 was an international project (within ESA = European Space Agency),
and at the same time it naturally belonged to an area of high secrecy (which
is, as you probably know, traditionally maintained within strictly national
frame). This created a difficult issue and caused uncommonly massive involvement
of persons with political, diplomatic, economical etc. rather than technical
background and/or experience into the high management of the project.
  Those persons naturally have mostly consumer-like expectations about modern
high-tech devices. This means that while they may be generally smart and able
to occupy some position within large technical project, nevertheless they have
different (from an engineer) default assumptions for many technical issues.
  So they dealt with one critical part of the equipment as if it was some
regular consumer market product from a reliable vendor: they assumed that they
may use the device in all circumstances that aren't explicitly and clearly
prohibited in its documentation. Because of their insufficient engineering
background and/or experience they weren't aware of the difference in this
respect between a complete product and its component part -- they did not know
well enough that for the latter the defaults are opposite, that is, you should
not use the component device in any circumstances that aren't explicitly and
clearly allowed.

Q. But certainly there were engineers also, who can see possible consequences
of that approach. So why they weren't alarmed enough?

A. This is difficult question indeed. An explanation exists, which tells that
the informational paths within the project were interspersed with those 
managers of non-engineering kind, and because of that no one of the engineers
can obtain enough information for recognition of the danger.

A contributing factor was the specifics of communications and crossings of
responsibilities, which often manifests itself within international projects.
Here is an insider's view on that specifics:

"As with many international projects, some of the information is eyes only.
This is sometimes a burden for engineers that write the software, since they
have to rely on good will and reliable deliveries of sub-components.
As you can imagine, Ariane is a fairly complex system which relies on many
"sub-systems"; now imagine that all those subsystems come from a different
supplier. The integration of all of them is a very large and complex project
on is own."

Q. Still don't understand how they managed to avoid testing?

A. They did not entirely avoid testing. Actually they tested most of the
rocket equipment, except of the Inertial Reference System (which then caused
the crash). This device was excluded from the test procedure and replaced by
its simulator (for financial and perhaps schedule reasons). The simulator
was written within Ariane 5 project. The crucial thing was that the developers
were not given the documentation for the software, but source code only. By
that administrative restriction some limitations of the software (which were
clearly stated in the documentation) were obscured from the developers of the
simulator. As a result, the simulator worked differently from the real device.
(It helped to test other equipment, but no more -- the real device remained
untested for the new rocket.) Subsequently, after the crash, the original
programmers of the Ariane 4 device were blamed for not stating the limitations
by comments within the source code (additionally to the documentation).

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

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

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

Q. Can you explain in several words what was the actual cause of the launch
failure, technically?

A. There are several points which are different for Ariane 5 vs. Ariane 4,
one of which was instrumental to the events: Ariane 4 is a vertical launch
vehicle where as Ariane 5 is slightly tilted.
  Ariane 4 software was developed to tolerate certain amount of inclination
but not as much as required by Ariane 5. The chain of events were as follows:

- The on-board software detects that one of the accelerometers is out of range
(actually, there was FPU exception generated when float-to-integer conversion
exceeded the capacity of the integer), this was interpreted as hardware error
and caused the backup processor to take over;
- The backup processor also detects that one of the accelerometers is out of
range (the same way), which caused the system to advice an auto destruction.


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

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

Q. Where this topic was discussed in depth?

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

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ariane5 FAQ, Observer's version, 8th draft
  2004-11-27 22:17 Ariane5 FAQ, Observer's version, 8th draft Alexander E. Kopilovich
@ 2004-11-28  0:06 ` Brian May
  2004-11-28 12:17   ` Simon Wright
  2004-11-28 23:02   ` Alexander E. Kopilovich
  0 siblings, 2 replies; 5+ messages in thread
From: Brian May @ 2004-11-28  0:06 UTC (permalink / raw)


>>>>> "Alexander" == Alexander E Kopilovich <aek@VB1162.spb.edu> writes:

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

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

I would argue this was in fact an error in the software installed,
even though the software itself did exactly as in intended.

If I accidently installed software designed for my Microwave oven in
my fridge, and my fridge subsequently tried to cook food rather then
cool/freeze food, I would still consider it an error in the software
installed. Despite the fact the software did exactly as intended.

I agree though that the choice of language was in no way a
contributing factor.
-- 
Brian May <bam@snoopy.apana.org.au>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ariane5 FAQ, Observer's version, 8th draft
  2004-11-28  0:06 ` Brian May
@ 2004-11-28 12:17   ` Simon Wright
  2004-11-29  2:48     ` Alexander E. Kopilovich
  2004-11-28 23:02   ` Alexander E. Kopilovich
  1 sibling, 1 reply; 5+ messages in thread
From: Simon Wright @ 2004-11-28 12:17 UTC (permalink / raw)


Brian May <bam@snoopy.apana.org.au> writes:

> I would argue this was in fact an error in the software installed,
> even though the software itself did exactly as in intended.

An error in the *software installation process*, not in the software.

> If I accidently installed software designed for my Microwave oven in
> my fridge, and my fridge subsequently tried to cook food rather then
> cool/freeze food, I would still consider it an error in the software
> installed. Despite the fact the software did exactly as intended.

No, that would be an error by and in *you* (or your thought processes,
to be fair!)

Software for an embedded environment cannot usually afford the luxury
of checking that the environment it is installed in is appropriate. We
tend to rely on human processes for that. It's not as though the
Ariane engineers could just pick up IRS software off the net ..

-- 
Simon Wright                               100% Ada, no bugs.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ariane5 FAQ, Observer's version, 8th draft
  2004-11-28  0:06 ` Brian May
  2004-11-28 12:17   ` Simon Wright
@ 2004-11-28 23:02   ` Alexander E. Kopilovich
  1 sibling, 0 replies; 5+ messages in thread
From: Alexander E. Kopilovich @ 2004-11-28 23:02 UTC (permalink / raw)
  To: comp.lang.ada

Brian May wrote:

> I would argue this was in fact an error in the software installed,
> even though the software itself did exactly as in intended.
>
> If I accidently installed software designed for my Microwave oven in
> my fridge, and my fridge subsequently tried to cook food rather then
> cool/freeze food, I would still consider it an error in the software
> installed. Despite the fact the software did exactly as intended.
There may be an error to blame either in the software installed or in the
software of that your fridge, because that improper coupling of components
at general consumer level was not prevented.

If you get an installable software bundle for microwave oven as a general
consumer (bought CD with it or downloaded it from vendor's website), you may
expect that reasonable precautions will be taken against improper use of it;
both sides - your fridge (which permits installation of separately obtained
software and then takes instructions from it) and the software bundle are
responsible for those checks.

If those checks were designed, but did not prevent inappropriate coupling
because of their improper implementation at the software level - then there
was a software error to blame indeed. Otherwise (for example, the checks were
not designed at all) the construction of your fridge is seriously flawed.

I think that your example is perfectly in line with the explanation, which is
given in the next (4th) Q-A pair of the FAQ (and is based on the effects of
general consumer's expectations).





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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Ariane5 FAQ, Observer's version, 8th draft
  2004-11-28 12:17   ` Simon Wright
@ 2004-11-29  2:48     ` Alexander E. Kopilovich
  0 siblings, 0 replies; 5+ messages in thread
From: Alexander E. Kopilovich @ 2004-11-29  2:48 UTC (permalink / raw)
  To: comp.lang.ada

Simon Wright wrote:

> > If I accidently installed software designed for my Microwave oven in
> > my fridge, and my fridge subsequently tried to cook food rather then
> > cool/freeze food, I would still consider it an error in the software
> > installed. Despite the fact the software did exactly as intended.
>
> No, that would be an error by and in *you* (or your thought processes,
> to be fair!)

There is a crucial difference between products for general consumer market
and very special things that are for professionals only. General consumer
is entitled to expect some reasonable level of foolproof. A spurious guess
and a wild association is not an error but rather normal way of general
consumer's thinking.

> Software for an embedded environment cannot usually afford the luxury
> of checking that the environment it is installed in is appropriate.

This is true while "embedded" implied that integration process requires
professional and highly trained personnel. I'm not sure that this traditional
implication (along with some others) will survive the next decade. Perhaps
some new name will be needed for retaining that current meaning in use.





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





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-11-29  2:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-27 22:17 Ariane5 FAQ, Observer's version, 8th draft Alexander E. Kopilovich
2004-11-28  0:06 ` Brian May
2004-11-28 12:17   ` Simon Wright
2004-11-29  2:48     ` Alexander E. Kopilovich
2004-11-28 23:02   ` Alexander E. Kopilovich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox