How to Calculate Performance Level (PL) under ISO 13849

To calculate Performance Level under ISO 13849, you solve two separate problems. First, determine the required Performance Level (PLr) from a risk graph driven by severity, frequency of exposure, and possibility of avoidance. Then verify the achieved PL of your safety function from its category, mean time to dangerous failure (MTTFd), average diagnostic coverage (DCavg), and common cause failure (CCF). The design is acceptable when achieved PL is at least equal to PLr. Most failed safety arguments come from treating those as one step instead of two.

Here is the part that trips people up. PLr tells you how good the safety function has to be. The achieved PL tells you how good it actually is. They are calculated from completely different inputs, and the only thing connecting them is a comparison at the end.

This post walks through both tasks, the inputs each one needs, where the math caps out, and the mistakes that quietly sink a PL claim during assessment.

Task One: Determine the Required Performance Level

Before you choose a single component, you need to know what the risk demands. That target is PLr, and it comes out of the ISO 13849-1 risk graph. The graph asks three questions about the hazard the safety function is there to control.

• Severity (S): S1 is a slight, normally reversible injury. S2 is serious, normally irreversible, including death.

• Frequency and duration of exposure (F): F1 is seldom to less often, or short exposure. F2 is frequent to continuous, or long exposure.

• Possibility of avoidance (P): P1 means avoidance is possible under specific conditions. P2 means it is scarcely possible.

You trace those three parameters through the graph and land on a required level from PLr a (lowest) up to PLr e (highest). This is risk-driven, not design-driven. A hand that can be crushed in a press that runs all day with no way to pull back fast lands at the top of the graph regardless of what controller you plan to use.

The risk graph inputs map like this:

The risk graph is part of the broader risk assessment for the machine. PLr is an output of that process, not a number you pick to make the project easier. Inflate the avoidance parameter to drop from PLr e to PLr d and an assessor will ask you to defend it. If you cannot, the whole safety function is built to the wrong target.

Task Two: Verify the Achieved Performance Level

Now you flip to the design side. The achieved PL describes how reliable your safety function actually is, and it depends on four inputs working together.

Category (the architecture)

ISO 13849-1 defines five designated architectures. The category sets the structural backbone for everything else.

MTTFd (how long a channel survives)

Mean time to dangerous failure is rated per channel in three bands: low (3 to under 10 years), medium (10 to under 30 years), and high (30 to 100 years). One detail matters more than any other here: MTTFd is capped at 100 years per channel. You cannot buy your way to a higher PL by quoting a component reliability figure nobody can stand behind over a real service life. Redundant designs can exceed that cap at the function level, but each channel is capped first.

DCavg (how much the diagnostics catch)

Average diagnostic coverage measures the fraction of dangerous failures your tests detect, banded as none (under 60%), low (60 to under 90%), medium (90 to under 99%), and high (99% or more). Categories 2, 3, and 4 lean on DCavg to push the achieved PL up. Without diagnostics, a redundant architecture cannot claim the higher levels.

CCF (the shared failure path)

Common cause failure is where redundancy gets undone. Two channels that fail from one shared root cause, a power transient, a temperature spike, a design fault baked into both, defeat the point of having two. For categories 2 through 4 you score CCF against the Annex F checklist and have to clear the minimum. Skip it and the redundancy you paid for does not count.

Combine category, MTTFd, and DCavg and you arrive at the achieved PL, from PLa (lowest) through PLe (highest). PL maps approximately to SIL: PLb and PLc sit near SIL 1, PLd near SIL 2, PLe near SIL 3. Useful for orientation, but the two standards calculate differently, so do not treat the mapping as a conversion you can drop into a safety case.

The Simplified Method vs the Full Calculation

There are two ways to land the achieved PL. The simplified method in Annex K uses a lookup chart: feed in category, MTTFd, and DCavg, read off the PL. It is valid when your architecture matches a designated category structure and your inputs fall inside the defined ranges. It is also conservative, so it can rate a design lower than a full calculation would. For most standard machine safety functions, the simplified method is enough and a lot faster.

The full calculation models the failure probability of the safety function directly, channel by channel, with the proof test interval and the actual reliability data. You reach for it when the architecture does not fit a designated structure cleanly, or when the simplified method rates a borderline design just below PLr and you need to know whether the real number clears the bar.

Where PL Claims Fall Apart

The recurring failures are not subtle once you know to look for them.

Claiming a category without meeting its requirements. A design labeled category 3 still has to be single-fault tolerant, with the diagnostics and CCF measures that category 3 demands. Drawing two channels on a diagram does not make it category 3. The structure, the diagnostics, and the CCF score all have to be there.

Ignoring CCF entirely. Teams build a redundant architecture, claim the PL that redundancy supports, and never score common cause failure. The PL claim is invalid the moment an assessor asks for the Annex F result and there isn’t one.

Treating the 100-year MTTFd cap as optional. Component datasheets sometimes quote enormous reliability figures. The standard caps a single channel at 100 years for a reason. Build the calculation on an uncapped figure and the achieved PL is overstated.

Designing to PLr before confirming PLr. If the risk graph parameters were rushed, every downstream decision inherits the error. A safety function engineered to PLd against a hazard that actually needs PLe is a function that does not control its risk.

This is also where the documentation burden compounds. Roughly 60% of safety engineering time goes to documentation rather than design, and PL calculations are a big slice of it. When category, MTTFd, DCavg, and CCF live in a desktop reliability calculator while the architecture lives somewhere else, every design change means re-entering values by hand and reconciling outputs across disconnected files.

How ASAP Keeps Performance Level Current

Reliability modeling has lived on the desktop for two decades. SISTEMA and similar desktop calculators compute PL from category, MTTFd, DCavg, and CCF, but they sit apart from the architecture they describe, so the model and the design drift out of sync the moment something changes.

ASAP takes a different approach. Its web-based reliability modeling computes Performance Level directly from the safety function architecture, and when the design changes, the PL updates with it. Add a channel to move a category 2 function to category 3, and the model reflects the new structure, the diagnostics, and the CCF requirement together. The PLr from the risk graph and the achieved PL from the architecture stay connected in one place, so the comparison that decides whether the design passes is always against current numbers.

ASAP is AI-assisted and human-verified, with an engineer confirming every safety-relevant decision. Fennec's specified ASAP tools are qualified by TÜV Rheinland as Tool Class 2 (T2) offline support tools under IEC 61508-3:2010, Clause 7.4.4. The qualification does not replace project-specific review of Performance Level calculations or evidence.