apportionment of safety integrity - tu...

Apportionment of Safety Integrity

oder Elementare Rechenoperationen im Zahlenraum bis 4

Dr. Hendrik SchäbeTÜV Rheinland InterTraffic GmbH

D 51101 KölnT +49 221 806 2466F +49 221 806 3940

E [email protected]

Safety in Transportation 17./17.11.2015

Contents

1. Introduction

2. Safety Integrity Levels

3. Combining Safety Integrity Levels

4. Examples

5. Conclusions

18.11.20152

Introduction

� Technical systems become more and more complex,

� The concept of Safety Integrity Levels (SILs) has been developed within different systems of standards (IEC 61508, EN 50129 / EN 50128 and DEF-STAN 00-56),

� How can components or sub-systems of a lower SIL be combined to give a system with a higher SIL.

� Note: combining sub-systems in series gives a system with a SIL thathas the minimum of the SILs of the sub-systems.

18.11.20153

Safety Integrity Levels

� Introduced in several standards (IEC 61508, DEF-STAN-0056, EN 50126, EN 50128, EN 50129)

� Four safety integrity levels are defined.

� A safety integrity level (SIL) is a discrete level for defining requirements for safety integrity.

� The SIL consists of two main aspects:

� a) A target failure rate which is a maximal rate of dangerous failures of the systems that must not be exceeded.

b) A set of measures that is dedicated to cope with systematic failures.

� For software, only systematic failures are considered and no target failure rate is given

18.11.20154


18.11.20155

SIL IEC 61508 / EN 50129 DEF-STAN-00-56

4 10-9 /h ≤ λ <10-8 /h Remote (λ ≈ 10-8/h)

3 10-8 /h ≤ λ <10-7 /h Occasional (λ ≈ 10-6/h)

2 10-7 /h ≤ λ <10-6 /h Probable (λ ≈ 10-4/h)

1 10-6 /h ≤ λ <10-5 /h Frequent (λ ≈ 10-2/h)


� The standards EN 50126 and EN 50128 do not give target failurerates. EN 50126 requires only the existence of Safety Integrity Levels.EN 50128 is dedicated to software and software SILs without numericrates.

� DEF-STAN-00-56 gives the target rates implicitly by stating verbalequivalents and presenting numbers for those in another place.

� It has to be noted that the Safety Integrity Levels as defined in IEC61508 and EN50129 on the one hand side do not coincide with theSafety Integrity Levels as defined in DEF-STAN 00-56 on the otherhand side.

18.11.20156

Combining Safety Integrity Levels

� How should safety relevant sub-systems be combined to give a safetyrelevant system with a specified SIL?

� Example: Can a SIL4 system constructed from two SIL2 systemsconnected in parallel, since

2x2 =4?

� “SIL apportionment”

18.11.20157

18.11.2015 Corporate Presentation8

Place of THR / SIL definition in the process(EN 50129)


Where to apportion

Apportionment on a functional level?

Apportionment on a hardware / unit level?

Common cause failure

Function B failure

Function A failure

Hazard

Faults leading to Function A failure

Faults leading to Function B failure

CCF

Beware of common cause failures!


Apportionment is realised via AND-Gates (larger THRs)

For each AND gate, a common cause failure analysis needs to be carried out, and

consequently when decombining a SIL (e.g. SIL 4 into 2 x SIL 3)

Commmon cause failure analysis according to IEC 61508 (Beta factor), EN 50129,

ARP 4761 appendix K

Common Cause Failures can only be identified if the hardware structure (physical

implementation) is known.

Note: In the safety case, a fault tree (or comparable analysis) must be provided with a

common cause failure analysis to prove that the goal is reached.


18.11.201511

� DEF-STAN 00-56, clause 7.4.4, table 8

SIL combination rules (DEF-STAN 00-56) – don’t mix withthe SILs for EN 50159

SIL3 || SIL3 → SIL4SIL2 || SIL2 → SIL3SIL1 || SIL1 → SIL2SILx || SILy → SILmax (x,y)


� Yellow Book: applied to SILs as defined in IEC 61508 / EN 50129,but not to those in DEF-STAN 00-56. SILs differ at least regardingtheir target failure rates.

18.11.201512

Combining Safety Integrity Levels: IEC 61508

� Selecting the channel with the highest safety integrity level that has been achieved for the safety function under consideration and then adding N safety integrity levels to determine the maximum safety integrity level for the overall combination of the subsystem.

� N is the hardware fault tolerance of the combination of parallel elements

� Hardware failure tolerance: number of dangerous failures that are tolerated

� Note: N=1 in the worst case

� Details: IEC 61508-2, clause 7.4.4.2.4

18.11.201513


� Cook: alternate approach based on combination of target rates forIEC 61508, purely on numeric aspects.

� Cook does not take into account measures against systematic failures

18.11.201514

Combining Safety Integrity Levels: SIRF 400 (German y)

� OR gates: each branch gests the same SIL.

� Allowed AND-combinations according to a simple rule

� Rule of thumb, green is allowed combination, red is forbidden, yellowrequires additional analyses

� Acceptance outside Germany is not guranteed

18.11.201515

Combining Safety Integrity Levels: SIRF 400

� Conditions for application:

� (a) A SIL >0 must not be constructed from SIL 0 elements

� (b) The SIL may be released only by one SIL within an AND gate

� (c) Exclusion from (b): one branch completely takes over the safetyfunction

� (d) Exclusion from (b): a common cause failure analysis is carried out

� (e) In case of d, a suitable systematic method (FMEA, HAZOP, etc.) has to be used down to the lowest level of the hazard tree to showthat common cause / mode failures are excluded

18.11.201516

Combining Safety Integrity Levels SIRF 400 (Germany )

� SAS = Sicherheitsanforderungsstufe (equivalent to SIL, but not quitethe same)

� Allowed AND-combinations

� Two elements

� SIL 1

� SIL 2

18.11.201517


� SIL 3

� SIL 4

18.11.201518


� AND combinations of 3 elements

� SIL 1

� SIL 2

18.11.201519


� SIL 3

18.11.201520


� SIL 4

� Leaving out some combinationsstarting with 4, however thematrix is symmetric

18.11.201521


� Observation:

� In the ModSafe model an additional barrier (e.g. SIL 1 system) is ableto reduce the required SIL by 1.

18.11.201522

Combining Safety Integrity Levels – numerical approa ch

� Assumptions for comparison

1) A combinator is not necessary.

2) The inspection interval is t.

3) The system is constructed of two sub-systems that areconnected in parallel and have the same SIL.

4) The system is intended to have a SIL which is one incrementhigher than those of the sub-systems.

λ = λ1 ⋅λ2 ⋅tλ1 – Rate of first System

λ2 – rate of second system

t – inspection interval

18.11.201523

Combining SILs: SILs for an inspection interval of 10000 hours

18.11.201524

System

SIL Target rate

Computed rate

4 10-8/h 10-10/h

3 10-7/h 10-8/h

2 10-6/h 10-6/h

Sub-system

SIL Target rate

3 10-7/h

2 10-6/h

1 10-5/h

Combining SILs: SILs and required maintenance time

18.11.201525

System

Target rate(IEC 61508)

Necessary inspection interval (IEC 61508

10-8/h 1000000

10-7/h 100000

10-6/h 10000

Sub-system

SIL Target rate (IEC 61508)

3 10-7/h

2 10-6/h

1 10-5/h

Combining SILs and common Cause failures


Combine in parallel 2 systems with a SIL n

Perform a common cause analysis according to IEC 61508-6

The worst case beta factor would 10%.

For the THR of the combined system, the common cause failures are

dominating:

10% of 10-(n+4)/h

This gives SIL n+1.

Combining SILs

� Besides the target rates, design requirements have to be consideredwhen sub-systems of a lower SIL are combined with the intention toconstruct a system with a higher SIL.

� DEF-STAN 00-56 requires in clauses 7.3.3 that “Design rules andtechniques appropriate to each safety integrity level.. shall bedetermined prior to implementation...”. No particular rules are given.

� IEC 61508 (part 2, annex A3, annex B) and ENV 50129 (Annex E)give different design methods for different SILs. The most extensiveset of methods are required for SIL4.

� The set of methods cannot be transferred easily and for all possiblesystems into a simple rule for combination of sub-systems of a lowerSIL to form a system with a higher SIL.

18.11.201527

Example 1

� Two sub-systems

� No software

� No comparator

� If difference is noticed by one sub-system, it switches the other off.

18.11.201528

Sub-system 2

Sub-system 1

Example 1

� If both sub-systems are in SIL3 and they are independent, they could be combined to a SIL 4 system. Design rules are not very different for SIL3 and SIL4.

� If the system is required to have SIL2, it could be combined from two SIL1 sub-systems.

� If both sub-systems have a SIL2 and the system is required to have SIL3, deeper investigation regarding the system is needed. Design rules required for SIL3 (system) differ from those for SIL2.

18.11.201529

Example 2

� As example 1

� Sub-systems are operated by software

� The same software is used in both sub-systems

18.11.201530

Sub-system 1

Sub-system 2

Software

Example 2

� If the system shall have SIL4, the software shall also have SIL4. (The software SIL must be at least as good as the system SIL).

� A SIL2 system can be constructed from two parallel SIL1 systems with a SIL2 software.

� If the system is required to have SIL3, the software must also have SIL3. If the hardware is SIL2, additional considerations have to be made as for the system in example 1.

18.11.201531

Example 3

� System with diverse software

18.11.201532

Sub-system 1(Hardware)

Sub-system 2(Hardware)

Software 1

Software 2

Example 3

� A different software in both sub-systems.

� The same considerations as in example 1 apply regarding the SIL apportionment.

� SIL4 system can be constructed from two SIL3 sub-systems, each equipped with a SIL3 software.

� A SIL2 system can be constructed from two SIL1 sub-systems.

� For constructing a SIL3 system from two SIL2 sub-systems, additional considerations must take place.

18.11.201533

Example 4

� System with one hardware channel but redundant software.

� The software “redundancy” can come from two different software packages or from redundant programming techniques (diverse software).

18.11.201534

Hardware

Software 1

Software 2

Example 4

� If the system is required to have a SIL4, the hardware must have aSIL4 and both software versions must be at least according to SIL3.In addition, it must be proven, that each failure of the hardware isdetected by the software and that there are means to bring thesystem into a safe state.

� If the system shall have SIL2, the hardware has to have SIL2 and twoindependent software versions with a SIL1 each.

� For a SIL3 system, however, a detailed study is necessary if thehardware is SIL3 and the software versions are SIL2.

� The question of independence of two software versions running in the same hardware is not trivial

18.11.201535

Example 5

� Electronic system with software and a hardware system acting in parallel

18.11.201536

Hardware 1 Software 1

Hardware bypass

Example 5

� If the “hardware bypass” has the same SIL as required for the system, hardware 1 and software 1 do not need to have any SIL.

� Also, the same logic as in example 1 can be applied: SIL 4 system can be constructed from SIL3 sub-systems (Hardware 1 and software 1 on the one side and hardware bypass on the other side).

� The “software 1” must have the same SIL as the “hardware 1”, or better.

18.11.201537

Conclusions

� A general rule for SIL apportionment as given in DEF-STAN 00-56, Yellow book or SIRF cannot be provided for all countries.

� Target failure rates and /or inspection intervals have to be taken into account.

� General rules can only be given for sub-systems connected in parallel and for some SIL combinations (see e.g. Yellow Book, SIRF). Think about common cause failures

� Other system architectures have to be studied in detail.

� A good indication whether the chosen architecture would meet a SIL requirement is when the target failure rate of the system SIL is not exceeded by the rate of the system, computed from the rates of its sub-systems.

18.11.201538

apportionment of safety integrity - tu...

Documents