Boeing and Dreamliner

Boeing and Dreamliner

[Robert Love]

Now that Boeing has announced the 7E7 I'll be curious to see how much 
they Ada they use.  I'm sure that the "internet aboard" will all be COTS.  
And I'm sure a lot will be common with their earlier aircraft but if 
they have to create new flight control systems, will they still choose 
Ada?  It would be the rational decision but I see the C++ steam roller 
just bulldozing everything.

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <20030619221951073-0500@library.airnews.net>, Robert Love <rblove@airmail.net> writes:
> Now that Boeing has announced the 7E7 I'll be curious to see how much 
> they Ada they use.  I'm sure that the "internet aboard" will all be COTS.  

That is a reasonable use for non-Ada COTS.  You would not expect them to
use titanium for the magazine racks.

Re: Boeing and Dreamliner

[Matt Brenneke]

Robert Love <rblove@airmail.net> wrote in message news:<20030619221951073-0500@library.airnews.net>...
> Now that Boeing has announced the 7E7 I'll be curious to see how much 
> they Ada they use.  I'm sure that the "internet aboard" will all be COTS.  
> And I'm sure a lot will be common with their earlier aircraft but if 
> they have to create new flight control systems, will they still choose 
> Ada?  It would be the rational decision but I see the C++ steam roller 
> just bulldozing everything.

I'm an intern at Boeing St. Louis this summer, and from what the head
of the software dept. told me, there is the big "C++ steam roller"
coming along through many projects.  There is still a lot of Ada left
in Weapons and other things though.  ex. For my assignment this summer
I had to learn Ada to write a simulation, which reading months of this
newsgroup through google helped me do :-)

Re: Boeing and Dreamliner

[Wojtek Narczynski]

> I'm an intern at Boeing St. Louis this summer, and from what the head
> of the software dept. told me, there is the big "C++ steam roller"
> coming along through many projects. 

I wonder, does something really bad need to happen to "unroll" C++?

Regards,
Wojtek

Re: Boeing and Dreamliner

[Jeffrey Carter]

Robert Love wrote:
> Now that Boeing has announced the 7E7 I'll be curious to see how much 
> they Ada they use.  I'm sure that the "internet aboard" will all be COTS.  
> And I'm sure a lot will be common with their earlier aircraft but if 
> they have to create new flight control systems, will they still choose 
> Ada?  It would be the rational decision but I see the C++ steam roller 
> just bulldozing everything.

For Boeing the question should be, "How much will it cost to develop S/W 
to safely fly hundreds of people in language X?" Ada still has a 
tremendous advantage in that kind of situation. Achieving the necessary 
reliability in most other languages, including C++, is significantly 
more expensive than in Ada. Add to that the added cost of adding C++ to 
existing Ada code, compared to doing the new code in Ada, and the 
business decision should still point to Ada.

Unlike gov't contracts, this is not a case where more expensive equals 
more profitable.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail

Re: Boeing and Dreamliner

[Jeffrey Carter]

Mark Lorenzen wrote:
> 
> But the infamous: "But, we can't find any Ada programmers..."
> argument still sits in its dark and damp corner of a manager's office
> and just waits to be spoken out loud. Sadly.

Even with the cost of training and retaining staff, the business 
decision should still point to Ada.

> 
> And now C++ is used for JSF. So the "If C++ is good enough for the
> worlds most expensive and advanged figther jet, then it surely is good
> enough for a civilian passenger jet" argument will also be used.

JSF is a gov't contract, where more expensive = more profitable, so 
choosing C++ is a good business decision, though a poor technical one. 
Commercial airliner S/W is not that kind of situation. The question 
shouldn't be what language is good enough (since the compiler produces 
machine code, obviously machine code is "good enough"), it's how much it 
costs to achieve the necessary reliability in the language. Machine 
could is orders of magnitude more expensive than C++, and C++ is about 
an order of magnitude more expensive than Ada.

Boeing would have to be pretty stupid to use C++ for its commercial 
airliner S/W. Unfortunately, stupidity is not in short supply.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail

Re: Boeing and Dreamliner

[Mark Lorenzen]

Jeffrey Carter <spam@spam.com> writes:

> For Boeing the question should be, "How much will it cost to develop
> S/W to safely fly hundreds of people in language X?" Ada still has a
> tremendous advantage in that kind of situation. Achieving the
> necessary reliability in most other languages, including C++, is
> significantly more expensive than in Ada. Add to that the added cost
> of adding C++ to existing Ada code, compared to doing the new code in
> Ada, and the business decision should still point to Ada.
> 

But the infamous: "But, we can't find any Ada programmers..."
argument still sits in its dark and damp corner of a manager's office
and just waits to be spoken out loud. Sadly.

And now C++ is used for JSF. So the "If C++ is good enough for the
worlds most expensive and advanged figther jet, then it surely is good
enough for a civilian passenger jet" argument will also be used.

We live in sad times.

- Mark

Re: Boeing and Dreamliner

[Mark A. Biggar]

Larry Kilgallen wrote:
> In article <20030619221951073-0500@library.airnews.net>, Robert Love <rblove@airmail.net> writes:
> 
>>Now that Boeing has announced the 7E7 I'll be curious to see how much 
>>they Ada they use.  I'm sure that the "internet aboard" will all be COTS.  
> 
> 
> That is a reasonable use for non-Ada COTS.  You would not expect them to
> use titanium for the magazine racks.

Perfectly reasonable.  If I was part of the 7E7 design team I would
insist that the "internet aboard" system be a complete isolated stand
alone system that shared at most power supply with the rest of the
plane.  And if I were part of the FAA certification team I wouldn't
approve it otherwise.  So a COTS solution to "internet aboard" makes
sense.  I'd still want to use Ada for the avionics.

--
Mark@biggar.org

RE: Boeing and Dreamliner

[rleif]

All the Boeing management need to do is read the JAVA and C# literature on
why these languages were created. Choosing an inferior technology is bad;
choosing and inferior, obsolete technology is worse. 

I might note that there are enough potential expert witnesses in this group
to cause Boeing grave financial damage in the event management is negligent
in the choice of programming language and this negligence leads to deaths or
injuries.

Bob Leif

-----Original Message-----
From: Wojtek Narczynski [mailto:wojtek@power.com.pl] 
Sent: Friday, June 20, 2003 10:23 AM
To: comp.lang.ada@ada.eu.org

> I'm an intern at Boeing St. Louis this summer, and from what the head
> of the software dept. told me, there is the big "C++ steam roller"
> coming along through many projects. 

I wonder, does something really bad need to happen to "unroll" C++?

Regards,
Wojtek

RE: Boeing and Dreamliner

[rleif]

The level of safety required for a commercial airliner is higher than for a
fighter jet.
Bob Leif

-----Original Message-----
From: Mark Lorenzen [mailto:mark.lorenzen@ofir.dk] 
Sent: Friday, June 20, 2003 3:41 PM
To: comp.lang.ada@ada.eu.org

Jeffrey Carter <spam@spam.com> writes:

> For Boeing the question should be, "How much will it cost to develop
> S/W to safely fly hundreds of people in language X?" Ada still has a
> tremendous advantage in that kind of situation. Achieving the
> necessary reliability in most other languages, including C++, is
> significantly more expensive than in Ada. Add to that the added cost
> of adding C++ to existing Ada code, compared to doing the new code in
> Ada, and the business decision should still point to Ada.
> 

But the infamous: "But, we can't find any Ada programmers..."
argument still sits in its dark and damp corner of a manager's office
and just waits to be spoken out loud. Sadly.

And now C++ is used for JSF. So the "If C++ is good enough for the
worlds most expensive and advanged figther jet, then it surely is good
enough for a civilian passenger jet" argument will also be used.

We live in sad times.

- Mark

Re: Boeing and Dreamliner

[Preben Randhol]

Mark Lorenzen wrote:
> 
> And now C++ is used for JSF. So the "If C++ is good enough for the
> worlds most expensive and advanged figther jet, then it surely is good
> enough for a civilian passenger jet" argument will also be used.

Are you going to equip every seat with ejector button and a parachute on
civilian passenger jets now?

Preben

Re: Boeing and Dreamliner

[Bobby D. Bryant]

On Sat, 21 Jun 2003 08:05:51 +0000, Preben Randhol wrote:

> Mark Lorenzen wrote:
>> 
>> And now C++ is used for JSF. So the "If C++ is good enough for the
>> worlds most expensive and advanged figther jet, then it surely is good
>> enough for a civilian passenger jet" argument will also be used.
> 
> Are you going to equip every seat with ejector button and a parachute on
> civilian passenger jets now?

Ah, so _that_ is how the "throw" and "catch" error handlers work!

-- 
Bobby Bryant
Austin, Texas

Re: Boeing and Dreamliner

[Preben Randhol]

Bobby D. Bryant wrote:
> On Sat, 21 Jun 2003 08:05:51 +0000, Preben Randhol wrote:
> 
>> Mark Lorenzen wrote:
>>> 
>>> And now C++ is used for JSF. So the "If C++ is good enough for the
>>> worlds most expensive and advanged figther jet, then it surely is good
>>> enough for a civilian passenger jet" argument will also be used.
>> 
>> Are you going to equip every seat with ejector button and a parachute on
>> civilian passenger jets now?
> 
> Ah, so _that_ is how the "throw" and "catch" error handlers work!

Hehehe.

Preben
-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Pascal Obry]

mbrennek@umr.edu (Matt Brenneke) writes:

> I'm an intern at Boeing St. Louis this summer, and from what the head
> of the software dept. told me, there is the big "C++ steam roller"
> coming along through many projects.  There is still a lot of Ada left
> in Weapons and other things though.  ex. For my assignment this summer
> I had to learn Ada to write a simulation, which reading months of this
> newsgroup through google helped me do :-)

Hum, they will use C++ for commercial planes... and Ada for high-secure
software in weapons !!!! Are people on a plane less important than
weapons trajectory ? :)

Pascal.

-- 

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

Re: Boeing and Dreamliner

[Hyman Rosen]

rleif wrote:
> All the Boeing management need to do is read the JAVA and C# literature on
> why these languages were created. Choosing an inferior technology is bad;
> choosing and inferior, obsolete technology is worse. 
> 
> I might note that there are enough potential expert witnesses in this group
> to cause Boeing grave financial damage in the event management is negligent
> in the choice of programming language and this negligence leads to deaths or
> injuries.

Ada made the Ariane 5 crash!

Re: Boeing and Dreamliner

[Preben Randhol]

Hyman Rosen wrote:
> Ada made the Ariane 5 crash!

Oh?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <zN9Ja.2184$N%6.569@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> rleif wrote:
>> All the Boeing management need to do is read the JAVA and C# literature on
>> why these languages were created. Choosing an inferior technology is bad;
>> choosing and inferior, obsolete technology is worse. 
>> 
>> I might note that there are enough potential expert witnesses in this group
>> to cause Boeing grave financial damage in the event management is negligent
>> in the choice of programming language and this negligence leads to deaths or
>> injuries.
> 
> Ada made the Ariane 5 crash!

Inappropriate software reuse, possibly caused by management pennypinching,
made the Ariane 5 crash.

Re: Boeing and Dreamliner

[Marin David Condic]

Do I detect a troll??? ;-)

MDC

Larry Kilgallen wrote:
> In article <zN9Ja.2184$N%6.569@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
>>
>>Ada made the Ariane 5 crash!
> 
> 
> Inappropriate software reuse, possibly caused by management pennypinching,
> made the Ariane 5 crash.


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

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

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

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

Re: Boeing and Dreamliner

[James Rogers]

Marin David Condic <nobody@noplace.com> wrote in
news:3EF5B10E.40804@noplace.com: 

> Do I detect a troll??? ;-)
> 

I believe the point was that expert witnesses could not show that
using Ada by itself prevents class A mishaps. In that respect he
is correct. The remark was in response to the assertion that this
newsgroup could provide many expert witnesses to support a claim
that use of C++ in avionics was irresponsible.

The problem is that such testimony is highly technical.
Such a technical level of information is easily distorted by a
clever lawyer who relies upon the confusion of the judge and
jury. A question about the Ariane 5 would be the opening argument
from such a lawyer.

Jim Rogers

Re: Boeing and Dreamliner

[Vinzent Hoefler]

Hyman Rosen wrote:

>Ada made the Ariane 5 crash!

Of course it did. This problem always occurs, when someone expects a
washing machine control program to handle the nuclear reactor of a
submarine.


SCNR,

Vinzent.

Re: Boeing and Dreamliner

[Dmitry A. Kazakov]

James Rogers wrote:

> I believe the point was that expert witnesses could not show that
> using Ada by itself prevents class A mishaps. In that respect he
> is correct. The remark was in response to the assertion that this
> newsgroup could provide many expert witnesses to support a claim
> that use of C++ in avionics was irresponsible.
> 
> The problem is that such testimony is highly technical.
> Such a technical level of information is easily distorted by a
> clever lawyer who relies upon the confusion of the judge and
> jury. A question about the Ariane 5 would be the opening argument
> from such a lawyer.

True, one should argue on same level of [in]competence. Isn't the time to 
start sampling examples of crashes C/C++, C#, Java systems?

At AdaPower?

It would be nice to present our customers tables and graphs of overall 
losses caused by C++ software per year.

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

Re: Boeing and Dreamliner

[Frank J. Lhota]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:BlP8QhSlZjC+@eisner.encompasserve.org...
> In article <zN9Ja.2184$N%6.569@nwrdny02.gnilink.net>, Hyman Rosen
<hyrosen@mail.com> writes:
> > rleif wrote:
> >> All the Boeing management need to do is read the JAVA and C# literature
on
> >> why these languages were created. Choosing an inferior technology is
bad;
> >> choosing and inferior, obsolete technology is worse.
> >>
> >> I might note that there are enough potential expert witnesses in this
group
> >> to cause Boeing grave financial damage in the event management is
negligent
> >> in the choice of programming language and this negligence leads to
deaths or
> >> injuries.
> >
> > Ada made the Ariane 5 crash!
>
> Inappropriate software reuse, possibly caused by management pennypinching,
> made the Ariane 5 crash.

All of this was hashed out years ago in the "Ariane 5 failure" thread from
several years ago. See

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=325572AA.4663%40delphi.com&rnum=6&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DISO-8859-1%26safe%3Doff%26q%3D%2522Ariane%2B5%2522%26meta%3Dgroup%253Dcomp.lang.ada

Re: Boeing and Dreamliner

[Tino Goertemoeller]

Dmitry A. Kazakov wrote:

> James Rogers wrote:
> 
>> I believe the point was that expert witnesses could not show that
>> using Ada by itself prevents class A mishaps. In that respect he
>> is correct. The remark was in response to the assertion that this
>> newsgroup could provide many expert witnesses to support a claim
>> that use of C++ in avionics was irresponsible.
>> 
>> The problem is that such testimony is highly technical.
>> Such a technical level of information is easily distorted by a
>> clever lawyer who relies upon the confusion of the judge and
>> jury. A question about the Ariane 5 would be the opening argument
>> from such a lawyer.
> 
> True, one should argue on same level of [in]competence. Isn't the time to
> start sampling examples of crashes C/C++, C#, Java systems?


http://www-aix.gsi.de/~giese/swr/index.html  (german)

Re: Boeing and Dreamliner

[Robert I. Eachus]

Hyman Rosen wrote:

> Ada made the Ariane 5 crash!

No, stupid management decisions made Ariane 5 crash.  This is one of 
those stories where the truth really needs to catch up to the rumor. 
Some brilliant management type had the idea that reusing the flight 
control software from the Arianne 4 on Ariane 5 would save lots of money 
on testing and verification.  As a result, and for political reasons, 
there was no Ariane 5 contractor who even got to see the Ariane 4 source 
code.

And awful lot of analysis has been written looking at the chain of 
events that caused the Ariane 5 failure.  But what is usually missed 
happened way downstream of the unhandled exception.  The engines were 
commanded to deflect beyond what the stack could take, and the Arianne 5 
broke up.  How could THAT happen?  The reuse included the flight 
dynamics profile for the Arianne 4!  Since the Arianne 4 had smaller 
moments and a larger tolerance for guidance inputs, ANY significant 
correction sent to the engines, such as hitting wind shear, would have 
pushed the software into a regime where errors would build up. 
Eventually the commanded input would exceed the stack's structural 
limits and destroy everything.

There was some indication that such errors had occured during the 39 
seconds of flight, but all had been small enough errors to be damped out 
by other deviations.

Or to vastly simplify, the Arianne 5 would have been better off with no 
guidance system than with an Arianne 4 guidance system.  In that case, 
there would have been some small chance that it would actually perform 
as expected.  Or if the profile for the first flight had been slightly 
different so that the error that did occur would have been pushed from 
39+ seconds to 40, and thus safe, the launch would have failed anyway. 
There was no way the actual guidance system could achieve a working orbit.

Re: Boeing and Dreamliner

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

>         Lazy programmers who didn't check the performance spec for their 
> attempted reuse caused the crash

As I understand it, project management decided to reuse the Ariane 4
software and would not allow anyone to check performance againse the
new flight profile.

I don't believe this sort of problem could ever be just down to lazy
programmers, that implies a completely laissez-faire attitude on the
part of engineering management, design authorities, system engineering
...

Re: Boeing and Dreamliner

[John R. Strohm]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns93A25BF6DF4E2jimmaureenrogers@204.127.36.1...
> Marin David Condic <nobody@noplace.com> wrote in
> news:3EF5B10E.40804@noplace.com:
>
> > Do I detect a troll??? ;-)
> >
>
> I believe the point was that expert witnesses could not show that
> using Ada by itself prevents class A mishaps. In that respect he
> is correct. The remark was in response to the assertion that this
> newsgroup could provide many expert witnesses to support a claim
> that use of C++ in avionics was irresponsible.
>
> The problem is that such testimony is highly technical.

The real test of an expert is his ability to present information in a way
that a layman can understand it.

Richard Feynman's freshman lectures on physics, and his WONDERFUL little
book "QED" (quantum electrodynamics for the man in the street) come
immediately to mind.  The fundamental test of whether one really understands
the topic is whether one CAN prepare a "freshman lecture" (or a "man in the
street" book or article) on it.

RE: Boeing and Dreamliner

[rleif]

The Ariane 5 software did exactly as it was supposed to. The argument about
lawyers cuts both ways. A good lawyer could, just as well, count on the
distrust of big business by the jury. Obviously, there is no certitude in
jury and even judicial decisions. However, a reasonable deterrent need not
be 100 percent reliable to have a positive effect.

Bob Leif

-----Original Message-----
From: James Rogers [mailto:jimmaureenrogers@att.net] 
Sent: Sunday, June 22, 2003 8:06 AM
To: comp.lang.ada@ada.eu.org

Marin David Condic <nobody@noplace.com> wrote in
news:3EF5B10E.40804@noplace.com: 

> Do I detect a troll??? ;-)
> 

I believe the point was that expert witnesses could not show that
using Ada by itself prevents class A mishaps. In that respect he
is correct. The remark was in response to the assertion that this
newsgroup could provide many expert witnesses to support a claim
that use of C++ in avionics was irresponsible.

The problem is that such testimony is highly technical.
Such a technical level of information is easily distorted by a
clever lawyer who relies upon the confusion of the judge and
jury. A question about the Ariane 5 would be the opening argument
from such a lawyer.

Jim Rogers

Re: Boeing and Dreamliner

[Robert I. Eachus]

John R. Strohm wrote:

> Richard Feynman's freshman lectures on physics, and his WONDERFUL little
> book "QED" (quantum electrodynamics for the man in the street) come
> immediately to mind.  The fundamental test of whether one really understands
> the topic is whether one CAN prepare a "freshman lecture" (or a "man in the
> street" book or article) on it.

Your point is well taken, but the Feyman lectures are a bad example. 
Yes, they are readable and understandable, and anyone with a PhD in 
Physics who hasn't read them should remedy that mistake.

But when Feynman originally gave the course, the Freshman were soon 
outnumbered by the rest of the Physics Faculty, grad students, TAs for 
the course, and  some guest faculty from other schools.  Freshman can 
learn from them, but grad students and PhDs find there is so much more 
information in there.

Another similar example is the recent proof of Fermat's Last Theorem. 
The proof was published in a book, and is readable. But you have to have 
a pretty thorough grounding in half a dozen areas of math to understand 
all the implications and asides.  (I caught maybe 10%.)

Re: Boeing and Dreamliner

[AG]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:BlP8QhSlZjC+@eisner.encompasserve.org...

> In article <zN9Ja.2184$N%6.569@nwrdny02.gnilink.net>, Hyman Rosen
<hyrosen@mail.com> writes:
> > Ada made the Ariane 5 crash!
>
> Inappropriate software reuse, possibly caused by management pennypinching,
> made the Ariane 5 crash.

Anybody heard of the force of gravity?  :-)

Understanding and Teaching: Who may teach Ada?

[Georg Bauhaus]

Robert I. Eachus <rieachus@attbi.com> wrote:
: John R. Strohm wrote:
: 

:> The fundamental test of whether one really understands
:> the topic is whether one CAN prepare a "freshman lecture" (or a "man in the
:> street" book or article) on it.

In a better world, this phrase should be put in a frame,
and teachers should not be employed if they fail.
Maybe the test should be more flexible, offering a choice
of audience, but only for the test.
Do you think that Feynman might have succeeded in teaching
"real" average Freshman, had he been under more pressure?

: Your point is well taken, but the Feyman lectures are a bad example. 
: Yes, they are readable and understandable, and anyone with a PhD in 
: Physics who hasn't read them should remedy that mistake.
: 
: But when Feynman originally gave the course, the Freshman were soon 
: outnumbered ...

(The same arguments might apply to teaching Ada, or programming.)

Re: Boeing and Dreamliner

[Robert Kaiser]

In article <ZhPIa.48441$Fa6.33594@sccrnsc02>,
	"Mark A. Biggar" <mark@biggar.org> writes:
> If I was part of the 7E7 design team I would
> insist that the "internet aboard" system be a complete isolated stand
> alone system that shared at most power supply with the rest of the
> plane.  And if I were part of the FAA certification team I wouldn't
> approve it otherwise.

Is physical isolation of the system really a requirement? AFAIK DO-178B
explicitly allows for software partitioning. (I.e. suppose I had a kernel
that can provide -say- an Ada runtime system and a Linux environment
in the same physical machine, protected from each other by the MMU, and
I could prove that there is no way for those systems to interfere.)

I'd be interested to hear what people in this NG would would think
about something like that.

Rob

-- 
Robert Kaiser                     email: rkaiser AT sysgo DOT de
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.de

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <HNzJa.45996$JA5.801194@news.xtra.co.nz>, "AG" <ang@xtra.co.nz> writes:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:BlP8QhSlZjC+@eisner.encompasserve.org...
> 
>> In article <zN9Ja.2184$N%6.569@nwrdny02.gnilink.net>, Hyman Rosen
> <hyrosen@mail.com> writes:
>> > Ada made the Ariane 5 crash!
>>
>> Inappropriate software reuse, possibly caused by management pennypinching,
>> made the Ariane 5 crash.
> 
> Anybody heard of the force of gravity?  :-)

-- 

Gravity: It's the Law.

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <bd6lor$sq0$2@dagobert.svc.sysgo.de>, bitbucket@invalid-domain-see-sig.nil (Robert Kaiser) writes:
> In article <ZhPIa.48441$Fa6.33594@sccrnsc02>,
> 	"Mark A. Biggar" <mark@biggar.org> writes:
>> If I was part of the 7E7 design team I would
>> insist that the "internet aboard" system be a complete isolated stand
>> alone system that shared at most power supply with the rest of the
>> plane.  And if I were part of the FAA certification team I wouldn't
>> approve it otherwise.
> 
> Is physical isolation of the system really a requirement? AFAIK DO-178B
> explicitly allows for software partitioning. (I.e. suppose I had a kernel
> that can provide -say- an Ada runtime system and a Linux environment
> in the same physical machine, protected from each other by the MMU, and
> I could prove that there is no way for those systems to interfere.)

I don't understand how a Memory Management Unit could keep one of those
partitions from grabbing all the CPU time.

Re: Boeing and Dreamliner

[Martin Dowie]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:UnpZF+XVri0n@eisner.encompasserve.org...
> I don't understand how a Memory Management Unit could keep one of those
> partitions from grabbing all the CPU time.

The MMU doesn't but there are plenty of OS out there that allow mixed levels
of criticality programs to sit quite happily in the same box. So you could
have
you flight control and your in-flight cinema on the same card, if you wanted
;-)

see, www.csleos.com

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <3ef6f042$1@baen1673807.greenlnk.net>, "Martin Dowie" <martin.dowie@baesystems.com> writes:
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:UnpZF+XVri0n@eisner.encompasserve.org...
>> I don't understand how a Memory Management Unit could keep one of those
>> partitions from grabbing all the CPU time.
> 
> The MMU doesn't but there are plenty of OS out there that allow mixed levels
> of criticality programs to sit quite happily in the same box. So you could
> have
> you flight control and your in-flight cinema on the same card, if you wanted
> ;-)

Trusting such software to be perfect is precisely what is avoided by using
hardware.

Re: Boeing and Dreamliner

[Robert Kaiser]

In article <UnpZF+XVri0n@eisner.encompasserve.org>,
	Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> In article <bd6lor$sq0$2@dagobert.svc.sysgo.de>, bitbucket@invalid-domain-see-sig.nil (Robert Kaiser) writes:
>> In article <ZhPIa.48441$Fa6.33594@sccrnsc02>,
>> 	"Mark A. Biggar" <mark@biggar.org> writes:
>>> If I was part of the 7E7 design team I would
>>> insist that the "internet aboard" system be a complete isolated stand
>>> alone system that shared at most power supply with the rest of the
>>> plane.  And if I were part of the FAA certification team I wouldn't
>>> approve it otherwise.
>> 
>> Is physical isolation of the system really a requirement? AFAIK DO-178B
>> explicitly allows for software partitioning. (I.e. suppose I had a kernel
>> that can provide -say- an Ada runtime system and a Linux environment
>> in the same physical machine, protected from each other by the MMU, and
>> I could prove that there is no way for those systems to interfere.)
> 
> I don't understand how a Memory Management Unit could keep one of those
> partitions from grabbing all the CPU time.

Sorry, I forgot to mention this: Of course, an MMU can only help with
memory partitioning. In addition to that, a time partitioning mechanism
(e.g. something like an ARINC-(653?) scheduler) would be required, too. 

I'm thinking of a small (thus easily testable) kernel that implements
partitioning, where partitions are assigned individual subsets of the
hardware's resources (CPU time, memory, IO-space). In each partition,
it would provide enough mechanisms to support basically any OS, be it
some form of UNIX or an Ada runtime system.

I really don't want to start a technical discussion, I'm merely interested
in people's opinions whether something like this would stand any chance of
obtaining, e.g. FAA acceptance, whether it would be a worthwhile approach to
pursue, etc.

Rob

-- 
Robert Kaiser                     email: rkaiser AT sysgo DOT de
SYSGO AG                          http://www.elinos.com
Klein-Winternheim / Germany       http://www.sysgo.de

Re: Boeing and Dreamliner

[Martin Dowie]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:ZAEpZ6ty2RK4@eisner.encompasserve.org...
> Trusting such software to be perfect is precisely what is avoided by using
> hardware.

Very true but there are so few genuinely safety critical systems that having
a box sit there and basically waste CPU time isn't on - plus all the extra
weight of extra hardware etc. So, these certifiable OS, guarantee space
and, as you point out, *time* partitioning - so, that cinema system won't
hog a CPU.

It isn't easy to do - there is at least one OS from a well known vendor
that has allegedly had its 'brick wall partitioning' breached, but it isn't
impossible.

Re: Boeing and Dreamliner

[Wesley Groleau]

John R. Strohm wrote:
> The real test of an expert is his ability to present information in a way
> that a layman can understand it.

Sometimes, in a courtroom, what they want a
witness to do is confuse the jury.  Get them
to think, "I don't understand this, but he
seems to, so I'll take his word for it."

That may violate the principle of reasonable
doubt, but it nevertheless happens.

Of course, I speak of U.S. courts, which would
not be involved in an Ariane 4/5/6 case/  :-)

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

Preben Randhol wrote:
> Bobby D. Bryant wrote:
>>On Sat, 21 Jun 2003 08:05:51 +0000, Preben Randhol wrote:
>>>Mark Lorenzen wrote:
>>>
>>>>And now C++ is used for JSF. So the "If C++ is good enough for the
>>>>worlds most expensive and advanged figther jet, then it surely is good
>>>>enough for a civilian passenger jet" argument will also be used.
>>>
>>>Are you going to equip every seat with ejector button and a parachute on
>>>civilian passenger jets now?
>>
>>Ah, so _that_ is how the "throw" and "catch" error handlers work!
> 
> Hehehe.
> 
> Preben

If it were Ada, you would just have your seat "raised" instead of the
"throw" ;-)

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

Re: Boeing and Dreamliner

[Mike Silva]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrnbfast4.l1.randhol+abuse@kiuk0152.chembio.ntnu.no>...
> Hyman Rosen wrote:
> > Ada made the Ariane 5 crash!
> 
> Oh?

Hyman is playing devil's advocate here, and no doubt enjoying himself
immensely over the ruckus he's caused!

Re: Boeing and Dreamliner

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Ada made the Ariane 5 crash!

Hyman, are you going to play a Troll !

Pascal.

-- 

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

Re: Boeing and Dreamliner

[Mike Silva]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message news:<3EF5F3F3.6000806@attbi.com>...
> Hyman Rosen wrote:
> 
> > Ada made the Ariane 5 crash!
> 
> No, stupid management decisions made Ariane 5 crash.  This is one of 
> those stories where the truth really needs to catch up to the rumor. 

Unfortunately the rumor (unlike the truth) is an excellent club for
the hostile to use against Ada.  Of course they never bother to
explain how simply using another language would have prevented the
microprocessor Operand Error trap from happening on the fatal
FP-to-int conversion.

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>Another similar example is the recent proof of Fermat's Last Theorem.
>The proof was published in a book, and is readable. But you have to have
>a pretty thorough grounding in half a dozen areas of math to understand
>all the implications and asides.  (I caught maybe 10%.)

What is the title (and/or author) of that book?

Re: Understanding and Teaching: Who may teach Ada?

[Robert I. Eachus]

Georg Bauhaus wrote:
> Robert I. Eachus <rieachus@attbi.com> wrote:
> : John R. Strohm wrote:

> :> The fundamental test of whether one really understands
> :> the topic is whether one CAN prepare a "freshman lecture" (or a "man in the
> :> street" book or article) on it.
> 
> In a better world, this phrase should be put in a frame,
> and teachers should not be employed if they fail.
> Maybe the test should be more flexible, offering a choice
> of audience, but only for the test.

Definitely agree.

> Do you think that Feynman might have succeeded in teaching
> "real" average Freshman, had he been under more pressure?

I guess I didn't do a good job of making my point about the Feynman 
lectures.  They CAN be understood by a college freshman.  But the 
lectures work at several different levels.  You could take them every 
year for a half dozen years and learn a completely new set of 
information each time.

Sort of like "Alice in Wonderland" and "Through the Looking Glass." 
Delightful stories for children, but if you reread them in college, you 
find that there is a completely different world of informantion in them. 
  (In fact I almost borrowed from Humpty Dumpty and called the Feynman 
Lectures a portmanteau course.  But I wasn't sure how many readers would 
understand the reference.)  Snap quiz:  There are six (now) common 
English words which appeared for the first time in Jabberwocky.  Name 
them. ;-)  (If you really want to try here is a hint: 
http://tinyurl.com/f34d for what seems to be the hardest neologism to 
recognize today.)

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>Hyman Rosen wrote:
>
> > Ada made the Ariane 5 crash!
>
>No, stupid management decisions made Ariane 5 crash.

No, simple "stupid management" is not enough here. Something more technical
was rotten. There was not single decision (or couple of decisions) taken by
top level manager at the last moment - there was nothing like ordering a
launch despite inappropiate weather. It was a long project with many presumably
competent people involved; and it is important to investigate more deeply:
why consequences of initial wrong decision (which was made by incompetent
people) were not recognized by scientific and technical staff before the
actual failure happened.

>This is one of 
>those stories where the truth really needs to catch up to the rumor. 

It must be not so simple, because the "truth" position is vulnerable - I think
that I'd feel myself rather comfortable in devil's advocate role for that
dispute (despite of my ignorance - your excellent description/explanation of
the case is enough for me -:) .

>Some brilliant management type had the idea that reusing the flight 
>control software from the Arianne 4 on Ariane 5 would save lots of money 
>on testing and verification.  As a result, and for political reasons, 
>there was no Ariane 5 contractor who even got to see the Ariane 4 source 
>code.

Beautiful decision. But engines were new, so there was a contractor for them,
right? And that contractor probably has own scientists and engineers, right?
Were those scientists and engineers interested in successful flights? Probably
yes. Were they informed about the decision to use old flight control software
unchanged and untested for their new engines? If yes then how can they agree
to that decision? If not, why they were not alarmed by the absence of combined
testing?

>...
>The engines were 
>commanded to deflect beyond what the stack could take, and the Arianne 5 
>broke up.  How could THAT happen?  The reuse included the flight 
>dynamics profile for the Arianne 4!  Since the Arianne 4 had smaller 
>moments and a larger tolerance for guidance inputs, ANY significant 
>correction sent to the engines, such as hitting wind shear, would have 
>pushed the software into a regime where errors would build up. 
>Eventually the commanded input would exceed the stack's structural 
>limits and destroy everything.
>
>There was some indication that such errors had occured during the 39 
>seconds of flight, but all had been small enough errors to be damped out 
>by other deviations.

Obviously, all that would be caught during the tests (even if engines were
simulated, those errors would be caught)... Perhaps this is (in)famous
"culture barrier", but I can't get how can one even think about avoiding
combined system testing for such complex and costly systems.



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

Re: Boeing and Dreamliner

[Hyman Rosen]

The software which was reused was not "flight control software".
It was the alignment software for the Inertial Reference System
which contained the flaw, and when the flaw triggered and shut
down both SRIs, it sent out diagnostic data onto the bus which
got interpreted as valid data.

The main problem was that the people who wrote this software
didn't leave any indication behind that it was valid only for
data which could be encountered by an Ariane 4. Pure and simple,
the Ariane 4 programmers left a buffer overflow bug in their
code, and the Ariane 5 people tripped over it. The fact that it
was in Ada helped not at all.

Re: Boeing and Dreamliner

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> What is the title (and/or author) of that book?

"Fermat's Last Theorem: The Story of a Riddle That Confounded the 
World's Greatest Minds for 358 Years" by Simon Singh (Hardcover) Be 
careful, it is out of print, and Barnes & Noble lists several similar 
books by Singh, that may or may not be as good, including a recent 
paperback "Fermat's Last Theorem" and  "Fermat's Enigma: The Epic Quest 
to Solve the World's Greatest Mathematical Problem" by Simon Singh.  The 
first may be a cut down versions of the 1998 book, I don't know.  The 
second is more or less the script for the Nova episode "The Proof" which 
Singh put together.

Singh does a very good job of laying a trail of breadcrumbs that anyone 
should be able to follow.  But he also has lots of side trails and 
offhand remarks where you need your mountain climbing gear if you try to 
follow them.

Re: Boeing and Dreamliner

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<pNOJa.9904$Kg7.2691@nwrdny01.gnilink.net>...
> ...Pure and simple,
> the Ariane 4 programmers left a buffer overflow bug in their
> code, and the Ariane 5 people tripped over it. 

Good heavens, no, you're thinking of C!  There was no buffer overflow,
and there was no bug.  There was a float-to-int conversion that was
proven to be safe (FP value guaranteed to always fit into int) for the
-4.  Therefore, any conversion overflow was assumed to be caused by a
sensor/hardware problem and thus programmed by intention to shut down
the SDI and let the backup system take over.  There is no way I can
imagine that the -4 people can be accused of leaving a bug in the
code.  To me the situation is akin to correctly specifying a 5 Amp
fuse in a 4 Amp circuit, then "reusing" the circuit but now pumping 10
Amps through it.  When the 5A fuse blows, was that a design error in
the original circuit?

> The fact that it was in Ada helped not at all.

True enough, even though the exception was a hardware trap that would
have done the same thing regardless of language.

Mike

Re: Boeing and Dreamliner

[Hyman Rosen]

Mike Silva wrote:
> Good heavens, no, you're thinking of C!  There was no buffer overflow,
> and there was no bug.

The people who coded the Ariane 4 SRI never described, in
their program or in their documentation, the fact that if
the Horizontal Bias became too large, their alignment code
would blow up. The Ariane 5 people would have had no reason
to believe that they were getting code that depended on a
restricted trajectory to be valid. Why should they? The SRI
didn't even do anything useful after takeoff. It was a
perfectly natural assumption that they were getting SRI
software, not SRI-for-Ariane 4 software. Have a look at the
report - <http://java.sun.com/people/jag/Ariane5.html>.

Of course, these kinds of errors can happen in any language.
And that's the point. When certain people start claiming that
using C++ is an actionable offense, the Ariane 5 case shows
that using Ada is no panacea.

And just to make the buffer overflow analogy again, since you
don't seem to get it, what is a buffer overflow? It happens
when a programmer makes an assumption about the size of the
input he expects his program to receive, and circumstances
cause that size to be exceeded, whereupon the program functions
erroneously. Did that not happen in the Ariane 5 case? Is there
a statue of limitations on buffer overflows, so that if it takes
a long time for them to show up, the original programmer is not
to blame? If the programmer insists that the unchecked size
limits are needed, for efficiency, say, shouldn't the limits be
documented?

Re: Boeing and Dreamliner

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> No, simple "stupid management" is not enough here. Something more technical
> was rotten. There was not single decision (or couple of decisions) taken by
> top level manager at the last moment - there was nothing like ordering a
> launch despite inappropiate weather. It was a long project with many presumably
> competent people involved; and it is important to investigate more deeply:
> why consequences of initial wrong decision (which was made by incompetent
> people) were not recognized by scientific and technical staff before the
> actual failure happened.

I can give you some of the answers from memory, but the best thing to do 
is to actually read the technical report on what happened. (I found a 
copy at http://www.dcs.ed.ac.uk/home/pxs/Book/ariane5rep.html)  There 
are a number of places where the international politics are not included 
in the technical report.  But some political details are important.  The 
French didn't want Germans getting access to the Ariane 5 performance 
data, even though the SRI software was written by the English subsidiary 
of a German company, if I remember right.

But the real cap on the whole thing was that there was supposed to be a 
full up test rig which would allow system test for the gyros, the 
computers and the engine controls.  This test platform was behind 
schedule so the French decided to go ahead and launch without doing the 
test!  I don't know about the formal test methods in Russia, but in the 
US the common practice is to come up with a set of test objectives, then 
  assign them to one of four major categories.  In effect what happened 
was that ALL the guidance and engine control subsystems test objectives 
that were supposed to be Demoed (i.e. demonstrate that the subsystem 
does what it is supposed to do in operation) were signed off without 
ever being run.

But to me the crowning idiocy of the whole thing is in one sentence of 
the report: "The main explanation for the absence of this test has 
already been mentioned above, i.e. the SRI specification (which is 
supposed to be a requirements document for the SRI) does not contain the 
Ariane 5 trajectory data as a functional requirement."

The SRI requirements document was never updated for the Ariane 5, and as 
I pointed out, the software had built in parameters that reflected 
physical constants relating to the Ariane4.  Also, it doesn't take a 
genius to tell you what that ten second period of "pressure surges" in 
the flight control hydraulics was.  But of course the politics of the 
situation kept the fact that oscillations were building up in the stack 
from being an obvious part of the official report--and from being left 
out of it:

"One anomaly which was brought to the particular attention of the Board 
was the gradual development, starting at Ho + 22 seconds, of variations 
in the hydraulic pressure of the actuators of the main engine nozzle. 
These variations had a frequency of approximately 10 Hz.

"There are some preliminary explanations as to the cause of these 
variations, which are now under investigation.

"After consideration, the Board has formed the opinion that this 
anomaly, while significant, has no bearing on the failure of Ariane 501."

Don't you just love that attempted slight of hand?  The stack was 
swinging back and forth ten times a second.  (Of course it was, the 
control systems model didn't match the actual system.)  Before the 
oscillations got too bad, this other thing destroyed Ariane 501.  Of 
course, if you just fix that other bug, Ariane 502 will go boom! a 
little higher up.  But we aren't going to say that in public.

Re: Boeing and Dreamliner

[tmoran]

>what is a buffer overflow? It happens
>when a programmer makes an assumption about the size of the
  Whoa there!  A numerical value out of range is not a buffer overflow in
the languages used on c.l.a.  Surely as a programmer you appreciate the
value of precise expression.

Re: Boeing and Dreamliner

[Robert I. Eachus]

Hyman Rosen wrote:

> The main problem was that the people who wrote this software
> didn't leave any indication behind that it was valid only for
> data which could be encountered by an Ariane 4. Pure and simple,
> the Ariane 4 programmers left a buffer overflow bug in their
> code, and the Ariane 5 people tripped over it. The fact that it
> was in Ada helped not at all.

First, wrong!  The software was well documented.  And since the 
programmers had appealed the decision not to protect that particular 
conversion with a local exception handler, it was a very well documented 
part of the design.

But the tean that wrote the software never saw the Ariane 5 
requirements, and the people who could have checked the SRI 
documentation against the Ariane 5 requirements didn't have access to 
the SRI documentation.  Any attempt to put the two together would have 
resulted in a much bigger "Hey, wait a minute!"  Since the control laws 
depended on Ariane 4 physical parameters.

Changing the control law parameters to match the Ariane 5 was such a 
simple and obvious necessity, that it took almost Byzantine maneuvers to 
insure that it didn't happen.  I was a boy in short pants when I saw the 
American space program learn this lesson the hard way.  Not letting one 
contractor's employees talk to the other constractor's employees can 
cause bad things to happen.

The particular case I had in mind though was a Navy vs. Air Force 
disconnect on the Polaris program.  The Range Safety Officer at Patrick 
AFB was an Air Force Officer, but of course, some Polaris missile 
testing was done from Navy submarines.  The test plan called for a 
missle to be launched at an angle to see if the guidance system could 
recover.  As was expected the guidance system commanded the missle to 
loop.  (When the missle attitude was too great, the only way to recover 
was to gain altitude then loop quickly. You can't throttle solid fuel 
rockets, and the nozzles on the original Polaris were fixed with the 
only directional control from internal deflectors.)  The missle was 
almost out of the loop when the Air Force RSO destroyed it.  My father 
was a consulting engineer (actually as a radar expert), and I got to 
spend a couple more days on the beach, which I didn't mind.

But I still remember when my father came back to the motel and told us 
to start packing, the rest of the explosion was going to happen in the 
Pentagon.  The test plans were of course classified, but some (hmmm, 
jackass is probably the politest term I heard used) had decided that the 
  range safety officer did not need to know the test objectives.

So we stopped in D.C. on the way north, and I gather that Rickover "went 
nuclear" when he found out what had happened.  The "stem to stern" 
review security policies on the program found over a dozen cases where 
contractors were not considered to have need to know for key technical 
information.  The example that made my father's job easier, was that the 
radar contractor finally found out what the radars were supposed to be 
tracking.  (Uh, there's all that aluminum in the fuel, and the missile 
casing is wound fiberglass?  No wonder we keep getting screwy velocity 
readings.  We're tracking the exhaust.  What was my father there to do? 
  You guessed it.  Figure out why the radars were getting incorrect 
velocity data...)

For the record, AFAIK, my father never told me anything that was 
classified.  But there were many cases where I could put two and two, 
and recently declassifed data together.  Then, once I showed the 
declassified information to my father, I could get the inside story. 
The Polaris radar problem was one such case.

Re: Boeing and Dreamliner

[Hyman Rosen]

Robert I. Eachus wrote:
> First, wrong!  The software was well documented.

This is the report: <http://java.sun.com/people/jag/Ariane5.html>.
This is a quote from the report:
     The Board has also noted that the systems specification
     of the SRI does not indicate operational restrictions
     that emerge from the chosen implementation. Such a
     declaration of limitation, which should be mandatory for
     every mission-critical device, would have served to
     identify any non-compliance with the trajectory of Ariane 5.

So I can believe you, or I can believe them. Which shall it be?

Re: Boeing and Dreamliner

[Preben Randhol]

Hyman Rosen wrote:
> The fact that it was in Ada helped not at all.

Neither does it help you to claim that C++ would/is better for the job.
So please go off Trolling somewhere else.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Preben Randhol]

Hyman Rosen wrote:
> Of course, these kinds of errors can happen in any language.
> And that's the point. When certain people start claiming that
> using C++ is an actionable offense, the Ariane 5 case shows
> that using Ada is no panacea.

Perhaps not, but C++ is even less so than Ada, so what is your point?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Marin David Condic]

Rising to the bait, Marin writes... :-)

The important thing to remember is that the original designers 
*deliberately* stripped out the Ada safety features and *deliberately* 
designed the system to do exactly what it did. There was no bug here - 
it was a carefully considered engineering decision and, in the context 
of Ariane 4, it was the correct one. You're analogy of the 5 amp fuse in 
the 4 amp circuit is 100% on track. It was adequately designed for the 
original intended usage and then stuck in a different situation where it 
was not tested for the modified usage.

MDC


Mike Silva wrote:
> 
> 
> Good heavens, no, you're thinking of C!  There was no buffer overflow,
> and there was no bug.  There was a float-to-int conversion that was
> proven to be safe (FP value guaranteed to always fit into int) for the
> -4.  Therefore, any conversion overflow was assumed to be caused by a
> sensor/hardware problem and thus programmed by intention to shut down
> the SDI and let the backup system take over.  There is no way I can
> imagine that the -4 people can be accused of leaving a bug in the
> code.  To me the situation is akin to correctly specifying a 5 Amp
> fuse in a 4 Amp circuit, then "reusing" the circuit but now pumping 10
> Amps through it.  When the 5A fuse blows, was that a design error in
> the original circuit?



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

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

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

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

Re: Understanding and Teaching: Who may teach Ada?

[Georg Bauhaus]

Robert I. Eachus <rieachus@attbi.com> wrote:
: They CAN be understood by a college freshman.  But the 
: lectures work at several different levels.  You could take them every 
: year for a half dozen years and learn a completely new set of 
: information each time.
: 
: Sort of like "Alice in Wonderland" and "Through the Looking Glass." 

Thanks for the info, it is comforting when I look back at
my first life ;-) Maybe  I can ask my employer to work on
space optimizing strategies to improve on aliasing in and
around London, using techniques exemplified in these books.
Hey, maybe they agree, one of them is currently playing with
neuzzy networks ;)


-- Georg

Re: Boeing and Dreamliner

[Hyman Rosen]

Preben Randhol wrote:
> Perhaps not, but C++ is even less so than Ada, so what is your point?

My point is that when Bob Leif comes along and says
     "I might note that there are enough potential expert witnesses
      in this group to cause Boeing grave financial damage in the
      event management is negligent in the choice of programming
      language and this negligence leads to deaths or injuries."
we're going to be able to demonstrate that a project which used his
supposedly non-negligent language managed to blow up their rocket
anyway.

Re: Boeing and Dreamliner

[Hyman Rosen]

tmoran@acm.org wrote:
>   Whoa there!  A numerical value out of range is not a buffer overflow in
> the languages used on c.l.a.  Surely as a programmer you appreciate the
> value of precise expression.

In cause and effect, the two are precisely the same. The program with
the potential buffer overflow works for inputs of a certain size, but
fails catastrophically when input exceeds that size. That program is
seldom documented with a description of this limit. The Ariane 4 SRI
program worked fine for BH in a certain range, but failed
catastrophically when input exceeded that range. That range was not
documented.

Please tell me what you perceive as the meaningful difference between
the two cases?

Re: Boeing and Dreamliner

[Hyman Rosen]

Marin David Condic wrote:
 > It was adequately designed for the original intended usage and then stuck
 > in a different situation where it was not tested for the modified usage.

But the original designers didn't leave any indication behind that the
software they had written would fail in such a modified usage. That's
not just my conclusion, that's the conclusion of the investigatory
board. Had they documented the limits on trajectories, teh Ariane 5
team would have known that the code needed to be re-examined.

Since when do Ada advocates favor testing over documentation?

Re: Boeing and Dreamliner

[Hyman Rosen]

Preben Randhol wrote:
> Neither does it help you to claim that C++ would/is better for the job.
> So please go off Trolling somewhere else.

Where have you seen me claim any such thing? I was merely responding
to the statement that one should be sued for using C++.

Re: Boeing and Dreamliner

[Hyman Rosen]

Robert I. Eachus wrote:
> The SRI requirements document was never updated for the Ariane 5, and as 
> I pointed out, the software had built in parameters that reflected 
> physical constants relating to the Ariane4.

The report says that these physical constraints were not described in the
documentation of the SRI software, and therefore the people who attempted
to reuse it had no clue that it would fail outside of such limits.

Do you think it's appropriate to write software like that and not tell
anyone about it? If the code was in C++ and the failure mode was a
buffer overflow, would you accept that argument, or would you be villifying
that language?

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <Y6YJa.40577$hI1.28108@nwrddc01.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Marin David Condic wrote:
>  > It was adequately designed for the original intended usage and then stuck
>  > in a different situation where it was not tested for the modified usage.
> 
> But the original designers didn't leave any indication behind that the
> software they had written would fail in such a modified usage. That's
> not just my conclusion, that's the conclusion of the investigatory
> board. Had they documented the limits on trajectories, teh Ariane 5
> team would have known that the code needed to be re-examined.

Should someone reusing software presume that it has no limitations at all ?

Would you reuse such software in a vehicle capable of Warp 5 ?

Re: Boeing and Dreamliner

[Vinzent Hoefler]

Hyman Rosen wrote:

[Arian5 software reuse]
>But the original designers didn't leave any indication behind that the
>software they had written would fail in such a modified usage.

Interesting. AFAIK there existed proofs that led to the decision that
four out of seven variables could have their range checks turned off.

>board. Had they documented the limits on trajectories, teh Ariane 5
>team would have known that the code needed to be re-examined.

So the Ariane5 team didn't even reconsider the existing proofs for the
turned off range checks?

>Since when do Ada advocates favor testing over documentation?

No. But the documentation for Ariane 4 didn't really fit the one for
Ariane 5, did it? So what the hell did they expect?


Vinzent.

Re: Boeing and Dreamliner

[Preben Randhol]

Hyman Rosen wrote:
> Where have you seen me claim any such thing? I was merely responding
> to the statement that one should be sued for using C++.

No you weren't.

Preben
-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

If there isn't a FAQ on this yet, there should be!!!  8-/

Warren.

Robert I. Eachus wrote:
> Hyman Rosen wrote:
> 
>> The main problem was that the people who wrote this software
>> didn't leave any indication behind that it was valid only for
>> data which could be encountered by an Ariane 4. Pure and simple,
>> the Ariane 4 programmers left a buffer overflow bug in their
>> code, and the Ariane 5 people tripped over it. The fact that it
>> was in Ada helped not at all.
> 
> 
> First, wrong!  The software was well documented.  And since the 
> programmers had appealed the decision not to protect that particular 
> conversion with a local exception handler, it was a very well documented 
> part of the design.
> 
> But the tean that wrote the software never saw the Ariane 5 
> requirements, and the people who could have checked the SRI 
> documentation against the Ariane 5 requirements didn't have access to 
> the SRI documentation.  Any attempt to put the two together would have 
> resulted in a much bigger "Hey, wait a minute!"  Since the control laws 
> depended on Ariane 4 physical parameters.

...

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

Re: Boeing and Dreamliner

[@ 2003-06-24 16:38 UTC (permalink / raw)]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
>> The SRI requirements document was never updated for the Ariane 5, and 
>> as I pointed out, the software had built in parameters that reflected 
>> physical constants relating to the Ariane4.
> 
> 
> The report says that these physical constraints were not described in the
> documentation of the SRI software, and therefore the people who attempted
> to reuse it had no clue that it would fail outside of such limits.
> 
> Do you think it's appropriate to write software like that and not tell
> anyone about it? If the code was in C++ and the failure mode was a
> buffer overflow, would you accept that argument, or would you be villifying
> that language?
> 


What is the advantage of C++ here? You would have to document all 
possible "out of range" values and "buffer overflow" cases. In Ada, you 
save the "buffer overflow" section.

Rodrigo

Re: Boeing and Dreamliner

[Robert I. Eachus]

Hyman Rosen wrote:

> This is the report: <http://java.sun.com/people/jag/Ariane5.html>.
> This is a quote from the report:
>     The Board has also noted that the systems specification
>     of the SRI does not indicate operational restrictions
>     that emerge from the chosen implementation. Such a
>     declaration of limitation, which should be mandatory for
>     every mission-critical device, would have served to
>     identify any non-compliance with the trajectory of Ariane 5.
> 
> So I can believe you, or I can believe them. Which shall it be?

How about believe both?  As I said:

But to me the crowning idiocy of the whole thing is in one sentence of 
the report: "The main explanation for the absence of this test has 
already been mentioned above, i.e. the SRI specification (which is 
supposed to be a requirements document for the SRI) does not contain the 
Ariane 5 trajectory data as a functional requirement."

If I write a program for a washing machine, should the requirements spec 
include: "This software is unsuitable for the Ariane 5, whatever that is?"

The software for the Ariane 4 met the all the functional requirements in 
the systems specification for the SRI.  If it didn't, of course that 
should have been documented in the systems specification.  But the 
software was not suited to launching an Ariane 4 from Mars or Venus. 
Did it say that?  Of course not, there was no requirement for launching 
an Ariane 4 from anywhere other than the surface of the Earth.

Asking the writers of the SRI functional specification to imagine all 
the possible uses someone might try in the future to use the SRI 
for--including washing machines--is crazy.  What was required, and 
didn't happen, was for the Ariane 5 project to write a requirements 
document for the SRI, and then either test to those requirements, or 
evaluate the existing Ariane 4 test data to show that the SRI met the 
Ariane 5 requirements.  None of that was done, and Ariane 501 destroyed 
itself.

Re: Boeing and Dreamliner

[tmoran]

>>   Whoa there!  A numerical value out of range is not a buffer overflow in

>the potential buffer overflow works for inputs of a certain size, but
>fails catastrophically when input exceeds that size.
  When lightning strikes the computer and the input voltage exceeds
110V, the program fails catastrophically to work.  If you call that a
buffer overflow, then I will call you a genius, using my own special
definition of the word "genius".

Re: Boeing and Dreamliner

[Robert I. Eachus]

Hyman Rosen wrote:

> The report says that these physical constraints were not described in the
> documentation of the SRI software, and therefore the people who attempted
> to reuse it had no clue that it would fail outside of such limits.
> 
> Do you think it's appropriate to write software like that and not tell
> anyone about it? If the code was in C++ and the failure mode was a
> buffer overflow, would you accept that argument, or would you be villifying
> that language?

Be careful, you are asserting something the report does not say. 
Remember this report was much more a political document than an 
engineering document.  The requirements document DID include the Ariane 
4 related requirements.  As anyone who has ever writen control law 
software should know, the physical moments of the system are required 
inputs, and you need the physical limitations of the system to get the 
constraints on the output right.  All those were in the SRI 
specification--for the Ariane 4.  Those values were incorrect for the 
Ariane 5, but no one was PERMITTED to see both the Ariane 5 performance 
specification and the SRI system specification. NO ONE.

Sorry to shout, but that is the key finding of the investigation.  It is 
surrounded by lots of dry language to make it sound like it could happen 
to anyone, but it was pure and simple politics.

The whole discussion of "protecting" the conversion that failed is a red 
herring.  The software people wanted to put in the code, they were 
overruled because in the Ariane 4, that overflow was physically 
impossible.  It was very reasonable for the software designers to want 
to put the check in, and it was very reasonable for management, in the 
context of the overall system, to decide that the default action was 
correct.  If the software engineers or project management had access to 
the Ariane 5 specifications, the decision would have been different.

Re: Boeing and Dreamliner

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<i3YJa.40543$hI1.21397@nwrddc01.gnilink.net>...
> tmoran@acm.org wrote:
> >   Whoa there!  A numerical value out of range is not a buffer overflow in
> > the languages used on c.l.a.  Surely as a programmer you appreciate the
> > value of precise expression.
> 
> In cause and effect, the two are precisely the same. The program with
> the potential buffer overflow works for inputs of a certain size, but
> fails catastrophically when input exceeds that size. That program is
> seldom documented with a description of this limit. The Ariane 4 SRI
> program worked fine for BH in a certain range, but failed
> catastrophically when input exceeded that range. That range was not
> documented.
> 
> Please tell me what you perceive as the meaningful difference between
> the two cases?

The difference is that the Ariane 4 software behaved *exactly* as
designed and intended for *all* ranges of inputs, for the Ariane 4. 
Raising an exception was not "failing catasrophically" but was the
correct behavior, triggering the correct shutdown of the unit, for the
data in question.  What data limitation is there to document, when the
software performs correctly for all data?

Then the Ariane 5 people came along, and they had an unstated, and
apparently even unrecognized, requirement for *different* behavior
over a certain range of data.  That certainly does not mean there was
a bug in the Ariane 4 software.

Mike

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Hyman Rosen wrote:

>But the original designers didn't leave any indication behind that the
>software they had written would fail in such a modified usage. That's
>not just my conclusion, that's the conclusion of the investigatory
>board. Had they documented the limits on trajectories, teh Ariane 5
>team would have known that the code needed to be re-examined.
>
>Since when do Ada advocates favor testing over documentation?

Testing is a fundamental requirement for any enginering. Please, read this
attentively: for any engineering. This is one of main characteristcs that
differentiate engineering from scientific exploration, art, terrorism... all
activities, good or bad, looking for a chance.

Software engineering is, first of all, a kind and a part of engineering,
therefore it inherits testing as its fundamental requirement.

Ada language was designed and is used primarily for software engineering.
So it should not surprise anyone when Ada advocates demand testing.

In engineering, documentation is (and always was) secondary vs. testing.
Just like your human rights are secondary vs. your need to eat -- you may be
very unhappy without you rights or with restricted rights, but you still can
keep hope for future liberation and future better life; but if you don't eat
you'll certainly die very soon,

Returning to the Ariane 5 case, if I were Civil Investigator for this case,
I would close civil part of the investigation at the moment when I became
aware of absence of testing -- at that moment I'd call for Criminal Investigator.
Then, criminal part of the investigation must decide whether there was major
neglect or deliberate plot (sabotage or financial affair, for example), and
all technical details (about numbers, stacks, overflows etc.) naturally
belongs to it. Personally, I think that Criminal Investigator would suspect
a plot when he discovered that the launch was doomed unconditionally.


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

Re: Boeing and Dreamliner

[Pascal Obry]

Hyman Rosen <hyrosen@mail.com> writes:

> Of course, these kinds of errors can happen in any language.

Right and we never claimed the opposite. I have never heard anybody saying
that in Ada you can't have bugs. So please Hyman, let's stop this kind of
stupid arguments..

Thanks,
Pascal.

-- 

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

Re: Boeing and Dreamliner

[Wesley Groleau]

> Where have you seen me claim any such thing? I was merely responding
> to the statement that one should be sued for using C++.

In some application domains, using C++ should be
criminal.  The fact that Ada is not perfect will
NEVER justify using something that's worse when
lives are at stake.  Were lives at stake in Ariane?

If not, then use C++ and see what happens.

Re: Boeing and Dreamliner

[Hyman Rosen]

Wesley Groleau wrote:
> In some application domains, using C++ should be criminal.

Umm, no.

> The fact that Ada is not perfect will NEVER justify using
 > something that's worse when lives are at stake.

C++ isn't worse. It's different. People who favor their own
little pet language will say it's worse, but that's not really
my problem. I'm sure C++ is used in lots of areas where lives
are at stake.

 > Were lives at stake in Ariane?

Hundreds of millions of dollars were at stake, which is easily
the equivalent of a few lives. Lots of lives, in some places.

> If not, then use C++ and see what happens.

Thanks, I will.

Re: Understanding and Teaching: Who may teach Ada?

[John R. Strohm]

"Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message
news:bd6jq6$kr0$2@a1-hrz.uni-duisburg.de...
> Robert I. Eachus <rieachus@attbi.com> wrote:
> : John R. Strohm wrote:
> :
>
> :> The fundamental test of whether one really understands
> :> the topic is whether one CAN prepare a "freshman lecture" (or a "man in
the
> :> street" book or article) on it.
>
> In a better world, this phrase should be put in a frame,
> and teachers should not be employed if they fail.
> Maybe the test should be more flexible, offering a choice
> of audience, but only for the test.

No.  That is the whole point of the test.  If you can explain it to someone
who has the prerequisite N many years of specialized knowledge and
experience, you may understand it thoroughly, or you may not.  If you can
explain it to a layman, who DOESN'T have the specialized knowledge, who
needs YOU to walk him through possibly YEARS of work in the course of
minutes, you DO understand it thoroughly.

Read the section in Clifford Stoll's "Cuckoo's Egg", about his Ph.D. oral
examination, where the department chairman asked the final question: "Why is
the sky blue?", and then, to EVERYTHING Stoll said, responded "Can you be
more specific?" and made him go ALL THE WAY THROUGH several years of
multiple disciplines, to answer the question IN DETAIL and show that he knew
it, all the way down.

Incidentally, I've been through that experience.  Many years ago, a
mathematician co-worker walked me through four years or so of mathematical
development, in outline form, touching all the key points, although not
rigorously, over beers at Happy Hour one evening, to explain to me precisely
why the standard deviation formula used (N-1) instead of N in the
denominator.  I think it took him about an hour, and I came away with, while
not a complete understanding, at least a grasp of what was involved.

> Do you think that Feynman might have succeeded in teaching
> "real" average Freshman, had he been under more pressure?

Georg, Feynman also did a series of four lectures, for laymen, on quantum
electrodynamics.  Those four lectures were, MUCH later, collected into a
small, thin book entitled "QED".

I've read that book.

Based primarily on that book and secondarily on the freshman lectures (which
I also have, somewhere packed away in the course of a VERY disorganized
move), yes, I believe he could have been quite successful in teaching "real"
average freshmen.

I will grant that some of the subtleties were lost on the freshmen, and
could only be appreciated by the fellow Ph.D.s, but I also believe that the
freshmen who went on in physics would later review those lectures during
their later education, and working careers, and realize what they'd missed
at the time that was also in there.

> : Your point is well taken, but the Feyman lectures are a bad example.
> : Yes, they are readable and understandable, and anyone with a PhD in
> : Physics who hasn't read them should remedy that mistake.
> :
> : But when Feynman originally gave the course, the Freshman were soon
> : outnumbered ...

Yeah, and it is a damned shame that the physics department chairman did not
understand that Feynman's job in that classroom at that time was to teach
the FRESHMEN, and HIS job was to keep the tourists OUT OF THE WAY so Feynman
COULD teach the freshmen.

Re: Understanding and Teaching: Who may teach Ada?

[Wesley Groleau]

> mathematician co-worker walked me through four years or so of mathematical
> development, in outline form, touching all the key points, although not
> rigorously, over beers at Happy Hour one evening, to explain to me precisely
> why the standard deviation formula used (N-1) instead of N in the
> denominator.  I think it took him about an hour, and I came away with, while
> not a complete understanding, at least a grasp of what was involved.

I remember being convinced by various sources that
Einstein's relativity theories were esoteric stuff
way over my head.  Then I found a copy of

Relativity
The Special and the General Theory
A popular exposition by
Albert Einstein
Authorized Translation by
Robert W. Lawson

Seems really quite simple.

Re: Understanding and Teaching: Who may teach Ada?

[Anders Wirzenius]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:WqydnQCrw-0atWSjXTWJhQ@gbronline.com...
> I remember being convinced by various sources that
> Einstein's relativity theories were esoteric stuff
> way over my head.  Then I found a copy of
>
> Relativity
> The Special and the General Theory
> A popular exposition by
> Albert Einstein
> Authorized Translation by
> Robert W. Lawson
>
> Seems really quite simple.
>

I have heard or read somewhere that Mr. Einstein himself has said at
some occasion:
"If you cannot expound a complicated thing using easy words, you don�t
really understand the thing yourself."

Maybe someone can point to a reliable source for that "rumour" about
Mr. E.?

Anders

Re: Boeing and Dreamliner

[Thierry Lelegard]

Isn't it a satisfaction to be obliged to go 10 years backward to
find an big failure where Ada was involved (I mean *involved*, not
responsible)?

In the mean time, thousands of Windows systems are crashing every day
around the world. That makes a few millions Windows crashes since the
Ariane 5 crash. Millions of M$ Word crashes (resulting in thousands
of corrupted and unusable documents, and among them a few of mine!).
How many "unavailable" ATM, due to software crash? "Unavailable"
Web servers? Etc...

So, on a software point of view, the Ariane 5 crash is not a proof of
Ada's weakness. Having *only" this event to speak about is a proof of
Ada's strength.

-Thierry

Re: Boeing and Dreamliner

[Dmitry A. Kazakov]

Hyman Rosen wrote:

> Wesley Groleau wrote:
>> In some application domains, using C++ should be criminal.
> 
> Umm, no.

Not naming concrete languages: "using knowingly wrong technology is criminal 
in some application domains." Using any programming language is definitely 
a technology. Thus, according to you, C++ is universally applicable 
everywhere under any circumstances. I would not claim that even for Ada.

>> The fact that Ada is not perfect will NEVER justify using
>  > something that's worse when lives are at stake.
> 
> C++ isn't worse. It's different. People who favor their own
> little pet language will say it's worse, but that's not really
> my problem. I'm sure C++ is used in lots of areas where lives
> are at stake.

Compare with: "I'm sure that many physicians do not clean their hands."

>  > Were lives at stake in Ariane?
> 
> Hundreds of millions of dollars were at stake, which is easily
> the equivalent of a few lives. Lots of lives, in some places.

So the proposition is:

"In some places one could take someone's life for pair dollars => if 
somebody dies because of my fault, I would not care, I would just get one 
beer less."

Observe that logically (and legally) it isn't perfect, because "place" in 
the left and right parts of the proposition are different.

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

Re: Boeing and Dreamliner

[Marin David Condic]

Precisely. The designers had looked at the range of possible inputs and 
concluded that if an input were to get beyond some point, this would 
indicate a sensor failure because the flight envelope could never 
contain that as valid data. That is the Failure Detection part. They 
further designed the unit to shut down the channel that had the presumed 
bad sensor. That was the accommodation part. It worked *exactly* as it 
was designed to work doing *precisely* what it was supposed to do. The 
software didn't fail. It didn't have a bug. It worked 100% according to 
plan. The problem was that in a different set of circumstances, this was 
not the desired behavior and nobody bothered to check.

Its a little like these lawsuits against gun manufacturers when 
criminals use their products to kill someone. The argument from the gun 
manufacturer ought to be "Look, you pointed the thing at someone, 
squeezed the trigger and that person died. It worked exactly as designed 
and there was no manufacturing flaw. What's your problem???" :-)

MDC



Mike Silva wrote:
> 
> 
> The difference is that the Ariane 4 software behaved *exactly* as
> designed and intended for *all* ranges of inputs, for the Ariane 4. 
> Raising an exception was not "failing catasrophically" but was the
> correct behavior, triggering the correct shutdown of the unit, for the
> data in question.  What data limitation is there to document, when the
> software performs correctly for all data?
> 
> Then the Ariane 5 people came along, and they had an unstated, and
> apparently even unrecognized, requirement for *different* behavior
> over a certain range of data.  That certainly does not mean there was
> a bug in the Ariane 4 software.
> 
> Mike


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

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

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

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

Re: Boeing and Dreamliner

[Marin David Condic]

Documentation may or may not be an issue. In the aerospace world in 
which I work, it would be considered *extremely* irresponsible to 
utilize a component without demonstrating through system testing that it 
operates throughout the intended flight envelope. Had they run the IRS 
through even a *minimal* test of the intended flight envelope, they 
would have discovered that it didn't work in the intended environment. 
The fact that this was not documented is a stalking horse used to divert 
attention away from the fact that they didn't do what they were supposed 
to do in the way of system testing. Lots of things in systems this 
complex are not documented. Lots of design decisions are left unnoted 
anywhere. You can't write them all down or you'd never get the job done. 
What *is* done is to run the unit under consideration through a formal 
qualification test that demonstrates it meets its requirements. This, 
they never did.

MDC



Hyman Rosen wrote:
> 
> But the original designers didn't leave any indication behind that the
> software they had written would fail in such a modified usage. That's
> not just my conclusion, that's the conclusion of the investigatory
> board. Had they documented the limits on trajectories, teh Ariane 5
> team would have known that the code needed to be re-examined.
> 
> Since when do Ada advocates favor testing over documentation?
> 


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

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

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

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

Re: Understanding and Teaching: Who may teach Ada?

[Georg Bauhaus]

John R. Strohm <strohm@airmail.net> wrote:
:>
:> In a better world, this phrase should be put in a frame,
:> and teachers should not be employed if they fail.
:> Maybe the test should be more flexible, offering a choice
:> of audience, but only for the test.
: 
: No.  That is the whole point of the test.  If you can explain it to someone
: who has the prerequisite N many years of specialized knowledge and
: experience, you may understand it thoroughly, or you may not.

No.  What I was thinking of is that if you can explain things, _during_
the test, to _some_ audience, you have demonstrated skills necessary for
(a) making explanations
(b) analysing making explanations
Then, if your job is going to be teaching another audience than that of
the test, you have proven that you can, if necessary, learn how
to prepare lectures for different sorts of audiences. If teaching
skills were an integral part of becoming a professor, things would be
better though, at least over here.

 If you can
: explain it to a layman, who DOESN'T have the specialized knowledge, who
: needs YOU to walk him through possibly YEARS of work in the course of
: minutes, you DO understand it thoroughly.

There are things to learn before you can do this, and if you have
the requirements for doing so, then a test might show this.
For example, if you are going to teach Russian school children,
the test might proove that you know Russian language, even if your
audience has been a bunch of engineers. sounds trivial,
but this is the idea: one can learn how to explain things, at least
to some extent, to different audiences. Requires work, forbids 
arrogance, and might need teching teachers, and a cultural change ;-)

: Read the section in Clifford Stoll's "Cuckoo's Egg", about his Ph.D. oral
: examination, where the department chairman asked the final question: "Why is
: the sky blue?", and then, to EVERYTHING Stoll said, responded "Can you be
: more specific?" and made him go ALL THE WAY THROUGH several years of
: multiple disciplines, to answer the question IN DETAIL and show that he knew
: it, all the way down.

A good example of teaching rhetorics. There is no good lecture absent 
skills in rhetorics. (I am not referring to the (self-)marketing
meaning of rhetorics.) However, what counts, in my view, is the
skills, (a) above, and the ability to understand what has been
going on, (b) above.


: Yeah, and it is a damned shame that the physics department chairman did not
: understand that Feynman's job in that classroom at that time was to teach
: the FRESHMEN, and HIS job was to keep the tourists OUT OF THE WAY so Feynman
: COULD teach the freshmen.

That is what made me ask whether he would have succeeded (in this
sense).

- Georg
hoping to find time, some day, for the exercises volume of the 
Lectures on Physics. Hey, preparing good exercises is another test,
I think, by which you demonstrate that you have really understood
something.

Re: Boeing and Dreamliner

[Mike Silva]

Hyman Rosen <hyrosen@mail.com> wrote in message news:<Qc6Ka.14618$Kg7.12799@nwrdny01.gnilink.net>...
> Wesley Groleau wrote:
> > In some application domains, using C++ should be criminal.
> 
> Umm, no.
> 
> > The fact that Ada is not perfect will NEVER justify using
>  > something that's worse when lives are at stake.
> 
> C++ isn't worse. It's different. 

Here's a report that reaches a different conclusion:

&#8220;....results of the UK
Ministry of Defense&#8217;s own retrospective
IV&V program that was carried out by
Aerosystems International at Yeovil in the
UK. It should be remembered that the
code examined by Aerosystems had
already been cleared to DO-178B Level A
standards, which should indicate that it
was suitable for safety-critical flight purposes.
Key conclusions of this study follow:
&#8226; Significant, potentially safety-critical
errors were found by static analysis in
code developed to DO-178B Level A.
&#8226; Properties of the SPARK code
(including proof of exception freedom)
could readily be proved against
Lockheed&#8217;s semi-formal specification;
this proof was shown to be cheaper
than weaker forms of semantic analysis
performed on non-SPARK code.
&#8226; SPARK code was found to have only
10 percent of the residual errors of
full Ada; Ada was found to have only
10 percent of the residual errors of
code written in C. This is an interesting
counter to those who maintain that
choice of programming language does
not matter, and that critical code can
be written correctly in any language:
The claim may be true in principle but
clearly is not commonly achieved in practice.&#8221;

from http://www.sparkada.com/downloads/Mar2002Amey.pdf

Unless you are prepared to demonstrate that C++ is 10 (ref. full Ada)
to 100 (ref. SPARK Ada) times safer than C, the only reasonable
conclusion is that C++ is indeed "worse."  BTW, I imagine that the C
code in question was already based on a "safe subset" of the C
language, so that's what you'd need to show improvment over.

Mike

Re: Boeing and Dreamliner

[Robert I. Eachus]

Someone asked:

>> > Were lives at stake in Ariane?

Several hundred people who thought their lives were not at stake 
discovered otherwise.  No one had looked for a worst case scenario until 
it happened.  The Ariane 501 disintegrating at 4000 meters altitude 
(about 2 1/2 miles) was never imagined.  Fortunately most of the larger 
chunks of debris were carried upward before falling to the ground so 
there were no serious injuries.  But I would not have liked to have been 
one of the many technicians watching the launch from a couple of 
kilometers distant suddenly realizing that the Ariane 501 wreckage was 
planning to land where I was standing.

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>... but the best thing to do 
>is to actually read the technical report on what happened. (I found a 
>copy at http://www.dcs.ed.ac.uk/home/pxs/Book/ariane5rep.html)

I read this report yesterday, and now I'd like to make several comments.

1) The report is quite good - it mentions many significant facts, gives some
necessary explanations, points at true cause of failure - the absence of
testing, and concludes with right recommendations.

2) Yes, this report is "politically correct" (which seems quite natural),
therefore it requires specific skills for reading (I can testify that 20
years of experience reading main Soviet newspaper Pravda ("Truth") are very
helpful -;) , and at least vague preliminary view on the subject (which was
provided within this thread).

3) Besides the things you already decribed (in full accordance with the report),
I discovered in this report one very interesting detail, which attracted my
special attention. Let's go to the quotes. First yours:

>... it doesn't take a 
>genius to tell you what that ten second period of "pressure surges" in 
>the flight control hydraulics was.  But of course the politics of the 
>situation kept the fact that oscillations were building up in the stack 
>from being an obvious part of the official report--and from being left 
>out of it:
>
>"One anomaly which was brought to the particular attention of the Board 
>was the gradual development, starting at Ho + 22 seconds, of variations 
>in the hydraulic pressure of the actuators of the main engine nozzle. 
>These variations had a frequency of approximately 10 Hz.
>
>"There are some preliminary explanations as to the cause of these 
>variations, which are now under investigation.
>
>"After consideration, the Board has formed the opinion that this 
>anomaly, while significant, has no bearing on the failure of Ariane 501."
>
>Don't you just love that attempted slight of hand?

I might just love that slight of hand, but during rereading the report I saw
the following:

"These nozzle deflections were commanded by the On-Board Computer (OBC)
software on the basis of data transmitted by the active Inertial Reference
System (SRI 2). Part of these data at that time did not contain proper flight
data, but showed a diagnostic bit pattern of the computer of the SRI 2, which
was interpreted as flight data."

"The reason why the active SRI 2 did not send correct attitude data was that
the unit had declared a failure due to a software exception."

This "showed a diagnostic bit pattern of the computer of the SRI 2, which
was interpreted as flight data" striked me. See, there was not just wrong SRI
behaviour, there was communication protocol error! OBC misinterprets SRI data,
it takes diagnostic "postmortem dump" as normal flight data! Certainly I have
no clue which part - SRI or OBC is guilty, but anyway it is highly unlikely
that this protocol error was caused by previous errors related to the flight
parameters.

Now the report's passage about variations of hydraulic pressure does not seem
"slight of hand" any more (if I understand this expression properly).
First, there was protocol error, so the "bugs" weren't localized in SRI.
Second, possibly there were other inconsistensies in SRI software. and those
additional inconsistencies might influence that "diagnostic pattern". which
was transmitted to OBC.

Well, I think that the report writers couldn't go further. They said enough...
perhaps even more than enough. Yes, an unexperienced reader has very little
chance to acquire proper view on the subject from this report without some
external help. So, it may be good thing indeed to provide some sort of FAQ
for the subject (as was already proposed in this thread). Something like that:

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

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

Q. Did that software cause the crash?

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

etc. (with references to the report).



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

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Robert I. Eachus wrote

> >> > Were lives at stake in Ariane?
> 
> Several hundred people who thought their lives were not at stake 
> discovered otherwise.  No one had looked for a worst case scenario until 
> it happened.  The Ariane 501 disintegrating at 4000 meters altitude 
> (about 2 1/2 miles) was never imagined.  Fortunately most of the larger 
> chunks of debris were carried upward before falling to the ground so 
> there were no serious injuries.  But I would not have liked to have been 
> one of the many technicians watching the launch from a couple of 
> kilometers distant suddenly realizing that the Ariane 501 wreckage was 
> planning to land where I was standing.

Yes, I saw a funeral about 1960, in Kharkov, USSR (now Ukraine).
I was a child, but I still remember it well. It was long procession on our
Pushkinskaja street, many coffins, military orchestra... My father explained
me that a rocket exploded during the launch, and all people on the site were
killed, even command staff, including a general (command bunker was destroyed
by the debris and burned by rocket's fuel).



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

Re: Boeing and Dreamliner

[Robert I. Eachus]

Alexander Kopilovitch wrote:

> I read this report yesterday, and now I'd like to make several comments.

Good.

>>... it doesn't take a 
>>genius to tell you what that ten second period of "pressure surges" in 
>>the flight control hydraulics was.  But of course the politics of the 
>>situation kept the fact that oscillations were building up in the stack 
> 
>>from being an obvious part of the official report--and from being left 
> 
>>out of it:

> "These nozzle deflections were commanded by the On-Board Computer (OBC)
> software on the basis of data transmitted by the active Inertial Reference
> System (SRI 2). Part of these data at that time did not contain proper flight
> data, but showed a diagnostic bit pattern of the computer of the SRI 2, which
> was interpreted as flight data."
> 
> "The reason why the active SRI 2 did not send correct attitude data was that
> the unit had declared a failure due to a software exception."

This happened at around 38 seconds.  The "hunting" of the flight 
guidance system was prior to that.  Ten Hertz (cycles per second) is 
almost certainly not due to any of the inertial moments of the system 
but a multiple of the SRI clock.

> First, there was protocol error, so the "bugs" weren't localized in SRI.
> Second, possibly there were other inconsistensies in SRI software. and those
> additional inconsistencies might influence that "diagnostic pattern". which
> was transmitted to OBC.

Correct, the OBC did no validation or sanity checks on the information 
sent from the SRI to the engine controls.  Nothing wrong with that--if 
you understand that the SRIs are category 1 systems. (Failure will cause 
system failure.) I didn't like at all the idea of sending diagnostic 
data over the bus from SRI to OBC, but it can be justified by this view 
that failure of the SRIs leads to failure of the system, and you want to 
get as much diagnostic information as possible before the telemetry 
fails as the Ariane is blown up.

But the other systemic mistake that I an nowhere near comfortable with 
was the implicit idea that that the SRI software must be correct.  I 
would prefer in the first Ariane 5 launched to allow for the possibility 
that the flight dynamics model doesn't perfectly match the actual 
system.  This would argue for a diagnostic data stream that shows the 
deviations between the model and the system, while still continuing the 
"best effort" to fly the Ariane.

In other words, the SRI should send both engine deflection commands and 
diagonstic data to the OBC.

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

Before the Ariane 501 disaster, the shorthand for this problem with 
reuse was that an M2 tank is not an M1 tank.  In other words, you have 
to repeat the requirements definition part of the effort. Even if you 
can, in the end, reuse the software without change.  Of course, now we 
just say Ariane 5.

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Robert I. Eachus wrote:

>The "hunting" of the flight 
>guidance system was prior to that.  Ten Hertz (cycles per second) is 
>almost certainly not due to any of the inertial moments of the system 
>but a multiple of the SRI clock.

I don't get why you pay so much attention to that error. Yes, I fully argee,
that most probably it was another incosistence, and that it alone guaranteed
Ariane 5 mission overall failure. But it was just another inconsistence, and
there might be several more, which just did not show themselves within initial
38 secons, so what? What does it add to the already established (and properly
reflected in the report) fact that there were fatal inconsistences (at least
one), which were certainly detectable within normal test procedure. (Obviously,
that incostistence - "hunting" - is also certainly detectable within the same
normal test procedure). Why do you think that that particular inconsistence
deserved (or even still deserves) special investigation effort?

>> First, there was protocol error, so the "bugs" weren't localized in SRI.
>> Second, possibly there were other inconsistensies in SRI software. and those
>> additional inconsistencies might influence that "diagnostic pattern". which
>> was transmitted to OBC.
>
>Correct, the OBC did no validation or sanity checks on the information 
>sent from the SRI to the engine controls.  Nothing wrong with that--if 
>you understand that the SRIs are category 1 systems. (Failure will cause 
>system failure.) I didn't like at all the idea of sending diagnostic 
>data over the bus from SRI to OBC, but it can be justified by this view 
>that failure of the SRIs leads to failure of the system, and you want to 
>get as much diagnostic information as possible before the telemetry 
>fails as the Ariane is blown up.

Yes, but if the postmortem diagnostic status is sent to OBC then OBC must
differentiate it from normal flight data -- it is part of the communication
protocol. I don't know whether Ariane 4 OBC did that, but Ariane 5 OBC apparently
failed to do that. So, there are 3 possibilities:

1) communication protocol between SRI and OBC was broken even for Ariane 4;

2) that communication protocol was designed and implemented for Ariane 4
correctly, but its OBC side was changed for Ariane 5, while its SRI side
remains unchanged;

3) heavy damage of SRI software or memory (resulted from previous errors)
caused improper protocol control data, which misguides OBC, 

The possibility 3 seems unlikely; I have no grounds for guessing between
the possibilities 1 and 2, but I'd like to say that the possibility 2 is more
interesting -;) .

Overall, I see that communication protocol problem as probably more significant
than "hunting" error problem.

>But the other systemic mistake that I an nowhere near comfortable with 
>was the implicit idea that that the SRI software must be correct.

But it was proved (by practice) to be correct for Ariane 4, so it should be
correct for all subsequent Arianes -- the same logic, isn't it?

>I would prefer in the first Ariane 5 launched to allow for the possibility 
>that the flight dynamics model doesn't perfectly match the actual 
>system.  This would argue for a diagnostic data stream that shows the 
>deviations between the model and the system, while still continuing the 
>"best effort" to fly the Ariane.
>
>In other words, the SRI should send both engine deflection commands and 
>diagonstic data to the OBC.

I don't see an actual need for that diagnostic stream from SRI to OBC --
the model may be duplicated inside OBC thus making OBC capable of all needed
comparisons without additional data stream from SRI. (I assume that OBC knows
actual flight data anyway... for telemetry etc. ... but I may be wrong here.)


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

Re: Boeing and Dreamliner

[Richard Riehle]

Hyman Rosen wrote:

> rleif wrote:
> > All the Boeing management need to do is read the JAVA and C# literature on
> > why these languages were created. Choosing an inferior technology is bad;
> > choosing and inferior, obsolete technology is worse.
> >
> > I might note that there are enough potential expert witnesses in this group
> > to cause Boeing grave financial damage in the event management is negligent
> > in the choice of programming language and this negligence leads to deaths or
> > injuries.
>
> Ada made the Ariane 5 crash!

Untrue.  Engineering mismanagement made Ariane 5 crash.

The Ada code that caused a problem in Ariane 5 was perfectly
good code reused from Ariane 4.   It worked exactly as intended
on Ariane 4.    The launch characteristics of Ariane 5 were different
from Ariane 4, and this difference was overlooked by the engineering
team.

To use an analogy, this is much like prescribing a medicine for a patient
that works exactly as intended on most patients.  However, some patients
will be allergic to that same medicine.   The physician has a responsibility
to do a careful medical analysis to ensure there are no contra-indicated
circumstances in the health history or the targeted patient.  The engineer
must determine whether there are differences between the targeted
platforms for existing, albeit otherwise correct, software components.

Richard Riehle

Re: Boeing and Dreamliner

[Richard Riehle]

AG wrote:

> Anybody heard of the force of gravity?  :-)

In solving any engineering problem, gravity
is cheap and dependable.

Richard Riehle

Re: Boeing and Dreamliner

[Hyman Rosen]

Richard Riehle wrote:
> The Ada code that caused a problem in Ariane 5 was perfectly
> good code reused from Ariane 4.

It was not perfectly good code. It contained an implementation
shortcut that was specific to the possible trajectories of the
Ariane 4, but the code containing this shortcut had no comment
as to why this was OK, nor was this documented in the description
of the SRI software.

While people here are focussed on the fact that the trajectory
specs were not made part of the specs of the Ariane 5 SRI, the
actual problem was that the Ariane 4 SRI programmers did not
indicate that the trajectory specs for the Ariane 4 actually
impacted the implementation of the SRI code.

Re: Boeing and Dreamliner

[Richard Riehle]

"Robert I. Eachus" wrote:

> But to me the crowning idiocy of the whole thing is in one sentence of
> the report: "The main explanation for the absence of this test has
> already been mentioned above, i.e. the SRI specification (which is
> supposed to be a requirements document for the SRI) does not contain the
> Ariane 5 trajectory data as a functional requirement."

Since this discussion began as a dialogue about the Boeing 7E7, and someone
raised the question of whether C++ would be appropriate for software on
that aircraft, the lesson of Ariane 5 is important for the engineers.

First, let's make clear that JSF is not being programmed in C++ but in
a very limited subset of C.    Some of the JSF systems will be programmed
in Ada, but not as many as one might expect if the JSF engineers were
using better judgement.

Second, we have the issue of reuse, as noted by Hyman Rosen in his mistaken
appraisal of the Ariane 5 failure.  I and others have commented on this
earlier.

If Boeing does decide to use Ada, and we would hope they would, the lessons
of Ariane 5 are valuable.  Those lessons indicate that, even when using
superior
technology, one can make other engineering decisions using incomplete data.

C++ would be a dangerous choice, not only because the language itself can lead

to so many undecidables and unpredictable fragments of code, but also because
the language, itself, implies a heavy reliance on resuable components.
Frankly,
I have greater confidence in the savvy of Boeing engineering management and
would expect them to have learned the lessons of Ada from the B-777, along
with
the lessons being learned in the on-going upgrades (in Ada) of software for
the
B-757, B-747, and B-767.

As far as I know, there is no DO-178B compliance inherent in C++.  One can
comply with DO-178B using a carefully selected subset of C.   Even in Ada,
one must take care to apply the appropriate pragmas from Annex H, apply
the constraints of Ravenscar or SPARK, and avoid certain low-level features
of the language a less experienced engineering might be tempted to engage.

C++ might be appropriate for certain systems such as cabin entertainment,
but it would be a serious error in engineering management to choose it for
any of the safety-critical software.   The more I see of C++, the more
experience
I gain with it, the more I realize why Ada is designed to a more rigorous
set of rules.  Those rules may be annoying to some programmers, but those
rules make sense to an engineer.

A fly-by-wire aircraft is an engineering problem, not a programming problem,
even when software (and programming) are part of the solution space.  When one

looks at this kind of system as a total engineering effort, one must also
consider
the software as part of the engineering, not separate from it.  With C++, it
is too
easy to disengage the software effort from the rest of the engineering effort.

The argument that one cannot find trained and experienced Ada programmers is
one of the most bogus arguments proposed by military and civilian contractors.

We are looking first for engineers.  In my experience, good engineers, when
exposed to Ada, do learn to create excellent software designs, and they learn
to do so independent of the the search for the perfect algorithm.   Often, it
is
better to start with engineers and teach them Ada than to start with
programmers
who have already developed bad habits.   I see lots of C++ programmers who
have to be re-educated to think as engineers when given problems in embedded
systems environments.

I have trained engineers to program in Ada and they take to it well and
understand
the underlying rationale for its design.   I have trained C++ programmers and
many
of the spend their time arguing about how they can do such-and-such in C++ and

why can't they do it that way in Ada.     We can train experienced programmers
in
Ada, but we need to first train them to think like engineers.   It seems that,
many
engineers grasp the reasons for Ada's design quickly.    Those same engineers
are not focused on  resume-building, but on problem-solving.    They realize
that Ada is an excellent tool for solving engineering problems.

For the past three years, I have been teaching Ada at the Naval Postgraduate
School.,
My students take Ada As A Second Language.  At the end of each Quarter, I
require
them to write a paper comparing Ada with their first (or other ) language.
They
often express their preference for Java (rarely for C++), but most of the
understand
the difference between using Ada for dependability and Java for ease of
creating
screens and little GUI programs.

I believe that the Boeing engineers also understand this.   They are building
software where life and safety are at stake.   When one objectively examines
the current choices in software engineering languages, Ada continues to be the

most appropriate choice when one is concerned with high dependability.  Let's
hope I am right about those Boeing engineers.   They have shown good judgement

in the past in making software decisions.   They will probably continue to do
so
in the future.

Richard Riehle

Re: Boeing and Dreamliner

[Richard Riehle]

"Robert I. Eachus" wrote:

> Someone asked:
>
> >> > Were lives at stake in Ariane?
>
> Several hundred people who thought their lives were not at stake
> discovered otherwise.  No one had looked for a worst case scenario until
> it happened.  The Ariane 501 disintegrating at 4000 meters altitude
> (about 2 1/2 miles) was never imagined.  Fortunately most of the larger
> chunks of debris were carried upward before falling to the ground so
> there were no serious injuries.  But I would not have liked to have been
> one of the many technicians watching the launch from a couple of
> kilometers distant suddenly realizing that the Ariane 501 wreckage was
> planning to land where I was standing.

We had just this scenario in China when launching an Intelsat VII
using a Chines Long March Rocket.    Although Intelsat VII is
programmed in Ada, Long March (as far as I am able to determine)
was not.

I knew some of the people present at the launch and they were close
enough to be in danger.  As it is, quite a few villagers nearby were
killed and maimed.

Richard Riehle

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

Richard Riehle wrote:
> "Robert I. Eachus" wrote:
>>But to me the crowning idiocy of the whole thing is in one sentence of
>>the report: "The main explanation for the absence of this test has
>>already been mentioned above, i.e. the SRI specification (which is
>>supposed to be a requirements document for the SRI) does not contain the
>>Ariane 5 trajectory data as a functional requirement."
> 
> Since this discussion began as a dialogue about the Boeing 7E7, and someone
> raised the question of whether C++ would be appropriate for software on
> that aircraft, the lesson of Ariane 5 is important for the engineers.
...
> I have trained engineers to program in Ada and they take to it well and
> understand
> the underlying rationale for its design.   I have trained C++ programmers and
> many
> of the spend their time arguing about how they can do such-and-such in C++ and
> why can't they do it that way in Ada.     
...
> Richard Riehle

This experience once again demonstrates that mantra "skills are
trainable, but _attitudes_ are not."

Many younger folk seem to think their skillset is their most
marketable asset. This is perhaps true for contractors.

But for fulltime staff, companies want the right attitude, which
is very difficult, if not impossible to change. Skills OTOH, can
be provided through training and experience.

This seems to extend into the use of Ada, as Richard just demonstrated.
People can be trained to use Ada (adopting the right attitude), vs
changing the attitude of skilled C/C++ (adopting the language Ada).

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

Re: Boeing and Dreamliner

[Preben Randhol]

Richard Riehle wrote:

> If Boeing does decide to use Ada, and we would hope they would, the
> lessons of Ariane 5 are valuable.  

Sure. I find the story, although not true, about OO resue gave armed
kangaroos in the simulation software quite illustration and funny.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Boeing and Dreamliner

[Robert I. Eachus]

Hyman Rosen wrote:

> While people here are focussed on the fact that the trajectory
> specs were not made part of the specs of the Ariane 5 SRI, the
> actual problem was that the Ariane 4 SRI programmers did not
> indicate that the trajectory specs for the Ariane 4 actually
> impacted the implementation of the SRI code.

Were you involved in the actual decision?  Do you know something that we 
don't?

I find it hard to keep from laughing at someone documenting this as a 
"limitation" of the Ariane 4 code:  "Caution moving Ariane 4 more than 3 
  kilometers during gyroscope alignment may have serious consequences."

The details were all well documented.  Including the Ariane 4 
REQUIREMENT for the alignment software to run for 40 seconds after 
launch, and why it was required.  This requirement did not apply to the 
Ariane 5, and anyone looking at the Ariane 4 documentation would see 
potential serious consequences associated with not fixing this requirements.

Re: Boeing and Dreamliner

[Hyman Rosen]

Robert I. Eachus wrote:
> Were you involved in the actual decision?
 >  Do you know something that we don't?

That's what the report says.
<http://www.dcs.ed.ac.uk/home/pxs/Book/ariane5rep.html>
     "No reference to justification of this decision
      was found directly in the source code. Given the
      large amount of documentation associated with any
      industrial application, the assumption, although
      agreed, was essentially obscured, though not
      deliberately, from any external review."

> I find it hard to keep from laughing at someone documenting this as a 
> "limitation" of the Ariane 4 code:  "Caution moving Ariane 4 more than 3 
>  kilometers during gyroscope alignment may have serious consequences."

There was an unprotected conversion in the code,
with nothing to explain why it was unprotected.
The review team seems to think that this is a
problem. It's their conclusion, not mine.

> The details were all well documented.  Including the Ariane 4 
> REQUIREMENT for the alignment software to run for 40 seconds after 
> launch, and why it was required.  This requirement did not apply to the 
> Ariane 5, and anyone looking at the Ariane 4 documentation would see 
> potential serious consequences associated with not fixing this 
> requirements.

Well, apparently not. In any case, leaving the alignment function
on triggered the problem, but the actual problem was the shortcut
in the code and the lack of warning for when that code would be
invalid.

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Hyman Rosen wrote:

>Richard Riehle wrote:
> > The Ada code that caused a problem in Ariane 5 was perfectly
> > good code reused from Ariane 4.
>
>It was not perfectly good code.

It was a good example of politically correct phrase, and you simply failed
to sense all its power and beauty -:). Look again:

"The Ada code that caused a problem in Ariane 5 was perfectly
good code reused from Ariane 4."

This is a correct sentense, it conveys truth, but in such a way that you can't
dissect it or extract contiguous part of it without converting the truth to a
lie. Actually, the SRI software code for Ariane 4 was *perfectly good for
Ariane 4*, although it quite probably was not so good in general -- so your
sentense "It was not perfectly good code." is probably true also.

>While people here are focussed on the fact that the trajectory
>specs were not made part of the specs of the Ariane 5 SRI, the
>actual problem was that the Ariane 4 SRI programmers did not
>indicate that the trajectory specs for the Ariane 4 actually
>impacted the implementation of the SRI code.

The actual problem was the absence of testing (and the report stated it
clearly). The absence or weakness of comments or other indications related
to Ariane 4 SRI software is no more than a contributing factor (surely, it
will be better for those developers to write in red and bold: "This software
is for Ariane 4 only, it relies upon Ariane 4 specifications, it should not
be used for any other purpose!" on the title pages of all their documents).



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

Re: Boeing and Dreamliner

[Wesley Groleau]

Warren W. Gay VE3WWG wrote:
> But for fulltime staff, companies want the right attitude, which
> is very difficult, if not impossible to change. Skills OTOH, can
> be provided through training and experience.

Oh, now I understand!  I thought I wasn't finding
a job because I didn't have extensive C++ experience.
But really, the problem is I don't have a C++ attitude?

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Richard Riehle wrote:

>C++ would be a dangerous choice, not only because the language itself can lead
>to so many undecidables and unpredictable fragments of code, but also because
>the language, itself, implies a heavy reliance on resuable components.

This observation is both true and important, I think. The implicit link
between C++ language and cheap/easy reusability really exists. This is because
C++ was designed and evolved primarily for solution space.

>... The more I see of C++, the more experience
>I gain with it, the more I realize why Ada is designed to a more rigorous
>set of rules.  Those rules may be annoying to some programmers, but those
>rules make sense to an engineer.

Yes, because Ada is for problem space, and that is what engineers are needed.
They rightfully aren't biased towards solution space because they do not
worry whether their acquired programming skills will be useful (and valued
by some future employer) in generic application domain (games, databases,
Web servers etc.

>A fly-by-wire aircraft is an engineering problem, not a programming problem,
>even when software (and programming) are part of the solution space.  When one
>looks at this kind of system as a total engineering effort, one must also consider
>the software as part of the engineering, not separate from it.  With C++, it
>is too easy to disengage the software effort from the rest of the engineering
>effort.

Yes, this is another true and important observation.

>In my experience, good engineers, when
>exposed to Ada, do learn to create excellent software designs, and they learn
>to do so independent of the the search for the perfect algorithm.

Yes, but you said "good engineers" -:)  This sounds like you mean engineers
that already can see the problem space properly, and all they need is to
express their view formally. So you convey them an appropriate formalism --
and all are happy.

>Often, it
>is better to start with engineers and teach them Ada than to start with
>programmers who have already developed bad habits.

True, if you have enough time to teach, and good teachers (in addition to
good pupils - "good engineers").



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

Re: Boeing and Dreamliner

[Robert I. Eachus]

Wesley Groleau wrote:

> Oh, now I understand!  I thought I wasn't finding
> a job because I didn't have extensive C++ experience.
> But really, the problem is I don't have a C++ attitude?

Ah!  They are looking for a "Can Do!" attitude, and you have a "Will do 
it right!" attitude. ;-)

Re: Boeing and Dreamliner

[Hyman Rosen]

Alexander Kopilovitch wrote:
> This is a correct sentense, it conveys truth, but in such a way that you can't
> dissect it or extract contiguous part of it without converting the truth to a
> lie. Actually, the SRI software code for Ariane 4 was *perfectly good for
> Ariane 4*, although it quite probably was not so good in general -- so your
> sentense "It was not perfectly good code." is probably true also.

The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.
They wrote code that took advantage of limited input range, and sent it out
into the world with insufficient protection against the future. It was
perfectly good in the same way as two digit years.

Re: Boeing and Dreamliner

[AG]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:k2wLa.21663$N%6.3746@nwrdny02.gnilink.net...

> The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.
> They wrote code that took advantage of limited input range, and sent it
out
> into the world with insufficient protection against the future. It was
> perfectly good in the same way as two digit years.
>

Come to think of that, had anyone heard of a really
dramatic Y2K failures? Something on the scale of
that example?

Re: Boeing and Dreamliner

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:k2wLa.21663$N%6.3746@nwrdny02.gnilink.net...
> The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.

This is a bad analogy.  No need to attempt to drag in the Y2K herring.

> They wrote code that took advantage of limited input range, and sent it
out
> into the world with insufficient protection against the future.

All constraint based bugs fall into this category.

> It was
> perfectly good in the same way as two digit years.

I take it you mean
"Y2k code is perfectly good for the years 1900 to 1999"
is similar to
"The Ariane 4's SRI software is perfectly good for the Ariane 4."

which is similar to saying that both systems are partially correct in some
sense.
You must have a distorted the meaning of the phase "perfectly good in
<context>" which has been used.  You seem to think that the phrase means
"perfectly good in general" a phrase that is of course false for all
programs.  Note the difference:

"Y2k code is perfectly good."
is similar to
"The Ariane 4's SRI software is perfectly good."

They are both similar in that they are both false statements.

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Hyman Rosen wrote:

>The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.

Why *micro*cosm? All Ariane rockets are for normal-scale cosmos, I think -:)

>They wrote code that took advantage of limited input range, and sent it out
>into the world with insufficient protection against the future. It was
>perfectly good in the same way as two digit years.

With these words you stepped on my (programmer's) native soil -;) , and here
I simply *know* why those 2-digit year representation was right thing in many
cases that old time (so programs that use it may be called perfect).

It's quite easy: imagine 1970th, IBM/360 running DOS/360, 64K or 128K of
memory, 2 or 3 hard drives, 7.25 Mb each, and 3-4 tape drives (about 20Mb
each). Then imagine that you must process all documents for all trucks in
quite big (5M) city every day. Each document contains several dates.

I hope it is obvious enough that several percents of whole data volume was
significant weight, and that there weren't many people who prefer to carry it
(having very limited hardware resources) for the reason that those programs
may survive 20+ years, and then, in far future there may be problems with
this issue.

We were all sure that those our programs can't survive 20+ years.
No one can predict in 1970th and early 1980th that hardware will skyrocket
while software will essentially stall. So, if there was an error, it was in
the prediction (or expectations) of general trends in computer development,
not in design of particular programs.

(Incidentally, here in Russia we did not feel any significant impact of Y2K
-- just because our mainframes did not survive that far; at the same time
many programmers here in 1999-2000 were making their living from American and
European Y2K problems -;)



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

Re: Boeing and Dreamliner

[Richard Riehle]

Hyman Rosen wrote:

> Alexander Kopilovitch wrote:
> > This is a correct sentense, it conveys truth, but in such a way that you can't
> > dissect it or extract contiguous part of it without converting the truth to a
> > lie. Actually, the SRI software code for Ariane 4 was *perfectly good for
> > Ariane 4*, although it quite probably was not so good in general -- so your
> > sentense "It was not perfectly good code." is probably true also.
>
> The Araine 4 programmers exactly reproduced the Y2K problem in microcosm.
> They wrote code that took advantage of limited input range, and sent it out
> into the world with insufficient protection against the future. It was
> perfectly good in the same way as two digit years.

A key difference between designing in Ada and  many other languages
is the use of problem-space constraints.   For example, a designer might
declare an integer type such as,

                   type Number is range 12..451;

if the problem under consideration called for that kind of constraint.  If,
at some later time, I decide to use the solution bounded by that constraint
to solve a problem that requires a different set of constraints, I will have
made a mistake.   The mistake, in that case, is mine, not that of the previous
designers.

What we often encourage, for Ada designs, is that the algorithmic details
be independent of some particular set of constraints.   Generic components
are sometimes useful for this.  For example,

                   generic
                       type Num is range <>;
                   function Compute(Data : Num) return Num;

where the internal algorithmic construct will behave exactly the
same way on every instantiation of Compute after associating the
generic formal parameter with a generic actual parameter.

Putting aside the option of designing with generics, since many in the
safety-critical community distrust this language feature,  the issue of
specifying constraints that precisely map the solution-space to the
problem-space continues to be a useful feature of the language.  If
I accept this constraint during development, many potential problems
will be identified early in my process.

If, on the other hand, I choose to bypass the language safeguards and
use  unchecked features of the language,  I am putting my entire design
at risk.   This is one aspect of the Ariane 4 software that contributed
to the Ariane 5 event.   The developers of the Ariane 4 software took
the trouble to ensure that the unchecked operations were appropriate.
The engineers on Ariane 5, many of who were the same people from
Ariane 4, failed to evaluate the potential consequences of those same
unchecked operations.

Is this a failure of the language.  One might suggest that the option of
unchecked operations in Ada is a language problem.  However, we
must also recognize that the language clearly specifies that unchecked
operations are "unchecked" by the compiler.   In most languages, such
unchecked operations are the default, not an option.   For  example, in
the C family of languages, automatic type promotions rarely present
any kind of warning to the programmer.   In Ada, the programmer must
bypass the normal rules of the language to achieve the same result.

So, the software design for Ariane 4 was exactly right for Ariane 4. It
was not designed for some future system.   To suggest that this is the
equivalent of Y2K is interesting.  It re-raises some issues related to the
original subject of this thread, that of the Boeing 7E7 and Boeing 777.
And those issues directly support the folly of even thinking about using
C++ for this aircraft.  They also indicate where caution should be the
watchword when transitioning 777 software to the 7E7.

As I indicated in an earlier posting, I am confident the Boeing engineers
will understand the lessons of Ariane 4/5 when re-using Ada code from
the 777 on the 7E7.  I am also confident that, pressures from resume-builders
notwithstanding, they will realize the value of using contemporary Ada,
with its excellent record for software safety, instead of a language so
characterized by unpredictability that they could never be sure that some
undetected behavior might manifest itself long after even the best of
testing has been completed.

Richard Riehle

Re: Boeing and Dreamliner

[Hyman Rosen]

Chad R. Meiners wrote:
> You must have a distorted the meaning of the phase "perfectly good in
> <context>" which has been used.  You seem to think that the phrase means
> "perfectly good in general" a phrase that is of course false for all
> programs.

No. The investigation board thought that the <context> was inadequately
documented, so that the reusers did not realize that the <context> was
present.

That's the Y2K problem in a nutshell. It's not just that two-digit years
were used, it's that no one remembered *where* they were used.

Re: Boeing and Dreamliner

[Hyman Rosen]

Alexander Kopilovitch wrote:
> I simply *know* why those 2-digit year representation was right thing

Yes, the problem wasn't just that two-digit years were used, it's that
no one remembered *where* they were used when the time came to worry
about them. In the Ariane 5 case, they didn't even realize that there
was something to worry about.

Re: Boeing and Dreamliner

[Hyman Rosen]

Richard Riehle wrote:
> And those issues directly support the folly of even thinking about using
> C++ for this aircraft.

Unsurprisingly, I disagree. You're talking about a situation where every
arithmetic operation in the code was carefully scrutinized. I'm sure that
in the cases were protection was left in the Ariane 4 code it did not
consist of allowing an Ada exception to be raised on overflow, but rather
coding in such a way that a correct numeric result would be produced. I
don't see why such scrutiny would not result in equally safe C++ code.


> I am also confident that, pressures from resume-builders
> notwithstanding, they will realize the value of using contemporary Ada,
> with its excellent record for software safety, instead of a language so
> characterized by unpredictability that they could never be sure that some
> undetected behavior might manifest itself long after even the best of
> testing has been completed.

I obviously disagree with you about the suitability of C++, but I
certainly agree that Ada is a fine choice as well. As for resume
building, I would just let such people do their building elsewhere.

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <RTHLa.23921$N%6.8888@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Alexander Kopilovitch wrote:
>> I simply *know* why those 2-digit year representation was right thing
> 
> Yes, the problem wasn't just that two-digit years were used, it's that
> no one remembered *where* they were used when the time came to worry
> about them. In the Ariane 5 case, they didn't even realize that there
> was something to worry about.

With Ariane 5, a human decision was made to change the context.

With Y2K, programs were in use which were both flawed in the face of
a context change and dependent on the context changing (mortgage accounts
depended on the year becoming "one greater", for instance).

Re: Boeing and Dreamliner

[Hyman Rosen]

Larry Kilgallen wrote:
> With Ariane 5, a human decision was made to change the context.

Please read the investigation report. It's clear from the report
that they think this decision was made because the Ariane 4 SRI
software did not come with sufficiently clear documentation that
this ocntext existed.

Re: Boeing and Dreamliner

[Larry Kilgallen]

In article <uJILa.24085$N%6.15479@nwrdny02.gnilink.net>, Hyman Rosen <hyrosen@mail.com> writes:
> Larry Kilgallen wrote:
>> With Ariane 5, a human decision was made to change the context.
> 
> Please read the investigation report. It's clear from the report
> that they think this decision was made because the Ariane 4 SRI
> software did not come with sufficiently clear documentation that
> this ocntext existed.

Assuming there is no context for a piece of software is fatuous.

Re: Boeing and Dreamliner

[Hyman Rosen]

Larry Kilgallen wrote:
> Assuming there is no context for a piece of software is fatuous.

In a project as thoroughly specified, documented, and tested as this,
assuming that important limitations would be mentioned is not fatuous,
just unfortunate.

Re: Boeing and Dreamliner

[Berend de Boer]

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

    >> Assuming there is no context for a piece of software is
    >> fatuous.

    Hyman> In a project as thoroughly specified, documented, and
    Hyman> tested as this, assuming that important limitations would
    Hyman> be mentioned is not fatuous, just unfortunate.

It was mentioned, but not in the source. I think it was even proven
this exception could not occur for Ariadne 4.

-- 
Regards,

Berend. (-:

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Hyman Rosen wrote:

>The investigation board thought that the <context> was inadequately
>documented, so that the reusers did not realize that the <context> was
>present.

Interesting turn. Let me recall your own quotaion from the report (from your
posting 23.06.2003 12:00:28 PST) :

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

So, the report says that the assumption was essentially obscured because of
large amount of documentation, This means that the assumption *was* documented,
I think. Do you think otherwise?

So, if we agree that the assumption *was* documented then the problem moves
to another area - organization of the documentation for the whole system.
Also, don't you think that there is something wrong in organization when
the source code has to be explored in a search for justification of some
decision, and at the same time a present one cannot be find in documentation
because of "large amount" of the latter? Should we consider source code as
documenation for documentation?

>That's the Y2K problem in a nutshell. It's not just that two-digit years
>were used, it's that no one remembered *where* they were used.

That was in Y2K, right. But there was nothing similar in Ariane 5 case: they
did not expect any problems with reuse of SRI software. If they suspected
anything like that, there was no obstacles for identifying and locating the
problem.



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

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

Hyman Rosen wrote:
> Richard Riehle wrote:
> 
>> And those issues directly support the folly of even thinking about using
>> C++ for this aircraft.
> 
> Unsurprisingly, I disagree. You're talking about a situation where every
> arithmetic operation in the code was carefully scrutinized. I'm sure that
> in the cases were protection was left in the Ariane 4 code it did not
> consist of allowing an Ada exception to be raised on overflow, but rather
> coding in such a way that a correct numeric result would be produced. I
> don't see why such scrutiny would not result in equally safe C++ code.

I would disagree with your position on the basis that even where code
is carefully scrutinized, within Ada you have the advantage of builtin
language features to check areas that you might neglect (while developing
and testing at least, prior to checks being turned off).

For example, where a short (16 bit integer) in C/C++ might hold the
value -32768, and be negated and assigned to a short result, this
operation might be undefined (I am not sure if any newer standard like
C99 addresses this). On some implementations at least, that result is
silently set to 0, which clearly is incorrect! In Ada, this cannot be
ignored without deliberately working around it (or turning the checks
off).

I would also suggest that there are probably better "proving tools"
available for Ada, than there are for C/C++. I don't have any direct
experience with these tools, but I am sure that others in this NG
can comment on that.

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

Re: Boeing and Dreamliner

[Alexander Kopilovitch]

Hyman Rosen wrote:

>Richard Riehle wrote:
>> And those issues directly support the folly of even thinking about using
>> C++ for this aircraft.
>
>Unsurprisingly, I disagree. You're talking about a situation where every
>arithmetic operation in the code was carefully scrutinized. I'm sure that
>in the cases were protection was left in the Ariane 4 code it did not
>consist of allowing an Ada exception to be raised on overflow, but rather
>coding in such a way that a correct numeric result would be produced. I
>don't see why such scrutiny would not result in equally safe C++ code.

There is vague but powerful thing - "expectations". In Ada world it is
natural to expect that a component is suited and perhaps optimized for the
particular purpose, unless otherwise it explicitly stated. The situation in
C++ world is often quite opposite: it is common to expect that a class or
class library provides some kind of acceptable/reasonable behaviour for some
generic range of applications, and that behaviour must be overridden if/when
we have have specific requirements.

Therefore typical C++ programmer will not scrutinize the component unless he
either has specific requirements or is alarmed by something - just because
he *expects* from the component a resonable generic behaviour. And when he
is given an Ada component, his habits - his usual expectations may well be
in effect in the area where they are certainly invalid.

Then to the habit of looking into source code as into a guide for documentation.
It is also a habit of C++ world. Just one real example from Symbian OS C++ SDK
(for SonyEricsson P800 smartphone): for preventing a dialog to be closed on
application deactivation you should implement ShutL() method of CEikDialog
class - this is said in the special separate page of SDK docs. But there is
no ShutL() method in the documentation of the CEikDialog class, as well as
in the documentation for its ancestors. Well, let's look into source code -
CEikDialog class definition - and yes, we see there method ShutL() - it is
private (so it was not included in documentation) but virtual (so it may be
overriden).

Thus C++ programmer often looks into source code, expecting to find there some
clues for documentation.

So, even the C++ habits may lead to disasters when applied in Ada world --
because expectations in these two worlds are quite different. And it is possible
that exactly this thing was a contributing factor in Ariane 5 case.



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

Re: Boeing and Dreamliner

[Richard Riehle]

Hyman Rosen wrote:

> Richard Riehle wrote:
> > And those issues directly support the folly of even thinking about using
> > C++ for this aircraft.
>
> Unsurprisingly, I disagree. You're talking about a situation where every
> arithmetic operation in the code was carefully scrutinized. I'm sure that
> in the cases were protection was left in the Ariane 4 code it did not
> consist of allowing an Ada exception to be raised on overflow, but rather
> coding in such a way that a correct numeric result would be produced. I
> don't see why such scrutiny would not result in equally safe C++ code.

C++ is simply not designed this way.   Ada is.   In C++ it is perfectly legal
to do all kinds of assignment statements where the result is not entirely
predictable.   A key difference between Ada and many other languages is
the absence of structural equivalence in favor of named equivalence.  That
is, the fact that there might be some possible structural compatibility between

objects with different names (or type designations) is never sufficient
justification for a legal operation involving types of different names.

Even unchecked operations, when there is a potential for an erroneous
result, result in a warning in better Ada compilers.  Also, unchecked
assignment (Unchecked_Conversion) only permits assignment in the
direction for which it is instantiated.   This eliminates many kinds of
errors.

Quite simply, the amount of error checking performed by an Ada compiler
is substantially greater than in C++.   This does not mean C++ is evil.  It
simply means it is inappropriate for software that demands a high level of
dependability, especially when one has Ada available as an option.

I really don't want this to sound like C++ bashing.   However, the more I
learn about C++, the more I realize it is an excellent language for certain
classes of problems, but is more dangerous for safety-critical software
than Ada.   By all means, use C++ for graphics, statistical analysis, business
problems, and similar kinds of problems.   But, do not use it for software
where life and safety are involved.   This is simply a matter of selecting
the right tool for the right job.

> > I am also confident that, pressures from resume-builders
> > notwithstanding, they will realize the value of using contemporary Ada,
> > with its excellent record for software safety, instead of a language so
> > characterized by unpredictability that they could never be sure that some
> > undetected behavior might manifest itself long after even the best of
> > testing has been completed.
>
> I obviously disagree with you about the suitability of C++, but I
> certainly agree that Ada is a fine choice as well. As for resume
> building, I would just let such people do their building elsewhere.

I know you are a skilled and experienced C++ developer.   Does it not
occur to you that simple little things such as automatic type promotion,
incorrect placement of curly braces, and errors in pointer arithmetic,
to name a few issues, might result in questionable code?   What about
incorrectly defined destructors?    Or default assignment operations?
Or many more such entertaining features of C++ that add power, but
also add the potential for undetected errors?   You know the list is
even longer than the one I just presented.

Richard Riehle

Re: Boeing and Dreamliner

[Hyman Rosen]

Richard Riehle wrote:
 > In C++ it is perfectly legal to do all kinds of assignment statements
 > where the result is not entirely predictable.

I'm not sure what you mean by this. If you're talking about order
of evaluation, Ada has the same lack of predictability, although
Java does not.

> A key difference between Ada and many other languages is
> the absence of structural equivalence in favor of named equivalence.

Again, I don't know how this applies to C++, except for one case I
can think of - a union with record members all of which share the
identical set of leading fields. X Window uses this feature to allow
access to the type of an event.

> Also, unchecked assignment (Unchecked_Conversion) only permits
 > assignment in the direction for which it is instantiated.
 > This eliminates many kinds of errors.

It's true that C and C++ allow interconversion between the basic
arithmetic types without requiring an explicit conversion, but I've
never noticed it as being a particularly fruitful source of errors.
Compilers are perfectly happy to whinge about these if you ask them
to, in any case.

> Quite simply, the amount of error checking performed by an Ada compiler
> is substantially greater than in C++.   This does not mean C++ is evil.  It
> simply means it is inappropriate for software that demands a high level of
> dependability, especially when one has Ada available as an option.

Proponents of SPARK have argued that plain Ada contains ten times as many
errors as SPARK code, so I suppose the continued use of plain Ada means that
its practitioners realize that their code does not demand that much
dependability.

> C++ is more dangerous for safety-critical software than Ada.

You are most likely correct. But Java provides many of the same sorts
of error checking - pointer access and bounds checking - that Ada does,
and with garbage collection, doesn't offer the possibility of an
unchecked deallocation sending code astray. So maybe it's better than
Ada?

> I know you are a skilled and experienced C++ developer.   Does it not
> occur to you that simple little things such as automatic type promotion,
> incorrect placement of curly braces, and errors in pointer arithmetic,
> to name a few issues, might result in questionable code?

They might, especially pointer arithmetic. I doubt that the others ever
affect real code, althouggh it's obviously possible to concoct examples.
But pointer arithmetic is used for processing within arrays. Ada will
catch you if you step off the ends and C won't, but if you have a muddle
in the middle, you can have it with indexes as well as with pointers.

> What about incorrectly defined destructors?

But Ada has finalizers which can be equally wrong.

> Or default assignment operations?

Ada has default bitwise assignment too. You can turn it off in Ada,
abd you can turn it off in C++.

> Or many more such entertaining features of C++ that add power, but
> also add the potential for undetected errors?   You know the list is
> even longer than the one I just presented.

I guess it's like riding a motorcycle.

Re: Boeing and Dreamliner

[Dmitry A. Kazakov]

On Tue, 01 Jul 2003 05:31:20 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Richard Riehle wrote:
> > In C++ it is perfectly legal to do all kinds of assignment statements
> > where the result is not entirely predictable.
>
>I'm not sure what you mean by this. If you're talking about order
>of evaluation, Ada has the same lack of predictability, although
>Java does not.
>
>> A key difference between Ada and many other languages is
>> the absence of structural equivalence in favor of named equivalence.
>
>Again, I don't know how this applies to C++, except for one case I
>can think of - a union with record members all of which share the
>identical set of leading fields. X Window uses this feature to allow
>access to the type of an event.

Another example is pointers. They are matched by structure not by
names. In Ada different pointer types are different even if they point
to objects of same type. It might look strange from C++ point of view,
but sometimes it is very useful (consider storage pools, for example).

However, it seems impossible to drop structured equivalence
completely. So even in Ada there are anonymous access types, array
types, ranges, T'Class etc, all matched by structure.

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

Re: Boeing and Dreamliner

[Marin David Condic]

That is exactly wherein lies the fault. The software itself was designed 
properly and it behaved exactly as it was intended to for an A-4 rocket. 
It detected a failure and accommodated it. Just that in the A-5 this 
wasn't a "failure". The true problem came in that the unit in question 
was never flown on a bench simulation for the new rocket. This was 
*extremely* poor judgement on the part of the program management - 
probably under pressure to cut costs. Its just practically unheard of to 
  take a critical piece of avionics and mount it in a new application 
and not do some form of system test across the expected flight envelope. 
(Even if the "system test" is a flight test with a pilot and a 
parachute. ;-) This was a management screw-up, pure and simple. Had they 
conducted a system test, it would have shown the flaw in the system. You 
can't blame the IRS - it did *exactly* what it was designed to do. 
Attempts to do so are akin to mounting a golf-cart tire on a semi truck 
and then cursing it when it blows out.

MDC



Dennis Lee Bieber wrote:
> 
>         Surely there was a /requirements/ document for both A-4 and A-5, and 
> somewhere in there was something specifying the performance of the 
> vehicles. /That/ should have been the red-flag that something needed to 
> be retested. That is, if the A-4 had a spec stating some performance 
> feature of "x", and the A-5 equivalent shows "X+1", then shouldn't the 
> software responsible for handling the spec be tested to ensure it can 
> handle "X+1"?
> 


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

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

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

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

Re: Boeing and Dreamliner

[John R. Strohm]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:qld2gv8e6mje2k6vbni41ffcke33jf1od2@4ax.com...
> On Tue, 01 Jul 2003 05:31:20 GMT, Hyman Rosen <hyrosen@mail.com>
> wrote:
>
> >Richard Riehle wrote:
> > > In C++ it is perfectly legal to do all kinds of assignment statements
> > > where the result is not entirely predictable.
> >
> >I'm not sure what you mean by this. If you're talking about order
> >of evaluation, Ada has the same lack of predictability, although
> >Java does not.
> >
> >> A key difference between Ada and many other languages is
> >> the absence of structural equivalence in favor of named equivalence.
> >
> >Again, I don't know how this applies to C++, except for one case I
> >can think of - a union with record members all of which share the
> >identical set of leading fields. X Window uses this feature to allow
> >access to the type of an event.
>
> Another example is pointers. They are matched by structure not by
> names. In Ada different pointer types are different even if they point
> to objects of same type. It might look strange from C++ point of view,
> but sometimes it is very useful (consider storage pools, for example).

Quibble.

My understanding is that Ada does not have "pointers", but rather "access
types".  Further, it is my understanding that, while the semantics of access
types in Ada resemble those of pointers in other languages, the Ada
compiler-writer is under NO obligation to implement access types using
physical pointers.

Is this correct?

RE: Boeing and Dreamliner

[rleif]

The discussion of the Ariane V fiasco below can be summed up by the first
law of software engineering, Garbage_In = Garbage_Out. The garbage, in this
case was a design specification that included inappropriate reuse. I hope
that we can either end this discussion or reorient it to something more
productive.
Bob Leif

Robert C. Leif, Ph.D.
e-mail rleif@rleif.com
-----Original Message-----
From: Marin David Condic [mailto:nobody@noplace.com] 
Sent: Tuesday, July 01, 2003 4:55 AM
To: comp.lang.ada@ada.eu.org

That is exactly wherein lies the fault. The software itself was designed 
properly and it behaved exactly as it was intended to for an A-4 rocket. 
It detected a failure and accommodated it. Just that in the A-5 this 
wasn't a "failure". The true problem came in that the unit in question 
was never flown on a bench simulation for the new rocket. This was 
*extremely* poor judgement on the part of the program management - 
probably under pressure to cut costs. Its just practically unheard of to 
  take a critical piece of avionics and mount it in a new application 
and not do some form of system test across the expected flight envelope. 
(Even if the "system test" is a flight test with a pilot and a 
parachute. ;-) This was a management screw-up, pure and simple. Had they 
conducted a system test, it would have shown the flaw in the system. You 
can't blame the IRS - it did *exactly* what it was designed to do. 
Attempts to do so are akin to mounting a golf-cart tire on a semi truck 
and then cursing it when it blows out.

MDC



Dennis Lee Bieber wrote:
> 
>         Surely there was a /requirements/ document for both A-4 and A-5,
and 
> somewhere in there was something specifying the performance of the 
> vehicles. /That/ should have been the red-flag that something needed to 
> be retested. That is, if the A-4 had a spec stating some performance 
> feature of "x", and the A-5 equivalent shows "X+1", then shouldn't the 
> software responsible for handling the spec be tested to ensure it can 
> handle "X+1"?
> 


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

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

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

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

Re: Boeing and Dreamliner

[Robert I. Eachus]

Dennis Lee Bieber wrote:

>         Surely there was a /requirements/ document for both A-4 and A-5, and 
> somewhere in there was something specifying the performance of the 
> vehicles. /That/ should have been the red-flag that something needed to 
> be retested. That is, if the A-4 had a spec stating some performance 
> feature of "x", and the A-5 equivalent shows "X+1", then shouldn't the 
> software responsible for handling the spec be tested to ensure it can 
> handle "X+1"?

Correct.  But what happened in the Ariane 5 case was a very well 
documented case of someone early on in the project defining how that 
testing was to be done, and management for cost reasons deciding not to 
do that particular testing--because the SRI had not changed one bit from 
the Ariane 4.

Anyone with major project experience should know this.  Any changes in 
the test plan have to be referenced back through the requirements 
allocations to see whether there are some requirements that are not 
being tested.  In this case the requirements that were not tested were 
that the SRI could control an Ariane 5, and that the SRI could accept 
the Ariane 5 trajectory.  Pretty fundamental requirements to fail to test.

-- 

                                                        Robert I. Eachus

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

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

Alexander Kopilovitch wrote:
> Hyman Rosen wrote:
>>Richard Riehle wrote:
>>
>>>And those issues directly support the folly of even thinking about using
>>>C++ for this aircraft.
>>
>>Unsurprisingly, I disagree. You're talking about a situation where every
>>arithmetic operation in the code was carefully scrutinized. I'm sure that
>>in the cases were protection was left in the Ariane 4 code it did not
>>consist of allowing an Ada exception to be raised on overflow, but rather
>>coding in such a way that a correct numeric result would be produced. I
>>don't see why such scrutiny would not result in equally safe C++ code.
> 
> There is vague but powerful thing - "expectations". In Ada world it is
> natural to expect that a component is suited and perhaps optimized for the
> particular purpose, unless otherwise it explicitly stated. The situation in
> C++ world is often quite opposite: it is common to expect that a class or
> class library provides some kind of acceptable/reasonable behaviour for some
> generic range of applications, and that behaviour must be overridden if/when
> we have have specific requirements.

What you're suggesting is that C++ code is always/mostly suitable in
a general way. This is like suggesting that an engine made for a
Piper cub should always be suitable for bigger jobs like bombers!

I think this argument leaks in a major way! ;-)

Even what you'd call generic or general solution has limitations. Whether
an int or a short is used, you have range limitations. Whether you use
a float or a double, you have precision and range limitations builtin.
And this is just the tip of the iceburg.

C++ does not hold any advantage here.

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

Re: Boeing and Dreamliner

[Dave Thompson]

On Mon, 30 Jun 2003 11:55:00 -0400, "Warren W. Gay VE3WWG"
<ve3wwg@cogeco.ca> wrote:
[snip]
> I would disagree with your position on the basis that even where code
> is carefully scrutinized, within Ada you have the advantage of builtin
> language features to check areas that you might neglect (while developing
> and testing at least, prior to checks being turned off).
> 
> For example, where a short (16 bit integer) in C/C++ might hold the
> value -32768, and be negated and assigned to a short result, this
> operation might be undefined (I am not sure if any newer standard like
> C99 addresses this). On some implementations at least, that result is
> silently set to 0, which clearly is incorrect! In Ada, this cannot be
> ignored without deliberately working around it (or turning the checks
> off).
> 
In C and C++ short is _at least_ 16 bits, but may be more, and
negation (prefix '-') is done after (at least virtually) applying the
integral promotions, which includes short to int.

If int is also 16bit 2sC capable of representing -32768 but not 
+32768, which is legal but increasingly rare, then the negation 
is overflow and undefined behavior, which may theoretically do
anything, and in particular no check or diagnostic required.
This is the same in C89, C99, and C++98.  In practice it is 
expected that if the platform has a negate (or subtract) 
instruction or function that works correctly for nonoverflow 
cases, the C compiler will just use it and accept whatever 
it does for overflow, which is typically either a wrong value, 
almost always a wrapped value, or some trap or signal.

If short is 16bit but int is larger (e.g. 32bit) then the (promotion
and) negation is well-defined, and the narrowing assignment to short 
produces an implementation-defined result in C89 or C++98, 
and either an implementation-defined result or an implementation-
defined signal in C99; implementation-defined means it must be 
documented.  Still no check or diagnostic is required, unless the 
implementor chooses to doument such, but it is required that 
you either get some value or in C99 only some definite signal 
which (presumably?) can be caught by a signal() routine although not
necessarily recovered/resumed; you may not get arbitrary weirdness or
crash.  FWTW.

These cases can be distinguished, if necessary, at or before compile
time by checking the values in <limits.h>.

- David.Thompson1 at worldnet.att.net

Re: Boeing and Dreamliner

[Wesley Groleau]

John R. Strohm wrote:
> types in Ada resemble those of pointers in other languages, the Ada
> compiler-writer is under NO obligation to implement access types using
> physical pointers.
> 
> Is this correct?

What is a physical pointer?  An address?
If so, you are correct.  I have found bugs
where a programmer thought (incorrectly)
that they could pass an access value to C
for a pointer instead of passing The_Access.all'Address

Re: Boeing and Dreamliner

[Robert I. Eachus]

Wesley Groleau wrote:
> John R. Strohm wrote:
> 
>> types in Ada resemble those of pointers in other languages, the Ada
>> compiler-writer is under NO obligation to implement access types using
>> physical pointers.
>>
>> Is this correct?
> 
> What is a physical pointer?  An address?
> If so, you are correct.  I have found bugs
> where a programmer thought (incorrectly)
> that they could pass an access value to C
> for a pointer instead of passing The_Access.all'Address

I would go further and say that there are many places in Ada where an 
access value CANNOT be implemented as a simple physical pointer.  The 
simplest example is an access to subprogram, where you need to pass both 
the code AND the environment/closure.  This is not new to Ada, and in 
fact I could probably recall offhand how this was handled in several 
PL/I compilers.  (Multics PL/I used three "physical" pointers, while 
Stratus used two.)  Then there are things like bit pointers and bit 
slices that need to point to something smaller than an address.

Wesley Groleau's idiom will always work if anything works.  But there 
are things you just can't do.  (For example passing a pointer to a 
nested Ada subprogram to C probably won't work if there are any 
"uplevel" references.  One of the nice things about OpenVMS is the 
common calling sequence for all languages, so if you do pass a "fat" 
pointer, the C environment knows what to do with it.)




-- 

                                                        Robert I. Eachus

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

Re: Boeing and Dreamliner

[Warren W. Gay VE3WWG]

Dave Thompson wrote:
> On Mon, 30 Jun 2003 11:55:00 -0400, "Warren W. Gay VE3WWG"
> <ve3wwg@cogeco.ca> wrote:
> [snip]
> 
>>I would disagree with your position on the basis that even where code
>>is carefully scrutinized, within Ada you have the advantage of builtin
>>language features to check areas that you might neglect (while developing
>>and testing at least, prior to checks being turned off).
>>
>>For example, where a short (16 bit integer) in C/C++ might hold the
>>value -32768, and be negated and assigned to a short result, this
>>operation might be undefined (I am not sure if any newer standard like
>>C99 addresses this). On some implementations at least, that result is
>>silently set to 0, which clearly is incorrect! In Ada, this cannot be
>>ignored without deliberately working around it (or turning the checks
>>off).
> 
> In C and C++ short is _at least_ 16 bits, but may be more, and
> negation (prefix '-') is done after (at least virtually) applying the
> integral promotions, which includes short to int.
> 
> If int is also 16bit 2sC capable of representing -32768 but not 
> +32768, which is legal but increasingly rare, then the negation 
> is overflow and undefined behavior, which may theoretically do
> anything, and in particular no check or diagnostic required.
> This is the same in C89, C99, and C++98.  In practice it is 
> expected that if the platform has a negate (or subtract) 
> instruction or function that works correctly for nonoverflow 
> cases, the C compiler will just use it and accept whatever 
> it does for overflow, which is typically either a wrong value, 
> almost always a wrapped value, or some trap or signal.
> 
> If short is 16bit but int is larger (e.g. 32bit) then the (promotion
> and) negation is well-defined, and the narrowing assignment to short 
> produces an implementation-defined result in C89 or C++98, 
> and either an implementation-defined result or an implementation-
> defined signal in C99; implementation-defined means it must be 
> documented.  Still no check or diagnostic is required, unless the 
> implementor chooses to doument such, but it is required that 
> you either get some value or in C99 only some definite signal 
> which (presumably?) can be caught by a signal() routine although not
> necessarily recovered/resumed; you may not get arbitrary weirdness or
> crash.  FWTW.
> 
> These cases can be distinguished, if necessary, at or before compile
> time by checking the values in <limits.h>.
> 
> - David.Thompson1 at worldnet.att.net

So what this says, in the end, is that it is up to the programmer
to make these "checks" and to "do the right thing".

This is clearly one specific area that Ada has a
advantage in safety. Unless you run/test your code
with the checks deliberately turned off, you will discover this
little gem immediately (assuming that you encounter the right
data, that is). Conversely, in C/C++, this "undefined
behavior" may go completely unnoticed, until it has a disasterous
side effect somewhere else down the line.

This is the precise scenario I ran into when porting some C code
into Ada some time ago. The SOX C code was oblivious to this
"error", but the Ada code that I ported caught it.  So this
was a real example of the C programmer failing to "do the
right thing", and Ada forcing _this_ programmer to
do "the right thing." ;-)

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