Safety Integrity Levels


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • WSN: health monitoring systems, bridge monitoring, tire pressure sensors with MEMs,
  • Safety Standards relevance in future
  • Safety Integrity applies to a function, not a system/subsystem/component! Note that the implication good process  good product is assumed to be valid Mention that there is another SIL table for demand mode Mention that many SIL standards define SILs – and they may be different!
  • Risk Matrix must be agreed with customer/regulatot/ISA
  • Safety Integrity Levels

    1. 1. Safety Critical Systems
    2. 2. Safety Critical Systems <ul><li>A safety-critical computer system is a computer system whose failure may cause injury or death to human beings or the environment </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Aircraft control system (fly-by-wire,...) </li></ul></ul><ul><ul><li>Nuclear power station control system </li></ul></ul><ul><ul><li>Control systems in cars (anti-lock brakes,...) </li></ul></ul><ul><ul><li>Health systems (heart pacemakers,...) </li></ul></ul><ul><ul><li>Railway control systems </li></ul></ul><ul><ul><li>Communication systems </li></ul></ul><ul><ul><li>Wireless Sensor Networks Applications? </li></ul></ul>
    3. 3. What is Safety? <ul><li>“ The avoidance of death, injury or poor health to customers, employees, contractors and the general public; also avoidance of damage to property and the environment” </li></ul>Safety is NOT an absolute quantity! Safety is also defined as &quot;freedom from unacceptable risk of harm&quot; A basic concept in System Safety Engineering is the avoidance of &quot; hazards &quot;
    4. 4. Safety vs. Security <ul><li>These two concepts are often mixed up </li></ul><ul><li>In German, there is just one term for both! </li></ul>
    5. 5. SILs and Dangerous Failure Probability
    6. 6. Railway Signalling Systems <ul><li>Signalling and Switching </li></ul><ul><li>Axle Counters </li></ul><ul><li>Applications for ETCS </li></ul><ul><li>An incorrect output may lead to an incorrect signal causing a major accident! </li></ul><ul><li>Safety Integrity Level 4 (highest) </li></ul>
    7. 7. (Old) Interlocking Systems Mechanical / Electromechanical Systems
    8. 8. Signal Box / Interlocking Tower <ul><li>Electric system with some electronics </li></ul>
    9. 9. Modern Signal Box / Interlocking Tower <ul><li>Lots of electronics and computer systems </li></ul>
    10. 10. What is a Hazard? <ul><li>Hazard </li></ul><ul><ul><li>physical condition of platform that threatens the safety of personnel or the platform, i.e. can lead to an accident </li></ul></ul><ul><ul><li>a condition of the platform that, unless mitigated, can develop into an accident through a sequence of normal events and actions </li></ul></ul><ul><ul><li>&quot;an accident waiting to happen&quot; </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>oil spilled on staircase </li></ul></ul><ul><ul><li>failed train detection system at an automatic railway level crossing </li></ul></ul><ul><ul><li>loss of thrust control on a jet engine </li></ul></ul><ul><ul><li>loss of communication </li></ul></ul><ul><ul><li>distorted communication </li></ul></ul><ul><ul><li>undetectably incorrect output </li></ul></ul>
    11. 11. Hazard Severity Level (Example) Category Id. Definition CATASTROPHIC I General : A hazard, which may cause death, system loss, or severe property or environmental damage. CRITICAL II General : A hazard, which may cause severe injury, major system, property or environmental damage. MARGINAL III General : A hazard, which may cause marginal injury, marginal system, property or environmental damage. NEGLIGIBLE IV General : A hazard, which does not cause injury, system, property or environmental damage.
    12. 12. Hazard Probability Level (Example) Level Probability [h -1 ] Definition Occurrences per year Frequent P ≥ 10 -3 may occur several times a month More than 10 Probable 10 -3 > P ≥ 10 -4 likely to occur once a year 1 to 10 Occasional 10 -4 > P ≥ 10 -5 likely to occur in the life of the system 10 -1 to 1 Remote 10 -5 > P ≥ 10 -6 unlikely but possible to occur in the life of the system 10 -2 to 10 -1 Improbable 10 -6 > P ≥ 10 -7 very unlikely to occur 10 -3 to 10 -2 Incredible P < 10 -7 extremely unlikely, if not inconceivable to occur Less than 10 -3
    13. 13. Risk Classification Scheme (Example) Hazard Severity Hazard Probability CATASTROPHIC CRITICAL MARGINAL NEGLIGIBLE Frequent A A A B Probable A A B C Occasional A B C C Remote B C C D Improbable C C D D Incredible C D D D
    14. 14. Risk Class Definition (Example) Risk Class Interpretation A Intolerable B Undesirable and shall only be accepted when risk reduction is impracticable. C Tolerable with the endorsement of the authority. D Tolerable with the endorsement of the normal project reviews.
    15. 15. <ul><li>Having identified the level of risk for the product we must determine how acceptable & tolerable that risk is </li></ul><ul><ul><li>Regulator / Customer </li></ul></ul><ul><ul><li>Society </li></ul></ul><ul><ul><li>Operators </li></ul></ul><ul><li>Decision criteria for risk acceptance / rejection </li></ul><ul><ul><li>Absolute vs. relative risk (compare with previous, background) </li></ul></ul><ul><ul><li>Risk-cost trade-offs </li></ul></ul><ul><ul><li>Risk-benefit of technological options </li></ul></ul>Risk Acceptability
    16. 16. Risk Tolerability Hazard Severity Probability Risk Risk Criteria Tolerable? No Risk Reduction Measures Yes
    17. 17. What are Safety Requirements <ul><li>The system requirements specification (or sub-system/equipment as appropriate) may be considered in two parts : </li></ul><ul><li>1. Requirements which are not related to safety </li></ul><ul><li>2. Requirements which are related to safety </li></ul><ul><li>Requirements which are related to safety are usually called safety requirements. These may be contained in a separate safety requirements specification. </li></ul>
    18. 19. <ul><li>Safety integrity relates to the ability of a safety-related system to achieve its required safety functions. The higher the safety integrity, the lower the likelihood that it will fail to carry out the required safety functions </li></ul><ul><li>Safety integrity comprises two parts : </li></ul><ul><li>Systematic failure integrity </li></ul><ul><li>Random failure integrity </li></ul>
    19. 20. <ul><li>Systematic failure integrity is the non-quantifiable part of the safety integrity and relates to hazardous systematic faults (hardware or software). Systematic faults are caused by human errors in the various stages of the system/sub-system/equipment life-cycle. </li></ul><ul><li>Examples of Systematic Faults are : </li></ul><ul><li>Specification errors </li></ul><ul><li>Design errors </li></ul><ul><li>Manufacturing errors </li></ul><ul><li>Installation errors </li></ul><ul><li>Operation errors </li></ul><ul><li>Maintenance errors </li></ul><ul><li>Modification errors </li></ul>
    20. 21. <ul><li>Random failure integrity is that part of the safety integrity which relates to hazardous random faults, in particular random hardware faults, which are the result of the finite reliability of hardware components. </li></ul><ul><li>Examples of Random Faults are: </li></ul><ul><li>Failure of Resistor </li></ul><ul><li>Failure of an IC Etc. </li></ul>
    21. 22. Diversity <ul><li>Goal: Fault Tolerance/Detection </li></ul><ul><li>Diversity is &quot;a means of achieving all or part of the specified requirements in more than one independent and dissimilar manner.&quot; </li></ul><ul><li>Can tolerate/detect a wide range of faults </li></ul>&quot;The most certain and effectual check upon errors which arise in the process of computation, is to cause the same computations to be made by separate and independent computers; and this check is rendered still more decisive if they make their computations by different methods .&quot; Dionysius Lardner, 1834
    22. 23. Layers of Diversity
    23. 24. Examples for Diversity <ul><li>Specification Diversity </li></ul><ul><li>Design Diversity </li></ul><ul><li>Data Diversity </li></ul><ul><li>Time Diversity </li></ul><ul><li>Hardware Diversity </li></ul><ul><li>Compiler Diversity </li></ul><ul><li>Automated Systematic Diversity </li></ul><ul><li>Testing Diversity </li></ul><ul><li>Diverse Safety Arguments </li></ul><ul><li>… </li></ul>Some faults to be targeted: programming bugs, specification faults, compiler faults, CPU faults, random hardware faults (e.g. bit flips), security attacks,...
    24. 25. Compiler Diversity <ul><li>Use of two diverse compilers to compile one common source code </li></ul>
    25. 26. Compiler Diversity: Issues <ul><li>Targeted Faults: </li></ul><ul><ul><li>Systematic compiler faults </li></ul></ul><ul><ul><li>Some systematic and permanent hardware faults (if executed on one board) </li></ul></ul><ul><li>Issues: </li></ul><ul><ul><li>To some degree possible with one compiler and different compile options (optimization on/off,…) </li></ul></ul><ul><ul><li>If compilers from different manufacturers are taken, independence must be ensured </li></ul></ul>
    26. 27. Systematic Automatic Diversity <ul><li>What can be &quot;diversified&quot;: </li></ul><ul><ul><li>memory usage </li></ul></ul><ul><ul><li>execution sequence </li></ul></ul><ul><ul><li>statement structures </li></ul></ul><ul><ul><li>array references </li></ul></ul><ul><ul><li>data coding </li></ul></ul><ul><ul><li>register usage </li></ul></ul><ul><ul><li>addressing modes </li></ul></ul><ul><ul><li>pointers </li></ul></ul><ul><ul><li>mathematical and logic rules </li></ul></ul>