From: Lionel Bouton <lionel-subscription@...>
Date: 2008-04-17T03:00:06+09:00
Subject: Re: Ada vs Ruby

Phillip Gawlowski wrote:
 > [...]
> Anyway, this problem is (AFAIK, anyway), countered by using redundant
> implementations of the hardware and software (well, as far as possible,
> anyway), to minimize the effect of unknown states.
> 

This solves some problems but not all of them. If the software and 
hardware are designed based on flawed specifications you get a rocket 
explosion (Ariane V first test flight: the 3 redundant systems all 
failed one after the other because some flight patterns constraints were 
reused from Ariane IV but weren't applicable to the new rocket...).

> I don't think that I ever heard of a pilot encountering an unhandled
> exception during normal operation, for example. I guess we mean the
> same, after all.

I think it happened at least once on an Airbus where a pilot had to 
switch to manual controls or deactivate a safety measure because the 
autopilot was going to bring the plane to stall (sensors reporting 
incorrect measures). I could't find the reference for this specific 
instance, but google brought other problems :

# Unforeseen conditions leading to autopilot misbehaving :
http://aviation-safety.net/database/record.php?id=19940630-0
http://shippai.jst.go.jp/en/Detail?fn=0&id=CA1000621

# Software glitches putting aircraft in danger :
http://online.wsj.com/article/SB114895279859065931-search.html?KEYWORDS=flight+check&COLLECTION=wsjie/6month

# several incidents, look for the "Cause" lines to filter the problems
# caused by flight systems.
http://www.airsafety.com/aa587/faa_fltcont.pdf

> |
> | Never rely upon suspicions when talking with people who actually know
> | for sure. As I pointed out earlier in this thread I've written and
> | certified cockpit systems (for both civilian and paramilitary use) and
> | requirements have tended to be just as amorphous as in any other
> | industry I've subsequently worked in. The main difference has been one
> | of management realising in the former case that good systems rely on
> | good code and that this is something a small percentage of developers
> | can produce, whereas in the latter there's a belief that any two coders
> | are interchangeable so long as the process and tools are right.

In my experience this latter case is widespread in companies with no 
real inside CS knowledge believing they can manage IT projects 
themselves (with pointy-haired bosses :-)). It's hard to realize that 
you need sharp minds to produce good code when your own view of software 
building is limited to playing with Lego systems... This is a recurrent 
problem for CS people : making other people aware of the inherent 
complexities of software design.

> 
> I mean, we pretty much know the physics that make flight work, for
> example. That a different airframe needs different software to work is
> obvious (can't trim a fighter the same as a jumbo, for example).

If only you could have advised Arianespace :-)

Lionel