Re: over-automation with glass cockpits

From:         Tom Speer <speer%do.edw@mhs.elan.af.mil>
Organization: 412th Test Wing / TSFF
Date:         04 Aug 96 16:44:56 
References:   1 2 3
Next article
View raw article
  or MIME structure

Pete Mellor wrote:
>
> C. Marin Faure <faurecm@halcyon.com> writes in response to
> John M. Hunt <johnmhunt@ipa.net>:-
>
> > A computer (so far) can't
> > anticipate every single variable that can affect an airplane.
>
> After "so far" add "and almost certainly never". The anticipation
> is done by the designers of the system, and particularly the software
> designers. The software cannot be better than its specification, and
> no specification can define behaviour appropriate to all eventualities
> in the environment of the aircraft.
>
>...

Problems with software design for automated flight systems are not
confined to the cockpit.  The recent Ariane 5 failure has highlighted
this issue in spectacular fashion, and the crash of the Dark Star
reconnaisance drone also has been attributed to software changes made
after the first flight (ref. recent Aviation Week articles). This is a
little off topic for sci.aeronautics.airliners, so I'm cross posting to
sci.aeronautics, and the thread is probably better continued there.

The Ariane 5 mishap raises lots of questions about software development
practices:
- Should one minimize the execution of code that isn't completely
relevant to the task at hand, or does it matter?
- Limits checking for some of the variables was apparently deleted in an
effort to maintain their specification on spare execution time.  Should
spare resource requirements be treated as hard specs, or management
reserve to be released as required in the final design?
- Was realistic hardware in the loop simulation performed, and if not,
should it be required of all digital flight control systems?
- Ariane apparently did not provide for automatic restart following an
arithmetic overflow.  What are reasonable scenarios that the designer
should consider with respect to accomodating the generic software fault?
- Does this experience strengthen the argument for dissimilar redundancy
or backup systems?

Finally, I see two trends converging:  systems are becoming more and more
automated, with some missions handed over to totally autonomous vehicles
(Global Hawk, Dark Star, X-33, etc.).  The second trend is the low number
of new airframe designs being done today.  In the 50's, an engineer could
expect to work on something like 20 designs in one's career, and today
the average is something like 2, with the result that a great number of
engineers are working on their first aircraft, and the "experienced"
hands have only seen one more before that.  What do these two trends say
about our ability anticipate problems and design for them in automated
systems?

TS