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.9 required=5.0 tests=BAYES_00,FROM_NUMERIC_TLD autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,193117a6843a81b2 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!news.astraweb.com!newsrouter-eu.astraweb.com!newsfeed10.multikabel.net!multikabel.net!newsfeeder20.multikabel.net!zen.net.uk!dedekind.zen.co.uk!news-peer-lilac.gradwell.net!not-for-mail From: "Stuart" Newsgroups: comp.lang.ada References: <9f80aed6-6509-4faf-931b-e05dc2b314d9@59g2000hsb.googlegroups.com> Subject: Re: iFACTS (was: SPARK User Group 2008) Date: Wed, 28 May 2008 10:51:02 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Message-ID: <483d26f5$1_1@glkas0286.greenlnk.net> X-Original-NNTP-Posting-Host: glkas0286.greenlnk.net NNTP-Posting-Host: 20.133.0.1 X-Trace: 1211968271 news.gradwell.net 667 dnews/20.133.0.1:21017 X-Complaints-To: news-abuse@gradwell.net Xref: g2news1.google.com comp.lang.ada:417 Date: 2008-05-28T10:51:02+01:00 List-Id: "Michael" wrote in message news:ZCY_j.169009$rd2.39062@pd7urf3no... > Did you also notice your finding was posted: Wed, 07 Mar 2007 14:53:47 > GMT, > That's a few minutes after NATS proudly announced the iFACTS final trials. > > In other words you just confirm the problem: iFACTS has vanished after the > NATS's final trial and no one can say what the problems were. > (Since UK air traffic is still growing, delay is the safety problem) Nor could one reasonably conclude there is a problem with iFACTS. Deploying a new system into service is not a trivial undertaking! > Such problem seems to emanate from a UK military standard (00-55) > Requirements for safety related software in defence equipment - 1st August > 1997. > "The testing shall exercise all properties and functions which have not > been demonstrated by formal verification." > http://www.dstan.mod.uk/data/00/055/01000200.pdf Presumably you are citing 37.1.1 a) Might I suggest that you go on to read 37.1.1 b) > Since CbC is just about formal methods, as per standard 00-55, iFACT > reliability was merely demonstrated by formal verification. Aside from your selective quoting of 00-55, this also appears to be a poor presentation of the facts. The first thing that is not clear is whether you mean 'formal method' in the sense 00-55/56 means them - or just some methods with a degree of prescription about them. >From what I understand CbC, as it might have been used on iFACTS, does use formalism in the 00-55/56 sense - but to say it is just about that is a gross distortion, given the criticisms being made. The conclusion about how iFACT was demonstrated is a non-sequitur. The use of CbC in the creation of iFACT tells us nothing about what other processes may have been used to underpin the system certification - or reliability! > No testing means no visibility on problems, not even a doubt it might have > any problem. This is an untrue statement! Problems can, and are, revealed by processes other than testing. > e.g.: "Crew had also turned off alarms that would have alerted them to > danger." This example does not seem to illustrate the point you appeared to be trying to make. Operational misuse of equipment is highly unlikely to be revealed by testing! > In facts, the iFACTS fiasco was predictable before the iFACTS project even > begins. As Simon Wright asks - please provide details of your claims. > With some unit and non-regression testing, iFACTS divergences would have > been early detected. This is bordering on the libellous. I believe those involved in the development of iFACTS are highly professional and would use the appropriate level of testing. They would be fully aware of the need to validate (not simply verify). > i.e.: iFACTS would have had a chance to be commissioned, and another > safety risk could have been addressed. Nothing you have presented to date even supports a claim that iFACTS is not due to be commissioned let alone any reasons why! > http://seattletimes.nwsource.com/html/travel/2004128412_webaircanada16.html > e.g.: January the 10th, 2008, over BC, "Wake from passing plane may have > caused Air Canada jet's plunge: 10 passengers injured." > i.e.: Medium Term Conflict Detection strongly needed, but not iFACTS. Whether iFACTS is suited to the Canadian Air Traffic situation or not may be a reasonable point of discussion - but hardly impinges upon whther iFACTS meets its requirements for the UK Air Traffic situation.! > NOTES: > Next Ada Europe, Venice, Italy, 16 - 20, June 2008 - CbC is gone > (embroglio or fiasco?) > http://www.math.unipd.it/ae2008/ So because a conference does not discuss a particular topic which has previously been discussed you conclude that the subject matter is discredited!!! 0/10 - must do better! Show working! -- Stuart