Re: Ariane 5 - not an exception?

[Richard Riehle <rriehle@nunic.nu.edu>]

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