Re: EN 50129 (was Re: [sc] Are there any SIL 4 applications?)



Re: EN 50129 (was Re: [sc] Are there any SIL 4 applications?)

From: Martyn Thomas <martyn_at_xxxxxx>
Date: Mon, 30 Nov 2009 18:15:09 +0000
Message-ID: <4B140BAD.3080500@xxxxxx>


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