Apportionment of Safety Integrity

Transcription

1 Apportionment of Safety Integrity oder Elementare Rechenoperationen im Zahlenraum bis 4 Dr. Hendrik Schäbe TÜV Rheinland InterTraffic GmbH D Köln T F E schaebe@de.tuv.com Safety in Transportation 17./

2 Contents 1. Introduction 2. Safety Integrity Levels 3. Combining Safety Integrity Levels 4. Examples 5. Conclusions 2

3 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 / EN 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 that has the minimum of the SILs of the sub-systems. 3

4 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 4

5 Safety Integrity Levels SIL IEC / EN DEF-STAN /h λ <10-8 /h Remote (λ 10-8 /h) /h λ <10-7 /h Occasional (λ 10-6 /h) /h λ <10-6 /h Probable (λ 10-4 /h) /h λ <10-5 /h Frequent (λ 10-2 /h) 5

6 Safety Integrity Levels The standards EN and EN do not give target failure rates. EN requires only the existence of Safety Integrity Levels. EN is dedicated to software and software SILs without numeric rates. DEF-STAN gives the target rates implicitly by stating verbal equivalents and presenting numbers for those in another place. It has to be noted that the Safety Integrity Levels as defined in IEC and EN50129 on the one hand side do not coincide with the Safety Integrity Levels as defined in DEF-STAN on the other hand side. 6

7 Combining Safety Integrity Levels How should safety relevant sub-systems be combined to give a safety relevant system with a specified SIL? Example: Can a SIL4 system constructed from two SIL2 systems connected in parallel, since 2x2 =4? SIL apportionment 7

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

9 Where to apportion Apportionment on a functional level? Apportionment on a hardware / unit level? Hazard Faults leading to Function A failure CCF Faults leading to Function B failure Common cause Function A failure Function B failure 9 Corporate Presentation

10 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 (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. 10 Corporate Presentation

11 Combining Safety Integrity Levels DEF-STAN 00-56, clause 7.4.4, table 8 SIL combination rules (DEF-STAN 00-56) don t mix with the SILs for EN SIL3 SIL3 SIL4 SIL2 SIL2 SIL3 SIL1 SIL1 SIL2 SILx SILy SILmax (x,y) 11

12 Combining Safety Integrity Levels Yellow Book: applied to SILs as defined in IEC / EN 50129, but not to those in DEF-STAN SILs differ at least regarding their target failure rates. 12

13 Combining Safety Integrity Levels: IEC 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 , clause

14 Combining Safety Integrity Levels Cook: alternate approach based on combination of target rates for IEC 61508, purely on numeric aspects. Cook does not take into account measures against systematic failures 14

15 Combining Safety Integrity Levels: SIRF 400 (Germany) 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, yellow requires additional analyses Acceptance outside Germany is not guranteed 15

16 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 safety function (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 show that common cause / mode failures are excluded 16

17 Combining Safety Integrity Levels SIRF 400 (Germany) SAS = Sicherheitsanforderungsstufe (equivalent to SIL, but not quite the same) Allowed AND-combinations Two elements SIL 1 SIL 2 17

18 Combining Safety Integrity Levels: SIRF 400 SIL 3 SIL 4 18

19 Combining Safety Integrity Levels: SIRF 400 AND combinations of 3 elements SIL 1 SIL 2 19

20 Combining Safety Integrity Levels: SIRF 400 SIL 3 20

21 Combining Safety Integrity Levels: SIRF 400 SIL 4 Leaving out some combinations starting with 4, however the matrix is symmetric 21

22 Combining Safety Integrity Levels Observation: In the ModSafe model an additional barrier (e.g. SIL 1 system) is able to reduce the required SIL by 1. 22

23 Combining Safety Integrity Levels numerical approach 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 are connected in parallel and have the same SIL. 4) The system is intended to have a SIL which is one increment higher than those of the sub-systems. λ = λ 1 λ 2 t λ 1 Rate of first System λ 2 rate of second system t inspection interval 23

24 Combining SILs: SILs for an inspection interval of hours System SIL Target rate Computed rate /h /h /h 10-8 /h /h 10-6 /h Sub-system SIL Target rate /h /h /h 24

25 Combining SILs: SILs and required maintenance time System Target rate (IEC 61508) Necessary inspection interval (IEC /h /h /h Sub-system SIL Target rate (IEC 61508) /h /h /h 25

26 Combining SILs and common Cause failures Combine in parallel 2 systems with a SIL n Perform a common cause analysis according to IEC 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 Corporate Presentation

27 Combining SILs Besides the target rates, design requirements have to be considered when sub-systems of a lower SIL are combined with the intention to construct a system with a higher SIL. DEF-STAN requires in clauses that Design rules and techniques appropriate to each safety integrity level.. shall be determined prior to implementation.... No particular rules are given. IEC (part 2, annex A3, annex B) and ENV (Annex E) give different design methods for different SILs. The most extensive set of methods are required for SIL4. The set of methods cannot be transferred easily and for all possible systems into a simple rule for combination of sub-systems of a lower SIL to form a system with a higher SIL. 27

28 Example 1 Two sub-systems No software No comparator If difference is noticed by one sub-system, it switches the other off. Sub-system 1 Sub-system 2 28

29 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. 29

30 Example 2 As example 1 Sub-systems are operated by software The same software is used in both sub-systems Sub-system 1 Software Sub-system 2 30

31 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. 31

32 Example 3 System with diverse software Sub-system 1 (Hardware) Software 1 Sub-system 2 (Hardware) Software 2 32

33 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. 33

34 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). Software 1 Hardware Software 2 34

35 Example 4 If the system is required to have a SIL4, the hardware must have a SIL4 and both software versions must be at least according to SIL3. In addition, it must be proven, that each failure of the hardware is detected by the software and that there are means to bring the system into a safe state. If the system shall have SIL2, the hardware has to have SIL2 and two independent software versions with a SIL1 each. For a SIL3 system, however, a detailed study is necessary if the hardware is SIL3 and the software versions are SIL2. The question of independence of two software versions running in the same hardware is not trivial 35

36 Example 5 Electronic system with software and a hardware system acting in parallel Hardware 1 Software 1 Hardware bypass 36

37 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. 37

38 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. 38