Safety integrity level determination

How it works

This tool turns a hazard description into the integrity level that sets how much rigour a safety function needs: an ASIL for road vehicles, a SIL from a risk graph you can edit, a development assurance level for airborne software and hardware, or a safety class for medical device software. It can rate one hazard or a whole list and count the results by level.

1. ASIL from severity, exposure and controllability. Each hazardous event is rated for how bad the harm is (severity S0 to S3), how often the situation occurs (exposure E0 to E4) and how well a driver can avoid the harm (controllability C0 to C3). If any one of the three is 0, the event carries no ASIL and is QM. Otherwise the three numbers are added: a total of 10 is ASIL D, 9 is C, 8 is B, 7 is A and anything lower is QM. This is the published pattern of the determination table in ISO 26262-3 clause 6, written as a rule.if S = 0 or E = 0 or C = 0 then QM; otherwise S + E + C: 10 gives D, 9 gives C, 8 gives B, 7 gives A, below 7 gives QM
2. SIL from a risk graph. A risk graph walks four parameters to an outcome: the consequence of the hazard, the frequency or time of exposure, the possibility of avoiding the harm, and the demand rate on the safety function. The tool reads the outcome from a grid with one cell for every combination. The grid on the page is a Hub example for trying the tool; calibrate your own to your tolerable risk. You can edit the labels of every level and every cell. A sound graph never gives a lower outcome for a worse case, and the tool warns where yours does.outcome = grid[consequence, exposure, avoidance, demand]; Hub example: score = consequence + exposure + avoidance + demand (levels counted from 0), then 0 to 1 none, 2 to 3 SIL 1, 4 SIL 2, 5 SIL 3, 6 SIL 4, 7 not enough
3. Development assurance level from the failure condition. In civil aerospace the system safety assessment classifies the worst effect a function can have as catastrophic, hazardous, major, minor or no safety effect. The development assurance level follows from that classification: A, B, C, D or E. DO-178C uses the level for software and ARP4754B for aircraft and system development. A function takes the level of the worst failure condition it can contribute to. The level can be lowered only by a documented independent architecture, which this tool does not model.catastrophic gives A; hazardous gives B; major gives C; minor gives D; no safety effect gives E
4. Medical software safety class. IEC 62304 asks what harm the software could contribute to. If it cannot contribute to a hazardous situation, or the risk is acceptable once measures outside the software are counted, it is Class A. Otherwise the class follows the worst possible injury: no injury is A, non-serious injury is B, serious injury or death is C. The probability of the software failing is taken as 100%, so only severity and outside controls matter.A if no contribution, or risk acceptable after external controls, or no injury; B for non-serious injury; C for serious injury or death
5. Rate a list. In list mode each hazard is rated with the same rule. The function, item or software takes the highest level in the list, and the counts per level show where the effort will fall.item level = highest level over all hazards

Sources

The methods and default figures rest on these public sources. The wording here is our own; read the source for its full text.

• ISO 26262-3:2018, Road vehicles, Functional safety, Part 3: Concept phase (clause 6, hazard analysis and risk assessment), International Organization for Standardization, 2018. The ASIL determination, written here as a rule in our own words. No text or tables are copied.
• Understanding ISO 26262 ASILs (opens in a new tab), Electronic Design (Chris Hobbs and Patrick Lee), 9 July 2013. Public overview of how severity, exposure and controllability combine into an ASIL, with a worked example (S3, E3, C2 gives ASIL B).
• IEC 61508-5:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems, Part 5: Examples of methods for the determination of safety integrity levels, International Electrotechnical Commission, 2010. The risk graph idea and its parameters. The grid in this tool is the Hub's own example, not the grid of the standard.
• IEC 61508-1:2010, Part 1: General requirements (tables of target failure measures for a safety function), International Electrotechnical Commission, 2010. The low demand and high demand target failure measures shown for each SIL, restated in our own layout.
• DO-178C, Software Considerations in Airborne Systems and Equipment Certification, RTCA, 13 December 2011. Software levels A to E, set by the failure condition the software can contribute to.
• ARP4754B, Guidelines for Development of Civil Aircraft and Systems (opens in a new tab), SAE International, 20 December 2023. Development assurance for aircraft and systems, and the failure condition classification that feeds the levels.
• AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12() and RTCA DO-178() (opens in a new tab), U.S. Federal Aviation Administration, 21 July 2017. Recognises DO-178C as an acceptable means of compliance for airborne software.
• IEC 62304:2006+AMD1:2015, Medical device software, Software life cycle processes (clause 4.3, software safety classification), International Electrotechnical Commission, June 2015. The three software safety classes and the rule that classes follow the possible injury, written here in our own words.