Re: Ada / Boeing 777

Re: Ada / Boeing 777

[Thomas C. Timberlake]

See also the article "Software Development on the 777" by
Ron Pehrson, Boeing Manager, Embedded Software.  This
article appears in the STSC newsletter, CrossTalk.  It is 
available electronically via the STSC Web site at:

<http://www.stsc.hill.afb.mil>

follow the links to the January '96 issue of CrossTalk.

-- 
Tom Timberlake                                                 Member, Team Ada
Boeing Defense & Space Group                  Software Systems         
timberlake@xavier.ds..boeing.com
Member Team Ada

Re: Ada / Boeing 777

["Tim Rowe"]

ron thompson <thompsor@admin.tc.faa.gov>

> The only "bugs", "problems", "burps", "hiccups", whatever
> you wish to call them that matter in an airplane are
> the ones that keep it on the ground.

This is patently wrong, and dangerously so. "bugs", "problems", "burps", 
"hiccups" that keep an aircraft on the ground are intrinsically pretty 
safe. The ones that *do* matter are the ones that are likely to encourage 
the aircraft to *return* to the ground in an untimely and inadequately 
controlled manner. Commonly called a crash.

As an example, there was a known fault on one of the Airbus range (which 
has been flying total fly-by-wire for *many* years before the 777!) that 
meant that when flying a heading of 00 degrees, if the pilot commanded 
the aircraft to turn a bit one way, the aircraft could actually turn the 
other way. It was turning to the correct heading, but it was going the 
359 degree route, not the 1 degree route. Now, there are not many runways 
in the world that are close to north-south, but there are a few, and when 
that bug showed itself on a final approach I bet the pilots pants turned 
brown. The pilot recovered it safely, but it was the subject of an 
accident investigation, and I read about it in the published results. It 
turned up in comp.risks, too, as you might expect. Presumably JAA is 
satisfied that it's safe, but sorry, the fact that it is flying is not 
any such proof.

AIUI the Airbus range has triplicated *diverse* systems for critical 
functions. The 777 has triplicated *identical* systems (I'm trusting the 
press for this, so it may not be gospel).

digiTig
(Tim Rowe)

Re: Ada / Boeing 777

[Thomas C. Timberlake]

In article <timberlake-1503961518470001@tomt.ds.boeing.com>,
timberlake@xavier.ds.boeing.com (Thomas C. Timberlake) wrote:

> See also the article "Software Development on the 777" by
> Ron Pehrson, Boeing Manager, Embedded Software.  This
> article appears in the STSC newsletter, CrossTalk.  It is 
> available electronically via the STSC Web site at:
> 
> <http://www.stsc.hill.afb.mil>
> 
> follow the links to the January '96 issue of CrossTalk.

The correct URL is of course:

   <http://www.stsc.hill.af.mil>

-- 
Tom Timberlake                                                 Member, Team Ada
Boeing Defense & Space Group                  Software Systems         
timberlake@xavier.ds..boeing.com
Member Team Ada

Re: Ada / Boeing 777

[Ken Garlington]

ron thompson wrote:

> 777 is the first 100% fly by wire, no mechanical backups
> of any kind, built in the US of A.

First _commercial_ aircraft that is 100% fly by wire, no
mechanical backups, built in the USA, of course.

As far as I know, the first production aircraft, including
_military_ aircraft, that was 100% fly by wire with no mechanical
backups of any kind, and built in the USA, has been in production
for about two decades now. The first _digital_ (software-based)
production yah de dah de dah has been in production for about
six years.

The F-16, of course, has the honor on both counts.

Re: Ada / Boeing 777

[Ken Garlington]

Tim Rowe wrote:
> 
> AIUI the Airbus range has triplicated *diverse* systems for critical
> functions. The 777 has triplicated *identical* systems (I'm trusting the
> press for this, so it may not be gospel).

If I recall the TRI-Ada stuff on this, it's the same source code, compiled
with three different compilers for three different targets. So, it
depends on what you mean by "diversity."

As Levison and Knight's work indicates (and my experience bears out),
code diversity don't mean much, though.

Re: Ada / Boeing 777

[Bob Kurtz]

In article <314D2D86.41A8@lfwc.lockheed.com>, Ken Garlington
<garlingtonke@lfwc.lockheed.com> wrote:

> Tim Rowe wrote:
> > 
> > AIUI the Airbus range has triplicated *diverse* systems for critical
> > functions. The 777 has triplicated *identical* systems (I'm trusting the
> > press for this, so it may not be gospel).
> 
> If I recall the TRI-Ada stuff on this, it's the same source code, compiled
> with three different compilers for three different targets. So, it
> depends on what you mean by "diversity."
> 
> As Levison and Knight's work indicates (and my experience bears out),
> code diversity don't mean much, though.

So true.  Difficult software tends to be difficult for everybody.  And
with most (or at least many) major software faults originating in
requirements interpretation, who is to say that different software sets
weren't *all* built wrong based on an incorrect interpretation of
(probably vague) requirements?  Or worse yet, you could have as many sets
of perfect software as you like, all written to be compliant with faulty
requirements.

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

Ada95 (JobSearching)

[Kenneth Mays]

Hi,

I looked everywhere for jobs for Ada95 programmers. I posted some 
here, but would like to update the list.
If you have any new info on jobs, books or Ada95 software, please send it to:

maysk@wg53.eglin.af.mil

I'll compile the list each month for the BBS.

Ken

P.S. -> If you think Visual BASIC is tough, try relying
on C++!

Re: Ada / Boeing 777

["Tim Rowe"]

Bob Kurtz (kurtz@mustang.nrl.navy.mil) wrote:

> (probably vague) requirements?  Or worse yet, you could have as many 
> sets
> of perfect software as you like, all written to be compliant with faulty
> requirements.

Certainly my experience is that most serious system faults I have dealt 
with have originated with the requirements. I don't think that means we 
can neglect all the stuff that's being done at the moment over software 
safety, but I think it gives a hint as to what needs looking at now.

digiTig
(Tim Rowe)