From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,732030daa45ab98a X-Google-Attributes: gid103376,public X-Google-Thread: 115aec,732030daa45ab98a X-Google-Attributes: gid115aec,public X-Google-ArrivalTime: 2001-04-27 17:09:00 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: peb@amleth.demon.co.uk ("Paul E. Bennett") Newsgroups: comp.lang.ada,comp.realtime Subject: Re: European train deaths Date: Sat, 28 Apr 01 00:00:06 GMT Organization: HIDECS Consultancy Message-ID: <988416006snz@amleth.demon.co.uk> References: <9cbs3b$obf$1@nh.pace.co.uk> Reply-To: peb@amleth.demon.co.uk X-Trace: mail2news.demon.co.uk 988416506 mail2news:24022 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!amleth.demon.co.uk X-Newsreader: Demon Internet Simple News v1.30 Xref: newsfeed.google.com comp.lang.ada:7004 comp.realtime:2433 Date: 2001-04-28T00:00:06+00:00 List-Id: 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 .................... Forth based HIDECS Consultancy ..... 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.. ********************************************************************