Re: Papers on the Ariane-5 crash and Design by Contract

[Ken Garlington <GarlingtonKE@lmtas.lmco.com>]

Ulrich Windl wrote:
> 
> The modules computing course corrrection data both failed due to to
> problems mentioned (violating the specs for that code); they shut
> themselves down. But to me the main issue is that the module that
> received the course correction data did not detect that both computing
> modules failed and that the data was just a "test pattern" to indicate
> that event. Probably a better reaction would have been to stop making
> further corrections instead of driving the engine to its borders.

This is the same as saying: "If the driver of an automobile has a heart
attack and dies, the steering system should ignore further inputs and
lock the wheels in the last 'good' position." It doesn't work with
automobiles,
and it doesn't work with missiles, either. The flight control system
must
receive valid sensor data to maintain control of the aircraft. There is
generally no reasonable 'fail-safe" value for a feedback system like
this!

> If the modules to compute course correction data would have failed in
> a more paraniod way (the module had an exception due to overflow and
> shut itself down. If it would have continue with the appropriately
> signed maximum possible value, well I don't know).
> 
> Maybe one could postulate "Every part in a software system that must
> not fail that receives an unexpected exception should handle the
> situation as good as possible, even if it can't guarantee its
> specification". This sounds contrary to programming by contract, but
> sometimes this can help. Theoreticans might say "quit on the first
> error encountered" while real hackers might say "continue as long as
> you can".

Sounds good. Unfortunately, sometimes there is not an obvious way to
continue. This is the fallacy of the "add exception handlers to make
code safer" crowd - there has to be a reasonable response to the failure
available to the designer. Sometimes, there isn't one. Adding exception
handlers where there isn't a reasonable response only makes the design
more complex - which generally means a greater risk of failure!

> 
> (Excuse my non-rocket vocabulary, but this is from memory, and English
> is not my first language, too)
> 
> >
> > Successful reuse requires that what you reuse be equipped with a
> > specification - a contract. That's the point made Jean-Marc Jezequel
> > and I made in the article at
> > http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html.
> 
> Ulrich

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com