"Michael" <Michael@[EMAIL PROTECTED]
> wrote in message
news:ZCY_j.169009$rd2.39062@[EMAIL PROTECTED]
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 sup****ts 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
|
