Re: iFACTS (was: SPARK User Group 2008)

["Stuart" <stuart@0.0>]

"Michael" <Michael@home.ca> wrote in message 
news:ZCY_j.169009$rd2.39062@pd7urf3no...

<replying to Simon Wright>
> 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:
<snip>
> 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