[SystemSafety] HFT and systematic capability in IEC 61508 and IEC 61511

Date: Tue, 10 Sep 2013 12:55:18 +0200

Dear all,

I want to submit here an issue on clause of IEC61511 that states:

"For a device that has been assessed as having SC N based on compliance with requirements within IEC 61508, where a systematic fault of that device does not cause a failure of the specified SIF but does so only in combination with a second systematic fault of another device that has been assessed as having SC N, then the combination of the two devices can be treated as having SC (N + 1) ...."

If I understand well the clause, from a propositional logic point of view, it can be rephrased:

IF [A(SCn) and B(SCn) and HFT(A,B)=1] then AB(SCn+1)

This clearly interlocks the systematic capability property of devices, as well as of sub-assemblies (not to say subsystems) with the property of HFT (of sub-assemblies obviously) and rises IMHO some questions about the consequences of such an interlocking.

The first one is raised by the fact that HFT is related to the function of an assembly of devices, and thus is not a fixed definition (same issue as unstable sub-system definition). What happens in a 2oo3 arrangement for instance ?

The second one is related to the HFT itself. Does the used in the above equation is the same that the HFT of clause 11.4.5. In other words you build and architecture for SCn+1, but you have only A(SCn) and HFT=0 so you add B(SCn) so that you can claim AB(SCn+1) as requested. But does the fact of having two SCn equipment (satisfying thus SCn+1 requirement), satisfies also the HFT requirement of clause 11.4.5 (1 for example).

If yes, it means that we have this table:

SIL                                          1                             2(low demand)                2                             3                             4

HFT                                        0                             0                                             1                             1                             2

Usual design                      SC1                        SC2                                        SC2+SC2              SC3+SC3              SC4+SC4+SC4

Clause                 SC1                        SC1+SC1                              SC1+SC1              SC2+SC2              SC3+SC3+SC3

The consequence of clause of is to make strictly equivalent a "subsystem" made of SCn devices and a subsystem made of SCn+1 devices. This undermines totally the combined expected efficiency of HFT AND SC as if SC was no more important.

What is then the purpose of buying "SC3" equipments for SIL 3 when you have the same result with "SC2" ?

Shouldn't the two properties be decorrelated?

Souldn't a requirement be added to compensate (for instance say that for clause require HFT +1 on the top of clause 11.4.5).

Wouldn't a mandatory diversity be a solution ?

Bertrand RICQUE
Program Manager, Optronics and Defense Division

T +33 (0)1 58 11 96 82
M +33 (0)6 87 47 84 64
23 avenue Carnot



" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."

" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Sep 10 2013 - 12:55:31 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST