Ariane 5 - not an exception?

Ariane 5 - not an exception?

[Simon Bluck]

The Ariane 501 flight failure was due to the raising of an unexpected
Ada exception, which was handled by switching off the computer.  The
report on this:

   http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

is clear and hard-hitting: it will result in much improved software.
But does it get right to the bottom of the issues, and does the
software community appreciate that there are fundamental software
control problems which can directly give rise to such enormous
failures, in this particular case thankfully without loss of life?

It is most unfortunate, but must be accepted as true, that if the
Ariane software had been written in a less powerful language the
numeric overflow might have gone unnoticed, the computers would have
remained switched on, and the rocket would have continued its upward
flight.

Exceptions and assertions are both used, in Ada and C/C++, to detect
software/hardware anomalies.  When one of these trips, it is
frequently very difficult for the designer to know how best to handle
the problem.  To continue may result in corrupt data; to abort is
drastic but eliminates the possibility that further processing will
compound the problem.

The more checks you have, the more likely it is that one of them will
trip.  If you can't think of good ways of handling these checks, the
end result, for the user, may well be very much worse than if the
check had never been performed in the first place.

Of the two handling options, neither is really acceptable.  However,
there is a third option which ought to be considered: to continue but
mark the processed data as suspect.

I.e. each data item would have a truth value of 1.0 for good data,
0.0 for absolutely rotten data, utilising values in between if you
have some idea how good the data is.  If you have numeric overflow,
you could set the data to the largest value available, and mark it as
suspect.

Any data further derived from suspect data must also be marked as
suspect.

Taking a probabilistic attitude to data would bring a lot of software
into the real world where failures can happen at all levels.  Using
this approach would made complex mission-critical software like the
failing Ariane software much easier to understand and control.  Data
would be processed along the same path regardless of whether it is
suspect or entirely valid.  Only the end-users of the data would be
affected, and where duplication of systems provides redundancy, the
algorithm would be to switch to the backup on receiving suspect data,
and switch back to the main source if the backup was suspect.  If
both sources are suspect, then take the least suspect source.  This
is simple and you don't lose your vital input data.  The data truth
values would be passed on from system to system along with the data.

You _never_ switch off a computer, but you may have cause to mark all
data emanating from it as suspect.  Leave it up to the users of the
data to decide if they want to use it or not - they may have no
choice.


Along with the data truth attribute, you need a data type attribute.
This is tending to be relatively standard stuff now that objects are
around and need to know what kind of object they are.  But adding a
data type field is still something that designers skimp on if not
supplied by the language, relying instead on implicit coding of type
information in the senders and receivers of data.

Lack of type information accounts for why the Ariane flight control
was able to interpret diagnostic data as attitude data, virtually
guaranteeing catastrophic failure.  At least if attitude data had
been cut short it could have continued in a straight line.


Well, those are what I think are the important lessons to be learned.
The main reasons cited for Ariane 501's failure are typical human
ones which will be made again on the next big project.  I.e.
inadequate testing, particularly of the complete system in its
(simulated) environment.  Surprise, surprise, this turns out to be
too difficult and too costly to achieve thoroughly.  And small system
mistakes which stress the adequate functioning of the system as a
whole (like thinking that the Ariane 4 alignment process didn't need
changing for Ariane 5).  These will happen time and again, we're only
human.  But with more realistic data processing the system as a whole
would stand a better chance of survival.

SimonB

[All my own opinions, of course.]

Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Kirk Beitz]

after reading the failure analysis, it seems a little irresponsible to even
hint about the failure of the rocket being based solely on the lack of proper
exception handling.  

yes, it does seem clear that this was the final straw, and one of the heavy
hands from within the report comes down on the initial specification that
exceptions should be handled in such a manner.  but there were several
choices made over the course of a long period of development that helped lead
to the situation.

a set of decisions were made along the way that led to this (i won't rehash
the whole report in detail from the web; it is fairly clear and
self-explanatory): 

	- the value which caused the exception was on a variable that was
	  not "guarded" or protected when converted from a generated float
	  input in the same fashion as a couple of similar variables
	  (partially in response to a "maximum workload target" for the
	  system.)
	- the alignment software that generated the exception that went
	  unhandled was running when it didn't need to be after launch,
	  particularly on ariane 5 which had a different preparation
	  sequence and thus didn't require the hold to avoid the lengthy
	  reset of the launcher.  the exception occurred within the
	  window after the software was necessary and before that
	  particular portion of the software was shutdown.
	- the value that triggered the exception was out of range because
	  ariane 5 has higher horizontal velocity values than ariane 4;
	  the exception was on a value related to these horizontal vel vals.
	- no testing was performed on the software for behavior in the
	  circumstances of count-down and flight-time sequence and the
	  trajectory of ariane 5.  (the software did not contain this as
	  a measurement in its functional requirement.  the two machines
	  that shutdown as a result of the unhandled exception were not
	  present but only simulated in pre-flight simulation testing.
	  one of the reasons given for this latter was that it was tested
	  based on use in ariane 4.)

i understand some of the points raised in the initial post, and the final
full report on the ariane 5 failure does address this:  that system shutdown
following an unhandled exception was not a sound design decision in this
mission critical software.

it just seems to me that there are many more important lessons to be learned:

 - the value of treating an raised or potentially raised exception within
   a context that is as local as possible
 - the value of understanding the nature of potential exceptions raised from
   input 
 - the value of fully testing the software in the closest environment possible
   to the real situation 
 - the value of making the software conform to the real requirements of a
   mission, particularly in mission critical software
 - the value of creating requirements specifications that properly fit the
   mission at hand.  

every single one of these probably should have been done during design;
*any* single one would have probably prevented the failure of ariane 501.

my point:  the title of the original post (and much of its flavor) might to
suggest that the single problem that led to ariane 5 failing was the failure
to properly handle an exception.  and that is *not* the lesson that should be
taken from this at all.

--kirk beitz

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

	johndoe@zaphod.nosc.mil (Kirk Beitz) writes:

	>after reading the failure analysis, it seems a little irresponsible to even
	>hint about the failure of the rocket being based solely on the lack of proper
	>exception handling.  

---The failure of the project was, as the report stated, "ultimately"
due to the exception handler which shut down the system (in fact, both
the main system and the backup system, since they both experienced the
problem at the same time).

	>yes, it does seem clear that this was the final straw, and one of the heavy
	>hands from within the report comes down on the initial specification that
	>exceptions should be handled in such a manner.  but there were several
	>choices made over the course of a long period of development that helped lead
	>to the situation.

---The basic problem was due to 3 programming errors:

1. Converting from double precision foating-point to integer,
   without a magnitude check.  The conversion was programmed,
   and lacked the check.

2. assuming that a 58-bit value was going to fit into
   a 15-bit integer.

3. failure to include an error handler in the immediate routine
   to trap trivial errors (such as fixed-point overlow), and
   continuing.

The other failures were:

1. failure to simulate the effects of the error arising
   (can be done easily with PL/I's SIGNAL statement).

2. failure to OBJECT to the stupid design of the error
   handler, which was to shut down the system.  An experienced
   real-time programmer would have done this.  And certainly,
   a PL/I programmer would have NOT written an error-handler to shut
   down the system in the event of a fixed-point overflow.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Darren C Davenport]

++           robin (rav@goanna.cs.rmit.edu.au) wrote:
: 2. failure to OBJECT to the stupid design of the error
:    handler, which was to shut down the system.  An experienced
:    real-time programmer would have done this.  And certainly,
:    a PL/I programmer would have NOT written an error-handler to shut
:    down the system in the event of a fixed-point overflow.

I don't think any language endows a programmer with more intelligence.

Darren

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[U32872]

In <4u538f$9q6@hacgate2.hac.com>, ddavenpo@redwood.hac.com (Darren C Davenport) writes:
>I don't think any language endows a programmer with more intelligence.
>
>Darren
That is certainly true but, I think, PL/1 attracts programmers who are already
well endowed with intelligence.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

"That is certainly true but, I think, PL/1 attracts programmers who are already
well endowed with intelligence."

These daily PL/1 jokes are quite entertaining. An interesting reminder that
every language has an ardent band of supporters :-)

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Pascal Martin @lone]

In article <dewar.839392100@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>
>These daily PL/1 jokes are quite entertaining. An interesting reminder that
>every language has an ardent band of supporters :-)
>

It also remind us that languages don't want to die, even when it is long due.
Just consider COBOL :-)).

BTW, I am in search of an ALGOL68 compiler for Linux/PC. Anyone ?

Pascal.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

Pascal Martin said

"It also remind us that languages don't want to die, even when it is long due.
Just consider COBOL :-))."

Actually in the case of COBOL, I think it is only with the advent of Ada 95
that there is a tenable alternative. The lack of fundamental facilities
(arithmetic and edited output) for high precision scaled decimal arithmetic
is a huge handicap in most other potential COBOL replacements.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[dwnoon]

In <dewar.839592590@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>Actually in the case of COBOL, I think it is only with the advent of Ada 95
>that there is a tenable alternative. The lack of fundamental facilities
>(arithmetic and edited output) for high precision scaled decimal arithmetic
>is a huge handicap in most other potential COBOL replacements.

You posted this in a PL/I Newsgroup.

What do you think PL/I has been doing these past 30 years?

High-precision decimal arithmetic, with "all the bells and whistles" edit
patterns. It was always a better COBOL than COBOL, and far more
coherently structured.

Combined with being a better FORTRAN than FORTRAN and a better
Pascal than Pascal, I guess it's also a better Ada than Ada.

But only people who know all of these languages fluently are qualified
to comment.

Regards

Dave
<Team PL/I>

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

Dave said

"What do you think PL/I has been doing these past 30 years?

High-precision decimal arithmetic, with "all the bells and whistles" edit
patterns. It was always a better COBOL than COBOL, and far more
coherently structured."

Yes indeed, I completely overlooked PL/I, which of course has been around
a long time, and has not succeeded in displacing COBOL, even though it
is arguably better, although by modern standards its type system is rusty.
Is there a more modern version of PL/1, my knowledge really stops with
the (original) ANSI standard, and if there is a new standard I had not
heard of it.

To compete with OOCOBOL, you clearly need a language with powerful
abstraction facilities, and it was really that that I was thinking
about. Type abstraction, type extension, inheritance, polymorphism
and strong typing with named types seem pretty essential these days.
As I say, for all I know there is a wonderful OO-PL/I available
that I am unfamiliar with :-)

I guess the reason PL/I escaped my attention is precisely that it has
been around so long :-)

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[dwnoon]

In <dewar.839778764@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>To compete with OOCOBOL, you clearly need a language with powerful
>abstraction facilities, and it was really that that I was thinking
>about. Type abstraction, type extension, inheritance, polymorphism
>and strong typing with named types seem pretty essential these days.
>As I say, for all I know there is a wonderful OO-PL/I available
>that I am unfamiliar with :-)

PL/I has had type definitions for a few years now. You no longer need
to kludge using LIKE. It also has had enumerations, etc., for a few years
too. These first appeared under OS/2, but the Windows NT compiler has
them too, as does the latest mainframe compiler.

The latest release of PL/I has OO constructs. However, IBM has not
released the documentation on them, so nobody outside of Santa Teresa
labs has much experience with it. Perhaps Peter Elderon might like to let
a few cats out of the bag in this newsgroup.

Regards

Dave
<Team PL/I>

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

"PL/I has had type definitions for a few years now. You no longer need
to kludge using LIKE. It also has had enumerations, etc., for a few years
too. These first appeared under OS/2, but the Windows NT compiler has
them too, as does the latest mainframe compiler."

I thought PL/I had just structural typing, and not named typing, but
if we are talking about what people implement today, as opposed to
the standard, I may well be out of date!

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[dwnoon]

In <dewar.840250527@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
>I thought PL/I had just structural typing, and not named typing, but
>if we are talking about what people implement today, as opposed to
>the standard, I may well be out of date!

You are indeed out of date. ... :-)

Regards

Dave
<Team PL/I>

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

dwnoon@ibm.net wrote:
> 
> But only people who know all of these languages fluently are qualified
> to comment.

I've been paid fairly good wages to write programs in all four languages 
that you mentioned (COBOL, PL/I, Ada, and FORTRAN), so I guess I'm 
qualified to comment:

I think, feature-wise, PL/I has sufficient capability to write embedded 
flight software (which, if you look at the title of this thread, was the 
domain of interest), assuming the presence of an adequate support 
library. What strikes me as odd is the thought that PL/I is _better_ 
than Ada for this domain. I can't think of anything in PL/I that I would 
want for this domain, that I don't have in Ada.

More importantly, based on the list of targets posted recently for which 
PL/I is available, it seems to me that there's not been a lot of work 
done to target PL/I compilers to CPUs used in safety-critical flight 
applications. Ada compilers , on the other hand, are available for 
several appropriate CPUs (16-bit and 32-bit). Not having a compiler 
available would seem to be a serious limitation to its use for a 
particular CPU/domain :)

I am curious: Is there anyone in Team PL/I that has actual experience in 
building (successfully) operational flight control or inertial reference 
system software in PL/I? For what airframe? CPU? All my PL/I experience 
is on IBM mainframes...

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Richard Riehle]

On 10 Aug 1996 dwnoon@ibm.net wrote:

> Combined with being a better FORTRAN than FORTRAN and a better
> Pascal than Pascal, I guess it's also a better Ada than Ada.

  I have programmed in PL/I (when it was still PL/1) as well as
  Ada. I not the slightest doubt about the improvement of PL/I
  over its predecessors.  However, Ada is clearly superior to
  PL/I as a software engineering language. It is even a better
  programming language. I could go into detail about the model
  for pointers, or the frailty of the DO WHILE construct, but
  "He convinced against his will, is of the same opinion still."

  On the other hand, I would rather see people using PL/I for
  a serious project than C.  And I have heard there is an effort
  to release an Object-oriented version of PL/I in the near
  future.  That might actually make PL/I a viable alternative
  to C++.

  Richard Riehle

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

	Richard Riehle <rriehle@nunic.nu.edu> writes:

	>On 10 Aug 1996 dwnoon@ibm.net wrote:

	>> Combined with being a better FORTRAN than FORTRAN and a better
	>> Pascal than Pascal, I guess it's also a better Ada than Ada.

	>  I have programmed in PL/I (when it was still PL/1)


---PL/I has always been "PL/I".  From the first
implementation to the introduction of the standard, to now.

	>as well as
	>  Ada. I not the slightest doubt about the improvement of PL/I
	>  over its predecessors.  However, Ada is clearly superior to
	>  PL/I as a software engineering language. It is even a better
	>  programming language.

---Not really, when people have to ask how to do 
a square root [in Ada].

	> I could go into detail about the model
	>  for pointers,

---You seem not to be aware of the DEFINE STRUCTURE
statement and the strongly-typed pointer facilities of
PL/I for Windows 95/NT, OS/2 and AIX.

	> or the frailty of the DO WHILE construct, but

---DO WHILE is one of the structured constructs.

	>  On the other hand, I would rather see people using PL/I for
	>  a serious project than C.  And I have heard there is an effort
	>  to release an Object-oriented version of PL/I in the near
	>  future.  That might actually make PL/I a viable alternative
	>  to C++.

---It already is.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

++ robin wrote:

> ---Not really, when people have to ask how to do
> a square root [in Ada].

How do you do square root in PL/I? (Oops, now someone's asked, PL/I must
really be a horrible language! :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Richard Riehle]

On 22 Aug 1996, ++           robin wrote:

> Richard Riehle wrote:
>
> 	>  I have programmed in PL/I (when it was still PL/1)
> ---PL/I has always been "PL/I".  From the first
> implementation to the introduction of the standard, to now.

  Though I do not have them at hand, I recall some early IBM
  documents which referred to PL/1 after it changed its name
  from NPL.
>
> 	>as well as
> 	>  Ada. I not the slightest doubt about the improvement of PL/I
> 	>  over its predecessors.  However, Ada is clearly superior to
> 	>  PL/I as a software engineering language. It is even a better
> 	>  programming language.
>
> ---Not really, when people have to ask how to do
> a square root [in Ada].

  No serious Ada programmer has to ask such a question.

>
> 	> I could go into detail about the model
> 	>  for pointers,
>
> ---You seem not to be aware of the DEFINE STRUCTURE
> statement and the strongly-typed pointer facilities of
> PL/I for Windows 95/NT, OS/2 and AIX.

  I used PL/I long before Bill Gates heard of a computer. The
  PL/I I remember supported some rather scary notions of type
  flexibility, not appropriate for safety-critical systems. For
  example, implicit type conversions, etc.

> 	> or the frailty of the DO WHILE construct, but
>
> ---DO WHILE is one of the structured constructs.

  Yes it is. Too bad it also permits assignment to the loop
  control variable, among other things.

> 	>  On the other hand, I would rather see people using PL/I for
> 	>  a serious project than C.  And I have heard there is an effort
> 	>  to release an Object-oriented version of PL/I in the near
> 	>  future.  That might actually make PL/I a viable alternative
> 	>  to C++.
>
> ---It already is.

  Not unless if does not explicitly support object-oriented
  programming.  And OOP kludges do not count.

  Richard Riehle

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[++ robin]

	Richard Riehle <rriehle@nunic.nu.edu> writes:

	>On 22 Aug 1996, ++           robin wrote:

	>> Richard Riehle wrote:
	>>
	>> 	>  I have programmed in PL/I (when it was still PL/1)
	>> ---PL/I has always been "PL/I".  From the first
	>> implementation to the introduction of the standard, to now.

	>  Though I do not have them at hand, I recall some early IBM
	>  documents which referred to PL/1 after it changed its name
	>  from NPL.

---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I".

	>> 	>as well as
	>> 	>  Ada. I not the slightest doubt about the improvement of PL/I
	>> 	>  over its predecessors.  However, Ada is clearly superior to
	>> 	>  PL/I as a software engineering language. It is even a better
	>> 	>  programming language.
	>>
	>> ---Not really, when people have to ask how to do
	>> a square root [in Ada].

	>  No serious Ada programmer has to ask such a question.

---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
use it [SQRT].  Nothing special needed.

	>> ---You seem not to be aware of the DEFINE STRUCTURE
	>> statement and the strongly-typed pointer facilities of
	>> PL/I for Windows 95/NT, OS/2 and AIX.

	>  I used PL/I long before Bill Gates heard of a computer. The
	>  PL/I I remember supported some rather scary notions of type
	>  flexibility, not appropriate for safety-critical systems. For
	>  example, implicit type conversions, etc.

---There have been some changes since then . . .

	>> 	> or the frailty of the DO WHILE construct, but
	>>
	>> ---DO WHILE is one of the structured constructs.

	>  Yes it is. Too bad it also permits assignment to the loop
	>  control variable, among other things.

A DO WHILE construct doesn't have a control variable.

	>> 	>  On the other hand, I would rather see people using PL/I for
	>> 	>  a serious project than C.  And I have heard there is an effort
	>> 	>  to release an Object-oriented version of PL/I in the near
	>> 	>  future.  That might actually make PL/I a viable alternative
	>> 	>  to C++.
	>>
	>> ---It already is.

	>  Not unless if does not explicitly support object-oriented
	>  programming.  And OOP kludges do not count.

---we'll have to agree to disagree on that.

	>  Richard Riehle

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Richard A. O'Keefe]

rav@goanna.cs.rmit.edu.au (++           robin) writes:
>	Richard Riehle <rriehle@nunic.nu.edu> writes:
>	>  Though I do not have them at hand, I recall some early IBM
>	>  documents which referred to PL/1 after it changed its name
>	>  from NPL.

>---The first edition c. 1966 of IBM's PL/I Reference Manual
>for the S/360 (PL/I-F compiler) called it "PL/I".

That may be true, but all Riehle claimed is that PL/I was once
called NPL.

He's right.

Years ago I read the proceedings of a SHARE conference
where they talked about the "New Programming Language".
There was some discussion of requirements and examples.

>	>  No serious Ada programmer has to ask such a question.

>---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
>use it [SQRT].  Nothing special needed.

With respect to Fortran, Basic, Pascal, Algol, and PL/I:  true.
With respect to C (including Turbo C) and C++:  totally false.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[++ robin]

	ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

	>rav@goanna.cs.rmit.edu.au (++           robin) writes:
	>>	Richard Riehle <rriehle@nunic.nu.edu> writes:
	>>	>  Though I do not have them at hand, I recall some early IBM
	>>	>  documents which referred to PL/1 after it changed its name
	>>	>  from NPL.

	>>---The first edition c. 1966 of IBM's PL/I Reference Manual
	>>for the S/360 (PL/I-F compiler) called it "PL/I".

	>That may be true, but all Riehle claimed is that PL/I was once
	>called NPL.

	>He's right.

---No, that's not it at all.  NPL is not in dispute.  It's well
known that the early name of the language was NPL for New Programing
Language.

   He was claiming that PL/I was called "PL/1" before it
was called PL/I.  I pointed out that the first editions
of IBM's PL/I manuals called it "PL/I".

   Richard's previous posting was:
______________________________________________________

> Richard Riehle wrote:
>
>       >  I have programmed in PL/I (when it was still PL/1)
> ---PL/I has always been "PL/I".  From the first
> implementation to the introduction of the standard, to now.

  Though I do not have them at hand, I recall some early IBM
  documents which referred to PL/1 after it changed its name
  from NPL.
____________________________________________________________

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Robb Nebbe]

>    He was claiming that PL/I was called "PL/1" before it
> was called PL/I.  I pointed out that the first editions
> of IBM's PL/I manuals called it "PL/I".
> 

Isn't this from a Monty Python sketch?

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[shmuel]

In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++  robin) writes:
>
>   He was claiming that PL/I was called "PL/1" before it
>was called PL/I.  I pointed out that the first editions
>of IBM's PL/I manuals called it "PL/I".
>

Hardly relevant; that manual was printed well after the joint IBM/SHARE report. BTW, do you remember the truly 
ugly name that IBM picked between NPL and MPPL?

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Jay McFadyen]

In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++  robin) writes:
>
>   He was claiming that PL/I was called "PL/1" before it
>was called PL/I.  I pointed out that the first editions
>of IBM's PL/I manuals called it "PL/I".
>

There is an additional issue here. Not is there the question of what it was
called, but also how it was used. In the Multics environment - still 
probably the best use of PL/I that anyone knows of - the PL/I compiler
was named pl1. Note, no slash, no uppercase (all Multics commands are lower
case and case sensitive) and no capital "I". As you can see, I am willing
to call the Language PL/I, but I wish I had a nickel for every time I
invoked the compiler:

         pl1 fred.pl1

Can we call a halt  this fruitless, silly argument?


-- 
Jay McFadyen
Development Tools and Infrastructure, C2PSD, Ford Motor Company
mcfadyen@cadcam.pd9.ford.com or JMCFADYE
(313) 33-73359

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[John McCabe]

mcfadyen@cc0192.pd9.ford.com (Jay McFadyen) wrote:

>In <50g701$gah@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++  robin) writes:
>>
>>   He was claiming that PL/I was called "PL/1" before it
>>was called PL/I.  I pointed out that the first editions
>>of IBM's PL/I manuals called it "PL/I".
>>

>There is an additional issue here. Not is there the question of what it was
>called, but also how it was used. In the Multics environment - still 
>probably the best use of PL/I that anyone knows of - the PL/I compiler
>was named pl1. Note, no slash, no uppercase (all Multics commands are lower
>case and case sensitive) and no capital "I". As you can see, I am willing
>to call the Language PL/I, but I wish I had a nickel for every time I
>invoked the compiler:

>         pl1 fred.pl1

Does anyone really care?

>Can we call a halt  this fruitless, silly argument?

I agree - this is a complete waste of time and my newsreader still
thinks it's relevant to Ariane 5!


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

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[shmuel]

In <51l0rm$5lq@news1.mnsinc.com>, shmuel@os2bbs.com writes:

>Hardly relevant; that manual was printed well after the joint IBM/SHARE report. BTW, do you remember the truly 
>ugly name that IBM picked between NPL and MPPL?

Whoops! I meant to say between NPL and PL/1 and to *not* say MPPL in the 
message; my apologies for the "spoiler".

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[++ robin]

	Richard Riehle <rriehle@nunic.nu.edu> writes:

	>On 22 Aug 1996, ++           robin wrote:

	>> Richard Riehle wrote:
	>>
	>> 	>  I have programmed in PL/I (when it was still PL/1)
	>> ---PL/I has always been "PL/I".  From the first
	>> implementation to the introduction of the standard, to now.

	>  Though I do not have them at hand, I recall some early IBM
	>  documents which referred to PL/1 after it changed its name
	>  from NPL.

---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I".

	>> 	>as well as
	>> 	>  Ada. I not the slightest doubt about the improvement of PL/I
	>> 	>  over its predecessors.  However, Ada is clearly superior to
	>> 	>  PL/I as a software engineering language. It is even a better
	>> 	>  programming language.
	>>
	>> ---Not really, when people have to ask how to do
	>> a square root [in Ada].

	>  No serious Ada programmer has to ask such a question.

---In Fortran, BASIC, Pascal, Algol, PL/I, you just
use it [SQRT].  Nothing special needed.

	>> ---You seem not to be aware of the DEFINE STRUCTURE
	>> statement and the strongly-typed pointer facilities of
	>> PL/I for Windows 95/NT, OS/2 and AIX.

	>  I used PL/I long before Bill Gates heard of a computer. The
	>  PL/I I remember supported some rather scary notions of type
	>  flexibility, not appropriate for safety-critical systems. For
	>  example, implicit type conversions, etc.

---There have been some changes since then . . .

	>> 	> or the frailty of the DO WHILE construct, but
	>>
	>> ---DO WHILE is one of the structured constructs.

	>  Yes it is. Too bad it also permits assignment to the loop
	>  control variable, among other things.

A DO WHILE construct doesn't have a control variable.

	>> 	>  On the other hand, I would rather see people using PL/I for
	>> 	>  a serious project than C.  And I have heard there is an effort
	>> 	>  to release an Object-oriented version of PL/I in the near
	>> 	>  future.  That might actually make PL/I a viable alternative
	>> 	>  to C++.
	>>
	>> ---It already is.

	>  Not unless if does not explicitly support object-oriented
	>  programming.  And OOP kludges do not count.

---we'll have to agree to disagree on that.

	>  Richard Riehle

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

robin said

"---The first edition c. 1966 of IBM's PL/I Reference Manual
for the S/360 (PL/I-F compiler) called it "PL/I"."

Yes, of course that is true. But I assume you are aware of the NPL
papers that preceded this renaming of the language ...

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

	>robin said
	>"---The first edition c. 1966 of IBM's PL/I Reference Manual
	>for the S/360 (PL/I-F compiler) called it "PL/I"."

	>Yes, of course that is true. But I assume you are aware of the NPL
	>papers that preceded this renaming of the language ...

---Indeed.  I said so in a previous post in this thread:

"NPL is not in dispute.  It's well
known that the early name of the language was NPL for New Programing
Language."

   It's also mentioned in the FAQ for comp.lang.pl1, in the history
section.

Re: PL/I or PL/1

[Larry Hazel]

++ robin wrote:
[snip]
> 
>    It's also mentioned in the FAQ for comp.lang.pl1, in the history
> section.
comp.lang.pl(what)?
-- Larry Hazel => Larry.H.Hazel@cpmx.saic.com (205) 876-4509
-- I try to stay above C level,  I get C sick.
-- Team Ada & Team OS/2

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[J. Kanze]

rav@goanna.cs.rmit.edu.au (++           robin) writes:

> ---In Fortran, BASIC, Pascal, Algol, PL/I, Turbo C, you just
> use it [SQRT].  Nothing special needed.

This isn't true for C (and thus Turbo C), of course.  You have to
include math.h.  While it is a built in in older lanugages like Fortran
or Basic, most modern languages will require a declaration for the
function somewhere.  (I'm tempted to say that a language that doesn't
require a declaration for a function is somewhat deficient, but SQRT is
a special case.)

-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

James Kanze says

"This isn't true for C (and thus Turbo C), of course.  You have to
include math.h.  While it is a built in in older lanugages like Fortran
or Basic, most modern languages will require a declaration for the
function somewhere.  (I'm tempted to say that a language that doesn't
require a declaration for a function is somewhat deficient, but SQRT is
a special case.)"

I would definitely give in to this temptation (and say that a language
that does not require a definition for sqrt is deficient). In the absence
of a commitment to IEEE semantics, the definition of sqrt is not well
defined at the language level, and it is better that it come from a
designated library whose semantics are well defined (note that math.h
does not meet that requirement anyway, but certainly the math libraries
in Ada do meet this requirement).

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

	>I would definitely give in to this temptation (and say that a language
	>that does not require a definition for sqrt is deficient). In the absence
	>of a commitment to IEEE semantics, the definition of sqrt is not well
	>defined at the language level,

---I wonder what language(s) you are speaking about?

   SQRT is well-defined in a range of languages.
It's sufficiently well-used that it be available
with a routine call, definitely facilitated
when it's part of the language, as indeed it should be.

	>and it is better that it come from a
	>designated library whose semantics are well defined (note that math.h
	>does not meet that requirement anyway, but certainly the math libraries
	>in Ada do meet this requirement).

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

Robin says

"   SQRT is well-defined in a range of languages.
It's sufficiently well-used that it be available
with a routine call, definitely facilitated
when it's part of the language, as indeed it should be."

No, sorry that's plain wrong, in languages like Fortran, sqrt is not
well-defined at all, no more than addition (for float) is well defined
in such languages. The last I remember, PL/I did not have any properly
defined floating-point semantics either (the standard was too early
to be significantly influenced by either IEEE or LIAS). I suspect
Robin is not a floating-point expert!

Re: Ada versus PL/I (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

Robert Dewar wrote:
> 
> Robin says
> 
> "   SQRT is well-defined in a range of languages.
> It's sufficiently well-used that it be available
> with a routine call, definitely facilitated
> when it's part of the language, as indeed it should be."
> 
> No, sorry that's plain wrong, in languages like Fortran, sqrt is not
> well-defined at all, no more than addition (for float) is well defined
> in such languages. The last I remember, PL/I did not have any properly
> defined floating-point semantics either (the standard was too early
> to be significantly influenced by either IEEE or LIAS). I suspect
> Robin is not a floating-point expert!

Keep in mind that Robin's definition of "well-defined" is probably more 
along the lines of "it's listed in the index of my vendor's compiler 
manual." I don't really see Robin using such terms with much precision 
(pun intended).

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[J.Worringen]

Hi,

today is the first time I read this newsgroup, and allready I found this
interesting thread. Very interesting to me since I've worked for
Arianespace (in Kourou). Therefor, I'd be very happy if I could read the
whole thread right from the beginning. However, the articles have
allready expired at my newsserver. Could anyone help me to get the whole
thread, please ?
 
  Thanks, Joachim


-- 

// Joachim Worringen
// Zentralinstitut fuer angewandte Mathematik (ZAM)
// KFA Juelich

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

J.Worringen wrote:
> 
> Hi,
> 
> today is the first time I read this newsgroup, and allready I found this
> interesting thread. Very interesting to me since I've worked for
> Arianespace (in Kourou). Therefor, I'd be very happy if I could read the
> whole thread right from the beginning. However, the articles have
> allready expired at my newsserver. Could anyone help me to get the whole
> thread, please ?
> 
>   Thanks, Joachim

Can't help you with the thread; but you'd probably be better informed reading:

  http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

> 
> --
> 
> // Joachim Worringen
> // Zentralinstitut fuer angewandte Mathematik (ZAM)
> // KFA Juelich

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[David Alex Lamb]

In article <3236A386.625E@zam176.zam.kfa-juelich.de>,
J.Worringen <zdv181@zam176.zam.kfa-juelich.de> wrote:
>... Therefor, I'd be very happy if I could read the
>whole thread right from the beginning. However, the articles have
>allready expired at my newsserver. Could anyone help me to get the whole
>thread, please ?

You can fetch any thread from any newsgroup using http://www.dejanews.com/;
I'd suggest using the "Power Search" and "Create a Query Filter" options.
Unfortunately it's not always easy to view things in the best order, since
many articles that were part of the discussion weren't "threaded" in a way
that DejaNews (and, I presume, most threaded newsreaders) would recognize.
-- 
http://www.qucis.queensu.ca/home/dalamb/info.html

Use DejaNews to retrieve Ariane discussion

[David Alex Lamb]

In article <3236A386.625E@zam176.zam.kfa-juelich.de>,
J.Worringen <zdv181@zam176.zam.kfa-juelich.de> wrote:
>.... Therefor, I'd be very happy if I could read the
>whole thread right from the beginning. However, the articles have
>allready expired at my newsserver.

The discussion began with a message of subject "Ariane 5 - not an exception?"
posted by simonb@pact.srf.ac.uk (Simon Bluck) on 1996/07/25.  To view the
thread, use a Web browser supporting forms to reach http://www.dejanews.com/.
Click "Power Search" then "Create a Query Filter".
Fill in newsgroups with comp.software-eng, subject with
	+Ariane failure exception
and From* with 1996/7/25, then submit the form.  You'll have a lot of options
on how to view the information.

Multiple threads have discussed this subject (since people don't always post
in such a way as to link their notes into the thread).

-- 
http://www.qucis.queensu.ca/home/dalamb/info.html

Re: Use DejaNews to retrieve Ariane discussion

[Earl H. Kinmonth]

David Alex Lamb (dalamb@qucis.queensu.ca) wrote:
: In article <3236A386.625E@zam176.zam.kfa-juelich.de>,
: J.Worringen <zdv181@zam176.zam.kfa-juelich.de> wrote:
: >.... Therefor, I'd be very happy if I could read the
: >whole thread right from the beginning. However, the articles have
: >allready expired at my newsserver.

Most of these should still be on kuso.shef.ac.uk in
pub/News/comp.software-eng.  I also have a back file.

--
Earl H. Kinmonth, Kanji Users Service Operation (KUSO!),
University of Sheffield, Sheffield, England S10 2UJ

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

	>Pascal Martin said

	>"It also remind us that languages don't want to die, even when it is long due.
	>Just consider COBOL :-))."

	>Actually in the case of COBOL, I think it is only with the advent of Ada 95
	>that there is a tenable alternative. The lack of fundamental facilities
	>(arithmetic and edited output) for high precision scaled decimal arithmetic
	>is a huge handicap in most other potential COBOL replacements.

---In 1966 or so, PL/I introduced scaled decimal arithmetic,
to provide facilities to equal and surpass COBOL.

   The decimal facilities extended to I/O, as well as
to English pounds, shillings, and pence.

   The scaled decimal I/O extends to simple I/O
as well as picture specifications.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[A. Grant]

In article <4uvqos$iv4@news-s01.ny.us.ibm.net> dwnoon@ibm.net writes:
>PL/I has had type definitions for a few years now. You no longer need
>to kludge using LIKE. It also has had enumerations, etc., for a few years
>too. These first appeared under OS/2, but the Windows NT compiler has
>them too, as does the latest mainframe compiler.
>The latest release of PL/I has OO constructs. However, IBM has not
>released the documentation on them, so nobody outside of Santa Teresa
>labs has much experience with it.

Unless these extensions are going to make it into ANSI PL/I,
they are really not relevant to a discussion of embedded systems,
are they?

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[bohn]

In Article<4u6723$kp2@piglet.cc.uic.edu>, <U32872@uic.edu> writes:

> That is certainly true but, I think, PL/1 attracts programmers who are 
> already well endowed with intelligence.

That's no more true/false than any other language. I've used PL/1 quite
a bit in the past. I saw some truely stupid people pretending to be
great software people. I saw some truely BAD PL/1 software. I also saw
the opposite. 

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert I. Eachus]

In article <kdk9vs9cln.fsf@henning.camb> johndoe@zaphod.nosc.mil (Kirk Beitz) writes:

  > after reading the failure analysis, it seems a little
  > irresponsible to even hint about the failure of the rocket being
  > based solely on the lack of proper exception handling.

   One way of looking at the failure is that:

   1.  The software detected an out-of-range condition on horizontal
       velocity. 

   2.  The exception handler for this condition regarded it as a
       non-survivable hardware failure, and proceed to save failure
       data to help in the crash analysis.

   3.  The diagnostic data was regarded as valid navigational input...

   (Sounds preposterous, but read the report!)

   The first two are not obviously broken in isolation--in the Ariane
   4 the software was designed for, that high a horizontal velocity
   early in the fligh would be either a bogus reading or a severe
   hardware failure.  Point three, of course, is only acceptable if it
   can only occur AFTER catastrophic failure.

   But if your read the report, several levels of management reviewed
and agreed to 1 and 2.  So the software functioned correctly, if you
regard correctly as adherence to specifications.  If you want more for
your money, the reason that several levels of management looked at
points one and two was that, in Ada, it was obvious that there were
potential problems here.  Management literally decided that item 1
could never happen, and that the diagnostic information was "that
important."

    So the exception was handled exactly as management wanted, even
after being asked, "Are you sure?"

    To be fair, the managers asked about the out of range horizontal
velocity check answered correctly in the context the question was
asked.  And the software designers never knew to reraise the issue,
since they never saw the Ariane 5 flight profile data.  The managers
who goofed were the ones who decided to use the same software on
Ariane 4 and 5 without doing any checks against the new requirements.
That is NO checks as in no specification reviews, no code review and
no testing.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Jon S Anthony]

In article <4vjea6$gj7@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

> 	jsa@alexandria (Jon S Anthony) writes:
> 
> 	>In article <4vgkt1$s2v@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 
> 	>His standard idiotic rubbish and
> 
> 	>> ---Not really, when people have to ask how to do 
> 	>> a square root [in Ada].
> 
> 	>1. Go to readily available online hypertext ARM.
> 
> 	>2. Click on index
> 
> 	>3. Click on S, get
> 	>...
> 	>Sqrt 
> 	>       A.5.1(4), B.1(51), G.1.2(3)
> 	>...
> 	>4. Click on first entry and get full signature and semantics of operation.
> 
> 	>Total time to information: 10 seconds.  Duh!
> 
> 	>Do you have any idea how stupid and petty this makes you look?????
> 
> ---It doesn't make me look silly because I didn't ask
> the question.  I was pointing out the problems people
> have in writing codes in that language.  Do you have
> a problem with that?

You're becoming beyond hope.  It's not the asking of such a question
that is in any way wrong.  Its your pathetic implication that the need
to ask such a question somehow indicates that the language is "not as
good" as PL/I.

People have to ask this sort of question for ANY language - including
PL/I.  Are you saying that you magically know all this stuff for PL/I
just because your using it????  No way.  Your continual idiotic rants
in this thread have once again shown you to be a fool who's not to be
taken seriously.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

	jsa@alexandria (Jon S Anthony) writes:

	>It's not the asking of such a question
	>that is in any way wrong.  Its the implication that the need
	>to ask such a question somehow indicates that the language is "not as
	>good" as PL/I.

	>People have to ask this sort of question for ANY language

---not usually after reading the whole manual.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Jon S Anthony]

In article <4vgkt1$s2v@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

His standard idiotic rubbish and

> ---Not really, when people have to ask how to do 
> a square root [in Ada].

1. Go to readily available online hypertext ARM.

2. Click on index

3. Click on S, get
...
Sqrt 
       A.5.1(4), B.1(51), G.1.2(3)
...
4. Click on first entry and get full signature and semantics of operation.

Total time to information: 10 seconds.  Duh!

Do you have any idea how stupid and petty this makes you look?????


/Jon

BTW, the B entry shows you an example of pulling in the Fortran Sqrt
function and the G entry gives signature and semantics of the Complex
version...
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

	jsa@alexandria (Jon S Anthony) writes:

	>In article <4vgkt1$s2v@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

	>His standard idiotic rubbish and

	>> ---Not really, when people have to ask how to do 
	>> a square root [in Ada].

	>1. Go to readily available online hypertext ARM.

	>2. Click on index

	>3. Click on S, get
	>...
	>Sqrt 
	>       A.5.1(4), B.1(51), G.1.2(3)
	>...
	>4. Click on first entry and get full signature and semantics of operation.

	>Total time to information: 10 seconds.  Duh!

	>Do you have any idea how stupid and petty this makes you look?????

---It doesn't make me look silly because I didn't ask
the question.  I was pointing out the problems people
have in writing codes in that language.  Do you have
a problem with that?
_______________________________________

Newsgroups: comp.lang.ada
Subject: Re: How do I get the square root of a number?
Date: 30 Oct 1995 13:51:21 GMT
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

fyom@nova.umuc.edu (----) wrote:
>Hi!
>
>I have a simple question.  I am using a VAX ada compiler.  I would like
>to know what package I must include and what the operational syntax looks
>like for getting a square root of a number.
>
>I have searched my language manuals in vain.  I would greatly appreciate
>any help.
>
>Thanks!
>Francis Yom

_______________________________________

	>/Jon

	>BTW, the B entry shows you an example of pulling in the Fortran Sqrt
	>function and the G entry gives signature and semantics of the Complex
	>version...
	>Jon Anthony
	>Organon Motives, Inc.
	>1 Williston Road, Suite 4
	>Belmont, MA 02178
	>jsa@organon.com

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Richard A. O'Keefe]

rav@goanna.cs.rmit.edu.au (++           robin) writes:

>---It doesn't make me look silly because I didn't ask
>the question.  I was pointing out the problems people
>have in writing codes in that language.  Do you have
>a problem with that?

But people do NOT have a problem with using the square root in Ada.

	with Ada.Numerics.Elementary_Functions;
	use  Ada.Numerics.Elementary_Functions;

	... X := Sqrt(Y);			-- Ada

This is admittedly more verbose than

	#include <math.h>

	... X = sqrt(Y);			/* C */

which is again more verbose than

	... X := Sqrt(Y);			(* Pascal *)

but it's a price that need be paid but once at the top of a file.
In the last year I have frequently used Sqrt in Ada code and found it
to be no trouble at all.  At least with Gnat I don't have to worry
about that "-lm" nonsense you get in C.

>>I have a simple question.  I am using a VAX ada compiler.  I would like
                                          *******

There is the problem.  The questioner was using a compiler for Ada 83,
and was *not* looking in the right manuals, because DEC Ada provides
access to at least the core VMS libraries, which includes the MATH$
library.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

Richard A. O'Keefe wrote:
> 
> rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 
> 
> >>I have a simple question.  I am using a VAX ada compiler.  I would like
>                                           *******
> 
> There is the problem.  The questioner was using a compiler for Ada 83,
> and was *not* looking in the right manuals, because DEC Ada provides
> access to at least the core VMS libraries, which includes the MATH$
> library.

More specifically, see the "DEC Ada Run-Time Reference Manual for 
OpenVMS Systems." In the February 1995 release (DEC Ada version 3.2), 
the math library is noted in Appendix C. For history buffs, in the 
equivalent manual for VAX Ada version 2.0, dated May 1989, the math 
information is in Appendix B. So, it's not like this is a new feature in 
DEC Ada, although of course it was only formally defined in the Ada LRM 
with the advent of the current version of Ada (Ada 95).

> 
> --
> Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
> Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

	ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

	>rav@goanna.cs.rmit.edu.au (++           robin) writes:

	>>---It doesn't make me look silly because I didn't ask
	>>the question.  I was pointing out the problems people
	>>have in writing codes in that language.  Do you have
	>>a problem with that?

	>But people do NOT have a problem with using the square root in Ada.

---But they do, and did -- even after exploring the
manual -- or they wouldn't have to ask

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

++ robin wrote:
> 
>         ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> 
>         >rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 
>         >>---It doesn't make me look silly because I didn't ask
>         >>the question.  I was pointing out the problems people
>         >>have in writing codes in that language.  Do you have
>         >>a problem with that?
> 
>         >But people do NOT have a problem with using the square root in Ada.
> 
> ---But they do, and did -- even after exploring the
> manual -- or they wouldn't have to ask

Having worked at a user help desk in college, I received many questions
about how to do things in PL/I, even after students had attempted to
find the answer in the IBM PL/I manual. Boy, that PL/I must _really_
be a terrible language!

(In other words: this may be one of the top five silliest arguments
regarding the worth of a language ever presented on 
comp.lang._anything_!)

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Larry Kilgallen]

In article <3222E875.2E54@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:

> Having worked at a user help desk in college, I received many questions
> about how to do things in PL/I, even after students had attempted to
> find the answer in the IBM PL/I manual. Boy, that PL/I must _really_
> be a terrible language!
> 
> (In other words: this may be one of the top five silliest arguments
> regarding the worth of a language ever presented on 
> comp.lang._anything_!)

Sorry, Ken, but "Worth of a Language" is the Olympics of NetNews
bandwidth usage, and ability of a particular reader to understand
a particular vendor's manual just does not hold a candle to real
contenders like exactly which finger muscles must be exercised by
a particular poster to enter the assignment operator for a language.

Larry Kilgallen

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

Larry Kilgallen wrote:
> 
> In article <3222E875.2E54@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> 
> > Having worked at a user help desk in college, I received many questions
> > about how to do things in PL/I, even after students had attempted to
> > find the answer in the IBM PL/I manual. Boy, that PL/I must _really_
> > be a terrible language!
> >
> > (In other words: this may be one of the top five silliest arguments
> > regarding the worth of a language ever presented on
> > comp.lang._anything_!)
> 
> Sorry, Ken, but "Worth of a Language" is the Olympics of NetNews
> bandwidth usage, and ability of a particular reader to understand
> a particular vendor's manual just does not hold a candle to real
> contenders like exactly which finger muscles must be exercised by
> a particular poster to enter the assignment operator for a language.

Well, I did say it was in the top five, not the top _one_ ... :)
> 
> Larry Kilgallen

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

	>++ robin wrote:
	>> 
	>>         ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
	>> 
	>>         >rav@goanna.cs.rmit.edu.au (++           robin) writes:
	>> 
	>>         >>---I was pointing out the problems people
	>>         >>have in writing codes in that language.  Do you have
	>>         >>a problem with that?
	>> 
	>>         >But people do NOT have a problem with using the square root in Ada.
	>> 
	>> ---But they do, and did -- even after exploring the
	>> manual -- or they wouldn't have to ask

	>Having worked at a user help desk in college, I received many questions
	>about how to do things in PL/I, even after students had attempted to
	>find the answer in the IBM PL/I manual.

---We're not dealing with a student here, but an
adult....from NASA.  Please credit him with a bit of nous
in finding out the information.  If he could not find out
how to do it, then it's a problem, isn't it.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[David Weller]

(comp.lang.pl1 was dropped from folowups -- my newsposter says it's an
invalid language...er...newsgroup :-)

In article <505pto$bmr@goanna.cs.rmit.edu.au>,
++           robin <rav@goanna.cs.rmit.edu.au> wrote:
>---We're not dealing with a student here, but an
>adult....from NASA.  Please credit him with a bit of nous
>in finding out the information.  If he could not find out
>how to do it, then it's a problem, isn't it.

I'd say this thread has pretty much degenerated to namecalling and
speciousness...let me expand on that...

Let's get something straight: NASA sin't entirely populated with
rocket scientists.  It's staffed with students, engineers,
administrators, and technicians of various skill levels.  It is
ENTIRELY likely the original poster, 1) Was using the wrong manual
(Ada 83 instead of Ada 95), 2) Didn't want to bother looking it up in
the reference manual,  or 3) Was looking for additional help beyond the
fact that Sqrt obviously exists in the RM.  Never, in a million years,
would I presume, because one person had trouble finding "Sqrt" in
a comprehensive index, that a language was "in trouble".

You have made a horrendous leap of logic (several times, I might add),
and it's clear you insist on shaping your opinions as fact.  Please
drop this thread.  

(Then again, we haven't had a good "Internet Kook of
the Month" candidate since February :-)

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

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

++ robin wrote:
> 
>         Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> 
>         >++ robin wrote:
>         >>
>         >>         ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>         >>
>         >>         >rav@goanna.cs.rmit.edu.au (++           robin) writes:
>         >>
>         >>         >>---I was pointing out the problems people
>         >>         >>have in writing codes in that language.  Do you have
>         >>         >>a problem with that?
>         >>
>         >>         >But people do NOT have a problem with using the square root in Ada.
>         >>
>         >> ---But they do, and did -- even after exploring the
>         >> manual -- or they wouldn't have to ask
> 
>         >Having worked at a user help desk in college, I received many questions
>         >about how to do things in PL/I, even after students had attempted to
>         >find the answer in the IBM PL/I manual.
> 
> ---We're not dealing with a student here, but an
> adult....from NASA.  Please credit him with a bit of nous
> in finding out the information.  If he could not find out
> how to do it, then it's a problem, isn't it.

Ummm... I know several adults at NASA (one of them has been my best 
friend since junior high), and they can make the same boneheaded 
mistakes that any other student learning a new language can make. 
(Adults, even at NASA, are permitted to be students, by the way.) I 
build safety-critical software for the largest defense firm in the 
world, and I've certainly made my share of silly mistakes regarding Ada 
(read the archives of comp.lang.ada for a few :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Sandy McPherson]

Dear Ken and Robin,

Can't you guys get your own newsgroup, use email, the phone, or get
married or something. I used to be amused by your sometimes ungrounded
mutual accusations, however it is wearing a bit thin now. The Ariane 5
incident will go down Space Industry in history as the most spectacular
software failure so far. The reasons behind it are manifold, but I can't
remember the last time this thread mentioned Ariane 5.

I tended to think Robin was taking part in that well known (at least to
British, Aussies Kiwis etc.) activity of mug-baiting: you make an
outrageous statement wait for someone to take it seriously and then have
a good laugh watching them get wound up. However I'm not sure anymore.
If this is a real discussion, I think it is quite clear that neither of
you is going to win.

I don't think there has been one scrap of evidence to support Robin's
claims for divine superiority of homo PLIs, how can a NEW PL/I
programmer be any better than a NEW Ada programmer, does he download
experience from the manual? If Robin's point is reduced purely to
experience in the industry, then the the language become less important
as the number of years experience increases. Most people don't core dump
and forget their previous experience when they are required to use a new
language. Unfortunately there aren't many programmers around with
30+years of experience in any (programming?) language, who actually work
at the "coal face", so we will never know if the 50+ PL/I guys would
have done a better job than the 50+ Ada guys, but I think we could prove
that the 50+PL/Iers would do a better job than the usual bunch of 25-30
year olds who generally do the coding (and whose main ambition is to
stop coding as soon as possible, take up a management post and be able
to make the decisions which make the headllines).

I am not in a position to judge if the exception handling in PL/I is
better than that in Ada, I do object to this statement though:

++robin says:
---On the contrary, they do, because they have had more experience
in using the exception capabilities on a daily basis, not just
in dedicated real-time systems.

The very first Ada I wrote more than 8 years ago used the exception
capabilities and I have used it regularly since (but not on a daily
basis), I have also never used Ada in an embedded system, only on big
clunky machines with big clunky operating systems. There are certain
(non)features of Ada which had me pulling my hair out, but these seem to
have been fixed by Ada95- the exception handling wasn't one of them.

The only PL/I program I have seen was such a pile of garbage, (it was
more then 5000 lines long with no indentation no comments and no
sub-programs), it was an operational analysis tool which happened to
prove the invincibility of the air force, because the random number
generator was broken. Not even the cleverest of exception handling
capabilities would have been able to rescue pilots from the mess this
thing would have gotten them into. This does not lead me however to the
conclusion that PL/I is crap. IMO it is complete nonsense to trash Ada
(or any other language, including PL/I), simply because people make
stupid management/ design/ coding decisions, because we would quickly
have no languages left to use!!

It takes two to cause an argument, but only one to step out and stop it.
Would one of you please come to your senses and spare the rest of us.

Sandy

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

Sandy McPherson wrote:
> 
> Dear Ken and Robin,
> 
> Can't you guys get your own newsgroup, use email, the phone, or get
> married or something. I used to be amused by your sometimes ungrounded
> mutual accusations, however it is wearing a bit thin now. The Ariane 5
> incident will go down Space Industry in history as the most spectacular
> software failure so far. The reasons behind it are manifold, but I can't
> remember the last time this thread mentioned Ariane 5.

Your newsreader (or is it mine?) must be lagging. I've discontinued that thread.

The claim made by Robin in the thread (and then denied, and then re-stated) was
that the Ariane 5 incident would not have happened if PL/I programmers had been
used. I dsagreed with that point. Except for the curious wanderings into the
SQRT world, I've certainly tried to stay on that point.

> I tended to think Robin was taking part in that well known (at least to
> British, Aussies Kiwis etc.) activity of mug-baiting: you make an
> outrageous statement wait for someone to take it seriously and then have
> a good laugh watching them get wound up. However I'm not sure anymore.
> If this is a real discussion, I think it is quite clear that neither of
> you is going to win.

I've stated more that once that I think Robin is just doing this for a laugh,
although I have received some e-mail from others that claims he's completely
serious.

> I don't think there has been one scrap of evidence to support Robin's
> claims for divine superiority of homo PLIs, how can a NEW PL/I
> programmer be any better than a NEW Ada programmer, does he download
> experience from the manual?

I agree. 

> If Robin's point is reduced purely to
> experience in the industry, then the the language become less important
> as the number of years experience increases. Most people don't core dump
> and forget their previous experience when they are required to use a new
> language. Unfortunately there aren't many programmers around with
> 30+years of experience in any (programming?) language, who actually work
> at the "coal face", so we will never know if the 50+ PL/I guys would
> have done a better job than the 50+ Ada guys, but I think we could prove
> that the 50+PL/Iers would do a better job than the usual bunch of 25-30
> year olds who generally do the coding (and whose main ambition is to
> stop coding as soon as possible, take up a management post and be able
> to make the decisions which make the headllines).

That's a fair point, but I would also say that a 50+ programmer who has not been
developing real-time operational flight programs might not be able to beat
a 30-year old who has spent five years in that field. "Experience" has to be
quantified not just in years, but in terms of the type of experience. Even
within the real-time domain, the kind of experience gained in development of
automated banking systems might not be fully transferable to a safety-critical
embedded application, for example.

I knew that PL/I is used in real-time applications, but I didn't think that it
had been used much for embedded real-time safety critical flight applications.
(If someone knows of any recent projects where PL/I has been used in this domain,
I'll gladly be corrected). Ada, on the other hand, does get used in this domain,
both in the military and commercial world. So, if I was building the Ariane 5
inertial reference system, and the only question I could ask was: "Are you more
familiar with Ada or PL/I?", I'd go with the Ada programmer. Of course, in real
life, that's not the most important question.

> 
> I am not in a position to judge if the exception handling in PL/I is
> better than that in Ada, I do object to this statement though:
> 
> ++robin says:
> ---On the contrary, they do, because they have had more experience
> in using the exception capabilities on a daily basis, not just
> in dedicated real-time systems.
> 
> The very first Ada I wrote more than 8 years ago used the exception
> capabilities and I have used it regularly since (but not on a daily
> basis), I have also never used Ada in an embedded system, only on big
> clunky machines with big clunky operating systems. There are certain
> (non)features of Ada which had me pulling my hair out, but these seem to
> have been fixed by Ada95- the exception handling wasn't one of them.
> 
> The only PL/I program I have seen was such a pile of garbage, (it was
> more then 5000 lines long with no indentation no comments and no
> sub-programs), it was an operational analysis tool which happened to
> prove the invincibility of the air force, because the random number
> generator was broken. Not even the cleverest of exception handling
> capabilities would have been able to rescue pilots from the mess this
> thing would have gotten them into. This does not lead me however to the
> conclusion that PL/I is crap. IMO it is complete nonsense to trash Ada
> (or any other language, including PL/I), simply because people make
> stupid management/ design/ coding decisions, because we would quickly
> have no languages left to use!!

I've seen (and, I think, written) good PL/I programs, and have seen (and
probably written) poor Ada programs. I think we're in total agreement on
this point: there's no magic here. I happen to think Ada is well-designed
for what I use it for, but I am painfully aware that programmers, even
experienced programmers, can make mistakes in any language. 

> It takes two to cause an argument, but only one to step out and stop it.
> Would one of you please come to your senses and spare the rest of us.

See my last post to Robin.

> 
> Sandy

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Jon S Anthony]

In article <505pto$bmr@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

> 	Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> 
> 	>++ robin wrote:
> 	>> 
> 	>>         ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> 	>> 
> 	>>         >rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 	>> 
> 	>>         >>---I was pointing out the problems people
> 	>>         >>have in writing codes in that language.  Do you have
> 	>>         >>a problem with that?
> 	>> 
> 	>>         >But people do NOT have a problem with using the square root in Ada.
> 	>> 
> 	>> ---But they do, and did -- even after exploring the
> 	>> manual -- or they wouldn't have to ask
> 
> 	>Having worked at a user help desk in college, I received many questions
> 	>about how to do things in PL/I, even after students had attempted to
> 	>find the answer in the IBM PL/I manual.
> 
> ---We're not dealing with a student here, but an
> adult....from NASA.  Please credit him with a bit of nous

Irrelevant.


> in finding out the information.  If he could not find out
> how to do it, then it's a problem, isn't it.

No.  And in case you still have your fingers in your ears and are still
humming real loud, NO!!!


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

++ robin wrote:
> 
> ---It doesn't make me look silly because I didn't ask
> the question.  I was pointing out the problems people
> have in writing codes in that language.  Do you have
> a problem with that?
> _______________________________________
> 
> Newsgroups: comp.lang.ada
> Subject: Re: How do I get the square root of a number?
> >Hi!
> >
> >I have a simple question.  I am using a VAX ada compiler.  I would like
> >to know what package I must include and what the operational syntax looks
> >like for getting a square root of a number.
> >
> >I have searched my language manuals in vain.  I would greatly appreciate
> >any help.

Given that this information _is_ in the VAX Ada language manual (and has been 
for all of this decade, and then some), yes, I have a problem with using a
user question to somehow indicate there's something wrong with the Ada 
language.

And yes, it does make you look silly to try to use it in this manner.

How's that list of real-time flight systems written in PL/I progressing?

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Dave Jones]

Ken,

On Mon, 26 Aug 1996, Ken Garlington wrote:

> 
> How's that list of real-time flight systems written in PL/I progressing?
>
   
    It's not a flight system, of course (unless you count the times I've
loaded up my P/390 box on an airliner and used it for work...:-)), but
my company has been quite successful in using PL/I to develop and
market a line of VM/ESA performance monitor analysis and reporting tools.
The data capture part *has* to be able to respond within a fixed amount
of time whenever CP has more monitor data to be processed (and if it
isn't, it's overwritten by the next interval's data), and it can't hog
the entire CPU doing it, either. Most sites don't want to see their
performance monitor as one of the top consumers of cycles....:-) We use
PL/I as the primary development language and we've had a very good track
record in the market. It provides all of the tools we need to be able
to capture the data, reduce it to a manageable subset (a lot of floating
point work here), and output to files for further analysis *very quickly*.

  Many VM sites use the data in the CP monitor for a wide variety of
tasks and cannot afford to lose even a very small amount of it do to
any failures in the data collect and reporting systems. PL/I provides us
with the necessary features to make our software robust and fail-soft;
when things do get out of hand, we're able to note what the problem is,
(and, in many cases, gracefully recover from it), alert the operators,
and continue in some manner. To our customers, taking a CP dump and 
terminating is simply unacceptable. 

   Does, this mean that PL/I is "better than" Ada, or C, or Fortran, or
....? No, of course not, it just means that when used in an appropreate
manner in an environment it was designed for, it's a very good choice
for a serious development language. We'd gain nothing by switching
languages for this kind of work in this type of environment. I think that
this is also true of a large number of other sites that currently use PL/I
now as  well. 

Dave Jones
Velocity Software
Houston, TX 
 
> -- 
> LMTAS - "Our Brand Means Quality"
> 
> 

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

Dave Jones wrote:
> 
> Ken,
> 
> On Mon, 26 Aug 1996, Ken Garlington wrote:
> 
> >
> > How's that list of real-time flight systems written in PL/I progressing?
> >
> 
>     It's not a flight system, of course (unless you count the times I've
> loaded up my P/390 box on an airliner and used it for work...:-)), but
> my company has been quite successful in using PL/I to develop and
> market a line of VM/ESA performance monitor analysis and reporting tools.
[snip]
> 
>    Does, this mean that PL/I is "better than" Ada, or C, or Fortran, or
> ....? No, of course not, it just means that when used in an appropreate
> manner in an environment it was designed for, it's a very good choice
> for a serious development language.

No argument there. I've used PL/I very successfully myself (although, oddly
enough, I never used PL/I while working at IBM!). However, real-time systems
such as you describe are very different than real-time embedded flight
systems. It is completely absurd to claim that someone, knowing PL/I (or
any language, for that matter) somehow is an expert in the real-time embedded
flight system environment. It is even more absurb to make such claims if the
language isn't routinely used in that environment. Of course, given the other
bizarre statements by ++robin (Ada is bad because it doesn't have exception
mechanisms, Ada is bad because someone once asked how to do a square root
operation, etc. etc.) I have to believe it's all a put-on on his part. Anything
for a laugh, eh?
-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

        In comp.lang.pl1 you write:

        >I've used PL/I very successfully myself (although, oddly
        >enough, I never used PL/I while working at IBM!). However, real-time systems
        >such as you describe are very different than real-time embedded flight
        >systems. It is completely absurd to claim that someone, knowing PL/I (or
        >any language, for that matter) somehow is an expert in the real-time embedded
        >flight system environment. It is even more absurb to make such claims if the
        >language isn't routinely used in that environment. Of course, given the other
        >bizarre statements by ++robin (Ada is bad because it doesn't have exception
        >mechanisms,

---Are you just making this up?

   If you read the postings, you will find that I
never made such a silly statement.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Ken Garlington]

++ robin wrote:
> 
>         In comp.lang.pl1 you write:
> 
>         >I've used PL/I very successfully myself (although, oddly
>         >enough, I never used PL/I while working at IBM!). However, real-time systems
>         >such as you describe are very different than real-time embedded flight
>         >systems. It is completely absurd to claim that someone, knowing PL/I (or
>         >any language, for that matter) somehow is an expert in the real-time embedded
>         >flight system environment. It is even more absurb to make such claims if the
>         >language isn't routinely used in that environment. Of course, given the other
>         >bizarre statements by ++robin (Ada is bad because it doesn't have exception
>         >mechanisms,
> 
> ---Are you just making this up?

No.

> 
>    If you read the postings, you will find that I
> never made such a silly statement.

I'm glad we now both agree that PL/I programmers don't have any special advantage over
Ada programmers with respect to the use of exception handling mechanisms, and that
PL/I has no special advantage over Ada in this regard. Thank you.

-- 
LMTAS - "Our Brand Means Quality"

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

        >++ robin wrote:
        >>
        >>         In comp.lang.pl1 you write:
        >>
        >>         >I've used PL/I very successfully myself (although, oddly
        >>         >enough, I never used PL/I while working at IBM!). However, real-time systems
        >>         >such as you describe are very different than real-time embedded flight
        >>         >systems. It is completely absurd to claim that someone, knowing PL/I (or
        >>         >any language, for that matter) somehow is an expert in the real-time embedded
        >>         >flight system environment. It is even more absurb to make such claims if the
        >>         >language isn't routinely used in that environment. Of course, given the other
        >>         >bizarre statements by ++robin (Ada is bad because it doesn't have exception
        >>         >mechanisms,
        >>
        >> ---Are you just making this up?

        >No.

---Well, it seems that you are, because I didn't say that.

	>>    If you read the postings, you will find that I
	>> never made such a silly statement.

	>I'm glad we now both agree that PL/I programmers
	>don't have any special advantage over
	>Ada programmers with respect to the use of exception
	>handling mechanisms,

---On the contrary, they do, because they have had more experience
in using the exception capabilities on a daily basis, not just
in dedicated real-time systems.  Exception handling has been
available in PL/I from 1966, and has been routinely used in
commercial and scientific programs, as well as, of course,
real-time systems.

	 and that
	>PL/I has no special advantage over Ada in this regard. Thank you.

---The PL/I exception and recovery capabilities are, in general,
superior to those of Ada.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Merlin Dorfman]

     I haven't been reading this newsgroup recently, so this question may
already have been discussed.
     From what I have read (e.g., the current Aviation Week), the Ariane
problem would have been disclosed by running a simulation of the launch
trajectory, either software-only (in a stand-alone computer) or hardware
in the loop.  The failure would occur every time in such a simulation.  
     I am quite sure that the Atlas, Titan, Shuttle, etc. launches
are subject to such a full simulation.  I find it hard to believe that
Ariane does not do this.  Can anyone enlighten me as to whether such
simulations are not run, or why they did not disclose the problem?
                                      Merlin Dorfman
                                      DORFMAN@NETCOM.COM

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[John McCabe]

dorfman@netcom.com (Merlin Dorfman) wrote:

>     I haven't been reading this newsgroup recently, so this question may
>already have been discussed.
>     From what I have read (e.g., the current Aviation Week), the Ariane
>problem would have been disclosed by running a simulation of the launch
>trajectory, either software-only (in a stand-alone computer) or hardware
>in the loop.  The failure would occur every time in such a simulation.  
>     I am quite sure that the Atlas, Titan, Shuttle, etc. launches
>are subject to such a full simulation.  I find it hard to believe that
>Ariane does not do this.  Can anyone enlighten me as to whether such
>simulations are not run, or why they did not disclose the problem?

It is incredibly difficult to believe, but its true. The full report
(the address of which is mentioned somewhere else in this thread)
mentions that the trajectory information wasn't even provided in the
requirements or rather, that it was agreed not to include it!




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

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[++ robin]

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

	>++ robin wrote:
	>> 
	>> I was pointing out the problems people
	>> have in writing codes in that language.  Do you have
	>> a problem with that?
	>> _______________________________________
	>> 
	>> Newsgroups: comp.lang.ada
	>> Subject: Re: How do I get the square root of a number?
	>> >Hi!
	>> >
	>> >I have a simple question.  I am using a VAX ada compiler.  I would like
	>> >to know what package I must include and what the operational syntax looks
	>> >like for getting a square root of a number.
	>> >
	>> >I have searched my language manuals in vain.  I would greatly appreciate
	>> >any help.

	>Given that this information _is_ in the VAX Ada language manual (and has been 
	>for all of this decade, and then some), yes, I have a problem with using a
	>user question to somehow indicate there's something wrong with the Ada 
	>language.

	>And yes, it does make you look silly to try to use it in this manner.

---It does?  We're not dealing with a student here, but an
adult....from NASA.  Please credit him with a bit of nous
in finding out the information.  If he could not find out
how to do it, then it's a problem, isn't it.

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[John McCabe]

rav@goanna.cs.rmit.edu.au (++           robin) wrote:

<..snip..>
>---It does?  We're not dealing with a student here, but an
>adult....from NASA.  Please credit him with a bit of nous
>in finding out the information.  If he could not find out
>how to do it, then it's a problem, isn't it.

++robin,

Why don't you just give up on this pointless argument. You are the
only one ever to make a comment based on the Ariane failure that it
was a programming error. READ THE REPORT then go off and get a bit of
experience in the real-time embedded system world, and if you still
think it's a programming error, find a new career.


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

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Jon S Anthony]

In article <50o6c4$88g@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

> 	 and that
> 	>PL/I has no special advantage over Ada in this regard. Thank you.
> 
> ---The PL/I exception and recovery capabilities are, in general,
> superior to those of Ada.

Only in your weird twisted fantasies.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Multiple reasons for failure of Ariane 5 (was: Re: Ariane 5 - not an exception?)

[Robert Dewar]

In article <50o6c4$88g@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++
      robin) writes:

>        and that
>       >PL/I has no special advantage over Ada in this regard. Thank you.
>
> ---The PL/I exception and recovery capabilities are, in general,
> superior to those of Ada.

Well there have always been those who
argue for resumption semantics, as provided for
example in PL/I, instead of replacement semantics,
but I think that argument is largely decided in favor
of the replacement semantic model, which is very much
cleaner, both from a formal definition point of view
and from an implementation point of view. Ada 83 made this
choice over 15 years ago, and more recently C++ has made
the same assumption.

So the bottom line is that only a small minority would agree that
the PL/I model is superior at this stage. The PL/I model was of
course well known to both the Ada and C++ designers, and was
very conciously rejected as inferior.

Re: Ariane 5 - not an exception?

[JP Thornley]

In article: <Dv45EJ.8r@fsa.bris.ac.uk>  simonb@pact.srf.ac.uk (Simon 
Bluck) writes:
> 
> The Ariane 501 flight failure was due to the raising of an unexpected
> Ada exception, which was handled by switching off the computer.  The
> report on this:
> 
>    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> 
> is clear and hard-hitting: it will result in much improved software.
> But does it get right to the bottom of the issues, 

Don't know about that until I get to read the full report (the above 
reference is to a press release about the report).

                                               ...... and does the
> software community appreciate that there are fundamental software
> control problems which can directly give rise to such enormous
> failures, in this particular case thankfully without loss of life?

Yup - that's why we accept coding rates that we haven't seen since all 
input and output was in reverse binary (and I'm not sure that we get 
even that).


> [snip]
> Exceptions and assertions are both used, in Ada and C/C++, to detect
> software/hardware anomalies.  When one of these trips, it is
> frequently very difficult for the designer to know how best to handle
> the problem.  To continue may result in corrupt data; to abort is
> drastic but eliminates the possibility that further processing will
> compound the problem.
> 

That's why the *software* designer must not make these decisions.  Any 
action in response to an unexpected event (corrupt data, out-of-range 
values, etc) affects the *system* behaviour and must be known about at 
the system level, so that the consequences can be taken into account in 
the system safety case.

> The more checks you have, the more likely it is that one of them will
> trip.  If you can't think of good ways of handling these checks, the
> end result, for the user, may well be very much worse than if the
> check had never been performed in the first place.
> 

My experience is with systems where all the code is compiled with  
checks suppressed.  This allows us to strip out the exception handling 
code from the run-time (a substantial simplification) and put in exactly 
the checks we want exactly where we want them.  (But I am aware of 
differences in approach by other people).

> Of the two handling options, neither is really acceptable.  However,
> there is a third option which ought to be considered: to continue but
> mark the processed data as suspect.
> 

Simon then goes on to describe a way of dealing with data validities 
that unfortunately breaks the most fundamental rule of safety-critical 
code - Keep It Simple.  It's an idea that might work with 
mission-critical code, but the thought of implementing it for 
safety-critical code (remembering that any one of these systems is 
probably handling in the range 200-500 pieces of data - each with its 
associated data validity) is beyond anything that I know how to tackle.

(and I've just realised that each of these 'truth values' and the data 
type information will require their own data validities - this gets 
even more complicated than I first thought)

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Nigel Tzeng]

In article <285641259wnr@diphi.demon.co.uk>,
JP Thornley  <jpt@diphi.demon.co.uk> wrote:
>In article: <Dv45EJ.8r@fsa.bris.ac.uk>  simonb@pact.srf.ac.uk (Simon 
>Bluck) writes:

[snip] 

>> Of the two handling options, neither is really acceptable.  However,
>> there is a third option which ought to be considered: to continue but
>> mark the processed data as suspect.
>> 
>
>Simon then goes on to describe a way of dealing with data validities 
>that unfortunately breaks the most fundamental rule of safety-critical 
>code - Keep It Simple.  It's an idea that might work with 
>mission-critical code, but the thought of implementing it for 
>safety-critical code (remembering that any one of these systems is 
>probably handling in the range 200-500 pieces of data - each with its 
>associated data validity) is beyond anything that I know how to tackle.
>
>(and I've just realised that each of these 'truth values' and the data 
>type information will require their own data validities - this gets 
>even more complicated than I first thought)

Actually we do this all the time...on the ground.  Generating "truth
values" isn't very different (if I understand it correctly) from doing
limit checking and detection of stale data in the telemetry stream.

Now the primary caveat is that on the ground we have tons of CPU to
throw at the problem.  Not something you can do with a 1750A or even a
386.

Actually if you flag the data when an overflow exception is generated
it wont be too bad at all...hmmm...and it gives all downstream
processes visibility in which data point(s) went bad.  Not as good as
true limit checking but much much faster.

It would be annoying to shoehorn this into legacy code but if you're
doing something from scratch...you need a reasonably transparent way
of associating data points with truth values.  That could be as simple
as creating your own int and float classes.  I wont hazard a guess at
what performance hits you'd take though...and there are simpler ways
(already suggested elsewhere in this thread) to solve this particular
problem and it doesn't address the higher level problem of the
failover mechanism from primary to backup.

>Phil Thornley

Nigel

Re: Ariane 5 - not an exception?

[JP Thornley]

In article: <285641259wnr@diphi.demon.co.uk>  JP Thornley 
<jpt@diphi.demon.co.uk> writes:
> In article: <Dv45EJ.8r@fsa.bris.ac.uk>  simonb@pact.srf.ac.uk (Simon 
> Bluck) writes:
> > 
> > The Ariane 501 flight failure was due to the raising of an 
unexpected
> > Ada exception, which was handled by switching off the computer.  The
> > report on this:
> > 
> >    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> > 
> > is clear and hard-hitting: it will result in much improved software.
> > But does it get right to the bottom of the issues, 
> 
> Don't know about that until I get to read the full report (the above 
> reference is to a press release about the report).
> 

Ah well, goofed on that one - the printed report has no more info than 
the reference above.  

To me the big lesson is not the various technical issues, but the 
statement that "the view had been taken that software should be 
considered correct until it is shown to be at fault".  This seems quite 
amazing.

The report also describes the software as "mission critical", which in 
my terminology suggests a much lower dependability of software than 
safety-critical.  Even though there were no crew at risk I would have 
expected the enormous financial cost of a failure to push the software 
into the safety-critical area.

Phil Thornley
-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Ken Garlington]

JP Thornley wrote:
> 
> In article: <Dv45EJ.8r@fsa.bris.ac.uk>  simonb@pact.srf.ac.uk (Simon
> Bluck) writes:
> >
> > The Ariane 501 flight failure was due to the raising of an unexpected
> > Ada exception, which was handled by switching off the computer.  The
> > report on this:
> >
> >    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> >
> > is clear and hard-hitting: it will result in much improved software.
> > But does it get right to the bottom of the issues,
> 
> Don't know about that until I get to read the full report (the above
> reference is to a press release about the report).

There is a pointer to the full report at the bottom of the press release.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Robert I. Eachus]

In article <483202904wnr@diphi.demon.co.uk> JP Thornley <jpt@diphi.demon.co.uk> writes:

  > The report also describes the software as "mission critical", which in 
  > my terminology suggests a much lower dependability of software than 
  > safety-critical.  Even though there were no crew at risk I would have 
  > expected the enormous financial cost of a failure to push the software 
  > into the safety-critical area.

   First, I think of mission critical as a different category than
safety critical.  In safety critical systems, fail safe is often an
option where in mission critical systems you need to fail operational.
And yes, systems can be safety AND mission critical.  Those are the
expensive ones.

   Having said that, this software should have been classed exactly
that way, given the amount of miscellaneous missle parts that ended up
scattered over the launch site, and the possibility that a guidance
failure could put the missle anywhere in the world.



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ariane 5 - not an exception?

[JP Thornley]

In article: <EACHUS.96Jul30184744@spectre.mitre.org>  
eachus@spectre.mitre.org (Robert I. Eachus) writes:
>    First, I think of mission critical as a different category than
> safety critical.  In safety critical systems, fail safe is often an
> option where in mission critical systems you need to fail operational.

Hmmm, hadn't come across that distinction before, but it does seem to 
make sense in some cases.  But making fail operational a defining 
characteristic of mission critical systems seems a bit too strong - how 
many 'glass cockpit' aircraft have no backup suck and blow instruments 
to use when all the screens go blank?

> And yes, systems can be safety AND mission critical.  Those are the
> expensive ones.
> 

Again, in my terminology, the development standards for mission critical 
are wholly subsumed in those for safety-critical code, so classifying 
something both as no real effect on the software development methods 
used.

>    Having said that, this software should have been classed exactly
> that way, given the amount of miscellaneous missle parts that ended up
> scattered over the launch site, and the possibility that a guidance
> failure could put the missle anywhere in the world.
> 

As I read the report, the recommendation that "software should be 
assumed to be faulty until applying the currently accepted best practice 
methods can demonstrate that it is correct" is saying that if the system 
design is to be based on the assumption of correct software then they 
will have to build that software to safety-critical standards.  I wonder 
if they realise just how expensive that is going to be.

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Alan Brain]

JP Thornley <jpt@diphi.demon.co.uk> wrote:

>As I read the report, the recommendation that "software should be 
>assumed to be faulty until applying the currently accepted best practice 
>methods can demonstrate that it is correct" is saying that if the system 
>design is to be based on the assumption of correct software then they 
>will have to build that software to safety-critical standards.  I wonder 
>if they realise just how expensive that is going to be.

Umm. It appears I may have a small but critical difference of opinion here. IMHO 
safety-critical software _in particular_ should be assumed to be faulty, (perhaps) 
_even though_ shown to be correct.

To make an analogy, on one side you have "guarenteed impenetrable" armour plate, 
surrounding a fragile crystal glass. On the other, you have ballistic gelatine. I 
prefer the latter, as it keeps on working sorta, kinda, even though your basic 
assumptions re Immunity to Murphy may be incorrect.

I've seen error-_tolerance_ work very well in practice. The biggest problem is 
finding the bugs that exist, because the darn thing still works! Only careful 
examination of error logs reveals you're running at 5% efficiency, and encountering 
200 Software Detected Errors per second ( Real figures by the way ).
 

Re: Ariane 5 - not an exception?

[JP Thornley]

Alan Brain <aebrain@dynamite.com.au> writes:
> Umm. It appears I may have a small but critical difference of opinion 
here. IMHO 
> safety-critical software _in particular_ should be assumed to be 
faulty, (perhaps) 
> _even though_ shown to be correct.
> 

We definitely have a difference of opinion here - a software component 
of a system is classified as safety-critical if failure of that 
component *alone* creates a significant risk of the system suffering or 
causing a catastrophic accident.  If the system is designed so that the 
risk only becomes significant when both this software component and some 
other component of the system (wholly independent of this software 
component) fail, then the software is not safety-critical.

So, assuming that the software is faulty (which I take to mean 'can be 
expected to suffer a hazardous failure') results in an assumption that 
the catastrophic accident *will occur*.

My favorite example at the moment is the Flight Control System on the 
Boeing 777 - running on three separate and diverse boxes (I think that 
one is a 68K, another is a 486 and I can't remember the third) but all 
programmed from the same Ada source.  No single box is safety-critical, 
as there are two wholly independent back-ups, but the software clearly 
is.  An assumption that this software is faulty must lead to the 
conclusion that the plane should never be certified.

Clearly this isn't the case, and the software must have been created 
using a rigorous process that gives adequate assurance that it will not 
suffer a hazardous failure (and that's what I think the report means 
when it talks about "applying the currently accepted best practice 
methods" in order to "demonstrate that it is correct" ).

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Ken Garlington]

Robert I. Eachus wrote:
> 
>    First, I think of mission critical as a different category than
> safety critical.  In safety critical systems, fail safe is often an
> option where in mission critical systems you need to fail operational.
> And yes, systems can be safety AND mission critical.  Those are the
> expensive ones.

Actually, safety-critical systems can either be fail-safe or fail-op, just
like mission critical systems. A nuclear reactor might be able to be fail safe,
but a flight control system might have to be fail op.

You can get a lot of definitions of safety critical if you work at it.
Here's AFISC SSH 1-1's definition:

"Those software operations that, if not performed, performed out-of-sequence,
or performed incorrectly could result in improper control functions (or lack
of cotnrol functions required for proper system operation) which could
directly or indirectly cause or allow a hazardous condition to exist."

"Hazardous" usually gets defined as loss of life, serious injurity, or major
property loss.

If the absense of the software function doesn't lead to a hazardous condition,
then the system can be fail-safe. If the software function must be present to
avoid a hazardous condition, then it usually has to be fail-op. However, there's
not exactly a hard and fast rule here. It depends on the system.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Theodore E. Dennison]

Simon Bluck wrote:
> 
> It is most unfortunate, but must be accepted as true, that if the
> Ariane software had been written in a less powerful language the
> numeric overflow might have gone unnoticed, the computers would have
> remained switched on, and the rocket would have continued its upward
> flight.

If the Ariane software had been written in a less powerful language, 
the overflow might have gone unnoticed, while writing garbage in a 
nearby data/code location. This could easily have caused the exact
same result, with the important difference that the committe could
never have isolted the problem as well as they did.

> You _never_ switch off a computer, but you may have cause to mark all
> data emanating from it as suspect.  Leave it up to the users of the
> data to decide if they want to use it or not - they may have no
> choice.

Silly. If you _never_ switch over to the standby computer, there is
no point to having it, is there?

I could see the logic in rewriting the code on the backup machine
to try to continue with "best effort" data when an error is detected,
but I can't agree with the logic that the primary machine should 
continue to spit out data, even when it knows it has errors (and there
is a backup machine available), which is what the committe seems to
be suggesting.

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

Re: Ariane 5 - not an exception?

[Ken Garlington]

Theodore E. Dennison wrote:
> 
> I could see the logic in rewriting the code on the backup machine
> to try to continue with "best effort" data when an error is detected,
> but I can't agree with the logic that the primary machine should
> continue to spit out data, even when it knows it has errors (and there
> is a backup machine available), which is what the committe seems to
> be suggesting.

Note that this would require the backup computer to have different
software than the primary. That isn't the case now:

"There are two SRIs operating in parallel, with identical hardware and software.
One SRI is active and one is in "hot" stand-by, and if the OBC detects that the
active SRI has failed it immediately switches to the other one, provided that
this unit is functioning properly."

To keep the software identical in both, you would want both to attempt to
produce semi-valid data in the presence of errors. Having identical software
in both might be advantageous from an analysis standpoint.

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

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[++ robin]

	simonb@pact.srf.ac.uk (Simon Bluck) writes:

	>The Ariane 501 flight failure was due to the raising of an unexpected
	>Ada exception,

---An exception, yes, but not unexpected.

   The programming mistake made was in assuming that a
floating-point value of some 58 significant bits would
somehow "fit" into a 15-bit integer.

   There was no check that the data conversion would not
result in overflow, so the problem went to the error
handler, which shut down the system.

 	>which was handled by switching off the computer.  The
	>report on this:

	>   http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

	>is clear and hard-hitting: it will result in much improved software.
	>But does it get right to the bottom of the issues, and does the
	>software community appreciate that there are fundamental software
	>control problems which can directly give rise to such enormous
	>failures, in this particular case thankfully without loss of life?

	>It is most unfortunate, but must be accepted as true, that if the
	>Ariane software had been written in a less powerful language the
	>numeric overflow might have gone unnoticed, the computers would have
	>remained switched on, and the rocket would have continued its upward
	>flight.

	>Exceptions and assertions are both used, in Ada and C/C++,

---and PL/I

	>to detect
	>software/hardware anomalies.  When one of these trips, it is
	>frequently very difficult for the designer to know how best to handle
	>the problem.

---Not in the case of a simple fixed-point overflow -- as was the
case with Ariane.  It is a fact that real-time programming
has been available in PL/I for some 30 years, and recovery
from errors is standard established practice.

	> To continue may result in corrupt data;

---To continue in this case probably would need the value to
be set to the maximum. And it wouldn't be corrupt data.

	>to abort is
	>drastic but eliminates the possibility that further processing will
	>compound the problem.

---What?  Here, the lack of further processing resulted in
destruction of the project!

	>The more checks you have, the more likely it is that one of them will
	>trip.  If you can't think of good ways of handling these checks, the
	>end result, for the user, may well be very much worse than if the
	>check had never been performed in the first place.

	>Of the two handling options, neither is really acceptable.  However,
	>there is a third option which ought to be considered: to continue but
	>mark the processed data as suspect.

There are other better approaches.  One is to continue
with the maximum value; another is to avoid the use of
a 16-bit variable, and to use a variable as the same
size and type (here floating-point storage),
thus avoiding the problem altogether.

	>I.e. each data item would have a truth value of 1.0 for good data,
	>0.0 for absolutely rotten data, utilising values in between if you
	>have some idea how good the data is.  If you have numeric overflow,
	>you could set the data to the largest value available, and mark it as
	>suspect.

	>Any data further derived from suspect data must also be marked as
	>suspect.

	>Taking a probabilistic attitude to data would bring a lot of software
	>into the real world where failures can happen at all levels.  Using
	>this approach would made complex mission-critical software like the
	>failing Ariane software much easier to understand and control.  Data
	>would be processed along the same path regardless of whether it is
	>suspect or entirely valid.  Only the end-users of the data would be
	>affected, and where duplication of systems provides redundancy, the
	>algorithm would be to switch to the backup on receiving suspect data,
	>and switch back to the main source if the backup was suspect.

---In Ariane, both the active processor and the backup failed at
the same time, because it was a *programming* error that was
encountered at the same time in both processors, and both
processors were shut down at the same time by their respective
error handlers.

	>  If both sources are suspect, then take the least suspect source.  This
	>is simple and you don't lose your vital input data.  The data truth
	>values would be passed on from system to system along with the data.

	>You _never_ switch off a computer, but you may have cause to mark all
	>data emanating from it as suspect.  Leave it up to the users of the
	>data to decide if they want to use it or not - they may have no
	>choice.

---Indeed.

	>Along with the data truth attribute, you need a data type attribute.
	>This is tending to be relatively standard stuff now that objects are
	>around and need to know what kind of object they are.  But adding a
	>data type field is still something that designers skimp on if not
	>supplied by the language, relying instead on implicit coding of type
	>information in the senders and receivers of data.

	>Lack of type information accounts for why the Ariane flight control
	>was able to interpret diagnostic data as attitude data, virtually
	>guaranteeing catastrophic failure.  At least if attitude data had
	>been cut short it could have continued in a straight line.

---This is more of a lack of communication between the two
programs.  Another design error.

	>Well, those are what I think are the important lessons to be learned.

---I think the real lessons are that
1. real-time programming requires special expertise.
2. the choice of language is suspect.  A better-established
   language such as PL/I -- specifically designed for
   real-time programming -- with robust compilers, and
   with its base of experienced programming
   staff could well have prevented this disaster.

Re: Ariane 5 - not an exception?

[Bill Angel]

In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
++           robin <rav@goanna.cs.rmit.edu.au> wrote:
>In Ariane, both the active processor and the backup failed at
>the same time, because it was a *programming* error that was
>encountered at the same time in both processors, and both
>processors were shut down at the same time by their respective
>error handlers.

	I am under the impression that for the US manned spaceflight
program (to get to the moon) ,an on-board computer that was serving as a
backup to the primary computer would have been performing its computations
using completely different software than the primary computer. By
utilizing this methodology, the same software "glitch" would not halt both
systems simultaneously.  Perhaps a group of software developers could be
tasked with producing a version of the on-board software for Ariane in a
different computer language than that used by the primary processor. The
two processors, running simultaneously, would serve to check each other's
results with greater independence that they apparently do now.

 -- Bill Angel

Re: Ariane 5 - not an exception?

[Paul_Green]

In article <4tiu6e$kpm@news2.cais.com>, wtangel@cais3.cais.com (Bill Angel) 
writes:

>
>In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
>++           robin <rav@goanna.cs.rmit.edu.au> wrote:
>>In Ariane, both the active processor and the backup failed at
>>the same time, because it was a *programming* error that was
>>encountered at the same time in both processors, and both
>>processors were shut down at the same time by their respective
>>error handlers.
>
>	I am under the impression that for the US manned spaceflight
>program (to get to the moon) ,an on-board computer that was serving as a
>backup to the primary computer would have been performing its computations
>using completely different software than the primary computer. By
>utilizing this methodology, the same software "glitch" would not halt both
>systems simultaneously.  Perhaps a group of software developers could be
>tasked with producing a version of the on-board software for Ariane in a
>different computer language than that used by the primary processor. The
>two processors, running simultaneously, would serve to check each other's
>results with greater independence that they apparently do now.
>
> -- Bill Angel

Two doesn't do you much good. Who do you believe when they disagree? The 
fault-tolerant designs I'm aware of use at least 3 computers (so-called triple 
module redundancy). Stratus happens to use 4. The US space shuttle uses 5. 
There is no reason you can't use even more. Ever heard of the Byzantine 
Generals problem?  How does a group of generals make decisions based on the 
true consensus of the group despite the presence in their midst of a traitor.  
If you can solve this problem, you can build a fault-tolerant computer.

Last I knew, the shuttle had 4 computers programmed by one group and 1 computer 
programmed by a separate group. But this is so expensive to do that I think 
they only use this technique for the takeoff/landing phases. Even then, I 
suspect that the 5th computer is really there only in case the first 4 fail 
utterly. But perhaps someone who works on this can tell us for sure.


Paul Green                  | Mail: Paul_Green@stratus.com
Senior Technical Consultant | Voice: +1 508-460-2557 FAX: +1 508-460-0397
Stratus Computer, Inc.      | Video: PictureTel/AT&T by request.
Marlboro, MA 01752          | Disclaimer: I speak for myself, not Stratus.

Re: Ariane 5 - not an exception?

[Lloyd Fischer]

Bill Angel wrote:
> 
> In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
> ++           robin <rav@goanna.cs.rmit.edu.au> wrote:
> >In Ariane, both the active processor and the backup failed at
> >the same time, because it was a *programming* error that was
> >encountered at the same time in both processors, and both
> >processors were shut down at the same time by their respective
> >error handlers.
> 
>         I am under the impression that for the US manned spaceflight
> program (to get to the moon) ,an on-board computer that was serving as a
> backup to the primary computer would have been performing its computations
> using completely different software than the primary computer. By
> utilizing this methodology, the same software "glitch" would not halt both
> systems simultaneously.  Perhaps a group of software developers could be
> tasked with producing a version of the on-board software for Ariane in a
> different computer language than that used by the primary processor. The
> two processors, running simultaneously, would serve to check each other's
> results with greater independence that they apparently do now.
> 
>  -- Bill Angel
A better example is the flight control system for the A320 aircraft.
From memory now: there are 4 flight control computers, each controlling
separate hardware. The computers are of two types, with different
hardware and software. The designers of each type were completely
isolated from the designers of the other. The idea is that the computers
battle for control of the plane. If one computer generates completely
erroneous controls the other three can completely overpower it. If one,
two, or three die there is no problem. I can't recall if the computers
have the power to cause the shutdown of an offender and how the handled
the 2 vs. 2 problem.



If anyone has a spec for the A320 system please pipe in. I'm out of
aerospace now and can't just run down to the library.

IMHO the ariane, 4 and 5, with two computers running the same software
is a systemic error just waiting to happen. 
-- 
Lloyd Fischer  lloyd@dvcorp.com  fischer@crocker.com (home)  
DataViews Corporation                  |
47 Pleasant St, Northampton, MA 01060  | from disclaimers import
standard
Voice 413 586-4144 Fax 413 586-3805    |

Re: Ariane 5 - not an exception?

[Ken Garlington]

Bill Angel wrote:
> 
>         I am under the impression that for the US manned spaceflight
> program (to get to the moon) ,an on-board computer that was serving as a
> backup to the primary computer would have been performing its computations
> using completely different software than the primary computer. By
> utilizing this methodology, the same software "glitch" would not halt both
> systems simultaneously.  Perhaps a group of software developers could be
> tasked with producing a version of the on-board software for Ariane in a
> different computer language than that used by the primary processor. The
> two processors, running simultaneously, would serve to check each other's
> results with greater independence that they apparently do now.

The problem with N-version programming is the common mode requirements error.
See Dr. Levison's work, which fits my own experience. In this case, if both
systems had the same problems with throughput margins, and the same basic
information regarding the need to protect calculations were available to both
teams, the very likely would have chosen the same (wrong) design solution.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Nancy Mead]

In article <4tiu6e$kpm@news2.cais.com>, wtangel@cais3.cais.com (Bill Angel) writes:
|> 
|> In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
|> ++           robin <rav@goanna.cs.rmit.edu.au> wrote:
|> >In Ariane, both the active processor and the backup failed at
|> >the same time, because it was a *programming* error that was
|> >encountered at the same time in both processors, and both
|> >processors were shut down at the same time by their respective
|> >error handlers.
|> 
|> 	I am under the impression that for the US manned spaceflight
|> program (to get to the moon) ,an on-board computer that was serving as a
|> backup to the primary computer would have been performing its computations
|> using completely different software than the primary computer. By
|> utilizing this methodology, the same software "glitch" would not halt both
|> systems simultaneously.  Perhaps a group of software developers could be
|> tasked with producing a version of the on-board software for Ariane in a
|> different computer language than that used by the primary processor. The
|> two processors, running simultaneously, would serve to check each other's
|> results with greater independence that they apparently do now.
|> 
|>  -- Bill Angel

The Space Shuttle software has 4 computers running the same software, and
a 5th running different software (same function, different development team).
I'm not sure about the Apollo software, although I think there were some 
calculations that could be done on-board as well on the primary computer.

You may recall that one of the early shuttle launches was cancelled because
of a timing difference between the 4 computers and the single computer.  This
was indeed an intermittent software error that caused the problem, and the
glitch resulted in cancellation of the launch in that particular case.  Of
course, error recovery was a lot less sophisticated in those days, and
it was probably impossible to isolate the cause of the discrepancy in real
time and proceed with the launch.  

I was not one of the developers, but I was at IBM Federal Systems HQ at the
time, and IBM FSD was one of the development organizations.  I believe
Rockwell (the prime contractor) developed the software that ran on the single
computer, but it might have been another subcontractor.

Re: Ariane 5 - not an exception?

[Tucker Taft]

Nancy Mead (nrm@sei.cmu.edu) wrote:

: ...
: The Space Shuttle software has 4 computers running the same software, and
: a 5th running different software (same function, different development team).

This mode is only used during critical phases of a mission.  In other
phases, the "backup" computer may be used for independent activities.

: I'm not sure about the Apollo software, although I think there were some 
: calculations that could be done on-board as well on the primary computer.

: You may recall that one of the early shuttle launches was cancelled because
: of a timing difference between the 4 computers and the single computer.  

Not really.  It was a timing difference among the 4 computers running
identical software.  The timing difference was detected by the 5th ("backup")
computer, and it ordered the shut-down.

: ... This
: was indeed an intermittent software error that caused the problem, and the
: glitch resulted in cancellation of the launch in that particular case.  Of
: course, error recovery was a lot less sophisticated in those days, and
: it was probably impossible to isolate the cause of the discrepancy in real
: time and proceed with the launch.  

It was not trivial to determine the cause, and it is highly unlikely
it could have been determined in "real time," even using more "sophisticated"
error recovery.  The problem related to the fact that the computers were
started almost exactly on a clock tick, and 2 of the computers got
one time, and the other 2 got a time one tick later.

: I was not one of the developers, but I was at IBM Federal Systems HQ at the
: time, and IBM FSD was one of the development organizations.  I believe
: Rockwell (the prime contractor) developed the software that ran on the single
: computer, but it might have been another subcontractor.

The backup flight software was developed by Intermetrics, as a subcontractor
to Rockwell.

For what it is worth, the Space Shuttle software is developed in the
language Hal/S, which was also developed by Intermetrics ;-).

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Ariane 5 - not an exception?

[Steve O'Neill]

Nancy Mead wrote:
> I was not one of the developers, but I was at IBM Federal Systems HQ at the
> time, and IBM FSD was one of the development organizations.  I believe
> Rockwell (the prime contractor) developed the software that ran on the single
> computer, but it might have been another subcontractor.

I believe that the BFS software was written by Intermetrics.

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[root]

In article <DvEw7C.2K8.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes:

[BIG SNIP]

   For what it is worth, the Space Shuttle software is developed in the
   language Hal/S, which was also developed by Intermetrics ;-).

So what's that like then? Please give us your thoughts on comparisons
between it and Ada95 (a newish language I think you know something of
;-)

Chris Morgan

chris.morgan@baesema.co.uk

Re: Ariane 5 - not an exception?

[Tucker Taft]

Chris Morgan (chris.morgan@baesma.co.uk) wrote:
: In article <DvEw7C.2K8.0.-s@inmet.camb.inmet.com> 
: stt@henning.camb.inmet.com (Tucker Taft) writes:

: [BIG SNIP]

:    For what it is worth, the Space Shuttle software is developed in the
:    language Hal/S, which was also developed by Intermetrics ;-).

: So what's that like then? Please give us your thoughts on comparisons
: between it and Ada95 (a newish language I think you know something of
: ;-)

Hal/S is also a Pascal-based language.  It had prioritized 
multi-threading and synchronization primitives.  It also
had built-in support for matrix arithmetic, since this is used
heavily in navigation computations.  However, like Pascal, it
lacked any notion of "abstract data type," so it was not particularly
extensible via user-defined abstractions.  It was designed about
10 years before (the first) Ada.

: Chris Morgan

: chris.morgan@baesema.co.uk

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Ariane 5 - not an exception?

[Richard Shetron]

In article <4tiu6e$kpm@news2.cais.com>,
Bill Angel <wtangel@cais3.cais.com> wrote:
>
>In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
>++           robin <rav@goanna.cs.rmit.edu.au> wrote:
>>In Ariane, both the active processor and the backup failed at
>>the same time, because it was a *programming* error that was
>>encountered at the same time in both processors, and both
>>processors were shut down at the same time by their respective
>>error handlers.
>
>	I am under the impression that for the US manned spaceflight
>program (to get to the moon) ,an on-board computer that was serving as a
>backup to the primary computer would have been performing its computations
>using completely different software than the primary computer. By
>utilizing this methodology, the same software "glitch" would not halt both
>systems simultaneously.  Perhaps a group of software developers could be
>tasked with producing a version of the on-board software for Ariane in a
>different computer language than that used by the primary processor. The
>two processors, running simultaneously, would serve to check each other's
>results with greater independence that they apparently do now.

I've been told that the shuttle uses 5 computers with software developed
by 3 independent programming groups.  A best 2 out of 3 is used to
determine which software/hardware is operating properly.

Re: Ariane 5 - not an exception?

[++ robin]

	multics@wizvax.wizvax.net (Richard Shetron) writes:

	>In article <4tiu6e$kpm@news2.cais.com>,
	>Bill Angel <wtangel@cais3.cais.com> wrote:

	>>In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
	>>++           robin <rav@goanna.cs.rmit.edu.au> wrote:
	>>>In Ariane, both the active processor and the backup failed at
	>>>the same time, because it was a *programming* error that was
	>>>encountered at the same time in both processors, and both
	>>>processors were shut down at the same time by their respective
	>>>error handlers.

	>>	I am under the impression that for the US manned spaceflight
	>>program (to get to the moon) ,an on-board computer that was serving as a
	>>backup to the primary computer would have been performing its computations
	>>using completely different software than the primary computer. By
	>>utilizing this methodology, the same software "glitch" would not halt both
	>>systems simultaneously.  Perhaps a group of software developers could be
	>>tasked with producing a version of the on-board software for Ariane in a
	>>different computer language than that used by the primary processor. The
	>>two processors, running simultaneously, would serve to check each other's
	>>results with greater independence that they apparently do now.

	>I've been told that the shuttle uses 5 computers with software developed
	>by 3 independent programming groups.  A best 2 out of 3 is used to
	>determine which software/hardware is operating properly.

---Ariane's SRI computer (for processing sensor inputs)
had a backup running an identical program.  That's why
they both experienced the same fixed-point overflow in
the same place  at the same time, with the same data.
And that's why both shut down almost simultaneously.
(As you now know, any trivial error resulted in "sudden
death".  No room to maneuver.)

   The main computer (the OBC = On-Board Computer) also
had a backup.

   That's 4 computers.

   It's all in the report.

Re: Ariane 5 - not an exception?

[Bob Kurtz]

In article <4tiu6e$kpm@news2.cais.com>, wtangel@cais3.cais.com (Bill
Angel) wrote:

> In article <4t9vdg$jfb@goanna.cs.rmit.edu.au>,
> ++           robin <rav@goanna.cs.rmit.edu.au> wrote:
> >In Ariane, both the active processor and the backup failed at
> >the same time, because it was a *programming* error that was
> >encountered at the same time in both processors, and both
> >processors were shut down at the same time by their respective
> >error handlers.
> 
>         I am under the impression that for the US manned spaceflight
> program (to get to the moon) ,an on-board computer that was serving as a
> backup to the primary computer would have been performing its computations
> using completely different software than the primary computer. By
> utilizing this methodology, the same software "glitch" would not halt both
> systems simultaneously.  Perhaps a group of software developers could be
> tasked with producing a version of the on-board software for Ariane in a
> different computer language than that used by the primary processor. The
> two processors, running simultaneously, would serve to check each other's
> results with greater independence that they apparently do now.
> 
>  -- Bill Angel

A number of people have posted on this topic, about the space shuttle, the
A340, etc.  And I'll admit, there is some value (though expensive) to this
approach.  But...

Very frequently, errors are introduced into large software systems in the
requirements specification and design phases.  These are often problems
that dwarf mere coding errors, and are much more difficult to detect
("Gosh, it all passed unit testing okay...").  The Ariane 501 failure is,
in my opinion, an error of this type.  The root cause of the inertial
navigation system failure was the support for an Ariane 4 alignment
requirement not valid for Ariane 5, along with Ariane 4 trajectory
constraints also not valid for Ariane 5.

This sounds like a serious requirements/design oversight.  It's not clear
that having several developer teams working independently would not result
in two completely different programs that exhibit the same disasterous
behavior.

-- 
Bob Kurtz (kurtz@mustang.nrl.navy.mil)
Hughes STX Corp., US Naval Research Lab, Washington DC

Re: Ariane 5 - not an exception?

[Richard Riehle]

On 29 Jul 1996, Bill Angel wrote:

> 	I am under the impression that for the US manned spaceflight
> program (to get to the moon) ,an on-board computer that was serving as a
> backup to the primary computer would have been performing its computations
> using completely different software than the primary computer. By
> utilizing this methodology, the same software "glitch" would not halt both
> systems simultaneously.  Perhaps a group of software developers could be
> tasked with producing a version of the on-board software for Ariane in a
> different computer language than that used by the primary processor. The
> two processors, running simultaneously, would serve to check each other's
> results with greater independence that they apparently do now.

  I have been following this thread with interest.  I am no expert on
  Ariane, but lack of expertise has not an obstacle to others who have
  posted on this topic.

  1) redundant processors

     The idea of using different processor architectures is a good
     one and often employed for other systems such as the Boeing 777.
     However, if I recall correctly, Ariane has a "rad-hard" requirement
     (right or wrong) and uses Mil-Std 1750A processors to satisfy that
     requirement. This would not permit using multiple processors of
     differing architectures.

  2) Pl/I

     a) There is no Pl/I compiler for the 1750A

     b) Ada is far more suitable for safety-sensitive software than Pl/I

     c) This failure was not a language issue. It is a management issue.
        Specifically, it is a failure of engineering management.

     d) Given the incorrect specifications against which the program was
        designed, the same failure would have occurred in Pl/I or any
        other language.


  3) Turning off the Computer

     Not always an incorrect decision in embedded computing. This time
     it clearly was.

  4) Software Reuse

     If one intends to "reuse" software, such as Ariane 4xx software in
     Ariane 5xxx, in a significantly different architecture, there is some
     virtue in extensive testing.

  5) Unchecked Conversion

     Ada practitioners have been preaching for years that this should not
     be done without substantial examination and testing. One more example
     of why unchecked_conversion is usually not a good idea. Sometimes it
     is unavoidable, I know.

  6) Exception Handling

     Anyone remember C.A.R Hoare's Turing Lecture?

  7) Ada

     This is still the best language for doing this kind of system. But
     stupid management is something no programming language can change.
     Given other engineering constraints on this project, Ada is really
     the only reasonable language to choose.


   Richard Riehle

Re: Ariane 5 - not an exception?

[Fergus Henderson]

Richard Riehle <rriehle@nunic.nu.edu> writes:

>  5) Unchecked Conversion
>
>     Ada practitioners have been preaching for years that this should not
>     be done without substantial examination and testing. One more example
>     of why unchecked_conversion is usually not a good idea. Sometimes it
>     is unavoidable, I know.

I agree that in general unchecked_conversions should be avoided,
but Ariane 5 wasn't an example of unchecked_conversion going wrong,
in fact it was just the opposite, it was an example of a checked
conversion going wrong.  If the conversion had been unchecked,
then the rocket may not have crashed (indeed the problem may have
gone unnoticed).

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Ariane 5 - not an exception?

[Nigel Tzeng]

In article <Pine.GSO.3.92.960804145456.23377A-100000@nunic.nu.edu>,
Richard Riehle  <rriehle@nunic.nu.edu> wrote:
>On 29 Jul 1996, Bill Angel wrote:

[snip]

>  I have been following this thread with interest.  I am no expert on
>  Ariane, but lack of expertise has not an obstacle to others who have
>  posted on this topic.
>
>  1) redundant processors
>
>     The idea of using different processor architectures is a good
>     one and often employed for other systems such as the Boeing 777.
>     However, if I recall correctly, Ariane has a "rad-hard" requirement
>     (right or wrong) and uses Mil-Std 1750A processors to satisfy that
>     requirement. This would not permit using multiple processors of
>     differing architectures.

There are several space qual'd processors, including the 386.  We
flew one on SAMPEX and will also fly them on XTE and TRMM.  I think
the R3000 has also been flight qual'd for space (fairly sure there was
one on Clementine).  IIRC the 68K has been on a getaway special
although when I last looked it had not ever been flight qual'd.

And yeah...I'd say there's good reason to spec out rad tested components
for use on any launch vehicle or spacecraft.

(As an aside, SAMPEX did not use two different CPUs...SAMPEX was a
cheaper, faster, better NASA project that no one ever heard about.  It
was around 40 million as well and unlike Clementine isn't spinning
uselessly about.  I've worked for both NRL and NASA.  NRL Code 5100 is
as competent as NASA Code 700 in producing small inexpensive
satellites but NRL/BMDO's PR dept blows away NASA's PR dept).

[snip]

>  4) Software Reuse
>
>     If one intends to "reuse" software, such as Ariane 4xx software in
>     Ariane 5xxx, in a significantly different architecture, there is some
>     virtue in extensive testing.

Understatement.  Goddard regression tests the flight software between
releases much less between missions (ie TRMM and XTE are based on the
SAMPEX flt hw/sw) using their simulator to feed sensor data to the
actual flight s/w running on the engineering test unit boards and
later on the actual flight h/w itself during I&T.

Screw ups still happen. :)

>   Richard Riehle

Nigel

Re: Ariane 5 - not an exception?

[John McCabe]

nigel@access1.digex.net (Nigel Tzeng) wrote:

<..snip..>

>There are several space qual'd processors, including the 386.  We
>flew one on SAMPEX and will also fly them on XTE and TRMM.  I think
>the R3000 has also been flight qual'd for space (fairly sure there was
>one on Clementine).  IIRC the 68K has been on a getaway special
>although when I last looked it had not ever been flight qual'd.

Just a comment, but a US space qualified processor isn't necessarily
ESA space qualified. Apparently true ESA qualification requires more
extensive testing than the US requirement. Seems a bit stupid to me
personally but if ESA just accepted US space qualification testing and
methods then there'd be quite a few of them out of a job.

As a matter of interest, which 386 did you use? Was it the repackaged
SEI one?

<..snip..>

>[snip]

>>  4) Software Reuse
>>
>>     If one intends to "reuse" software, such as Ariane 4xx software in
>>     Ariane 5xxx, in a significantly different architecture, there is some
>>     virtue in extensive testing.

>Understatement.  Goddard regression tests the flight software between
>releases much less between missions (ie TRMM and XTE are based on the
>SAMPEX flt hw/sw) using their simulator to feed sensor data to the
>actual flight s/w running on the engineering test unit boards and
>later on the actual flight h/w itself during I&T.

>Screw ups still happen. :)

Yes, but if the SRIs on ARiane 5 had been tested (let alone regression
tested) using a reasonable simulator then it probably wouldn't have
been destroyed in the first place!

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

Re: Ariane 5 - not an exception?

[John McCabe]

Richard Riehle <rriehle@nunic.nu.edu> wrote:

<..snip..>

>  1) redundant processors

>     The idea of using different processor architectures is a good
>     one and often employed for other systems such as the Boeing 777.
>     However, if I recall correctly, Ariane has a "rad-hard" requirement
>     (right or wrong) and uses Mil-Std 1750A processors to satisfy that
>     requirement. This would not permit using multiple processors of
>     differing architectures.

As far as I know, from a much earlier post, Ariane 5 used 68000 series
processors. I don't see why it should have a rad-hard requirement, but
even then that should not enforce the use of MIL-STD-1750A processors,
as there are a number of alternatives e.g. 8086, RTX2010, and some
versions of the ADSP2100 are apparently rad-tolerant. Even if
MIL-STD-1750 processors were necessary, there is more than one
rad-hard version produced.

However, I don't really think that it is the processor architecture
itself that is a issue, more the system architecture as it is possible
to design completely differet systems round a single processor to do
the same job.

>  2) Pl/I

<..snip..>

>     c) This failure was not a language issue. It is a management issue.
>        Specifically, it is a failure of engineering management.

>     d) Given the incorrect specifications against which the program was
>        designed, the same failure would have occurred in Pl/I or any
>        other language.

Exactly.

>  3) Turning off the Computer

>     Not always an incorrect decision in embedded computing. This time
>     it clearly was.

It sounds to me like not enough analysis was performed to make a
reasonable judgement on whether computer shutdown was sensible in this
case. It obviously was not sensible in this case because there was a
comon-mode failure of both SRIs.

>  4) Software Reuse

>     If one intends to "reuse" software, such as Ariane 4xx software in
>     Ariane 5xxx, in a significantly different architecture, there is some
>     virtue in extensive testing.

Exactly. And even more virtue in correctly analysing and specifying
the requirements.

>  5) Unchecked Conversion

>     Ada practitioners have been preaching for years that this should not
>     be done without substantial examination and testing. One more example
>     of why unchecked_conversion is usually not a good idea. Sometimes it
>     is unavoidable, I know.

Mmm. Despite the language used in the report, I don't think it was the
Ada feature Unchecked_Conversion that was involved here, merely that a
conversion from float to integer was used. Unchecked_Conversion
wouldn't be used to convert a 64bit float into a 16bit integer by
anyone unless they were really stupid.

>  6) Exception Handling

>     Anyone remember C.A.R Hoare's Turing Lecture?

Not me. Any more information on it?

>  7) Ada

>     This is still the best language for doing this kind of system. But
>     stupid management is something no programming language can change.
>     Given other engineering constraints on this project, Ada is really
>     the only reasonable language to choose.

Or PL/I :-) Only joking!



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

Re: Ariane 5 - not an exception?

[++ robin]

	Richard Riehle <rriehle@nunic.nu.edu> writes:

	>On 29 Jul 1996, Bill Angel wrote:

	>> 	I am under the impression that for the US manned spaceflight
	>> program (to get to the moon) ,an on-board computer that was serving as a
	>> backup to the primary computer would have been performing its computations
	>> using completely different software than the primary computer. By
	>> utilizing this methodology, the same software "glitch" would not halt both
	>> systems simultaneously.  Perhaps a group of software developers could be
	>> tasked with producing a version of the on-board software for Ariane in a
	>> different computer language than that used by the primary processor. The
	>> two processors, running simultaneously, would serve to check each other's
	>> results with greater independence that they apparently do now.

	>  I have been following this thread with interest.  I am no expert on
	>  Ariane, but lack of expertise has not an obstacle to others who have
	>  posted on this topic.

	>  1) redundant processors

	>     The idea of using different processor architectures is a good
	>     one and often employed for other systems such as the Boeing 777.
	>     However, if I recall correctly, Ariane has a "rad-hard" requirement
	>     (right or wrong) and uses Mil-Std 1750A processors to satisfy that
	>     requirement. This would not permit using multiple processors of
	>     differing architectures.

	>  2) PL/I

	>     a) There is no PL/I compiler for the 1750A

---Not an obstacle.  How was an Ada compiler written for it?

	>     b) Ada is far more suitable for safety-sensitive software than Pl/I

---Nonsense.  PL/I has a long (30 years) record in
excellent real-time facilities, and with people with
experience in error-recovery and fail-soft in routine
commercial applications as well as real-time programming.

	>     c) This failure was not a language issue.

---Isn't it?  One of the arguments put forward was that
an Ada condition couldn't be raised and leave a trace,
and that it would be argued that there was no guarantee
whether a piece of code was executed.

   In PL/I, a SIGNAL statement (which can be used for
program checkout) leaves a printed record that it was
executed.  It gives a message that the condition was
raised, and comes with line numbers, etc.  There is
absolutely no doubt that the statement did not execute!

	> It is a management issue.
	>        Specifically, it is a failure of engineering management.

---There are lots of things for which one can blame 
management, but the lack of a check for overflow has
to come down to the programmer.

	>     d) Given the incorrect specifications against which the program was
	>        designed, the same failure would have occurred in PL/I or any
	>        other language.

---No it wouldn't.  The lack of a test for overflow was
the problem.  But even supposing for a moment that
all conversions were checked, then
an interrupt handler could be included for fixed-point
overflow.  This would have trapped any unchecked
overflow.  A R/T (and even non R/T) PL/I programmer
routinely puts in error control.

	>  3) Turning off the Computer

	>     Not always an incorrect decision in embedded computing. This time
	>     it clearly was.

	>  4) Software Reuse

	>     If one intends to "reuse" software, such as Ariane 4xx software in
	>     Ariane 5xxx, in a significantly different architecture, there is some
	>     virtue in extensive testing.

---In this case, with simulated inputs, and with SIGNAL
statements to check out what happens when an interrupt
occurs.  If this had been done (routine in PL/I), the
effect of an unchecked conversion would have been observed.

	>  5) Unchecked Conversion

	>     Ada practitioners have been preaching for years that this should not
	>     be done without substantial examination and testing. One more example
	>     of why unchecked_conversion is usually not a good idea. Sometimes it
	>     is unavoidable, I know.

	>  7) Ada

	>     This is still the best language for doing this kind of system.

---PL/I would be clearly better, as it meets the requirments
for audit trails in program and system checkout (in addition
to the other facilities that it offers).

	> But
	>     stupid management is something no programming language can change.
	>     Given other engineering constraints on this project, Ada is really
	>     the only reasonable language to choose.

---Scarcely convincing, in view of the failure.

	>   Richard Riehle

Re: Ariane 5 - not an exception?

[Ken Garlington]

++ robin wrote:
> 
>         >  2) PL/I
> 
>         >     a) There is no PL/I compiler for the 1750A
> 
> ---Not an obstacle.  How was an Ada compiler written for it?

I believe an existing one was purchased. I don't believe an Ada
compiler was written specifically for the Ariane SRI, as apparently
you are suggesting be done for PL/I. How would your argument about
mature PL/I compliers stand up in the face of a requirement to 
develop a brand-new compiler for a new target?

> 
>         >     b) Ada is far more suitable for safety-sensitive software than Pl/I
> 
> ---Nonsense.  PL/I has a long (30 years) record in
> excellent real-time facilities, and with people with
> experience in error-recovery and fail-soft in routine
> commercial applications as well as real-time programming.

It must be the lag in these newsgroups. I've posted more than one
request in comp.lang.pl1 for some examples of PL/I's use in safety-critical
real-time flight software, and narya a taker yet. I look forward to
some examples...

Perhaps those people are too busy building such software to read
the Internet?

>         >     c) This failure was not a language issue.
> 
> ---Isn't it?  One of the arguments put forward was that
> an Ada condition couldn't be raised and leave a trace,
> and that it would be argued that there was no guarantee
> whether a piece of code was executed.

That argument could be put forth, but of course it would be false.
We routinely trace Ada 83 exceptions in our debugging environments.
Ada 95 also adds a standardized capability to annotate exceptions with
user-defined information.

>    In PL/I, a SIGNAL statement (which can be used for
> program checkout) leaves a printed record that it was
> executed.  It gives a message that the condition was
> raised, and comes with line numbers, etc.  There is
> absolutely no doubt that the statement did not execute!

There is no SIGNAL statement in PL/I. In fact, PL/I has no
exception handling capabilities. (I figure, since ++robin can
continue to ignore the capabilities of Ada, why shouldn't we
ignore his claims as to the capabilities of PL/I)?

As a side issue: Could someone post the printer port address for the
Ariane SRI? Most of our IRSs don't have a printer attachment.
Must be something those experienced PL/I programmers demand be
added to the hardware... :)

> 
>         > But
>         >     stupid management is something no programming language can change.
>         >     Given other engineering constraints on this project, Ada is really
>         >     the only reasonable language to choose.
> 
> ---Scarcely convincing, in view of the failure.

Again, I would be more convinced of _your_ arguments if you would post some
of the flight software items you've developed in PL/I. For some reason,
this request keeps getting lost in the newsgroup. Until then, I think I'll
just enjoy the speculation...

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Kirk Bradley]

Why do you say that PL/I has no signalling facility. What do you
call ON units? how do they get triggered?  I'd say it for sure
has signalling 

In article <32106B34.57DB@lmtas.lmco.com>, Ken Garlington
<garlingtonke@lmtas.lmco.com> wrote:

> ++ robin wrote:
> > 
> >         >  2) PL/I
> > 
> >         >     a) There is no PL/I compiler for the 1750A
> > 
> > ---Not an obstacle.  How was an Ada compiler written for it?
> 
> I believe an existing one was purchased. I don't believe an Ada
> compiler was written specifically for the Ariane SRI, as apparently
> you are suggesting be done for PL/I. How would your argument about
> mature PL/I compliers stand up in the face of a requirement to 
> develop a brand-new compiler for a new target?
> 
> > 
> >         >     b) Ada is far more suitable for safety-sensitive
software than Pl/I
> > 
> > ---Nonsense.  PL/I has a long (30 years) record in
> > excellent real-time facilities, and with people with
> > experience in error-recovery and fail-soft in routine
> > commercial applications as well as real-time programming.
> 
> It must be the lag in these newsgroups. I've posted more than one
> request in comp.lang.pl1 for some examples of PL/I's use in safety-critical
> real-time flight software, and narya a taker yet. I look forward to
> some examples...
> 
> Perhaps those people are too busy building such software to read
> the Internet?
> 
> >         >     c) This failure was not a language issue.
> > 
> > ---Isn't it?  One of the arguments put forward was that
> > an Ada condition couldn't be raised and leave a trace,
> > and that it would be argued that there was no guarantee
> > whether a piece of code was executed.
> 
> That argument could be put forth, but of course it would be false.
> We routinely trace Ada 83 exceptions in our debugging environments.
> Ada 95 also adds a standardized capability to annotate exceptions with
> user-defined information.
> 
> >    In PL/I, a SIGNAL statement (which can be used for
> > program checkout) leaves a printed record that it was
> > executed.  It gives a message that the condition was
> > raised, and comes with line numbers, etc.  There is
> > absolutely no doubt that the statement did not execute!
> 
> There is no SIGNAL statement in PL/I. In fact, PL/I has no
> exception handling capabilities. (I figure, since ++robin can
> continue to ignore the capabilities of Ada, why shouldn't we
> ignore his claims as to the capabilities of PL/I)?
> 
> As a side issue: Could someone post the printer port address for the
> Ariane SRI? Most of our IRSs don't have a printer attachment.
> Must be something those experienced PL/I programmers demand be
> added to the hardware... :)
> 
> > 
> >         > But
> >         >     stupid management is something no programming language
can change.
> >         >     Given other engineering constraints on this project, Ada
is really
> >         >     the only reasonable language to choose.
> > 
> > ---Scarcely convincing, in view of the failure.
> 
> Again, I would be more convinced of _your_ arguments if you would post some
> of the flight software items you've developed in PL/I. For some reason,
> this request keeps getting lost in the newsgroup. Until then, I think I'll
> just enjoy the speculation...
> 
> -- 
> LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Ken Garlington]

Kirk Bradley wrote:
> 
> Why do you say that PL/I has no signalling facility. What do you
> call ON units? how do they get triggered?  I'd say it for sure
> has signalling

To repeat the explanation from the original post:

> > (I figure, since ++robin can
> > continue to ignore the capabilities of Ada, why shouldn't we
> > ignore his claims as to the capabilities of PL/I)?

Once the PL/I world realizes that there are other languages that
also have exception handling, I'll accept your statement. Otherwise,
why shouldn't _both_ newsgroups show ignorance of each other's language?

(In other words, would a ;) have helped here?)

-- 
LMTAS - "Our Brand Means Quality"

PL/I Versus Ada (Was: Arianne ...)

[Richard Riehle]

I changed the caption for the subject since this thread has
become more one of advocacy than issues related to Arianne.

1) I have heard a rumor that the first Alsys Ada compiler was
   written in PL/I. True or False?


2) If PL/I is so excellent, why was it rejected during the
   evaluation process that led to the development of Ada?  For
   that matter, why was C rejected?

3) I have heard that there is an object-oriented version of PL/I
   under development.  True or False?  When?


Language debates are almost always non-productive. But PL/I was
one of the first languages designed with many of the same goals we
attribute to Ada. Reflecting on PL/I in the context of those goals
might be useful in a better understanding of why we choose Ada rather
than PL/I for software that absolutely, positively must not fail.

Richard Riehle

Re: PL/I Versus Ada (Was: Arianne ...)

[Robert Dewar]

Richard Riehle asks

1) I have heard a rumor that the first Alsys Ada compiler was
   written in PL/I. True or False?

     False, the first version was written in Ada, the bootstrap was done
     using a translator that translated from a subset of Ada to a subset
     of PL/1 (which is what gave rise to rumour you heard). The PL/1
     translator was thrown away as soon as the compiler was bootstrapped.

Re: PL/I Versus Ada (Was: Arianne ...)

[Lon Amick]

Richard Riehle <rriehle@nunic.nu.edu> wrote:



>3) I have heard that there is an object-oriented version of PL/I
>   under development.  True or False?  When?

While not an answer to your question, there is an article on
object-oriented programming in PL/I by the SABRE Group.
They include a base class library and a class code generator
as well as several coding examples:
http://www.ionet.net/~mclapper/

Re: PL/I Versus Ada (Was: Arianne ...)

[Tim Dugan]

In article <Pine.GSO.3.92.960818165237.13803A-100000@nunic.nu.edu>,
Richard Riehle  <rriehle@nunic.nu.edu> wrote:
>
>[...]
>2) If PL/I is so excellent, why was it rejected during the
>   evaluation process that led to the development of Ada?  

Good question.  I guess there were reasons.  They probably underestimated
the costs involved ith going to a totally new language.  It might have been
good to impose the new features on PL/I and remove the bad ones.  It
could have been called PL/Ada! :)

Analogous to evolving from C to C++...

But perhaps this is also a government procurement problem.  Might this
have given an unfair advantage to those who already built PL/I
compilers?

> For that matter, why was C rejected?

Lots of reasons...but mostly the lack of type safety and threads,
I think.  C++ has "fixed" a lot of the problems, though.

-t
-- 

Tim Dugan
mailto:timd@ghgcorp.com
http://www.ghgcorp.com/timd

Re: PL/I Versus Ada (Was: Arianne ...)

[Lon D. Gowen, Ph.D.]

Richard Riehle wrote:
> 
> I changed the caption for the subject since this thread has
> become more one of advocacy than issues related to Arianne.
> 
> 1) I have heard a rumor that the first Alsys Ada compiler was
>    written in PL/I. True or False?
> 
> 2) If PL/I is so excellent, why was it rejected during the
>    evaluation process that led to the development of Ada?  For
>    that matter, why was C rejected?
> 
> 3) I have heard that there is an object-oriented version of PL/I
>    under development.  True or False?  When?
> 
> Language debates are almost always non-productive. But PL/I was
> one of the first languages designed with many of the same goals we
> attribute to Ada. Reflecting on PL/I in the context of those goals
> might be useful in a better understanding of why we choose Ada rather
> than PL/I for software that absolutely, positively must not fail.
> 
> Richard Riehle

Richard, thank you for changing the subject.  I agree that it needed
it!  I have no answers for your first question above, and someone
else has already answered your third question.  I am not sure what
you are after with your second question, but if it is referring to
why Ada and not PL/I, the answer is probably due to PL/I's weak
typing rules.  The PL/I language is very flexible, but one pays a
price for flexibility.  The same reasoning applies to the "C"
language as well.

Lon

-- 
Lon D. Gowen, Ph.D.
Phone:      (515) 223-8000 x217         Fax:  (515) 224-1352
e-mail:     gowen@microware.com         WWW:  www.microware.com
U.S. Mail:  Microware Systems Corporation
            Research & Development Department for Core Technologies
            1900 N.W. 114th Street
            Des Moines, IA 50325-7077

Disclaimer: All opinions are mine and not necessarily those of anyone else.

"Many 'real-life' errors are in fact easy to detect if one is careful to
determine whether a test run failed to execute properly."  --Joe W. Duran

Re: PL/I Versus Ada (Was: Arianne ...)

[Tony Konashenok]

In article <Pine.GSO.3.92.960818165237.13803A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:

|> 3) I have heard that there is an object-oriented version of PL/I
|>    under development.  True or False?  When?

What exactly is an "object-oriented version" of a language? Why is PL/I
not object-oriented? IMHO, one can do object-oriented programming even in
assembly language, given enough skill and dedication. Too many people are
confusing object-oriented programming as a method with the usage of
C++/Ada-specific features.

Tony Konashenok
Team PL/I

Re: PL/I Versus Ada (Was: Arianne ...)

[Richard Riehle]

On 21 Aug 1996, Tony Konashenok wrote:

> What exactly is an "object-oriented version" of a language? Why is PL/I
> not object-oriented? IMHO, one can do object-oriented programming even in
> assembly language, given enough skill and dedication. Too many people are
> confusing object-oriented programming as a method with the usage of
> C++/Ada-specific features.

  Well you may have your own idea of object-oriented programming.
  We usually think of encapsulated classes which support extensible
  inheritance, dynamic binding, and polymorphism.  We ordinarily do not
  consider the heroic efforts of a star programmer as being sufficient
  to implement the method.  There are specific, widely-accepted criteria
  for object-oriented programming which are not language-specific.
  So I will rephrase the question.

  Is there a version of PL/I which:

     1) has explicit syntactic support for extensible inheritance
        of encapsulated classes (i. e., supports Meyer's "open/closed
        principle") ?

     2) supports dynamic selection of class object based on run-time
        evaluation of class membership  (dynamic binding and
        polymorphism)?

     3) permits the definition of a type/class with hidden data
        structures that are visible only via their exported
        methods?  (a la "programming by contract")?

     4) allows the definition of "abstract classes" (deferred classes)
        for implementation, through extensible inheritance and
        polymorphism, of variants of that class.  This should include
        the capability for late binding?

   None of these characteristics are language-specific, but each is
   included in any language defined, by contemporary usage, as an
   object-oriented programming language.  How does PL/I compare?

   Richard Riehle

Re: PL/I Versus Ada (Was: Arianne ...)

[Lon D. Gowen, Ph.D.]

Richard Riehle wrote:
> 
> On 21 Aug 1996, Tony Konashenok wrote:
> 
> > What exactly is an "object-oriented version" of a language? Why is PL/I
> > not object-oriented? IMHO, one can do object-oriented programming even in
> > assembly language, given enough skill and dedication. Too many people are
> > confusing object-oriented programming as a method with the usage of
> > C++/Ada-specific features.
> 
>   Well you may have your own idea of object-oriented programming.
>   We usually think of encapsulated classes which support extensible
>   inheritance, dynamic binding, and polymorphism.  We ordinarily do not
>   consider the heroic efforts of a star programmer as being sufficient
>   to implement the method.  There are specific, widely-accepted criteria
>   for object-oriented programming which are not language-specific.
>   So I will rephrase the question.

Well, now that poor Tony is ducking arrows from Richard, allow me to take
a few arrows.  Tony is correct in a sense.  A coder can do OOP without
using an OOP language such as C++, Ada 95, etc. (see "Software Engineering"
by Ian Sommerville, which is a well-known text on SE ideas).  However,
using an OOP language does make the coding of an OOD easier.

The beginning of OOP came from SIMULA 67; however, no one ever made this
connection until Hoare did in 1972.  The basic tenants of OOP go back to
its originator SIMULA 67, and they basically focus around the ideas of
the "class construct," which allowed a person to keep a data structure
and its associated routines packaged together (i.e., data abstraction).
Unfortunately, SIMULA 67 did not have "information hiding" (i.e., the
inforcement of abstractions; or, put another way, multiple-access
paths to data types).

One of the big (supposed) benifits and one of the most important
components of OOD/OOP is this idea of data abstraction.  All languages
(even assembly languages) can support data abstraction (and, therefore,
functional abstraction too).  Additionally, there are various levels of
data abstraction (e.g., all high-level languages--HLLs--use simple data
abstractions such as their builtin abilities to manipulate integers,
reals, strings, etc.).

OOP uses the ideas of data abstraction; and data abstraction, by definition,
includes encapsulation (i.e., the ability to group data or operations into
separate syntactic containers), functional abstraction, and sometimes
information hiding.  There are various groups of OOPLs, which we can break
up into two main groups:  pure OOPLs (e.g., smalltalk and Eiffel) and
hybrid OOPLs (e.g., C++ and Ada 95).  Generally speaking, an OOPL has the
following "features":  data abstraction, inheritance, and a particular
type of dynamic binding (i.e., a kind of polymorphism).  The purpose of
inheritance is to facilitate the reuse of abstract data types (ADTs).  And,
reuse is supposedly beneficial to software development efforts.  Therefore,
the big attraction to OOP is through the supposed improvements of ADTs,
dynamic binding of requests, and inheritance.

The information above comes from Bob's book on programming languages
(see "Concepts of Programming Languages" by Robert W. Sebesta, third
edition).  By the way, Bob Sebesta currently chairs the computer science
department at the University of Colorado at Colorado Springs:  At least
he was still there when I had dinner with him this Spring.  As a side
not on this whole issue, Chapter 10 (on Abstract Data Types) of Bob's
book begins with a picture of George Radin, who (as the book states)
"was one of the principal designers of both the PL/I language and IBM's
first compiler for PL/I"--kind of ironic :-)

> 
>   Is there a version of PL/I which:
> 
>      1) has explicit syntactic support for extensible inheritance
>         of encapsulated classes (i. e., supports Meyer's "open/closed
>         principle") ?

You can implement inheritance in PL/I (see prior articles regarding a
white paper by Smedley and Smith).  Most (if not all) PL/I compilers,
however, do not come with the proper libraries to facilitate it.

> 
>      2) supports dynamic selection of class object based on run-time
>         evaluation of class membership  (dynamic binding and
>         polymorphism)?

You can also support dynamic binding in PL/I of just about anything
including classes.  Once again, see the white paper by Smedley and
Smith.  Remember, PL/I's pointers are untyped, which means extreme
flexibility (and usually a decrease in reliability).

> 
>      3) permits the definition of a type/class with hidden data
>         structures that are visible only via their exported
>         methods?  (a la "programming by contract")?

This concept is information hiding and not necessary to do OOP.  The main
benefit of IH is to keep programmers from gaining access to an item
without following the proper channels.  IH is a "big brother" (liberal)
concept that programming in general could live without.

> 
>      4) allows the definition of "abstract classes" (deferred classes)
>         for implementation, through extensible inheritance and
>         polymorphism, of variants of that class.  This should include
>         the capability for late binding?

Again, I see no problems here.  Once again, you would have to build in
the features yourself or borrow (or buy) the ideas from someone else.

> 
>    None of these characteristics are language-specific, but each is
>    included in any language defined, by contemporary usage, as an
>    object-oriented programming language.  How does PL/I compare?
> 
>    Richard Riehle

The designers of PL/I wanted it to cover everything, and it pretty
much fulfills their expectations.  Depending on how you view
things, PL/I does support OOP; however, you have to do a little
work beforehand to make life consistent and easy.

Lon

-- 
Lon D. Gowen, Ph.D.
Phone:      (515) 223-8000 x217         Fax:  (515) 224-1352
e-mail:     gowen@microware.com         WWW:  www.microware.com
U.S. Mail:  Microware Systems Corporation
            Research & Development Department for Core Technologies
            1900 N.W. 114th Street
            Des Moines, IA 50325-7077

Disclaimer: All opinions are mine and not necessarily those of anyone else.

"Only when we have built a similar system before is it easy to determine the
requirements in advance."  --David L. Parnas

Re: PL/I Versus Ada (Was: Arianne ...)

[Tony Konashenok]

In article <3225E4D3.6F5992E1@microware.com>, "Lon D. Gowen, Ph.D." <gowen@microware.com> writes
$! Richard Riehle wrote:
$! >   Well you may have your own idea of object-oriented programming.
$! >   We usually think of encapsulated classes which support extensible
$! >   inheritance, dynamic binding, and polymorphism.  We ordinarily do not
$! >   consider the heroic efforts of a star programmer as being sufficient
$! >   to implement the method.  There are specific, widely-accepted criteria
$! >   for object-oriented programming which are not language-specific.

$! A coder can do OOP without
$! using an OOP language such as C++, Ada 95, etc. (see "Software Engineering"
$! by Ian Sommerville, which is a well-known text on SE ideas).  However,
$! using an OOP language does make the coding of an OOD easier.

Exactly my point! See below.

!$ One of the big (supposed) benifits and one of the most important
$! components of OOD/OOP is this idea of data abstraction.  All languages
$! (even assembly languages) can support data abstraction (and, therefore,
$! functional abstraction too).  Additionally, there are various levels of
$! data abstraction (e.g., all high-level languages--HLLs--use simple data
$! abstractions such as their builtin abilities to manipulate integers,
$! reals, strings, etc.).

I would add to this that a human being (assuming that a programmer is
human) also has certain capabilities of data abstraction [s]he uses in
writing code, and it had better be matched by the programming language.
What I assert here is that PL/I has the abstraction capacities roughly
equivalent to those of human thinking; furthermore, it operates the same
syntactic categories as most humans. Therefore, it is very intuitive.
If you look at meta-languages used here and there to facilitate the
description of logic flow, most of them are very much like PL/I. Not Ada.
Not C++. Oh well, BNF is indeed closer to Ada, but hardly anyone uses
it for intuitive explanations.
Even if one needs greater degree of abstraction, it is always possible to
formulate this abstraction once using the traditional syntactic constructs,
include it in your code, and then reuse it as you please. Just like writing
your own macros in assembly code. PL/I, by the way, has certain features
to help implement object-orientation. GENERIC comes to mind.

$! OOP uses the ideas of data abstraction; and data abstraction, by definition,
$! includes encapsulation (i.e., the ability to group data or operations into
$! separate syntactic containers), functional abstraction, and sometimes
$! information hiding.  There are various groups of OOPLs, which we can break
$! up into two main groups:  pure OOPLs (e.g., smalltalk and Eiffel) and
$! hybrid OOPLs (e.g., C++ and Ada 95).  Generally speaking, an OOPL has the
$! following "features":  data abstraction, inheritance, and a particular
$! type of dynamic binding (i.e., a kind of polymorphism).  The purpose of
$! inheritance is to facilitate the reuse of abstract data types (ADTs).  And,
$! reuse is supposedly beneficial to software development efforts.  Therefore,
$! the big attraction to OOP is through the supposed improvements of ADTs,
$! dynamic binding of requests, and inheritance.

It is certainly true that object-oriented languages afford a greater freedom
of operation with abstract data types. However, excessive use of these does 
not contribute much to comprehensibility of the code. It is an unfortunate
trend in modern programming that writing code is delegated to less and less
qualified people, and many think that the goal is to make writing of code
as simple as it can possibly be. Therefore, many features being promoted are
often an umbrella for quick-and-dirty or, worse yet, too-sloppy-to-think-
it-over approach to coding. Mind you, I have nothing against quick programming
as long as it works, but way too often it leads to an outright hogging of
computing resources, in the style of "toss your old hardware" Windows 95.
Yes, hardware is becoming cheaper and faster, but I, for one, do not have
the money to plunk for a new Pentium. Sorry, I digress...

Tony "Assembler programmers drive stick shifts" Konashenok
Team PL/I

Re: PL/I Versus Ada (Was: Arianne ...)

[Adam Beneschan]

tonyk@sseos.lbl.gov (Tony Konashenok) writes:

 >I would add to this that a human being (assuming that a programmer is
 >human) also has certain capabilities of data abstraction [s]he uses in
 >writing code, and it had better be matched by the programming language.
 >What I assert here is that PL/I has the abstraction capacities roughly
 >equivalent to those of human thinking; furthermore, it operates the same
 >syntactic categories as most humans. Therefore, it is very intuitive.
 >If you look at meta-languages used here and there to facilitate the
 >description of logic flow, most of them are very much like PL/I. Not Ada.
 >Not C++. Oh well, BNF is indeed closer to Ada, but hardly anyone uses
 >it for intuitive explanations.
 >Even if one needs greater degree of abstraction, it is always possible to
 >formulate this abstraction once using the traditional syntactic constructs,
 >include it in your code, and then reuse it as you please. Just like writing
 >your own macros in assembly code. PL/I, by the way, has certain features
 >to help implement object-orientation. GENERIC comes to mind.

OK, now you've got me curious.  I looked a little at PL/I many years
ago, but I'm afraid the language may have changed too much in the last
15-20 years.  Could you explain in greater detail the assertions
you've just made?  In particular, I'd be interested to see:

(1) What the syntactic categories of PL/I are that correspond to human
    thinking, and how Ada falls short in that regard.

(2) What the abstraction capacities of PL/I are, and what about them
    makes them more equivalent to human thought than Ada constructs
    do. 

(3) How PL/I's GENERIC features facilitate object-orientation better
    than Ada's GENERIC features do.

(4) How Backus-Naur Form resembles Ada.

                                -- Adam

Re: PL/I Versus Ada (Was: Arianne ...)

[John McCabe]

Richard Riehle <rriehle@nunic.nu.edu> wrote:

>On 21 Aug 1996, Tony Konashenok wrote:

<..snip..>

I think that Tony is perhaps confusing Object Oriented Programming
with Object Oriented design. It is quite possible to map an object
oriented design onto a non-object oriented programming language but
then you find that you end up with a system that does not contain
either the advantages, simplicity (relatively speaking) or protection
that the features you mentioned in your article provide.





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

Re: PL/I Versus Ada (Was: Arianne ...)

[arbuckj]

In <Pine.GSO.3.92.960818165237.13803A-100000@nunic.nu.edu>, Richard Riehle <rriehle@nunic.nu.edu> writes:
>
>
>I changed the caption for the subject since this thread has
>become more one of advocacy than issues related to Arianne.
>snipped...
>2) If PL/I is so excellent, why was it rejected during the
>   evaluation process that led to the development of Ada?  For
>   that matter, why was C rejected?

If memory serves me correctly, one of the concerns during the evaluation 
period was that PL/I (and C and other languages) allowed you to shoot 
yourself in the foot to some extent.  The evaluators were looking to decrease
programming errors so the decision was made to create a new language with
more checks and restrictions, hence ADA was born (I not familar enough with 
ADA to say whether or not it met that goal).

>3) I have heard that there is an object-oriented version of PL/I
>   under development.  True or False?  When?
>
It is my understanding that this is true based on informal information at a session
in a conference I went to.

>snipped...
   
John Arbuckle
arbuckj@aa.wl.com

Re: Ariane 5 - not an exception?

[++ robin]

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

	>++ robin wrote:
	>>         >  2) PL/I
	>>         >     a) There is no PL/I compiler for the 1750A
	>> ---Not an obstacle.  How was an Ada compiler written for it?

	>I believe an existing one was purchased. I don't believe an Ada
	>compiler was written specifically for the Ariane SRI, as apparently
	>you are suggesting be done for PL/I. How would your argument about
	>mature PL/I compliers stand up in the face of a requirement to 
	>develop a brand-new compiler for a new target?

---This is a red herring.  The same could be said of the
Ada compiler when it was written.

Re: Ariane 5 - not an exception?

[Ken Garlington]

++ robin wrote:
> 
>         Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
> 
>         >++ robin wrote:
>         >>         >  2) PL/I
>         >>         >     a) There is no PL/I compiler for the 1750A
>         >> ---Not an obstacle.  How was an Ada compiler written for it?
> 
>         >I believe an existing one was purchased. I don't believe an Ada
>         >compiler was written specifically for the Ariane SRI, as apparently
>         >you are suggesting be done for PL/I. How would your argument about
>         >mature PL/I compliers stand up in the face of a requirement to
>         >develop a brand-new compiler for a new target?
> 
> ---This is a red herring.  The same could be said of the
> Ada compiler when it was written.

And, it was said in in the 1980's, when the first Ada compilers were sold for the 1750.
That is why these Ada compilers were not considered mature when they first came out.
That is why people like myself had to do extensive work to use those first compilers
in the early Ada/1750 flight control systems.

Now, let's talk about the present-day, and the Ariane 5. Which is a more mature
compiler, a PL/I compiler for the 1750 which would have had its first use on
the Ariane 5, or an Ada compiler which has probably been used on several real-time
projects previously? You previous comment was that "PL/I is more mature than Ada,"
but with respect to the 1750, the Ada compilers would be the more mature 
implementations, right?

How's that list of PL/I-based real-time airborne control systems coming along, BTW? :)

When do we get to find out your background in real-time systems?

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Darren C Davenport]

++ robin wrote:
> 
> overflow.  A R/T (and even non R/T) PL/I programmer
> routinely puts in error control.
> 
> occurs.  If this had been done (routine in PL/I), the
> effect of an unchecked conversion would have been observed.

I think that it is quite evident that the world would be a better
place if we all just convert to PL/I because we will be more
intelligent and never make silly mistakes.  As a side effect, world
peace will become a reality and hunger will be eradicated.

Darren

Re: Ariane 5 - not an exception?

[John McCabe]

rav@goanna.cs.rmit.edu.au (++           robin) wrote:
<..snip..>

>	>  2) PL/I

>	>     a) There is no PL/I compiler for the 1750A

>---Not an obstacle.  How was an Ada compiler written for it?

Because the US Military decided that their standard microprocessor
(Mil-Std-1750A) should have a compiler for their standard language Ada
(Mil-Std-1815).

>	>     c) This failure was not a language issue.

>---Isn't it?  One of the arguments put forward was that
>an Ada condition couldn't be raised and leave a trace,
>and that it would be argued that there was no guarantee
>whether a piece of code was executed.

Of course it isn't. How many people have to point out that no matter
what language had been used the specification and design was still
faulty.

>	> It is a management issue.
>	>        Specifically, it is a failure of engineering management.

>---There are lots of things for which one can blame 
>management, but the lack of a check for overflow has
>to come down to the programmer.

Read the report - the lack of checks was the result of analysis done
on the software and obviously was accepted at a higher level. The
important point being that the analysis was done and the checks
removed, _not_ that they weren't there in the first place.

>	>     d) Given the incorrect specifications against which the program was
>	>        designed, the same failure would have occurred in PL/I or any
>	>        other language.

>---No it wouldn't.  The lack of a test for overflow was
>the problem.  But even supposing for a moment that
>all conversions were checked, then
>an interrupt handler could be included for fixed-point
>overflow.  This would have trapped any unchecked
>overflow.  A R/T (and even non R/T) PL/I programmer
>routinely puts in error control.

Chances are that this is exactly how the Operand Error exception was
raised. Why don't you find out about Ada and how it is implemented in
embedded systems before stating rubbish like this. You may learn a
lot.

>	>  4) Software Reuse

>	>     If one intends to "reuse" software, such as Ariane 4xx software in
>	>     Ariane 5xxx, in a significantly different architecture, there is some
>	>     virtue in extensive testing.

>---In this case, with simulated inputs, and with SIGNAL
>statements to check out what happens when an interrupt
>occurs.  If this had been done (routine in PL/I), the
>effect of an unchecked conversion would have been observed.

It's obvious from the report that the testing was inadequate. If the
inputs had been simulated well, the exception would have been raised.

>	>  7) Ada

>	>     This is still the best language for doing this kind of system.

>---PL/I would be clearly better, as it meets the requirments
>for audit trails in program and system checkout (in addition
>to the other facilities that it offers).

Read the Ada manual. Every feature you have mentioned for PL/I is
available in Ada.



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

Re: Ariane 5 - not an exception?

[Chris Papademetrious]

john@assen.demon.co.uk (John McCabe) wrote:
>Of course it isn't. How many people have to point out that no matter
>what language had been used the specification and design was still
>faulty.

 Exactly.  People have to realize that it's possible to write the
routine to blow up a rocket in ANY language.  A language is just a
facility to allow directives to be executed, but if the programmer
wants the thing blown up, it will happen...


-=-=-=-=-=-=-=-=-=-=-=-=-
 Chris Papademetrious
 Data Fusion Laboratory
 Drexel University
 Philadelphia, PA
-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Ariane 5 - not an exception?

[++ robin]

	john@assen.demon.co.uk (John McCabe) writes:

	>rav@goanna.cs.rmit.edu.au (++           robin) wrote:
	><..snip..>

	>>	>  2) PL/I

	>>	>     a) There is no PL/I compiler for the 1750A

	>>---Not an obstacle.  How was an Ada compiler written for it?

	>Because the US Military decided that their standard microprocessor
	>(Mil-Std-1750A) should have a compiler for their standard language Ada
	>(Mil-Std-1815).

---One had to be written, no?

	>>	>     c) This failure was not a language issue.

	>>---Isn't it?  One of the arguments put forward was that
	>>an Ada condition couldn't be raised and leave a trace,
	>>and that it would be argued that there was no guarantee
	>>whether a piece of code was executed.

	>Of course it isn't. How many people have to point out that no matter
	>what language had been used the specification

---No, the specification wasn't faulty.  The implementation
was.  Because of a programming error, a data conversion from
double precision floating-point to a 16-bit integer
overflowed.  In the absence of a check, an exception occurred,
the immediate action of which was to shut down the processor.
That shutdown resulted in the inevitable and almost immediate
destruction of the project.  Read the report.

	>and design was still faulty.

---There was a number of design problems that needs to be
addressed.

	>>	> It is a management issue.
	>>	>        Specifically, it is a failure of engineering management.

	>>---There are lots of things for which one can blame 
	>>management, but the lack of a check for overflow has
	>>to come down to the programmer.

	>Read the report - the lack of checks was the result of analysis done
	>on the software and obviously was accepted at a higher level.

---I had read the report ages ago, before making any
posting on the issue, and was horrified to read of the
cause being a simple overflow.

   If you had read the report, you would have notected that
the committee could not find any explanation in the code
as to why this & 2 other conversions did not have checks,
while all the other similar conversions in the vicinity
did.  There is the suggestion that the checks were overlooked.

	>The
	>important point being that the analysis was done and the checks
	>removed, _not_ that they weren't there in the first place.

---On the contrary, if you read the report, it states
clearly and unequivocally that the analysis was done
and the checks *added* where they felt that they were 
needed (NOT removed from ones that they felt did not
need it).

	>>	>     d) Given the incorrect specifications against which the program was
	>>	>        designed, the same failure would have occurred in PL/I or any
	>>	>        other language.

	>>---No it wouldn't.  The lack of a test for overflow was
	>>the problem.  But even supposing for a moment that
	>>all conversions were checked, then
	>>an interrupt handler could be included for fixed-point
	>>overflow.  This would have trapped any unchecked
	>>overflow.  A R/T (and even non R/T) PL/I programmer
	>>routinely puts in error control.

	>Chances are that this is exactly how the Operand Error exception was
	>raised.

---This is how -- obviously -- the exception was raised.
It is the *absence* of a specific check that caused this
to happen (the report used the term "unchecked").
You really should read the report.

	>Why don't you find out about Ada and how it is implemented in
	>embedded systems before stating rubbish like this. You may learn a
	>lot.

---BTW, it isn't rubbish.  You just haven't understood.
What I said was that a belt-and braces method was
needed.  All conversions should have been checked.
In addition, an interrupt handler should have been
included for fixed-point overflow, just in case
a check had been inadvertently omitted from any conversion.

   These matters are routine for a PL/I programmer.

   ANY kind of interrupt (even a trivial one) in Ariane 5
would cause sudden death to the project (the shutdown
of the processor).  It was the programmer's job to ensure
that such an error (number too large) never occurred under
any circumstances.

Re: Ariane 5 - not an exception?

[John McCabe]

rav@goanna.cs.rmit.edu.au (++           robin) wrote:

>	>>	>     a) There is no PL/I compiler for the 1750A

>	>>---Not an obstacle.  How was an Ada compiler written for it?

>	>Because the US Military decided that their standard microprocessor
>	>(Mil-Std-1750A) should have a compiler for their standard language Ada
>	>(Mil-Std-1815).

>---One had to be written, no?

What do you mean "One had to be written"? There are a number of
commercially available Ada compilers for the MIL-STD-1750A processor
e.g. TLD, Tartan, EDS-Scicon XD-Ada, DDC-I all already produce a
1750/Ada compiler. If you are suggesting that one had to be written
especially for the Ariane project you are wrong. As far as PL/I is
concerned, it is clear that there is absolutely no demand for a
1750/PL/I compiler so in this case, if the Ariane developers had
wanted to use PL/I and 1750 it would have been necessary to develop a
completely new compiler rather than use one that could already be
purchased off the shelf.

>	>>	>     c) This failure was not a language issue.

>	>>---Isn't it?  One of the arguments put forward was that
>	>>an Ada condition couldn't be raised and leave a trace,
>	>>and that it would be argued that there was no guarantee
>	>>whether a piece of code was executed.

>	>Of course it isn't. How many people have to point out that no matter
>	>what language had been used the specification

>---No, the specification wasn't faulty.  The implementation
>was.  Because of a programming error, a data conversion from
>double precision floating-point to a 16-bit integer
>overflowed.  In the absence of a check, an exception occurred,
>the immediate action of which was to shut down the processor.
>That shutdown resulted in the inevitable and almost immediate
>destruction of the project.  Read the report.

Why was the processor shut down? Because that was the SPECIFIED action
of the exception handler. The programmer implemented the
specification. Why was there an overflow? Because the implementation
followed the specification which _failed_ to specify the Ariane 5
requirements correctly (especially inrelation to the commonality
between Ariane 4 and Ariane 5).

And BTW I have read the report, a number of times and every time I
read it, it tells me that the programmers were not at fault. Think
about it, how much authority on design decisions has a programmer on a
large project - very little! If they raise a query on the design it is
still someone else's responsibility to make the decision as to what to
do about it.

>	>and design was still faulty.

>---There was a number of design problems that needs to be
>addressed.

Yes, but by the designer, not necessarily by the programmer.

>	>Read the report - the lack of checks was the result of analysis done
>	>on the software and obviously was accepted at a higher level.

>---I had read the report ages ago, before making any
>posting on the issue, and was horrified to read of the
>cause being a simple overflow.

>   If you had read the report, you would have notected that
>the committee could not find any explanation in the code
>as to why this & 2 other conversions did not have checks,
>while all the other similar conversions in the vicinity
>did.  There is the suggestion that the checks were overlooked.

Don't talk rubbish! Read this - an excerpt from the report:

"This led to protection being added to four of the variables, evidence
of which appears in the Ada code. However, three of the variables were
left unprotected. No reference to justification of this decision was
found directly in the source code. Given the large amount of
documentation associated with any industrial application, the
assumption, although agreed, was essentially obscured, though not 
------NOTE  ^^^^^^^^^^^^^^^
deliberately, from any external review.

>	>The
>	>important point being that the analysis was done and the checks
>	>removed, _not_ that they weren't there in the first place.

>---On the contrary, if you read the report, it states
>clearly and unequivocally that the analysis was done
>and the checks *added* where they felt that they were 
Accepted, however the report goes on to say:

"The reason for the three remaining variables, including the one
denoting horizontal bias, being unprotected was that further reasoning
indicated that they were either physically limited or that there was a
large margin of safety, a reasoning which in the case of the variable
BH turned out to be faulty. It is important to note that the decision
to protect certain variables but not others was taken jointly by
project partners at several contractual levels"
------------ NOTE   ^^^^^^^^^^^^^^^^^^^^^^^^^^

******* IT WAS NOT A PROGRAMMING ERROR ********

>needed (NOT removed from ones that they felt did not
>need it).

>	>>---No it wouldn't.  The lack of a test for overflow was
>	>>the problem.  But even supposing for a moment that
>	>>all conversions were checked, then
>	>>an interrupt handler could be included for fixed-point
>	>>overflow.  This would have trapped any unchecked
>	>>overflow.  A R/T (and even non R/T) PL/I programmer
>	>>routinely puts in error control.

>	>Chances are that this is exactly how the Operand Error exception was
>	>raised.

>---This is how -- obviously -- the exception was raised.
>It is the *absence* of a specific check that caused this
>to happen (the report used the term "unchecked").

The absence of a specific check is what ultimately caused the failure,
however this was not the problem - the problem was far more
fundamental than that.

>You really should read the report.

I have read the report - a number of times - you should try it
sometime it is rather interesting.

>	>Why don't you find out about Ada and how it is implemented in
>	>embedded systems before stating rubbish like this. You may learn a
>	>lot.

>---BTW, it isn't rubbish.  You just haven't understood.
>What I said was that a belt-and braces method was
>needed.  All conversions should have been checked.

The excuse was that not all conversions were checked because there was
not enough processing power to do so. I would, however, have to agree
with you here as I believe that processor loading margin requirements
should NEVER be met at the expense of mission success.

>In addition, an interrupt handler should have been
>included for fixed-point overflow, just in case
>a check had been inadvertently omitted from any conversion.

The "interrupt handler" was added - it was the Operand Error excepion
handler.

>   These matters are routine for a PL/I programmer.

>   ANY kind of interrupt (even a trivial one) in Ariane 5
>would cause sudden death to the project (the shutdown
>of the processor).

That is probably completely untrue! The exception that occurred would
be tied to a specific interrupt - if MIL-STD-1750 processors were
used, they allow up to 16 different interrupts to be handled, this
exception handler would not be invoked for all interrupts.

>It was the programmer's job to ensure
>that such an error (number too large) never occurred under
>any circumstances.

No it wasn't - a programmers job is to implement a specification and
raise any queries regarding his implementation. If those queries end
up in incorrect decisions to proceed in a given direction "by project
partners at several different contractual levels", is it the
programmers job to ignore that? I don't think so.

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

Re: Ariane 5 - not an exception?

[Ken Garlington]

John McCabe wrote:
> 
> And BTW I have read the report, a number of times and every time I
> read it, it tells me that the programmers were not at fault.

After some thought, I've come to the conclusion that ++robin is a troll.
I can't comprehend the alternative.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[John McCabe]

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

>John McCabe wrote:
>> 
>> And BTW I have read the report, a number of times and every time I
>> read it, it tells me that the programmers were not at fault.

>After some thought, I've come to the conclusion that ++robin is a troll.
>I can't comprehend the alternative.

I think I'd have to agree because he certainly seems to be "talking
out his arse" to coin a phrase (if anyone doesn't understand this -
e-mail me!).


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

Re: Ariane 5 - not an exception?

[Byron B. Kauffman]

John McCabe wrote:
> 
> Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
> 
> >John McCabe wrote:
> >>
> >> And BTW I have read the report, a number of times and every time I
> >> read it, it tells me that the programmers were not at fault.
> 
> >After some thought, I've come to the conclusion that ++robin is a troll.
> >I can't comprehend the alternative.
> 
> I think I'd have to agree because he certainly seems to be "talking
> out his arse" to coin a phrase (if anyone doesn't understand this -
> e-mail me!).
> 
> Best Regards
> John McCabe <john@assen.demon.co.uk>

Re: Ariane 5 - not an exception?

[John McCabe]

"Byron B. Kauffman" <KauffmanBB@lmtas.lmco.com> wrote:

>John McCabe wrote:
>> 
>> Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
>> 
>> >John McCabe wrote:
>> >>
>> >> And BTW I have read the report, a number of times and every time I
>> >> read it, it tells me that the programmers were not at fault.
>> 
>> >After some thought, I've come to the conclusion that ++robin is a troll.
>> >I can't comprehend the alternative.
>> 
>> I think I'd have to agree because he certainly seems to be "talking
>> out his arse" to coin a phrase (if anyone doesn't understand this -
>> e-mail me!).
>> 
>> Best Regards
>> John McCabe <john@assen.demon.co.uk>


Well that was a particularly interesting comment Byron :-)

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

Re: Ariane 5 - not an exception?

[Byron B. Kauffman]

John McCabe wrote:
> 
> "Byron B. Kauffman" <KauffmanBB@lmtas.lmco.com> wrote:
> 
> >John McCabe wrote:
> >>
> >> Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:
> >>
> >> >John McCabe wrote:
> >> >>
> >> >> And BTW I have read the report, a number of times and every time I
> >> >> read it, it tells me that the programmers were not at fault.
> >>
> >> >After some thought, I've come to the conclusion that ++robin is a troll.
> >> >I can't comprehend the alternative.
> >>
> >> I think I'd have to agree because he certainly seems to be "talking
> >> out his arse" to coin a phrase (if anyone doesn't understand this -
> >> e-mail me!).
> >>
> >> Best Regards
> >> John McCabe <john@assen.demon.co.uk>
> 
> Well that was a particularly interesting comment Byron :-)
> 
> Best Regards
> John McCabe <john@assen.demon.co.uk>

You know, I had a REALLY good one-liner to add, but managed to fat-finger
the keyboard or something and blew it away (I've already caught flak from
Dewar).  Now I can't remember what it was...

-- 
Byron Kauffman

Re: Ariane 5 - not an exception?

[Robert Dewar]

iByron said

"You know, I had a REALLY good one-liner to add, but managed to fat-finger
the keyboard or something and blew it away (I've already caught flak from
Dewar).  Now I can't remember what it was..."

The fflak here was simply a note pointing out that Byron had sent an empty message.

The reason I sent it was that I hoped it was in time to rescue what you
typed.
It is quite useful to use an environment which saves a huge window behind
you of everything you have typed in. That way you can rescue material which
is otherwise lost to the ages :-) :-)

Re: Ariane 5 - not an exception?

[Ted Dennison]

Robert Dewar wrote:
> 
> It is quite useful to use an environment which saves a huge window behind
> you of everything you have typed in. That way you can rescue material which
> is otherwise lost to the ages :-) :-)

Of course for some of us, that might not be such a bad thing. :-)

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

Re: Ariane 5 - not an exception?

[John McCabe]

"Byron B. Kauffman" <KauffmanBB@lmtas.lmco.com> wrote:

>You know, I had a REALLY good one-liner to add, but managed to fat-finger
>the keyboard or something and blew it away (I've already caught flak from
>Dewar).  Now I can't remember what it was...

Byron,

Thanks for your email message, unfortunately I couldn't "reply" to it
as I couldn't find a valid email address in the headers anywere -
however, the answer is "for sure, go for it!"



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

Re: Ariane 5 - not an exception?

[Martin Tom Brown]

In article <4vgmit$124@goanna.cs.rmit.edu.au>
           rav@goanna.cs.rmit.edu.au "++           robin" writes:

>    ANY kind of interrupt (even a trivial one) in Ariane 5
> would cause sudden death to the project (the shutdown
> of the processor).  

That was a fundamental *design* decision - read the report.

> It was the programmer's job to ensure
> that such an error (number too large) never occurred under
> any circumstances.
 
Sad though it is - the specification did not require the code
to work when flown along an Ariane 5 trajectory, it was *assumed*
that the code would continue to work as it had for Ariane 4.
No live trajectory checks of the IRS were done :(

You cannot blame the programmers for inadequate specifications.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Ariane 5 - not an exception?

[Bob Gilbert]

In article <4vgmit$124@goanna.cs.rmit.edu.au>, rav@goanna.cs.rmit.edu.au (++           robin) writes:
> 
> ---No, the specification wasn't faulty.

I disagree, I think the specification was faulty, and is the
primary cause of the problem.

>  The implementation
> was.  Because of a programming error, a data conversion from
> double precision floating-point to a 16-bit integer
> overflowed.  In the absence of a check, an exception occurred,
> the immediate action of which was to shut down the processor.

Exactly as the requirements specified, and the software performed
exactly to the specification, including saving into PROM the
current state.  It is the specification which wrongly assumed that
a data overflow would indicate a probably hardware failure, and if
a hardware failure occurred the action was to shut down the allegedly
failed equipment.

> That shutdown resulted in the inevitable and almost immediate
> destruction of the project.  Read the report.

>    If you had read the report, you would have notected that
> the committee could not find any explanation in the code
> as to why this & 2 other conversions did not have checks,
> while all the other similar conversions in the vicinity
> did.  There is the suggestion that the checks were overlooked.

Actually I think they suggested that there was weak documentation
in the code noting that an analysis of the conversions was
performed.  It is my impression that they concluded that an
analysis of the conversions was done, and a conscious decision to 
omit them was (wrongly) made, in part to meet their 80% processor
utilization goal (something some have suggested should have been
waived in this circumstance).

>   john@assen.demon.co.uk (John McCabe) writes:
> 	>The important point being that the analysis was done and the 
> 	>checks removed, _not_ that they weren't there in the first place.
> 
> ---On the contrary, if you read the report, it states
> clearly and unequivocally that the analysis was done
> and the checks *added* where they felt that they were 
> needed (NOT removed from ones that they felt did not
> need it).

I think the above poster meant that the checks were removed from the 
requirements specification, maybe?

As you say, an analysis was done and checks added where they felt it
was necessary.  Sounds like the analysis, which determined the
requirements, was in error.  The code was written and performed
per the faulty specification, that's not a programming error, and
certainly not a language issue.

-Bob

Re: Ariane 5 - not an exception?

[Robert I. Eachus]

In article <4vk8r4$2r7@zeus.orl.mmc.com> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:

  > ...It is my impression that they concluded that an analysis of the
  > conversions was done, and a conscious decision to omit them was
  > (wrongly) made, in part to meet their 80% processor utilization
  > goal (something some have suggested should have been waived in
  > this circumstance)...

  > As you say, an analysis was done and checks added where they felt it
  > was necessary.  Sounds like the analysis, which determined the
  > requirements, was in error...

    There is one detail you seem to have missed.  The analysis was
correct for the Ariane 4.  The incredible management blunder was that
reanalysis was not done for the Ariane 5, because the plan was to test
the actual hardware (and software) instead.  But later changes in
plans eliminated the full up testing.  So the software was not written
to Ariane 5 specifications--in fact the report specifically states
that the developers never had access to those specifications.  The
software was never analyzed with respect to those specifications. And
the software and hardware was never tested against those different
specifications.

    I would be be fired three times over for incompetent engineering
on that scale, and so would you.  But the decisions were political and
managerial.  I can't overemphasize this.  The decisions which caused
the failure were signed off not by engineers but by government
ministers and corporate executives.  And the effect, not the intent of
those decisions insured that the engineers never knew how badly things
were being botched.  It speaks well for the consortium that they did
an honest evaluation of what went wrong and published it.
Unfortunately it was clearly bowdlerized and mentions no names.  I
suspect that this was a condition imposed upon publishing it.





--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ariane 5 - not an exception?

[John McCabe]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>    I would be be fired three times over for incompetent engineering
>on that scale, and so would you.  But the decisions were political and
>managerial.  I can't overemphasize this.  The decisions which caused
>the failure were signed off not by engineers but by government
>ministers and corporate executives.

That is one of the most major problems of working in the European
space industry - NOTHING is ever decided on purely technical terms. I
have experience of this even within my own (Anglo-French) company.

>And the effect, not the intent of
>those decisions insured that the engineers never knew how badly things
>were being botched.  It speaks well for the consortium that they did
>an honest evaluation of what went wrong and published it.

I think this was necessary due to the amount of [European] government
money that went into the project in the first place, and therefore the
consortium had to make sure that _everyone_ was made aware that they
had discovered what the problem was. It would have been reasonably
easy to keep it quiet, but they need to build peoples confidence
again, and by publishing the report detailing that they knew exactly
what happened, and they knew exactly what to do about it in future, I
think they are well on their way to restoring that confidence.

>Unfortunately it was clearly bowdlerized and mentions no names.  I
>suspect that this was a condition imposed upon publishing it.

That's unfortunate, I'd love to know exactly who was to blame -
perhaps more information is given in the restricted circulation
technical report? If anyone knows any more, please let us know.

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

Re: Ariane 5 - not an exception?

[Tom Speer]

Robert I. Eachus wrote:
> 
>...It speaks well for the consortium that they did
> an honest evaluation of what went wrong and published it.
> Unfortunately it was clearly bowdlerized and mentions no names.  I
> suspect that this was a condition imposed upon publishing it.
> ....

My limited experience with investigating similar events is that it is the 
usual practice in such mishaps that there are actually two 
investigations.  The first one is done as a safety investigation, and 
its purpose is to determine the cause as quickly as possible so that 
the lessons can be learned and disseminated in time to avoid a repeat of 
the problem.  The information given to such a board is privledged 
information, and the specific interviews and deliberations of the board 
in arriving at their conclusions are never divulged.  Only the board's 
findings of fact and their analysis of why the mishap occured are 
reported.

The second investigation is done for the purpose of finding fault.  If 
this board interviews you, you better know what your rights are, because 
they're out to hang the guilty bastards.

What you've seen are the results of the first board.

TS

Re: Ariane 5 - not an exception?

[Jon S Anthony]

In article <840979842.3697.0@assen.demon.co.uk> john@assen.demon.co.uk (John McCabe) writes:

> That is one of the most major problems of working in the European
> space industry - NOTHING is ever decided on purely technical terms. I
> have experience of this even within my own (Anglo-French) company.

"Correction".  That is one of the most major problems of working in the
software biz.  I've seen it basically everywhere.  This business functions
more like the pop music biz than anything else.

1/2 :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ariane 5 - not an exception?

[Richard Riehle]

On 13 Aug 1996, ++           robin wrote:

   From: Richard Riehle

   Robin wrote in response to my posting regarding PL/I for Arianne:

>
> 	>  2) PL/I
>
> 	>     a) There is no PL/I compiler for the 1750A
>
> ---Not an obstacle.  How was an Ada compiler written for it?

  There are many Ada compilers for the 1750A from many different
  compiler publishers.  And there is considerable experience using
  Ada for this architecture.  The unavailability of a PL/I
  compiler is very much an obstacle to using it.

  Moreover, PL/I has plenty of problems of its own. From an
  engineering viewpoint, little nuisances such as "default
  identifiers,"  the ability to reference an unknown name
  outside a nested block, side effects created by "secret"
  variables, the poor facilities for explicit scope resolution,
  the unpredictability of "partial qualification," etc. I could
  go on for several pages, but this should give some idea.

  PL/I, when used carefully, has been used successfully for
  a wide-range of important applications, but it is not
  without a substantial number of warts and imperfections.
  Once again, I have not used PL/I for a long time, so some
  things about the language may have gotten better.


> 	>     b) Ada is far more suitable for safety-sensitive
>       >      software than Pl/I
>
> ---Nonsense.  PL/I has a long (30 years) record in
> excellent real-time facilities, and with people with
> experience in error-recovery and fail-soft in routine
> commercial applications as well as real-time programming.

  And there is far more successful experience using Ada for this
  processor architecture than there is PL/I. Moreover, Ada is
  explicitly designed for safety-sensitive software.

  Moreover, Ada's track record in safety-critical real time
  systems is excellent and getting better all the time.

> 	>     c) This failure was not a language issue.
>
> ---Isn't it?  One of the arguments put forward was that
> an Ada condition couldn't be raised and leave a trace,
> and that it would be argued that there was no guarantee
> whether a piece of code was executed.

  Vis a vis the Ada language, that is an incorrect statement.

>
>    In PL/I, a SIGNAL statement (which can be used for
> program checkout) leaves a printed record that it was
> executed.  It gives a message that the condition was
> raised, and comes with line numbers, etc.  There is
> absolutely no doubt that the statement did not execute!

  So who gets the message? Where is it stored?  Printed record?
  Now that is interesting. It reflects a mainframe point-of-view
  rather than an embedded systems point-of-view.  We seldom
  include a printer on a  space bound system.  On the other
  hand, we do collect a lot of telemetry data, and this should
  be available.  However, it would have been of little use for
  Arianne V since no one would be using it for corrective action
  in time to save the system.

> ---There are lots of things for which one can blame
> management, but the lack of a check for overflow has
> to come down to the programmer.

  Wrong again.  In an data processing system, we give the programmer
  greater latitude. In this kind of application, the programmer is a
  contributor, but not a final authority. This is engineering, not
  programming.  Or it should be.

>> d) Given the incorrect specifications against which the program was
>>    designed, the same failure would have occurred in PL/I or any
>>    other language.

  If a programmer decides, independently of the specifications, the
  systems engineering designers, the V & V team, and his peer review
  group, to include unapproved code with such serious implications as
  error correction, that programmer will never work on this kind of
  project again.

>
> overflow.  A R/T (and even non R/T) PL/I programmer
> routinely puts in error control.

  This is not the exclusive province of PL/I programmers. I am amazed
  at such a narrow view.  Error management is a well-known part of
  programming, and Ada has excellent facilities for doing it. Facilities
  every bit as good, perhaps better ( I have written PL/I in my ancient
  past) than PL/I.  However, the programmer may alert the development
  team to a potential error, but this software is the work of a team
  of engineers, not the independent creative effort of some single
  programmer.

> ---In this case, with simulated inputs, and with SIGNAL
> statements to check out what happens when an interrupt
> occurs.  If this had been done (routine in PL/I), the
> effect of an unchecked conversion would have been observed.

  Apparently, as I have learned from another post and a face-to-face
  conversation with one of the engineers on the project, this was not
  a function of unchecked conversion, so that is moot.

> 	>  7) Ada
>
> 	>     This is still the best language for doing this kind of system.
>
> ---PL/I would be clearly better, as it meets the requirments
> for audit trails in program and system checkout (in addition
> to the other facilities that it offers).

  Frankly, I am still baffled by this argument. It is increasingly clear
  that your knowledge of Ada is somewhere between sparse and none.
  PL/I was well-known at the time a decision was taken to bypass it as
  a choice for the new DoD language in the late 1970's. Why?

  I can think of lots of reasons, but they would be lost on anyone who
  is not ready to acknowledge their validity.

  In response to my comment regarding the role of management in this
  failure, you reply,

> ---Scarcely convincing, in view of the failure.

  Well, it had better be convincing to someone. If I understand my
  understanding as I think I understand it, the failure was a direct
  result of assuming that software which behaved correctly for
  Arianne IV, would also work correctly for Arianne V.  This assumption
  was made in spite of the fact that Arianne V was designed with a
  different set of launch behaviors that Arianne IV.

  On Arianne IV, the software, at the point where the overflow would
  be detected, was designed to shut down the system while it was still
  on the launch pad. Due to differences in launch behavior, this same
  software shut down the system after lift-off.

  The software behaved exactly as it should for the Arianne IV. It was
  an engineering error to use the same software, unchanged in a system
  with different launch characteristics.  No programming language can
  tell the engineers they are making such a fundamental error. Even
  your beloved PL/I would have failed under these circumstances, unless
  it has taken on far greater run-time intelligence than I recall.

  Richard Riehle

Re: Ariane 5 - not an exception?

[Ken Garlington]

++ robin wrote:
> 
>         simonb@pact.srf.ac.uk (Simon Bluck) writes:
> 
>         >The Ariane 501 flight failure was due to the raising of an unexpected
>         >Ada exception,
> 
> ---An exception, yes, but not unexpected.
> 
>    The programming mistake made was in assuming that a
> floating-point value of some 58 significant bits would
> somehow "fit" into a 15-bit integer.

Actually, you have values much larger than 58 significant bits
fit into a 15-bit (or 16-bit) integer. You just have to throw
out enough precision!

>    There was no check that the data conversion would not
> result in overflow, so the problem went to the error
> handler, which shut down the system.

This is certainly true.

> ---To continue in this case probably would need the value to
> be set to the maximum. And it wouldn't be corrupt data.

No. But it might still generate an incorrect vector to the flight
controls, which would still have crashed the vehicle. It's just that
the IRS would be spewing data right up to that last "hard landing."

> There are other better approaches.  One is to continue
> with the maximum value; another is to avoid the use of
> a 16-bit variable, and to use a variable as the same
> size and type (here floating-point storage),
> thus avoiding the problem altogether.

Not always easy to do. Do much MIL-STD-1553 processing between
dissimilar CPUs?

> ---This is more of a lack of communication between the two
> programs.  Another design error.

Actually, the amount of communication between a primary and a
backup system is another tough system problem. We went through
this on the F-16. In general, the backup shouldn't trust state
data from the primary, since this can create a common mode failure.
On the other hand, with _no_ state data, the backup may be unable
to take over from the primary. Add to this the desire to keep the
backup software identical to the primary, to reduce the amount of
unique software to analyze and test, and it's a non-trivial thought
process.

> ---I think the real lessons are that
> 1. real-time programming requires special expertise.

Amen to this. Safety-critical real-time programming even more so.

> 2. the choice of language is suspect.  A better-established
>    language such as PL/I -- specifically designed for
>    real-time programming -- with robust compilers, and
>    with its base of experienced programming
>    staff could well have prevented this disaster.

Every claim you just made for PL/I can amply be made for Ada.

Am I using anything you've built in PL/I?

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Craig P. Beyers]

Ken Garlington wrote:
> 
> Actually, the amount of communication between a primary and a
> backup system is another tough system problem. We went through
> this on the F-16. In general, the backup shouldn't trust state
> data from the primary, since this can create a common mode failure.
> On the other hand, with _no_ state data, the backup may be unable
> to take over from the primary. Add to this the desire to keep the
> backup software identical to the primary, to reduce the amount of
> unique software to analyze and test, and it's a non-trivial thought
> process.Clearly (from the report at least) the two IRS's were intended to 
provide redundant position capability. The back-up IRS is there to 
reduce the risk of hardware failure. But the Ariane folks missed the 
problem of software failure and left the bird without any backup. It's 
interesting to note, too, that the back-up IRS failed first for the same 
reason the primary failed, leaving the rocket nowhere to turn (pun 
intended). Worse, it appears that no one anticipated both IRS's failing 
concurrently, so there's no provision in the s/w to at least center the 
nozzles and at least attempt to get the bird up higher and further 
out over the water--and thus safer--before destroying it. To me, the 
provision for the Ariane 4 re-start fix (the 50-sec. alignment function) 
sounds like an "easy" fix that did not receive the proper study. Worse, 
it doesn't apply to the Ariane 5. Pretty expensive s/w error? Of course 
not--it's not a s/w error by a set of errors in decisions, since it 
appears that the s/w did exactly what it was supposed to do with the 
data it received! Sort of "the operation was a success but the patient 
died" situation.

CPB
-- 
American Management Systems, Inc.
"Achieving breakthrough performance through 
the intelligent use of information technology"
703-267-7194/703-267-2222 (fax); craig_beyers@mail.amsinc.com

Re: Ariane 5 - not an exception?

[Steve O'Neill]

++ robin wrote:
> ---I think the real lessons are that
> 1. real-time programming requires special expertise.

Agreed wholeheartedly

> 2. the choice of language is suspect.  A better-established
>    language such as PL/I -- specifically designed for
>    real-time programming -- with robust compilers, and
>    with its base of experienced programming
>    staff could well have prevented this disaster.

I disagree completely!  The language was not the problem the design decisions in how the language 
was used were.  Ada is completely capable the realm of real-time programming, has robust 
compilers and tools, and has quite a few experienced software engineers capable of implementing 
just about any requirements thrown their way (been there, done that).  

Had the designers of the system allowed the implementors to use Ada exception mechanisms fully 
and properly they could have localized the failure to, at worst, the alignment function (which 
was not necessary at the time of the failure anyway) without shutting down the entire device.  
Instead, as is common practice in the safety-critical world, local exception handlers are 
frequently banned and a global 'shut it all down' handler is the only stop gap measure.  
Unbelievably the rationale for disallowing local handlers is because they make it difficult to 
verify complete code coverage since they are only executed in the case of exceptional conditions 
(i.e. given the expected data (Ariane 4 profile) the handlers are not executed and therefore we 
can't prove that all of our code has been exercised at least once). I find this logic suspect in 
the extreme!  As somebody once said "expect the unexpected". In addition to trying for fault 
avoidance through analysis we should also be planning for fault resiliency in the presence of 
reality.

You're other conclusions are right on target though - you should never shut a system down 
(unless its presence is impacting system performance as in the case of babbling nodes et.al.) but 
do indicate its distress to a higher authority who then can take this into account in using the 
information provided.

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[Martin Tom Brown]

In article <31FE35BC.1A0D@sanders.lockheed.com>
           smoneill@sanders.lockheed.com "Steve O'Neill" writes:

> ++ robin wrote:

> > 2. the choice of language is suspect.  A better-established
> >    language such as PL/I -- specifically designed for
> >    real-time programming -- with robust compilers, and
> >    with its base of experienced programming
> >    staff could well have prevented this disaster.
> 
> I disagree completely!  The language was not the problem the design decisions
>  in how the language was used were.  

It goes further back than that - the requirement specifications were
seriously at fault and incomplete. It was *not* a stated requirement 
that the unit would function correctly on the Ariane 5 trajectory.

An implementation of the algorithms in any language which detects
numerical overflow would have shut down the IRS to comply with spec.

> Ada is completely capable the realm of real-time programming,
>  has robust compilers and tools, and has quite a few experienced 
> software engineers capable of implementing ...

I agree that the language is in the clear.

> Had the designers of the system allowed the implementors to use Ada exception
>  mechanisms fully 
> and properly they could have localized the failure to, at worst, the alignment
>  function (which 
> was not necessary at the time of the failure anyway) without shutting down the
>  entire device.  

This was what surprised me - coming from an environment (not safety critical)
where continued function even if degraded is preferred to hard shutdown.
It seems unduly perverse to guarantee total system failure once an 
untrapped exception occurs. Is it really safer to blow the thing out of
the sky than inject its payload into an inaccurate orbit?

After all the hardware failsafe *will* destroy it automatically 
if the trajectory deviates sufficiently - as happened when the IRS
started feeding the navigation computer diagnostic bit patterns as data.

> Instead, as is common practice in the safety-critical world, local exception
>  handlers are 
> frequently banned and a global 'shut it all down' handler is the only stop gap
>  measure.  

This is an interesting insight.

> Unbelievably the rationale for disallowing local handlers is because they make
>  it difficult to 
> verify complete code coverage since they are only executed in the case of
>  exceptional conditions 

I can see there is a point there, OTOH perhaps there is something wrong
with a test philosophy that don't attempt to push the envelope of valid
data to find what happens if ...
Designing test data to execute each and every path is part of the game.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Ariane 5 - not an exception?

[Nigel Tzeng]

In article <838805582snz@nezumi.demon.co.uk>,
Martin Tom Brown  <Martin@nezumi.demon.co.uk> wrote:
>In article <31FE35BC.1A0D@sanders.lockheed.com>
>           smoneill@sanders.lockheed.com "Steve O'Neill" writes:

[snip]

>It goes further back than that - the requirement specifications were
>seriously at fault and incomplete. It was *not* a stated requirement 
>that the unit would function correctly on the Ariane 5 trajectory.

Well, it also states that had adequate simulations been done the fault
would have been detected fairly early in the sims.  The biggest flaw
in their simulation testing was not actually using flight s/w and
hardware during the testing (well, at least using the Engineering Test
Units for simulation).

Many compounding errors were required to create this problem.

[snip]

>This was what surprised me - coming from an environment (not safety critical)
>where continued function even if degraded is preferred to hard shutdown.
>It seems unduly perverse to guarantee total system failure once an 
>untrapped exception occurs. Is it really safer to blow the thing out of
>the sky than inject its payload into an inaccurate orbit?

>After all the hardware failsafe *will* destroy it automatically 
>if the trajectory deviates sufficiently - as happened when the IRS
>started feeding the navigation computer diagnostic bit patterns as data.

Well, that surprised me a little.  Granted that their facilites are in
the middle of nowhere I still would have expected that range safety
would have destroyed the vehicle given description of the attitude
deviation (20 degree AOA...that must have been interesting) rather
than having the breakup of the vehicle initiate the destructs...then
again it happened only 4 seconds after the nozzles were commanded to
extreme positions.

Anyone know off the cuff what the ER or WR would have done in this
case?  I'm assuming that they can see the relevant telemetry...at
least the LCC I'm working on has requirements that they can but
I'm new to the launch vehicle world.

[snip]

>Regards,
>-- 
>Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
>Scientific Software Consultancy             /^,,)__/

Nigel

Re: Ariane 5 - not an exception?

[Ken Garlington]

Martin Tom Brown wrote:

> > Instead, as is common practice in the safety-critical world, local exception
> >  handlers are
> > frequently banned and a global 'shut it all down' handler is the only stop gap
> >  measure.
> 
> This is an interesting insight.

At least in my experience, the statement is true but incomplete. One approach to
safety-critical systems is to write the software so as to _avoid_ exceptions. For
example, based on what I've read on the SRI exception, the precision of the 16-bit 
conversion might have been set such that any 64-bit value would reliably be
convertable to the 16-bit field. Other options include saturation arithmetic or
explicit checks (vs. Ada implicit checks).

Of course, just avoiding the exception is not enough. The alternative chosen has to
be capable of meeting the mission requirements.

If the software design is judged to be sufficiently reliable, and _sufficient_
analysis is done to show that input data cannot cause an exception, then the remaining
exception possibilities are things such as hardware failures. In this case, there may
not be an adequate internal response, and shutting down _with an appropriate failure
indication_ may be the best choice, if continued operation might cause adverse system
impacts. For example, if a system fails such that it is saturating a communications
channel with garbage data, you may want the system to shut down so that other 
communications can continue.

> 
> > Unbelievably the rationale for disallowing local handlers is because they make
> >  it difficult to
> > verify complete code coverage since they are only executed in the case of
> >  exceptional conditions
> 
> I can see there is a point there, OTOH perhaps there is something wrong
> with a test philosophy that don't attempt to push the envelope of valid
> data to find what happens if ...
> Designing test data to execute each and every path is part of the game.

Again, this isn't exactly the issue, in my experience. Whether you have exception
handlers or not, you want to test (as much as practical) the full "envelope" of
data inputs -- valid and invalid. However, each time code is added to the system,
you have to test the functionality and structure of that added code. If that code
is not shown to add sufficient value, then you are diverting resoruces from analyzing
and testing improtant code to test the less-important code. If you can show that
an exception cannot be raised at a certain point, this is sometimes a more effective
use of resources than adding code to catch the exception. Of course, whether you
do the analysis, or add code, you have to do the engineering correctly. In the
Ariane 5 case, this didn't happen.

> 
> Regards,
> --
> Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
> Scientific Software Consultancy             /^,,)__/

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Thomas Kendelbacher]

In article <3201D8EC.45E4@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> writes:
>If the software design is judged to be sufficiently reliable, and _sufficient_
>analysis is done to show that input data cannot cause an exception, then the remaining
>exception possibilities are things such as hardware failures. In this case, there may
>not be an adequate internal response, and shutting down _with an appropriate failure
>indication_ may be the best choice, if continued operation might cause adverse system
>impacts. For example, if a system fails such that it is saturating a communications
>channel with garbage data, you may want the system to shut down so that other 
>communications can continue.

Wouldn't that be "shut up" instead of "shut down", in that case?  :-D

Sorry, couldn't resist.

-- 
Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de
DASA RI / Abt. RIT14  |   voice : +49 421 539 5492 (working hours)
Postfach 28 61 56     |      or : +49 421 57 04 37 (any other time)
D-28361 Bremen        |     fax : +49 421 539 4529 (any time)
Germany

Re: Ariane 5 - not an exception?

[++ robin]

	Steve O'Neill <smoneill@sanders.lockheed.com> writes:

	>++ robin wrote:
	>> ---I think the real lessons are that
	>> 1. real-time programming requires special expertise.

	>Agreed wholeheartedly

	>> 2. the choice of language is suspect.  A better-established
	>>    language such as PL/I -- specifically designed for
	>>    real-time programming -- with robust compilers, and
	>>    with its base of experienced programming
	>>    staff could well have prevented this disaster.

	>I disagree completely!  The language was not the
	>problem the design decisions in how the language 
	>was used were.

---The choice of language is indeed very relevant.
What I wrote in an earlier posting on this topic is highly
apt:

"A PL/I programmer
experienced with real time systems, would have CHALLENGED
such a stupid requirement that the computer be shut down by the
error-handler in the event of a fixed-point overflow.  He would
have had it changed.

"I'd go further to say that no experienced PL/I programmer
would have shut down the system as a result of a fixed-point
overflow.

"Furthermore, he would have included a check that the value
did not go out of range;"

	>Ada is completely capable the realm [sic]
	>of real-time programming, has robust 
	>compilers and tools, and has quite a few experienced
	>software engineers capable of implementing 
	>just about any requirements thrown their way (been there, done that).  

	>Had the designers of the system allowed the
	>implementors to use Ada exception mechanisms fully 
	>and properly they could have localized the failure
	>to, at worst, the alignment function

---But all it needed was a check that the value was in range.
Such checks had been included on other similar conversions in
the vicinity!

	>(which 
	>was not necessary at the time of the failure anyway)

---what?  The OBC was using the attitude information to
direct the nozzles.  It was their [the nozzles] sudden change
that caused the space vehicle to break up, thereby forcing
the vehicle to self-destruct automatically [that sudden
change was the result of the OBC interpreting the error
readout from the shut-down SRI computer as attitide data.]

	> without shutting down the entire device.  
	>Instead, as is common practice in the safety-
	>critical world, local exception handlers are 
	>frequently banned and a global 'shut it all
	>down' handler is the only stop gap measure.  
	>Unbelievably the rationale for disallowing local
	>handlers is because they make it difficult to 
	>verify complete code coverage since they are
	>only executed in the case of exceptional conditions 

---As I wrote in an earlier post:

"This project might well have been written in PL/I, which
has excellent real-time facilities, including error
handling, error simulation and validation facilities.
The language has robust compilers, and experts with many
years of PL/I programming experience.

"As to PL/I facilities, I refer to the SIGNAL statement,
with which given conditions (errors such as fixed-point
overflow) can be signalled as if the condition (error)
actually occurred.

"This alone would have showed up the deficiency of the
overall design (that the system would shut itself down for
fixed-point overflow)."

	>(i.e. given the expected data (Ariane 4 profile)
	>the handlers are not executed and therefore we 
	>can't prove that all of our code has been
	>exercised at least once).

---But they can be, and shown to be, in PL/I -- the language
with the right tools -- with the SIGNAL statement.  That
statement leaves an indisputable footprint!

	>I find this logic suspect in 
	>the extreme!  As somebody once said "expect the
	>unexpected".  In addition to trying for fault 
	>avoidance through analysis we should also be
	>planning for fault resiliency in the presence of 
	>reality.

---Exactly what I wrote in an earlier posting.

	>You're other conclusions are right on target
	>though - you should never shut a system down 
	>(unless its presence is impacting system performance
	>as in the case of babbling nodes et.al.) but 
	>do indicate its distress to a higher authority
	>who then can take this into account in using the 
	>information provided.

	>Steve O'Neill                      | "No,no,no, don't tug on that!
	>Sanders, A Lockheed Martin Company |  You never know what it might
	>smoneill@sanders.lockheed.com      |  be attached to." 

Re: Ariane 5 - not an exception?

[Ken Garlington]

++ robin wrote:

[Editing ++robins statement to remove unnecessary words...]

> "A [...] programmer
> experienced with real time systems, would have CHALLENGED
> such a stupid requirement that the computer be shut down by the
> error-handler in the event of a fixed-point overflow.  He would
> have had it changed.
> 
> "I'd go further to say that no experienced [...] programmer
> would have shut down the system as a result of a fixed-point
> overflow.
> 
> "Furthermore, he would have included a check that the value
> did not go out of range;"

I can certainly agree that the absence of a check should have been
challenged, and that the system should have been analyzed to show
that the check was not needed.

However, the report states that the analysis was done. If you're saying
(1) that they should have done the analysis correctly, who can argue with
that? If you're saying (2) that the programmer should have ignored the analysis,
put the check in anyway, and said "Screw you, guys, I'm a [...] programmer
and I know better than you!", well, you might have a point. However, such
an action certainly requires a very brave (or very foolhardy) [...] programmer.

> 
>         >(which
>         >was not necessary at the time of the failure anyway)
> 
> ---what?  The OBC was using the attitude information to
> direct the nozzles.  It was their [the nozzles] sudden change
> that caused the space vehicle to break up, thereby forcing
> the vehicle to self-destruct automatically [that sudden
> change was the result of the OBC interpreting the error
> readout from the shut-down SRI computer as attitide data.]

I had to read the report a few times to catch the jist of this myself.
Although it's confusing, it sounds like the alignment function was
running, but was not providing correction vectors to the SRI output.
Therefore, the alignment function did not have to be executing at all.

This, to me, is very strange. From my limited experience with IRS
alignments, the alignment function shuts down as soon as the IRS moves (or the
alignment is complete), since you can't usually align a moving IRS
without a fixed reference input (like you get on shipboard systems).
The rationale in the report, that keeping the alignment system running
made it easier to realign the SRI close to liftoff, makes some sense.
But it's still an unusual approach.

Translating additional remarks into format appropriate to the
selected newsgroups:

> "This project might well have been written in [a real-time programming
> language], which
> has excellent real-time facilities, including error
> handling, error simulation and validation facilities.
> The language has robust compilers, and experts with many
> years of [real-time language] programming experience.

Of course, just because there are experts in a particular language,
this doesn't mean that all systems written in that language are
written by experts. I don't know the average experience level for
the Ariane V, so there's no way to know in this case...

> "As to [language] facilities, I refer to the statement
> [called SIGNAL in PL/I and RAISE in Ada],
> with which given conditions (errors such as fixed-point
> overflow) can be signalled as if the condition (error)
> actually occurred.
> 
> "This alone would have showed up the deficiency of the
> overall design (that the system would shut itself down for
> fixed-point overflow)."

Of course, the programmer (and tester) must employ these facilities
for them to be useful. If the programmer fails to use these facilities,
or defeats these facilities
(e.g., suppressing the built-in fixed-point overflow checks in Ada),
there's precious little the language can do.

As you noted earlier, the way in which the system handles the exception
is also important. In this case, clearly the exception was handled
inappropriately given the Ariane V environment.

It is also interesting to note one subtle distinction: The designers knew
that fixed-point overflow would shut the system down. They just didn't
believe the specific calculations could overflow. I suspect that, if a
SIGNAL or RAISE statement were inserted in the code, these same engineers
would say, "But you can't reach that statement in practice!" and so their
effect on the analysis might have been irrelevant.

> 
>         >(i.e. given the expected data (Ariane 4 profile)
>         >the handlers are not executed and therefore we
>         >can't prove that all of our code has been
>         >exercised at least once).
> 
> ---But they can be, and shown to be, in [a real-time language] -- the language
> with the right tools -- with the [SIGNAL, RAISE, etc.] statement.  That
> statement leaves an indisputable footprint!

Again, this depends upon the programmer using the statement for it to be
an "indisputable footprint." Some languages, such as Ada, attempt to overcome
this issue by _also_ inserting implicit exception raises for certain events.
However, if the programmer turns these features off, or fails to handle them,
their effect can be blunted.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[John McCabe]

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

<..snip..>

>I had to read the report a few times to catch the jist of this myself.
>Although it's confusing, it sounds like the alignment function was
>running, but was not providing correction vectors to the SRI output.
>Therefore, the alignment function did not have to be executing at all.

>This, to me, is very strange. From my limited experience with IRS
>alignments, the alignment function shuts down as soon as the IRS moves (or the
>alignment is complete), since you can't usually align a moving IRS
>without a fixed reference input (like you get on shipboard systems).
>The rationale in the report, that keeping the alignment system running
>made it easier to realign the SRI close to liftoff, makes some sense.
>But it's still an unusual approach.

If you checks through the report again, you'll notice that having the
alignment function running up to 40 seconds after lift-off was not an
applicable requirement for Ariane 5, it was left over from Ariane 4. 

Your comments on the alignment function providing a reference against
a fixed point seem perfectly valid to me also, and I cannot really
understand how they could continue to align after lift-off. It sounds
very silly to me, as I can't believe that even the Ariane 4 software
would continue to take alignment data into account after lift-off.

<..snip..>

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

Re: Ariane 5 - not an exception?

[Mark van Walraven]

In article <839266234.26317.0@assen.demon.co.uk>, john@assen.demon.co.uk (John McCabe) wrote:
>
>If you checks through the report again, you'll notice that having the
>alignment function running up to 40 seconds after lift-off was not an
>applicable requirement for Ariane 5, it was left over from Ariane 4. 
>
>Your comments on the alignment function providing a reference against
>a fixed point seem perfectly valid to me also, and I cannot really
>understand how they could continue to align after lift-off. It sounds
>very silly to me, as I can't believe that even the Ariane 4 software
>would continue to take alignment data into account after lift-off.

As I understand it, alignment data is computed for approx. fifty seconds after
Ariane 4 enters "flight-mode",  9 seconds before launch.  If the count-down
is halted after -9 secs, there is enough time to secure the rocket before the
alignment process stops.  Provided the count-down was held before -6 secs, it
should be possible to restart the count-down without the lengthy (45 min?)
delay needed to start alignment from cold.

I expect the alignment data was ignored after launch.  How ironic.

Regards,
Mark.

Re: Ariane 5 - not an exception?

[Ken Garlington]

FYI - This week's Aviation Week and Space Technology has an editorial on 
the Ariane 5 accident. It pretty much reflects the final report, but 
makes a few points about the management culture of the Ariane 5 team 
(more interested in selling flights than designing in safety) and the 
possible complacency of a team that had several successful designs under 
their belt. I'm not familiar enough with the real situation at 
Arianespace and their subcontractors to say that the editorial is 
correct, but it makes for interesting reading.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Ken Garlington]

John McCabe wrote:
> 
> If you checks through the report again, you'll notice that having the
> alignment function running up to 40 seconds after lift-off was not an
> applicable requirement for Ariane 5, it was left over from Ariane 4.

Right. Notice, however, that even on the Ariane 4, the alignment function
continued to run, but _not_ apply correction vectors, prior to lift-off.
I always had the impression that when an IRS was in alignment mode, it could
not be in operational mode, and vice versa. It sounds like this IRS was
designed to have a "pseudo" alignment mode, which would continue to calculate
corrections, but only apply them when the IRS was in "true" alignment mode.
As I understood the report, this "pseudo" mode was designed to allow quick
entry and exit into the "true" alignment mode for quick updates prior to
launch.

If the Ariane 4 did not have this design feature of a "pseudo" mode, then
the alignment task would have been disabled completely as soon as the IRS
moved -- whether on the Ariane 4 or Ariane 5 -- and so the alignment
calculations would not have been running in either case. There is a lesson
learned here about adding too many "neat" features to safety-critical software.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Pascal Martin @lone]

In article <4totv7$o9f@goanna.cs.rmit.edu.au>,
   rav@goanna.cs.rmit.edu.au (++           robin) writes:
>
> "Furthermore, he would have included a check that the value
> did not go out of range;"

This comment is totally misplaced: an Ada exception **is** a check.

Someone noted that shutdowning the system before it takes off was
probably a sound decision. Shutdown on board of a flying system looks
like the worst possible choice (could going **down** in a **flying**
system be a good choice, anyway ? :-).

I have seen systems which ignored suspect values, and send the latest
trusted result again and again instead, on the basis that the correct
result was probably close to this one. When you have nothing to work
with, this is perhaps the best gamble you can make. After all, rocket
science has a lot in common with gambling, looks like :-)

> "This project might well have been written in PL/I, which
> has excellent real-time facilities, including error
> handling, error simulation and validation facilities.
> The language has robust compilers, and experts with many
> years of PL/I programming experience.

Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
Windows/Intel and PowerPC/* ? I thought the language was dead since
the demise of IBM mainframes and the death of (the beloved) Multics.

I also though the PL/I experts have so many years of programming
experience that they are now.. retired.

PL/I had everything, except reserved words. The infamous "if if then then".

>"As to PL/I facilities, I refer to the SIGNAL statement,
>with which given conditions (errors such as fixed-point
>overflow) can be signalled as if the condition (error)
>actually occurred.

Sounds like the author never opened an Ada reference manual..

Pascal.

Re: Ariane 5 - not an exception?

[Dr. Richard Botting]

Pascal Martin @lone (pmartin@alsys.com) wrote:

: Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
: Windows/Intel and PowerPC/* ? I thought the language was dead since
: the demise of IBM mainframes and the death of (the beloved) Multics.

: I also though the PL/I experts have so many years of programming
: experience that they are now.. retired.

: PL/I had everything, except reserved words. The infamous "if if then then".

As one who taught PL/I by IBM trainers, while working,
when it was called NPL, and never used the language and got paid for it,
I completely agree with Pascal's comments... and will add the following opinion:
	PL/I was not designed for real time but to be a weapon
	against Algol, COBOL, FORTRAN and other tools that let
	people port their sofware to non-IBM platforms.

--
dick botting     http://www.csci.csusb.edu/dick/signature.html
Disclaimer:      CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
	I have nothing to sell, and I'm giving it away.

Re: Ariane 5 - not an exception?

[system]

 dick@silicon.csci.csusb.edu (Dr. Richard Botting) writes:
>Pascal Martin @lone (pmartin@alsys.com) wrote:
>
>: Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
>: Windows/Intel and PowerPC/* ? I thought the language was dead since
>: the demise of IBM mainframes and the death of (the beloved) Multics.

Well I know even less about PL/I than I do about Ada, (and I think the
origin of this thread (within the Adrian thread) was pretty tacky)
but it appears to be fairly healthy:

Windows 95, Windows NT, OS/2, VMS on both VAX and Alpha, AIX and
Digital Unix plus the traditional mainframes.

Robert
-------------------------------------------------------
**From IBM**

The new IBM PL/I for Windows+ Version 1.2 provides a PL/I application
   development environment on Windows NT and Windows 95 that is designed
   to allow you to create mission-critical, line-of-business applications
   that can run on host systems, workstations, or client/server systems
   with access to DB2(R), VSAM/SAM, and other data systems. IBM PL/I for
   Windows provides the PL/I programmer with an optimizing compiler and a
   set of high-productivity, Windows-based tools for the development of
   applications.
-------------------------------------------------------

   IBM PL/I for OS/2(R) Professional Version 1.2 builds upon the function
   in Version 1.1 and adds new enhancements, such as an improved run-time
   environment and additional data access support.
-------------------------------------------------------

   IBM introduces three new members of the PL/I family that have been
   designed with today's programmer in mind:
     * PL/I for OS/2 Personal Edition
     * PL/I for OS/2 Professional Edition
     * PL/I for OS/2 Toolkit, with Visual PL/I

-------------------------------------------------------
   IBM PL/I Set for AIX provides a PL/I application development
   environment designed to allow you to create mission critical,
   line-of-business applications that can run on host systems,
   workstations, or client/server systems with access to DB2(R),
-------------------------------------------------------
Some of the efforts we are investigating include:
     * Update MVS & VM compiler by porting function of the workstation
       compiler product to the host
     * Provide an object-oriented development environment that lets
       programmers develop PL/I applications using object-oriented
       extensions
     * Support for additional platforms such as Win32, PowerPC, and other
       UNIX environments
     * Support for open standards such as XPG and POSIX
-------------------------------------------------------
**From Digital**
VAX PL/I and DEC PL/I for OpenVMS AXP products have been transferred to
UniPrise Systems, Inc., of Irvine, California. UniPrise will continue to
offer these products under the current product names. Digital will continue
to sell and distribute the products under standard Digital license terms and
conditions. Digital will also continue to be the service provider. Current
Software Product Services users should be unaffected by this transfer;
Digital remains the primary contact for support.

The UniPrise acquisition of Digital's PL/I products will bring a renewed
focus on these compilers. Continued development and maintenance efforts will
provide investment protection for users with PL/I applications on the
OpenVMS VAX platform and allow users to move these applications to the
OpenVMS AXP platform easily.
   
-------------------------------------------------------
**From UniPrise**

   client/server systems. Whether your choice of environments is OpenVMS
   or UNIX, UniPrise has the full function Digital Alpha PL/I compiler
   for you.

Morphis@physics.niu.edu

Real Men change diapers

Re: Ariane 5 - not an exception?

[++ robin]

	pmartin@alsys.com (Pascal Martin @lone) writes:

	>Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
	>Windows/Intel and PowerPC/* ? I thought the language was dead since
	>the demise of IBM mainframes and the death of (the beloved) Multics.

   PL/I is available on at least the following systems:

     *	IBM PC and compatibles (80x86).

        *  IBM PL/I for OS/2: is available in 3 versions:
		Personal Edition	}
		Professional Edition	} Details at the bottom of this posting
		Toolkit.		}	
		---available from IBM

        *  Liant Open PL/I, for 80x86 & Pentium running UNIX SVR3 and SVR4
		---available from Liant Software Corporation
	   	959 Concord Street
	   	Framingham, MA 01701-4613
	   	Tel. (508) 872-8700  Fax (508) 626-2221
		(their PL/I generally is available on Unix-based systems)

	* Windows NT -- available from Liant

	* Windows 95/NT -- available 29 June 1996 from IBM

     * IBM AS/400
    		--- available from IBM

     *	IBM mainframes
		--- available from IBM

     *	HP 9000 HP-UX
		---available from Liant Software Corporation (address sbove)

     *	SPARC SunOS 4.x, Solaris 2.x
		---available from Liant

     *	IBM RS/6000 AIX
		---available from Liant Software Corporation;
		---also available from IBM as PL/I Set for AIX.

     *  Data General AViiON with DG-UX
		---available from Liant.

     *  Digital Equipment Corp. on Open VMS and Alpha AXP systems
		---available from Digital Equipment Corporation.
		UniPrise also has compilers for these systems.

     *  Stratus Computer, Inc.
		---available under VOS on all Stratus computers except AX/R-S.


_____________________________________________
P.S. IBM mainframes are still being installed.

Re: Ariane 5 - not an exception?

[Darius Blasband]

++ robin wrote:
> 
>         pmartin@alsys.com (Pascal Martin @lone) writes:
> 
>         >Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
>         >Windows/Intel and PowerPC/* ? I thought the language was dead since
>         >the demise of IBM mainframes and the death of (the beloved) Multics.
> 
>    PL/I is available on at least the following systems:     [ Quite an impressive list of platforms deleted here ]

But basically, how many of these compilers are used for other than
historical purposes ? Migrating and maintaining existing applications ?
How often do we see a project where virtually any tool can be used
and where PL/1 happens to be chosen out of a large number of possible
choices ? The fact that there are compilers available, the fact that billions
of PL/1 lines are in production today will not hide a basic, ugly truth:
PL/1 is one of the worst language design ever. As far as I know (or rather,
as far as what I believe a good language design should be) only C++
comes close.

IMHO...

Darius

Re: Ariane 5 - not an exception?

[dwnoon]

In <3209A6E6.17D4@phidani.be>, Darius Blasband <darius@phidani.be> writes:
>PL/1 is one of the worst language design ever. As far as I know (or rather,
>as far as what I believe a good language design should be) only C++
>comes close.

As far as lucid exression of algorithms, C++ isn't fit to lick PL/I's boots.

I suggest you try posting this message in a SmallTalk or Eiffel newsgroup
and see what their reaction is that C++ is a decent langauge. Even they
have their standards.

Regards

Dave
<Team PL/I>

Re: Ariane 5 - not an exception?

[Thomas Kendelbacher]

In article <4uic6d$1p76@news-s01.ny.us.ibm.net>, dwnoon@ibm.net writes:
>In <3209A6E6.17D4@phidani.be>, Darius Blasband <darius@phidani.be> writes:
>>PL/1 is one of the worst language design ever. As far as I know (or rather,
>>as far as what I believe a good language design should be) only C++
>>comes close.
>
>As far as lucid exression of algorithms, C++ isn't fit to lick PL/I's boots.
>
>I suggest you try posting this message in a SmallTalk or Eiffel newsgroup
>and see what their reaction is that C++ is a decent langauge. Even they
>have their standards.
>
>Regards
>
>Dave
><Team PL/I>

I'm not a native English speaker, but I'm pretty sure the original statement
meant to express that only C++ comes close *to PL/I* in the category of *worst*
language designs -- but certainly not close to *good language design*!

Maybe Darius as the original poster should clarify this.

-- 
Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de
DASA RI / Abt. RIT14  |   voice : +49 421 539 5492 (working hours)
Postfach 28 61 56     |      or : +49 421 57 04 37 (any other time)
D-28361 Bremen        |     fax : +49 421 539 4529 (any time)
Germany

Re: Ariane 5 - not an exception?

[++ robin]

	Thomas.Kendelbacher@erno.de (Thomas Kendelbacher) writes:

	>In article <4uic6d$1p76@news-s01.ny.us.ibm.net>, dwnoon@ibm.net writes:
	>>In <3209A6E6.17D4@phidani.be>, Darius Blasband <darius@phidani.be> writes:
	>>>PL/1 is one of the worst language design ever. As far as I know (or rather,
	>>>as far as what I believe a good language design should be) only C++
	>>>comes close.
	>>
	>>As far as lucid exression of algorithms, C++ isn't fit to lick PL/I's boots.
	>>
	>>I suggest you try posting this message in a SmallTalk or Eiffel newsgroup
	>>and see what their reaction is that C++ is a decent langauge. Even they
	>>have their standards.
	>>
	>>Regards
	>>
	>>Dave
	>><Team PL/I>

	>I'm not a native English speaker, but I'm pretty sure the original statement
	>meant to express that only C++ comes close *to PL/I* in the category of *worst*
	>language designs -- but certainly not close to *good language design*!

---Whatever the original poster was saying, Dave was
contradicting that assertion, as many of us know that
statement to be false.

   PL/I stands as an example of good language design.

   And, in fact, it is one of the enduring languages.

   BTW, the language has been extended, and the new
language is now available on OS/2, Windows 95/NT, and AIX.

	>Thomas Kendelbacher   |   email : Thomas.Kendelbacher@erno.de
	>Germany

Re: Ariane 5 - not an exception?

[Roy Gardiner]

Darius Blasband <darius@phidani.be> wrote:

>PL/1 is one of the worst language design ever. As far as I know (or rather,
>as far as what I believe a good language design should be) only C++
>comes close.
>
>IMHO...
>
>Darius

Exactly the opposite of my view, and I am sure I am as unlikely to be 
convinced of C++ as Darius is of PLI.

So let me revive a question aired on this group once before:

Who out there became expert in C first, and now prefers PLI? and vice 
versa?

All those persons who still prefer their 1st are ineligible to vote (I'm 
out, PLI first)

Regards, Roy Gardiner

Re: Ariane 5 - not an exception?

[Ken Garlington]

Roy Gardiner wrote:
> 
> Who out there became expert in C first, and now prefers PLI? and vice
> versa?

I used PL/I prior to Ada, and I prefer Ada to PL/I for safety-critical
real-time flight applications.

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Lance Kibblewhite]

Roy Gardiner <gardinerr@dcslambert.agw.bt.co.uk> wrote:
>Darius Blasband <darius@phidani.be> wrote:
>
>>PL/1 is one of the worst language design ever. As far as I know (or rather,
>>as far as what I believe a good language design should be) only C++
>>comes close.
>>
>>IMHO...
>>
>>Darius
>
>Exactly the opposite of my view, and I am sure I am as unlikely to be 
>convinced of C++ as Darius is of PLI.
>
>So let me revive a question aired on this group once before:
>
>Who out there became expert in C first, and now prefers PLI? and vice 
>versa?
>
>All those persons who still prefer their 1st are ineligible to vote (I'm 
>out, PLI first)

How about this, in order of learning.

   Language      Preference.

1. FORTRAN       FORTRAN (what else?)
2. COBOL         FORTRAN
3. PASCAL        PASCAL
4. PL/I          PL/I
5. C             PL/I
6. Ada           Ada
7. C++           Ada

Skipping things such as Prolog, Snobol, Lisp, APL, etc, which I
consider intersting and useful, but never of primary interst.

Re: Ariane 5 - not an exception?

[++ robin]

	Darius Blasband <darius@phidani.be> writes:

	>++ robin wrote:
	>>         pmartin@alsys.com (Pascal Martin @lone) writes:
	>>         >Which PL/I compilers are available today on Sparc/Solaris, HP700/HPUX,
	>>         >Windows/Intel and PowerPC/* ? I thought the language was dead since
	>>         >the demise of IBM mainframes and the death of (the beloved) Multics.
	>>    PL/I is available on at least the following systems:     [ Quite an impressive list of platforms deleted here ]

	>But basically, how many of these compilers are used for other than
	>historical purposes ?

---Problably all of them.

   If you have been reading job postings in comp.lang.pl1 and other
(job) newsgroups, you would have see that new projects are being
developed in PL/I.

	>Migrating and maintaining existing applications ?

---Certainly.

	>How often do we see a project where virtually any tool can be used
	>and where PL/1 happens to be chosen out of a large number of possible
	>choices ?

---The real choices are few.  PL/I is superior to most languages
for general programming.

   You see, PL/I was a significant advance on other languages
when it was introduced in 1966.  Features such as interrupt
handling (great for real-time processing) didn't then exist
in most other HL languages.

   Those features have kept PL/I at the forefront today.

   And the PL/I language has been extended recently with the
new implementations on the OS/2, Windows 95/NT and AIX platforms.

	>Darius

Re: Ariane 5 - not an exception?

[Richard Riehle]

On Thu, 8 Aug 1996, Darius Blasband wrote:

I am including the comp.lang.eiffel newsgroup in this reply since
it is guaranteed to give them a good bellylaugh.

> PL/1 is one of the worst language design ever. As far as I know (or rather,
> as far as what I believe a good language design should be) only C++
> comes close.

  I would hope Darious is joking. I suspect he is serious, but give
  him the benefit of the doubt.

  Richard Riehle

Re: Ariane 5 - not an exception?

[Steve O'Neill]

++ robin wrote:
>         Steve O'Neill <smoneill@sanders.lockheed.com> writes:
>         >I disagree completely!  The language was not the
>         >problem the design decisions in how the language
>         >was used were.
> 
> ---The choice of language is indeed very relevant.
> What I wrote in an earlier posting on this topic is highly
> apt:
> 
> "A PL/I programmer
> experienced with real time systems, would have CHALLENGED
> such a stupid requirement that the computer be shut down by the
> error-handler in the event of a fixed-point overflow.  He would
> have had it changed.
> 
> "I'd go further to say that no experienced PL/I programmer
> would have shut down the system as a result of a fixed-point
> overflow.

Substitute Ada (or C or FORTRAN or Assembly) for PL/I here and you see my 
point.  It's not the language that makes the developer challange the 
ridiculous requirement to shut down it is the developer "experienced with 
real-time systems".  Just because I am programming in PL/I doesn't mean I 
am magically a better real-time developer.  As a real-time designer 
concerned with the system-wide aspects of completely shutting down any 
sensor I would question this approach regardless of the language in use. 
This has nothing to do with the fact that much of my experience is with 
Ada.

The (flawed) reasoning for why certain conversions were not protected was 
also covered in the report.  Invalid assumptions were made and we know 
what assuming does don't we (makes an ASS out of U and ME).  This was 
compounded by the requirement for 20% spare capacity.  Spare capacity for 
what we don't know.  Especially considering that the very software which 
failed didn't need to be and should not have been running at the time 
consuming some of that precious spare.

Certainly you and I would not have shut down the system but what about 
the vast majority of developers without as much experience or who thought 
that their job was to implement the requirements that they were given?

> 
> "Furthermore, he would have included a check that the value
> did not go out of range;"
> 
> ---But all it needed was a check that the value was in range.
> Such checks had been included on other similar conversions in
> the vicinity!
> 

Yes, and there was mention in the report that 'they' thought that this 
would violate that precious spare requirement.  So they set about picking 
and choosing which conversions to protect.  I find it extremely hard to 
believe that the (small) handful of instructions to do a range check 
would have been too much!  And, in hindsight, well worth it.

The issue of the OBC interpreting the 'essentially diagnostic data' as 
valid sensor data really makes me wonder.  In a system with a reasonable 
interface between the two devices this should *never* happen.  I am 
surprised that this misinterpretation didn't cause a similar overflow in 
the OBC and resulting shutdown! :(

I think that we agree in our assessment of the situation and the fact 
that these problems could have been avoided with a better overall system 
design and more extensive testing.  Essentially the same conclusions that 
the review board came to.  My only disagreement is with your _opinion_ 
that the simple choice of a different language would have saved the day. 
 And with this point I will continue to disagree. 

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[Francis Lipski]

In article <32065615.77C7@sanders.lockheed.com>, you write:
> ++ robin wrote:
> >         Steve O'Neill <smoneill@sanders.lockheed.com> writes:
> >         >I disagree completely!  The language was not the
> >         >problem the design decisions in how the language
> >         >was used were.
> > 
> > ---The choice of language is indeed very relevant.
> > What I wrote in an earlier posting on this topic is highly
> > apt:
> > 
> > "A PL/I programmer
> > experienced with real time systems, would have CHALLENGED
> > such a stupid requirement that the computer be shut down by the
> > error-handler in the event of a fixed-point overflow.  He would
> > have had it changed.

   Not always possible.  If you are in the minority and are unsuccessful
to argue others to your point, what do you do?  

  As a previous message in this thread had stated, what should someone do?  Say to hell with the requirements, I'm going to code what I think is correct.  You
can argue you position for only so long.  If you haven't convinced others that
your position is correct, after a reasonable time, then either you can't argue
effectively, or may your position is wrong.  My recommendations would be to
document your position and your attempts to persuade others.  Then if something
like the Ariane 5 happens, you can say, "see I told you so".  Not that thats
a big consolation after the loss of a rocket, or if peoples lives have been
lost. 
> > 
> > "I'd go further to say that no experienced PL/I programmer
> > would have shut down the system as a result of a fixed-point
> > overflow.
> 
> Substitute Ada (or C or FORTRAN or Assembly) for PL/I here and you see my 
> point.  It's not the language that makes the developer challange the 
> ridiculous requirement to shut down it is the developer "experienced with 
> real-time systems".  Just because I am programming in PL/I doesn't mean I 
> am magically a better real-time developer.  As a real-time designer 
> concerned with the system-wide aspects of completely shutting down any 
> sensor I would question this approach regardless of the language in use. 
> This has nothing to do with the fact that much of my experience is with 
> Ada.
> 
> The (flawed) reasoning for why certain conversions were not protected was 
> also covered in the report.  Invalid assumptions were made and we know 
> what assuming does don't we (makes an ASS out of U and ME).  This was 
> compounded by the requirement for 20% spare capacity.  Spare capacity for 
> what we don't know.  Especially considering that the very software which 
> failed didn't need to be and should not have been running at the time 
> consuming some of that precious spare.
> 
> Certainly you and I would not have shut down the system but what about 
> the vast majority of developers without as much experience or who thought 
> that their job was to implement the requirements that they were given?
> 

  The report states that the rationale was based on the "culture within the
Ariane programme of only addressing random hardware failures.  From this point of view exception - or error- handling mechanisms are designed for a random
hardware failure which can quite rationally be handled by a backup system"

  If all conversions and other possible overflow conditions are protected,
and then an overflow occurs, what action should be taken?  The system has
just had a random hardware failure.  Continue to operate with known bad 
hardware?  In the case of an overflow, set to max value, continue and
hope for the best?  

  While clearly the design, in this case, did not protect itself sufficiently,
and compounded errors by not handling the case of a simultaneous failure of
both processors, what action should be taken on an overflow if not to shut
down.  With flight controls or inertial systems, partitioning into tasks and
then restarting the offending task is not an option.  It would take entirely
too long to restart the task to be able to effectively recover.

  Regarding the spare requirements.  The answer as to why to have spare time
is to ensure that all hard deadlines are met and to allow growth for future
versions of SW.   Allowing room for growth is necessary in development programs
however, the requirement is usually never relaxed as more functionality is
added.  That is another story.  However, it is necessary to ensure sufficient
time is available to complete all the processing within the allotted time.
The execution time of the software is at best a statistical problem, at least
the hardware times can be statistical.  If the SW is always measured as a worse
case time, and all these are added together can can not allow this time
to meet or exceed the allowable time, given the statistical nature of the HW.
So how much spare time should be allotted?  If 20% is unrealistic, what
number should be used, 10%, 1%, 0.001%?  

> > 
> > "Furthermore, he would have included a check that the value
> > did not go out of range;"
> > 
> > ---But all it needed was a check that the value was in range.
> > Such checks had been included on other similar conversions in
> > the vicinity!
> > 
> 
> Yes, and there was mention in the report that 'they' thought that this 
> would violate that precious spare requirement.  So they set about picking 
> and choosing which conversions to protect.  I find it extremely hard to 
> believe that the (small) handful of instructions to do a range check 
> would have been too much!  And, in hindsight, well worth it.
> 
> The issue of the OBC interpreting the 'essentially diagnostic data' as 
> valid sensor data really makes me wonder.  In a system with a reasonable 
> interface between the two devices this should *never* happen.  I am 
> surprised that this misinterpretation didn't cause a similar overflow in 
> the OBC and resulting shutdown! :(

 I was also amazed by the poor design of the interface that didn't detect
this problem.  Probably given enough time, some form of error would
have occurred resulting in the OBC shutting down.

> 
> I think that we agree in our assessment of the situation and the fact 
> that these problems could have been avoided with a better overall system 
> design and more extensive testing.  Essentially the same conclusions that 
> the review board came to.  My only disagreement is with your _opinion_ 
> that the simple choice of a different language would have saved the day. 
>  And with this point I will continue to disagree. 
> 
> -- 
> Steve O'Neill                      | "No,no,no, don't tug on that!
> Sanders, A Lockheed Martin Company |  You never know what it might
> smoneill@sanders.lockheed.com      |  be attached to." 
> (603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai
----------------------------------------------------------------------
Standard Disclaimer applies.
      Frank Lipski   lipski@fs1.mar.lmco.com          770-494-8322
"The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" ("I found it!") but rather "hmm....that's
funny..."  --   Isaac Asimov
---------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Martin Tom Brown]

In article <4u7fdm$e6m@morgan.vf.lmco.com>
           g1006@fs1.mar.lmco.com "Francis Lipski" writes:

>   If all conversions and other possible overflow conditions are protected,
> and then an overflow occurs, what action should be taken?  

The most obvious choice is drop back to a simple, but not necessarily
accurate primitive hardware backup system like levers and gyroscopes.
I have much more faith in the ability of mechanical and electronics
engineers to tolerance their designs for adverse conditions. When my
neck is on the line I like to see physical hardware interlocks in place.

> The system has just had a random hardware failure.  
> Continue to operate with known bad hardware?  

This decision is a hard one, but when the choice is between self-destruct 
now or flag the problem and press on and pray. I know which I'd chose.
It also depends to a large extent on the damage which could occur
if failure is delayed vs the cost to abort the mission.

> In the case of an overflow, set to max value, continue and 
> hope for the best?  

Not ideal, but neither was sending random diagnostic test data 
to the trajectory computation masquerading as IRS data packets.
With hindsight (a wonderful commodity, but in short supply)
we now know that ignoring the overflow would have been OK.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Ariane 5 - not an exception?

[Ken Garlington]

Martin Tom Brown wrote:
> 
> The most obvious choice is drop back to a simple, but not necessarily
> accurate primitive hardware backup system like levers and gyroscopes.
> I have much more faith in the ability of mechanical and electronics
> engineers to tolerance their designs for adverse conditions. When my
> neck is on the line I like to see physical hardware interlocks in place.

I think "faith" is certainly the right word for this belief, particularly
given the complexity of modern ASICs. If there's a simple mechanical
backup or interlock available, it's certainly a worthwhile design
consideration. However, feedback systems don't always react well to suddenly
being locked into a fixed position!

> --
> Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
> Scientific Software Consultancy             /^,,)__/

-- 
LMTAS - "Our Brand Means Quality"

Re: Ariane 5 - not an exception?

[Frank Manning]

In article <32065615.77C7@sanders.lockheed.com> Steve O'Neill
<smoneill@sanders.lockheed.com> writes:

>    [...]
> Just because I am programming in PL/I doesn't mean I am magically a
> better real-time developer.  
>    [...]

I agree totally.

> Certainly you and I would not have shut down the system but what about 
> the vast majority of developers without as much experience or who thought 
> that their job was to implement the requirements that they were given?
>    [...]

Over the years I periodically see Usenet debates about what the term
"software engineering" really means. It seems to me the Ariane problem
brings the question into sharp relief.

In a sci.aeronautics discussion about the Ariane problem, someone
brought up the interesting point there are two trends on a collision
course -- the increasing automation of flight vehicles, and the
plummeting number of new vehicle designs (see article
<rddDvHqG9.JIs@netcom.com> in sci.aero).

In other words, there are few engineers with more than one new vehicle
design under their belts, much less with vehicles having such
unprecedented automation requirements.

So how do you prevent another Ariane 5 problem? You really need people
who understand both aerospace engineering (another somewhat nebulous
term) and software engineering. Merely using ++robin's PL/I magic
bullet won't do it.

Like Steve says, you can't fault developers who implement the
requirements they're given, especially if the developers have no
specialized training in aerospace engineering. The converse is also
true -- what do you do about aero engineers (or mechanical/electrical/
etc.) who have little training in -- forgive me -- software
engineering? How do you bridge the gulf?

-- Frank Manning
-- Chair, AIAA-Tucson Section

Re: Ariane 5 - not an exception?

[Steve O'Neill]

Frank Manning wrote:
> In other words, there are few engineers with more than one new vehicle
> design under their belts, much less with vehicles having such
> unprecedented automation requirements.

This a new perspective on the problem, and a serious situation indeed.

> So how do you prevent another Ariane 5 problem? You really need people
> who understand both aerospace engineering (another somewhat nebulous
> term) and software engineering. Merely using ++robin's PL/I magic
> bullet won't do it.
> 
> Like Steve says, you can't fault developers who implement the
> requirements they're given, especially if the developers have no
> specialized training in aerospace engineering. The converse is also
> true -- what do you do about aero engineers (or mechanical/electrical/
> etc.) who have little training in -- forgive me -- software
> engineering? How do you bridge the gulf?

Easy, hire me, I've got a BS in Aero and about 15 years experience in the 
analysis and development of related real-time systems.

Sorry, I couldn't resist. ;)

But the fact remains that cross-training is critical for (especially) the 
system engineers and system designers of such complex systems.  Had 
someone with a 'big-picture' view of the Ariane system really spent the 
time to understand the implications of shutting down a critical sensor 
perhaps this tragic event would have been avoided.

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[Pat Rogers]

In <320A288E.725B@sanders.lockheed.com>, Steve O'Neill <smoneill@sanders.lockheed.com> writes:
>Frank Manning wrote:
[snip]
>> Like Steve says, you can't fault developers who implement the
>> requirements they're given, especially if the developers have no
>> specialized training in aerospace engineering. The converse is also
>> true -- what do you do about aero engineers (or mechanical/electrical/
>> etc.) who have little training in -- forgive me -- software
>> engineering? How do you bridge the gulf?
>
>Easy, hire me, I've got a BS in Aero and about 15 years experience in the 
>analysis and development of related real-time systems.
>
>Sorry, I couldn't resist. ;)


OK -- I'll hire you, but you'll have to move to Houston.... :)

pat
---------------
Patrick Rogers
progers@acm.org

Re: Ariane 5 - not an exception?

[JP Thornley]

frank@bigdog.engr.arizona.edu (Frank Manning) writes:
> So how do you prevent another Ariane 5 problem? You really need people
> who understand both aerospace engineering (another somewhat nebulous
> term) and software engineering. 
> 

I actually feel that there is a ray of hope here in the move towards 
executable prototypes.  To do these successfully requires a combination 
of systems and software expertise, and will *have* to be produced by 
combined teams - so that the dividing line between the two disciplines 
will become much less distinct.  (And if the systems engineers do carry 
on throwing the spec over the wall then the failures will come a lot 
quicker.)

Phil Thornley
-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
------------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[++ robin]

	g1006@fs1.mar.lmco.com (Francis Lipski) writes:

	>In article <32065615.77C7@sanders.lockheed.com>, you write:
	>> ++ robin wrote:
	>> >         Steve O'Neill <smoneill@sanders.lockheed.com> writes:
	>> >         >I disagree completely!  The language was not the
	>> >         >problem the design decisions in how the language
	>> >         >was used were.
	>> > 
	>> > ---The choice of language is indeed very relevant.
	>> > What I wrote in an earlier posting on this topic is highly
	>> > apt:
	>> > 
	>> > "A PL/I programmer
	>> > experienced with real time systems, would have CHALLENGED
	>> > such a stupid requirement that the computer be shut down by the
	>> > error-handler in the event of a fixed-point overflow.  He would
	>> > have had it changed.

	>   Not always possible.  If you are in the minority and are unsuccessful
	>to argue others to your point, what do you do?  

---Don't be absurd.  The checks WERE included in all but 3
of the type conversions in the vicinity of the conversion
that blew up.

	>  As a previous message in this thread had stated, what
	>should someone do?  Say to hell with the requirements,
	>I'm going to code what I think is correct.

---The requirements were that any kind of interrupt was
going to be handled by the interrupt handler (which would
then shut doen the computer).

   A *real* real-time PL/I programmer would have included
a test to make certain that the interrupt could not occur.
That was NOT going against the specifications.

   But, as I wrote in a previous post, a belt-and-braces
approach should have been taken, viz, to include an
error handler for fixed-point overflow, as an interrupt
was to be taken as SUDDEN DEATH for the project.

   This is where a PL/I programmer would have had the
specification changed.

	>> > "I'd go further to say that no experienced PL/I programmer
	>> > would have shut down the system as a result of a fixed-point
	>> > overflow.

	>> Substitute Ada (or C or FORTRAN or Assembly) for
	>> PL/I here and you see my point.

---Neither C nor Fortran have error-handling.
Ada *was* used, and look what happened.
Hence the suggestion that PL/I expertise on the
project would have been advantage.  You see,
real-time programming in PL/I has been part of the scene
since 1966!

	>> It's not the language that makes the developer challange the 
	>> ridiculous requirement to shut down it is the developer "experienced with 
	>> real-time systems".  Just because I am programming in PL/I doesn't mean I 
	>> am magically a better real-time developer.  As a real-time designer 
	>> concerned with the system-wide aspects of completely shutting down any 
	>> sensor I would question this approach regardless of the language in use. 
	>> This has nothing to do with the fact that much of my experience is with 
	>> Ada.

	>> The (flawed) reasoning for why certain conversions were not protected was 
	>> also covered in the report.  Invalid assumptions were made

---Yes; it was assumed that the value would not overflow
but it did!.  They have forgotten Murphy's Law:
"If anything can go wrong, it will".  And Robert's
Law: "Even if it *can't* go wrong, it will".

	>> Certainly you and I would not have shut down the system but what about 
	>> the vast majority of developers without as much experience or who thought 
	>> that their job was to implement the requirements that they were given?

---They could have implemented the "requirements"
WITHOUT raising a fixed-point interrupt,
just by checking for overflow!

	>  The report states that the rationale was based on the "culture within the
	>Ariane programme of only addressing random hardware failures.  From this point of view exception - or error- handling mechanisms are designed for a random
	>hardware failure which can quite rationally be handled by a backup system"

	>  If all conversions and other possible overflow
	>conditions are protected,
	>and then an overflow occurs, what action should be taken?

---Action should be taken to deal with a fixed-point overflow!
Something was overlooked.  It needed to be dealt with.  That
it was not is a fundamental error!  That's why error-handling
is provided!  To provide a margin of safety.

	> The system has
	>just had a random hardware failure.  Continue to operate with known bad 
	>hardware?  In the case of an overflow, set to max value, continue and
	>hope for the best?  

---Good idea, already suggested in the report.  But the
report also suggested that the design needed to
take into account programmer error.

	>  While clearly the design, in this case, did not protect itself sufficiently,
	>and compounded errors by not handling the case of a simultaneous failure of
	>both processors, what action should be taken on an overflow if not to shut
	>down.  With flight controls or inertial systems, partitioning into tasks and
	>then restarting the offending task is not an option.  It would take entirely
	>too long to restart the task to be able to effectively recover.

	>  Regarding the spare requirements.  The answer as to why to have spare time
	>is to ensure that all hard deadlines are met and to allow growth for future
	>versions of SW.   Allowing room for growth is necessary in development programs
	>however, the requirement is usually never relaxed as more functionality is
	>added.  That is another story.  However, it is necessary to ensure sufficient
	>time is available to complete all the processing within the allotted time.
	>The execution time of the software is at best a statistical problem, at least
	>the hardware times can be statistical.  If the SW is always measured as a worse
	>case time, and all these are added together can can not allow this time
	>to meet or exceed the allowable time, given the statistical nature of the HW.
	>So how much spare time should be allotted?  If 20% is unrealistic, what
	>number should be used, 10%, 1%, 0.001%?  

	>> > 
	>> > "Furthermore, he would have included a check that the value
	>> > did not go out of range;"
	>> > 
	>> > ---But all it needed was a check that the value was in range.
	>> > Such checks had been included on other similar conversions in
	>> > the vicinity!

	>> Yes, and there was mention in the report that 'they' thought that this 
	>> would violate that precious spare requirement.

---That's a red herring.

        > So they set about picking
        >> and choosing which conversions to protect.
   
---This doesn't sppear specifically in the report as regards
this conversion and the 2 others in the vicinity.  There's
the impliciation that these conversions were overlooked.
In any case, the test would have introduced a trivial
number of additional instructions.

        >>  I find it extremely hard to
        >> believe that the (small) handful of instructions to do a range check
        >> would have been too much!

---Agreed.

        >>  And, in hindsight, well worth it.

---Agreed again.

        >> The issue of the OBC interpreting the 'essentially diagnostic data' as
        >> valid sensor data really makes me wonder.  In a system with a reasonable
        >> interface between the two devices this should *never* happen.  I am
        >> surprised that this misinterpretation didn't cause a similar overflow in
        >> the OBC and resulting shutdown! :(

---Yes.

        > I was also amazed by the poor design of the interface that didn't detect
        >this problem.  Probably given enough time, some form of error would
        >have occurred resulting in the OBC shutting down.

---There were a number of inadequacies revealed in the design.

        >> I think that we agree in our assessment of the situation and the fact
        >> that these problems could have been avoided with a better overall system
        >> design and more extensive testing.  Essentially the same conclusions that
        >> the review board came to.  My only disagreement is with your _opinion_
        >> that the simple choice of a different language would have saved the day.

---As I stated, a PL/I programmer experienced in real-time
programming, would not have made this stupid mistake.

        >>  And with this point I will continue to disagree.

---You do not appear to have grounds for this opinion.

        >> Steve O'Neill                      | "No,no,no, don't tug on that!
        >> Sanders, A Lockheed Martin Company |  You never know what it might
        >> smoneill@sanders.lockheed.com      |  be attached to."
        >> (603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[Steve O'Neill]

++ robin wrote:
I previously said:
>         > So they set about picking
>         >> and choosing which conversions to protect.
> 

to which ++ robin replied:
> ---This doesn't sppear specifically in the report as regards
> this conversion and the 2 others in the vicinity.  There's
> the impliciation that these conversions were overlooked.
> In any case, the test would have introduced a trivial
> number of additional instructions.

Well, here's what the report said:
"It has been state that to the Board that not all of the conversions 
were protected because a maximum workload target of 80% had been set for 
the SRI computer.  To determine the vulnerability of unprotected code, 
an analysis was performed on every operation which could give rise to an 
exception, including an Operand Error.  In particular, the conversion of 
floating point values to integers was analysed and operations involving 
seven variables were at risk of leading to an Operand Error.  This led 
to protection being added to four of the variables, evidence of which 
appears in the Ada code.  However, three of the variables were left 
unprotected.  No reference to justification of this decision was found 
directly in the source code.  Given the large amount of documentation 
associated with any industrial application, the assumption, was 
essentially obscured, though not deliberately, from any external review.

The reason for the three remaining variables, including the one denoting 
horizontal bias, being unprotectedwas that further reasoning indicated 
that they were either physically limited or that there was a large margin 
of safety, a reasoning which in the case of the variable BH turned out to 
be faulty.  It is important to note that the decision to protect certain 
variables but not others was taken jointly by project partners at several 
contractual levels."

So, what this tells us is that they did what they thought was a thorough 
analysis and consciously made the decision to leave 3 variables 
unprotected.  An that this was not a unilateral decision.  I'm not 
saying that this whole approach made sense.  What I am saying is that 
this scenario is independent of the language used.  

Yes, in hindsight, it would have been much easier to add a couple lines 
of code even if it did cost 0.01% of that margin?

and ++robin continues to profess:
> 
> ---As I stated, a PL/I programmer experienced in real-time
> programming, would not have made this stupid mistake.
> 

And with this point I will continue to disagree. I guess that I need to 
learn PL/I since it obviously automatically endows people with god-like 
powers of reasoning that makes it impossible for them to build flawed 
systems.  Wow, I wonder if NASA and the FAA know this?! ;)

++robin> ---You do not appear to have grounds for this opinion.

Well, everyone has grounds for their opinions - it's called belief and 
it's mostly based on their experiences.  My experiences obviously differ 
from yours therefore we have different opinions.  Probably neither mine 
nor yours is entirely right or entirely wrong.

And with that I think I'll stop my participation in this thread.

-- 
Steve O'Neill                      | "No,no,no, don't tug on that!
Sanders, A Lockheed Martin Company |  You never know what it might
smoneill@sanders.lockheed.com      |  be attached to." 
(603) 885-8774  fax: (603) 885-4071|    Buckaroo Banzai

Re: Ariane 5 - not an exception?

[Jon S Anthony]

In article <4totv7$o9f@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

> ---The choice of language is indeed very relevant.
> What I wrote in an earlier posting on this topic is highly
> apt:

Not in this particular case.  It could have been written in anything and
it would not have made a difference (assuming it was "correctly" written,
i.e., conforming to spec.

> 	>Had the designers of the system allowed the
> 	>implementors to use Ada exception mechanisms fully 
> 	>and properly they could have localized the failure
> 	>to, at worst, the alignment function
> 
> ---But all it needed was a check that the value was in range.
> Such checks had been included on other similar conversions in
> the vicinity!

Irrelevant.  The point is that the requirements stated that the program
was to proceed as it did.  As several have pointed out this was not a
"programming" error.


> 	>(which 
> 	>was not necessary at the time of the failure anyway)
> 
> ---what?  The OBC was using the attitude information to
> direct the nozzles.  It was their [the nozzles] sudden change

The point is the particular system in question was only relevant _prior_
to launch.  Since it was clearly after launch that the failure happened
it should have been irrelevant.


> "This project might well have been written in PL/I, which

First, PL/I has nothing "extra" here at all.  Second, if the thing had
been written in PL/I and it had been in conformance with the
requirements, the thing would have failed.  Of course, you could claim
that were it written in PL/I it would not likely be in conformance and
then it might not have failed.  Shrug.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Ariane 5 - not an exception?

[James Kanze US/ESC 60/3/141 #40763]

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


In article <DvHuJq.7uJ@thomsoft.com> pmartin@alsys.com (Pascal Martin
@lone) writes:

|> Someone noted that shutdowning the system before it takes off was
|> probably a sound decision. Shutdown on board of a flying system looks
|> like the worst possible choice (could going **down** in a **flying**
|> system be a good choice, anyway ? :-).

Often it is.  Normally, you should have a back-up system; if you have
some reason to doubt the correctness of your answers, it might be better
to turn things over to the back-up system.  (Note that in the end, the
final back-up system may often be some sort of manual control.)
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, �tudes et r�alisations en logiciel orient� objet --
                -- A la recherche d'une activit� dans une region francophone

Re: Ariane 5 - not an exception?

[Robert I. Eachus]

In article <4totv7$o9f@goanna.cs.rmit.edu.au> rav@goanna.cs.rmit.edu.au (++           robin) writes:

  > "A PL/I programmer experienced with real time systems, would have
  > CHALLENGED such a stupid requirement that the computer be shut
  > down by the error-handler in the event of a fixed-point overflow.
  > He would have had it changed...

  > "This alone would have showed up the deficiency of the
  > overall design (that the system would shut itself down for
  > fixed-point overflow)."

   Substitute Ada for PL/I and you have it exactly right, except...

   Management decided not to authorize the change.  This was appealed
up the line, and the change was not approved at any level.  Only a
footnote, except that the same management approved reuse of the
computer (and software) in the Arianne 5 without a requirements
review.  That review would have shown both that this software should
not be running after launch, and that running it after launch would
result in a crash.

   The software was, and continues to be perfectly safe in the Ariane
4, although I suspect it will be changed for configuration management
reasons.  Say Boeing took the flight control software for the 747-300
and used it unchanged and without a requirements review in the
747-400.  Assume further that the first test flight crashed because of
a computer malfunction, and it turned out the cause that the crash
occured because the software decided that the (correct) center of
balance value was bogus, and either 1) substitued a "maximum" value
appropriate for the 747-300, 2) used the last "in-range" value, or 3)
shut down and printed diagnostic data.  Does which of those three
occured matter?  The cause of the crash was reusing the software
without checking that it met the new requirements.  Same here.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ariane 5 - not an exception?

[Stefan 'Stetson' Skoglund]

Hrmm, the two onboard computers is build by SAAB in Linkoping Sweden.
It is most definitely NOT of-the-shelf.

I don't think anybody really wanted to port PL/I to that architecture.

-- 
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund          I               |
sp2stes1@ida.his.se                I               |
<http://www.his.se/ida/~sp2stes1/> I         _____/0\_____
                                   I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige    I      I-+-I    O    I-+-I
                                   I
                                   I      Viggen with two Rb04
---------------------------------------------------------------------

Re: Ariane 5 - not an exception?

[Bob Gilbert]

In article <Dv45EJ.8r@fsa.bris.ac.uk>, simonb@pact.srf.ac.uk (Simon Bluck) writes:
> The Ariane 501 flight failure was due to the raising of an unexpected
> Ada exception, which was handled by switching off the computer.

The failure was due to the reuse of software, a software design, and software
requirements specification which was purposely designed to raise the said
exception and perform a SRI shutdown should certain limits be exceeded. 
Unfortunately these limits were well within normal operating budget of the
Ariane 5, but would be considered a failure (most probably hardware) if 
encountered on the Ariane 4 from which the software/design/requirements
were borrowed.

>  The report on this:
> 
>    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> 
> is clear and hard-hitting: it will result in much improved software.
> But does it get right to the bottom of the issues, and does the
> software community appreciate that there are fundamental software
> control problems which can directly give rise to such enormous
> failures, in this particular case thankfully without loss of life?
> 
> It is most unfortunate, but must be accepted as true, that if the
> Ariane software had been written in a less powerful language the
> numeric overflow might have gone unnoticed, the computers would have
> remained switched on, and the rocket would have continued its upward
> flight.

A "less powerful" language *might* have continued and the numeric
overflow gone unnoticed, or a similar catostrophic failure could
have occured with little chance of tracing the source of the failure.
But even if a "less powerful" language were used, it is probable
that the resulting code would have been designed to the same faulty
logic contained in the requirements specification.

The Ariane failure has little or nothing to do with language selection
or even correct coding.  The software performed exactly as designed.
The problem resulted in an oversight in the design limitations and
differences between the Ariane 4 and Ariane 5 systems.  I think the 
lessons to be learned here are about the reuse of software (especially
design and requirements) and testing.

-Bob

Re: Ariane 5 - not an exception?

[Martin Tom Brown]

In article <4tb8vv$bna@zeus.orl.mmc.com>
           rgilbert@unconfigured.xvnews.domain "Bob Gilbert" writes:

> In article <Dv45EJ.8r@fsa.bris.ac.uk>, simonb@pact.srf.ac.uk (Simon Bluck)
>  writes:
> > The Ariane 501 flight failure was due to the raising of an unexpected
> > Ada exception, which was handled by switching off the computer.
> 
> The failure was due to the reuse of software, a software design, and software
> requirements specification which was purposely designed to raise the said
> exception and perform a SRI shutdown should certain limits be exceeded. 

Yes - one can argue about the reasonableness of killing the active SRI
when the backup has already failed. And also about the decision made
during s/w development that out of 7 variables at risk of overflow only
4 were fully protected, and 3 unprotected which were felt not at risk
to keep CPU load inside bounds <80% (for Ariane 4 flight trajectories).

It adds insult to injury that the calculation code which failed was 
only valid when the system was on the *ground* awaiting launch.
It's a very good report and makes interesting reading.

> Unfortunately these limits were well within normal operating budget of the
> Ariane 5, but would be considered a failure (most probably hardware) if 
> encountered on the Ariane 4 from which the software/design/requirements
> were borrowed.
> 
> >  The report on this:
> > 
> >    http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
> > 

> The Ariane failure has little or nothing to do with language selection
> or even correct coding.  The software performed exactly as designed.

Again you can question the wisdom of shutting down the active IRS
when the backup is already dead - continuing with best guess data
would have been a marginally better option at that stage. 
The defect is traceable back to the requirements specification, and
the assumption that single point hardware failure is more likely 
than systematic software error in a redundant system.

> The problem resulted in an oversight in the design limitations and
> differences between the Ariane 4 and Ariane 5 systems.  I think the 
> lessons to be learned here are about the reuse of software (especially
> design and requirements) and testing.

The report's recommendations seem generally applicable to a large
number of systems engineering projects with a software component.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

Re: Ariane 5 - not an exception?

[John McCabe]

Martin Tom Brown <Martin@nezumi.demon.co.uk> wrote:

<..snip..>

>Yes - one can argue about the reasonableness of killing the active SRI
>when the backup has already failed. And also about the decision made
>during s/w development that out of 7 variables at risk of overflow only
>4 were fully protected, and 3 unprotected which were felt not at risk
>to keep CPU load inside bounds <80% (for Ariane 4 flight trajectories).

I find it difficult to understand why the design and development team
even considered maintaining the CPU load at <80% for this particular
case. If they requested a waiver on that margin and were refused then
obviously their prime contractor (or whatever) is to blame, but there
is no way that CPU loadings with margins of 20% should have been
enforced at the risk of mission failure.

<..snip..>

>Again you can question the wisdom of shutting down the active IRS
>when the backup is already dead - continuing with best guess data
>would have been a marginally better option at that stage. 
>The defect is traceable back to the requirements specification, and
>the assumption that single point hardware failure is more likely 
>than systematic software error in a redundant system.

True, but it certainly surprises me that there are 2 _identical_
computers running _identical_ software on a piece of equipment that is
so important to the future of the European space industry, and that
has had so much taxpayers money invested in it.

I would have thought that a triplex system using a voting mechanism
would have been used at least. I know this wold have extra cost, but
how much extra in terms of what we have seen happen with the system as
provided on flight 501. $300M (or was it pounds) worth of experimental
satellite went up with that rocket, would it have cost that much to
add one extra computer and some more software? I don't think so!

>> The problem resulted in an oversight in the design limitations and
>> differences between the Ariane 4 and Ariane 5 systems.  I think the 
>> lessons to be learned here are about the reuse of software (especially
>> design and requirements) and testing.

>The report's recommendations seem generally applicable to a large
>number of systems engineering projects with a software component.

I have been working in the European space industry for 9 years now,
and, hopefully with no disrespect to my peers, I am convinced that
there is far too little analysis of requirements performed. Around 3
years ago I took over a job that had been running for ~1.5 years, and
had produced development model software. Shortly after that I was
involved in redesigning the software in Ada (originally in C) for a
different processor. When it actually came down to finding out what
was really required, we spent months in discussions with our customer
because they really had no idea what they wanted, and had provided us
with what can only be described as a very poor requirement
specification. The problem was that this interaction with the customer
had never before taken place despite how far the software development
had gone. Even now there is the odd bit where what we are doing is
incompatible with their requirements (but that is mainly because they
changed one end of a timing requirement on an interface without
bothering to change the other end!).

I am convinced that with more effort in that area we are likely to see
a great improvement in the quality and reliability of software in
spaceborne equipment.

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

Re: Ariane 5 - not an exception?

[Greg Bond]

John McCabe wrote:
> snip...
>
> I find it difficult to understand why the design and development team
> even considered maintaining the CPU load at <80% for this particular
> case. If they requested a waiver on that margin and were refused then
> obviously their prime contractor (or whatever) is to blame, but there
> is no way that CPU loadings with margins of 20% should have been
> enforced at the risk of mission failure.
> 
> <..snip..>

Correct me if I'm wrong, but doesn't a lower CPU utilization help ensure
that hard deadlines will be met in exceptional copmutational
circumstances (thereby helping to prevent mission failure....)?

--
* Greg Bond                         * Dept. of Electrical Eng.  
* email: bond@ee.ubc.ca             * Univ. of British Columbia      
* voice: (604) 822 0899             * 2356 Main Mall                 
* fax:   (604) 822 5949             * Vancouver, BC              
* web: http://www.ee.ubc.ca/~bond   * Canada, V6T 1Z4

Re: Ariane 5 - not an exception?

[John McCabe]

Greg Bond <bond@ee.ubc.ca> wrote:

>John McCabe wrote:
>> snip...
>>
>> I find it difficult to understand why the design and development team
>> even considered maintaining the CPU load at <80% for this particular
>> case. If they requested a waiver on that margin and were refused then
>> obviously their prime contractor (or whatever) is to blame, but there
>> is no way that CPU loadings with margins of 20% should have been
>> enforced at the risk of mission failure.
>> 
>> <..snip..>

>Correct me if I'm wrong, but doesn't a lower CPU utilization help ensure
>that hard deadlines will be met in exceptional copmutational
>circumstances (thereby helping to prevent mission failure....)?

Yes, that is also true, but if adequate analysis and testing of
real-life situations take place, then this requirement should be
waived. On my current program we have performed these analyses to
discover exactly what can happen and when, and this takes into account
things that may happen but aren't supposed to. We can therefore ensure
(withiin reason) that the timing requirements we meet are realistic
but do not necessarily meet a (in our case) 30% margin.


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

Re: Ariane 5 - not an exception?

[Bill Angel]

In article <Dv45EJ.8r@fsa.bris.ac.uk>,
Simon Bluck <simonb@pact.srf.ac.uk> wrote:
>
>I.e. each data item would have a truth value of 1.0 for good data,
>0.0 for absolutely rotten data, utilising values in between if you
>have some idea how good the data is...Taking a probabilistic 
>attitude to data would bring a lot of software into the real world where
>failures can happen at all levels...

I believe that your idea is a very valid one.

It is so valid, that someone else has already thought of it!

You should check out the topic of "fuzzy logic" as it is applied to
industrial control. As you are suggesting, "fuzzy logic" allows one to
determine the membership of some measurement in the set comprised of "good
data". "Fuzzy logic" can also formulate a response when the input data
from various measurements yield conflicting directives as to how the
system should behave. If necessary, the response (to conflicting, out of
range, or inconsistent measurements) could be specified as a set of
directives with different precedence levels.  The directives could be
"heuristic" in nature and could have been  specified by human experts
during the analysis/design stage of the project. 

 -- Bill Angel

Re: Ariane 5 - not an exception?

[Dr. Richard Botting]

Simon Bluck at University of Bristol, England asserted incorrectly:
>>Exceptions and assertions are both used, in Ada and C/C++
Ada has no assertions.
C/C++ assertions are a debugging aid.

--
dick botting     http://www.csci.csusb.edu/dick/signature.html
Disclaimer:      CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
	I have nothing to sell, and I'm giving it away.

Re: Ariane 5 - not an exception?

[David Weller]

In article <4tjr76$ktj@news.csus.edu>,
Dr. Richard Botting <dick@silicon.csci.csusb.edu> wrote:
>Simon Bluck at University of Bristol, England asserted incorrectly:
>>>Exceptions and assertions are both used, in Ada and C/C++
>Ada has no assertions.

	Bzzt!  Wrong, but thank you for playing.  GNAT, by far the
	most popular Ada 95 compiler, supports 'pragma Assert'.

>C/C++ assertions are a debugging aid.
>

C/C++ assertions are not part of the language, but part of a separate
library (assert.h).  

That being said, assertions are indeed a useful debugging aid -- in
both Ada 95 and C :-)


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

Re: Ariane 5 - not an exception?

[Robert Dewar]

iDavid Weller said

"C/C++ assertions are not part of the language, but part of a separate
library (assert.h)."

Is this true? I thought that at least the draft standard for C++
included this library. I don't know about ANSI C?

Libraries that are included in the ANSI C standard or C++ DIS are every
much a part of the language as the if statement -- the same is true
of course for Annex A in the Ada 95 standard.

Re: Ariane 5 - not an exception?

[Marin David Condic, 407.796.8997, M/S 731-93]

Francis Lipski <g1006@FS1.MAR.LMCO.COM> writes (with deletions):
>> > "A PL/I programmer
>> > experienced with real time systems, would have CHALLENGED
>> > such a stupid requirement that the computer be shut down by the
>> > error-handler in the event of a fixed-point overflow.  He would
>> > have had it changed.
>
>   Not always possible.  If you are in the minority and are unsuccessful
>to argue others to your point, what do you do?
>
    That's not always the case. Sometimes, the issue is "Either we do
    the project with runtime checks supressed or we don't do it at all
    because we don't have the CPU margin to make it work." Often what
    you do is turn off most or all of the runtime checks, then
    implement interrupt service routines to saturate math results on
    overflows, etc. and hope that will do the trick for any
    unanticipated errors.

    If they were running at 80% utilization without runtime checks,
    including the checks might have left an unacceptable risk. If they
    had run with checks in place and were at 98% utilization and hit a
    "corner case" in the software which drove them over 100%, we'd be
    able to sit here now and criticize them for failing to remove the
    checks to leave a safety margin on utilization.

    There's always tradeoffs in engineering. You have to weigh risks
    and rewards. Risk: public humiliation, billions of $ lost,
    thousands of casualties. Reward: a certificate with your name on
    it in a plastic frame. The Ariane 5 engineers have no doubt
    learned this lesson.

    With respect to the earlier poster's comments about "experienced
    PL/I programmers" I'd have to say that smacks of language bigotry.
    It would be the same sort of thing as saying "experienced German
    speaking engineers wouldn't have made such a stupid mistake. It's
    because the engineers were speaking French that the rocket went
    down."

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Some people say the rainforests must be saved because the cure for
    cancer might be there. Why aren't these same people worried that
    the scientist who would have found that cure might be aborted?"

        --  John Switzer
===============================================================================

Re: Ariane 5 - not an exception?

[John McCabe]

>    If they were running at 80% utilization without runtime checks,
>    including the checks might have left an unacceptable risk. If they
>    had run with checks in place and were at 98% utilization and hit a
>    "corner case" in the software which drove them over 100%, we'd be
>    able to sit here now and criticize them for failing to remove the
>    checks to leave a safety margin on utilization.

True, but even with a maximum limit of 80% utilisation, it's going to
be very difficult to guarantee that you are never going to exceed
100%.

The program I am on now has a 70% loading requirement, but we have
~8us on a 10MHz 1750A processor to do some work. Now, as you will know
from your own experience of 1750A, 8us is not a lot of instructions!
There is no way we can satisfy the loading requirement (which would
allow us ~5.6us) on that particular case, in actual fact we use about
7us nominally. There is nothing more we can do about it though as we
have already coded that section in assembler, but we have analysed the
consequences of going over 100% and taken account of them in our
system design. 

The point I am trying to make here is that I believe that the success
of a mission should never be traded off against such an arbitrary
requirement as a loading margin.

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

Re: Ariane 5 - not an exception?

[Marin David Condic, 407.796.8997, M/S 731-93]

John McCabe <john@ASSEN.DEMON.CO.UK> writes:
>The point I am trying to make here is that I believe that the success
>of a mission should never be traded off against such an arbitrary
>requirement as a loading margin.
>
    Well, I have to agree that the important thing is mission success,
    not loading margin. But the general reason you establish some sort
    of "goal" for margin is to insure mission success. When going to
    Zero Margin (or worse) means dropping the rocket in the drink, not
    leaving yourself some room for "corner cases" which you never
    tested could be construed as imprudent - just as turning off
    checks could be considered imprudent. Had the "unanticipated case"
    never occurred, the software developers would have been "heros"
    and would have been given a certificate with their name on it in a
    cheap plastic frame. They took a gamble and lost, so now they get
    to be the scapegoats for us to kick around for a while.

    I'll admit that I also dislike setting some absolute number for
    CPU margin and sticking to it blindly. Eroding margin simply
    erodes the level of confidence and you can afford to do that
    sometimes. Especially if you're willing to do the work to
    demonstrate that you really have found the worst-case behavior or
    that the system is sufficiently deterministic that you can run
    with less margin and maintain sufficient confidence. (Define
    "sufficient confidence...")

    Lots of people have tried to make the case that you should never
    turn off the runtime checks that Ada provides because they're
    critical to the safety of the system you are developing. I'd like
    to agree and certainly Ariane 5 is an example of where this might
    have prevented disaster. But sometimes us poor saps who have
    nothing to work with but a Mil-Std-1750a are stuck making
    tradeoffs between safety checks and building a system that will
    work at all.

    Anybody want to make me a rad-hard, space tested, 200mips
    processor that I can buy in small lots at $40 a piece and has a
    full suite of development tools (including Ada95 compiler)
    available for it? (Sober up, Marin! ;-)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Being in a minority, even a minority of one, did not make you
    mad. There was truth, and there was untruth, and if you clung to
    the truth even against the whole world, you were not mad. 'Sanity
    is not statistical.'"

        --  G. Orwell, "1984"
===============================================================================

Re: Ariane 5 - not an exception?

[John McCabe]

"Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>
wrote:

<..snip..>

>    Anybody want to make me a rad-hard, space tested, 200mips
>    processor that I can buy in small lots at $40 a piece and has a
>    full suite of development tools (including Ada95 compiler)
>    available for it? (Sober up, Marin! ;-)

Wow, that would be nice - that would make my job such a lot easier :-)

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

Re: Ariane 5 - not an exception?

[Marin David Condic, 407.796.8997, M/S 731-93]

++ robin <rav@GOANNA.CS.RMIT.EDU.AU> writes:
>---As I stated, a PL/I programmer experienced in real-time
>programming, would not have made this stupid mistake.
>

    This still smacks of language bigotry. Why is it that only an
    experienced PL/I programmer would not make this "mistake"? I've
    personally seen *lots* of mistakes made by many "experienced"
    programmers in just about every language there is - including
    PL/I.

    Just remember that Ada has built-in runtime checks on conversions
    and the ability to write interrupt service routines as well. (And
    we "experienced Ada programmers" know how to use them, too!) The
    monday morning quarterbacks with 20/20 hindsight binoculars can
    easily see that the best thing would have been to leave in the
    checks or write an ISR which saturated the math rather than shut
    the unit down. But you don't need to be fluent in PL/I to see
    that.

    The language the system was programmed in or the language spoken
    by the developers has nothing to do with the error that occurred.
    It occurred because there was a conscious decision on someone's
    part to remove the safety net and to handle all exceptions by
    shutting down the channel. The designers no doubt made this
    decision for engineering reasons that are more complex than are
    outlined in the failure report and certainly had little or nothing
    at all to do with the language of implementation. And sitting in
    the back-seat after the crash telling the driver "If *I* had been
    driving, I'd never have crashed..." is condescending as well as
    being completely unprovable.

    MDC


Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "It may be true that the law cannot make a man love me. But it can
    keep him from lynching me, and I think that's pretty important."

            --  Rev. Martin Luther King, Jr
===============================================================================

Re: Ariane 5 - not an exception?

[John McCabe]

"Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM>
wrote:

<..snip..>
>    ... the language spoken
>    by the developers has nothing to do with the error that occurred.

I wouldn't be too sure about that - cultural differences can
contribute to that kind of thing. As part of an Anglo-French company I
have become aware of the cultural differences between the British
"test to destruction" culture and the French "Analyse to distraction"
culture.

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