Nicholas Mc Guire wrote:
Is there anyone on this list who believes that this statement is
defensible, in a standard for safety related systems, and who is
prepared to defend it?
from the ideas of 61508 (and its derived standard like the EN 50126/50128/
50129 Rail standards) - software faults are always systematic faults -
systematic faults in hardware are "equally" always due to systematic failures
of the procedures (requirements/design/impelentation/etc.) - so the only thing
left is random faults. I don't see this as inconsistent. The functionality
that is implemented in software/hardware was developed according to the
methods for SIL x and thus is - by definition - suitable (qualitative argument
mapped onto quantiative requirements) - and thus there is no need to concider
systematic faults for the final setup. Mitigation of random faults is still
needed as these can principally not be eliminated by requirements/design/etc.
(they can at best be mitigated). As the systematic faults (HW/SW) are due to
systematic failures at the procedural level (that is atleast how I would read
61508 and derivatives like EN 50128/50129) they can't be mapped to a THR which
requires independance of events (i.e. architectural protection does not
make sense against CCFs in general) - so the above statement just says if you
covered all systematic faults by following procedures the only thing left is
random faults and thos can be described by a THR - which then must be
demonstrated for the components in use.
I would like to add that I don't agree with this - but it is consitent (and
thus defendable in the context of EN50126/8/9 (aside from the inconsistencies
in these standards them self).
hofrat
Nicholas
This may be "consistent" with 61508 and with other statements in 50129,
but since it provides no assurance that the required unsafe failure
probabilities have been achieved, how can it be "defensible"?
Surely, a safety standard should set out requirements that can be shown
to achieve the stated goals (which, for 50129, are a specific
probability of unsafe failure).
How can you defend a standard that says that, merely by following a set
of recommended development processes, you may legitimately claim a very
low probability of unsafe failure?
Martyn
Received on Mon 30 Nov 2009 - 18:15:16 GMT