Re: European train deaths

[peb@amleth.demon.co.uk ("Paul E. Bennett")]

In article <9cbs3b$obf$1@nh.pace.co.uk>
           marin.condic.auntie.spam@pacemicro.com "Marin David Condic" writes:

> The problem is that there is so much more that goes into a major system
> failure than just the software. Possibly you can only conclude in some cases
> that the software may have been the initiating cause of a failure, but its
> almost never possible to establish that the software may have been the
> critical in the prevention of a failure. If there are more/less accidents on
> EU trains, can Ada take blame/credit for it? That's really difficult to
> establish.
> 
> A more productive (yet still arguable) effort is to try to establish that
> Ada (and methods) reduce errors in delivered systems. This you stand a
> chance of demonstrating in a quantifiable way. From there you have a case
> that Ada contributes to safer systems. Looking at train wrecks and noting
> that Ada was involved really doesn't tell you much.

No matter how much crowing anyone is inclined to do about their 
software development language or methods it won't make the system any
better. Systems involve a mixture of physics, mechanics, hardware and
software coming together in unison to achieve a specific functional
goal within a defined range of environments and non-functional 
circumstances.

I am sure that, with the appropriate level of care and attention to 
detail at all levels, it is perfectly possible to produce a superbly
safe system. It will take a long time, will require enormous amounts
of witnessed testing and cost an absolute bundle of money.

The real trick is knowing how to implement seemingly complex systems 
in simple enough ways that we can remain certain of the outcomes, 
even when taking account of the personal aborations of the human 
operator (like the IQ-zero's that are all the other car drivers on
the road with the exception of yourself - please note that I choose 
not to drive anymore so I am not one of them).

The system developer needs a wide range of tools and techniques at
his disposal. Tools that he knows he can trust and that are easy
for him to use them regularly. Having looked at the formal methods 
through a series of introductory seminars and from the viewpoint of
using formal methods based tools (I-logix et al) I am certain that
some very complex views of multiple process-threads running on high
end processors can be modelled quite cleverly but it is very hard 
to see and be confident in the proof.

For myself, I find that limiting complexity, using many more 
processors in a structure that follows the process hierarchy well
and that can be tested thoroughly, is the best way of proceeding.
The testing is then layered. Once you prove out fully the behaviour 
of a module under normal and adverse conditions, proving full logic
path coverage in the process, you are very well placed to use it
as a component for the next level to build on.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-814586 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************