Deriving a Safety Integrity Level from Risk Parameters

A safety function has a target, and the target is a number. Before any code exists, someone has to decide whether the function that drops a lift brake on an open door may fail once in a hundred years or once in a hundred thousand, and that decision propagates into the architecture, the diagnostics, the test effort, and the evidence a certifier will demand. The number is called a safety integrity level, and it is derived from risk parameters rather than selected. Treating it as a quality grade, something a serious product simply has more of, is the most common way the derivation goes wrong.

Two failure-rate scales, split by demand mode

The first thing that fixes the metric is how often the safety function is expected to act. A function that is only invoked on demand, such as a pressure relief interlock or a fire damper release, is analysed in low demand mode, and its target is an average probability of failure on demand, abbreviated PFD. The word average matters: the probability is not constant, because a dormant function is only proven by periodic proof tests, so the value drifts upward between tests and drops back when a test detects and repairs a failure. The standard tabulates PFD ranges per level, from 10^-2 to 10^-1 for the lowest level and from 10^-5 to 10^-4 for the highest. Each level spans one decade, which is a deliberate coarse granularity: the underlying failure-rate estimates are rarely better than a factor of two, so a finer scale would imply precision that does not exist.

A function that runs continuously, or is demanded more than about once a year, is analysed in high demand or continuous mode. Its target is a probability of failure per hour, PFH, with the highest level sitting in the 10^-9 to 10^-8 per hour band and each lower level moving one decade up. The two metrics are not interchangeable, and a claim written in one mode cannot be checked against a target written in the other. A continuously operating drive monitor claiming 10^-9 per hour is claiming roughly 10^-5 per year of operation, which is a far stronger statement than the same number read as a PFD.

The demand mode is not a matter of taste. It follows from how the equipment is used, and misclassifying it changes the arithmetic by orders of magnitude, because in low demand mode most of the risk comes from the gap between proof tests while in continuous mode it comes from the failure rate itself.

Level	PFD (low demand)	PFH (high demand)
4	10^-5 to 10^-4	10^-9 to 10^-8
3	10^-4 to 10^-3	10^-8 to 10^-7
2	10^-3 to 10^-2	10^-7 to 10^-6
1	10^-2 to 10^-1	10^-6 to 10^-5

The risk graph: consequence, exposure, avoidance, demand rate

IEC 61508 does not dictate one method for arriving at the level, but it does publish a reference approach built on a small set of judged parameters. The consequence parameter classifies the severity of the harm if the function fails, from a slight injury through serious permanent injury of one person to death of several people. The frequency and exposure parameter describes how often and how long the hazardous zone is occupied. The avoidance parameter asks whether there is any possibility of avoiding the hazard, which depends on the speed of the event and on whether an operator is present and able to react. The demand rate parameter separates infrequent from frequent or continuous demands, which is what selects the metric described above.

The parameters are combined through a fixed decision graph that terminates in a level or in the conclusion that no safety function is required at all. Two properties of the method matter more than the specific branches. First, every parameter is a documented judgement with defined categories, so the derivation can be reviewed and challenged rather than reconstructed from memory. Second, the graph is monotone in the obvious direction: worse consequence, higher occupancy, less avoidability, and more frequent demand can only raise the required level, never lower it. That monotonicity is what makes a room full of engineers able to agree on a number without re-deriving the whole risk model.

The judgement is where the uncertainty lives, and honest derivations record the range of plausible parameter choices. A hazard that sits at a category boundary is exactly where a project should ask what evidence would move it, because moving one parameter one step can shift the target by a full level and change the architecture.

Automotive severity, exposure, and controllability

ISO 26262 takes the same idea and gives it three parameters with a different vocabulary. Severity runs from S0, no injuries, to S3, life-threatening injuries. Exposure runs from E0, incredibly unlikely, to E4, high probability of the operating situation occurring. Controllability runs from C0, controllable in general, to C3, difficult to control or uncontrollable. The three indices index a table whose cells hold either a quality-management result, meaning no integrity requirement beyond ordinary engineering, or one of ASIL A through ASIL D, with D the most demanding.

Two structural differences from the process-industry scheme are worth naming. The automotive parameters are evaluated at the vehicle level for a specific hazardous event, not for a whole plant, so the same component can carry different levels for different events. And controllability is a property of the driver and the situation rather than of the system: the question is whether a person can still avoid the harm after the malfunction occurs, which is why a failure at low speed in a car park and the same failure on a motorway can land in different cells.

The table is not a lookup that can be delegated to a spreadsheet without thought. Exposure in particular is often misread as a property of the equipment when it is a property of the operational scenario, and the standard’s own guidance treats the parameter as the fraction of operating time spent in the conditions that make the hazard possible.

Allocating the target across a chain of items

The level belongs to the safety function, not to a box on the network diagram. A function that reads a sensor, computes a limit, and drives an actuator is realised by several items, and the target has to be distributed among them with an argument for why the distribution meets the whole. Allocation is not division: the failure contributions combine by the architecture, not by arithmetic on the level numbers, and the resulting budget for each item is expressed in the metric of the mode, so a PFD contribution per subsystem in low demand mode or a PFH contribution per hour in continuous mode.

ISO 26262 adds a formal mechanism for one specific case. An ASIL D requirement can be decomposed across two sufficiently independent elements, written as ASIL C(D) on one and ASIL A(D) on the other, or as ASIL B(D) on both. The parenthesised letter records the original level and is not decoration: it is the reminder that the pair together carries the D requirement, that the independence claim must be argued and documented, and that if independence collapses the decomposition is void. The allowed splits are enumerated, so ASIL D cannot be decomposed into two ASIL A elements no matter how independent they are, and the same notation appears in the safety plan as a constraint on shared resources such as a common clock, supply, or communication channel.

IEC 61508 has no equivalent shorthand, and the absence is instructive. Instead of splitting a level, the project splits a failure-rate budget and must separately demonstrate systematic capability for each element, which prevents the mistake of assuming that two mediocre elements add up to one good one.

What the number constrains, and what it leaves alone

A level constrains random hardware failures through architecture and diagnostics: the hardware fault tolerance, the safe failure fraction, the diagnostic coverage of each safety mechanism, and the proof-test interval that determines how long undetected failures accumulate. Those quantities feed the calculation covered in Voting Redundancy and Average Probability of Failure on Demand, and the diagnostics that supply the coverage figures are themselves mechanisms with detection latencies, as described in Runtime Self-Tests and Diagnostic Coverage Measurement.

A level does not constrain systematic failures by rate, because software has no failure rate in the sense the PFD arithmetic assumes. What the level constrains there is process: the rigour of the requirements, the independence of review, the completeness of the test evidence, and the qualification of the tools. That is why a software claim at the highest level is argued through objectives and traceability, the subject of DO-178C Objectives and Structural Coverage, rather than through a calculated number.

The practical consequence is that the level is an input to architecture, fixed early and expensive to move. Assign it too low and the eventual claim cannot be supported without redesign; assign it too high and the project pays for redundancy, review independence, and tool qualification that the hazard never justified. Both errors are failures of the derivation, not of the implementation, and neither is visible in a test report.