ISO 13849 Performance Levels Explained: From PLr to Machine Validation
Performance Levels from PL a to PL e describe how reliably a defined safety-related control function can reduce risk. The required level, PLr, comes first; the achieved PL is then demonstrated from the complete input, logic and output chain, not from one component label.
Name the trigger, hazardous part, safe reaction, modes, timing and restart behavior.
Risk assessment or a relevant type-C standard sets the required Performance Level.
Architecture, reliability, diagnostics, CCF and systematic controls all affect achieved PL.
A calculation cannot prove wiring, timing, safe state, reset or fault behavior by itself.
What is an ISO 13849 Performance Level?
A Performance Level, or PL, describes the capability of safety-related control parts to perform one specified safety function under foreseeable conditions. ISO 13849-1 uses five levels: PL a provides the lowest contribution to risk reduction and PL e the highest.
For example: “Opening guard door GD-1 in automatic mode stops the spindle and hazardous axis, reaches the defined safe state within the required time, and prevents unexpected restart.” That statement is specific enough to design, evaluate and test.
PLr is the required target. Achieved PL is the demonstrated capability of the completed safety function. The design must achieve at least PLr and still meet every other requirement, including response time and safe-state behavior.
ISO 13849-1:2023 supplies a design and integration method for safety-related parts of control systems in high-demand and continuous operation. It applies across electrical, electronic, programmable, hydraulic, pneumatic and mechanical technologies. The standard does not choose the required safety functions or PLr for a particular machine. Those decisions must come from the machine risk assessment and any applicable machine-specific requirements.
| Current condition | Recommended action | Evidence required | Stop boundary |
|---|---|---|---|
| The safety function is still described only as “make the gate safe” | Write the trigger, hazardous part, safe state, timing, modes and restart behavior before selecting components. | Risk assessment, applicable type-C requirements and a reviewable safety requirements specification. | Do not assign parts or claim PL until the function boundary and PLr are defined. |
| A component data sheet says “up to PL e” | Treat it as maximum component capability under stated conditions, not as the result for the complete machine function. | Exact model, safety manual, PFH data, architecture limits, configuration, mission time and conditions of use. | Do not transfer the label to the whole input–logic–output chain. |
| The numerical PFH result falls inside a PL band | Continue the Category, diagnostics, CCF, systematic, software and architecture evaluation. | Controlled calculation model, source data, assumptions and subsystem boundaries. | A PFH band alone is not an achieved-PL claim. |
| A SISTEMA report is complete | Verify the model, then inspect and validate the as-built machine against the SRS. | Drawings, firmware and parameters, inspection record, functional and fault tests, and measured timing where required. | Do not release the safety function when the physical implementation or validation differs from the model. |
Identify hazards, tasks, operating modes, exposure and foreseeable misuse.
Determine the required level for each separate safety function.
Specify input, logic, output, safe state, timing and restart behavior.
Review Category, failure data, diagnostics, CCF and systematic controls.
Inspect and test the implemented function against its written requirements.
What do PL a through PL e mean?
ISO 13849-1:2023 Table 2 expresses each level with the average frequency of a dangerous failure per hour, written as PFH. Older editions and many current data sheets use PFHd. Always record the standard edition and the manufacturer's exact definition when transferring values.
10-5 ≤ PFH < 10-4
per hour
3 × 10-6 ≤ PFH < 10-5
per hour
10-6 ≤ PFH < 3 × 10-6
per hour
10-7 ≤ PFH < 10-6
per hour
PFH < 10-7
per hour
Important 2023 edition detail: Table 2 now states PL e as PFH below 10-7 per hour. Do not silently copy the older lower boundary of 10-8 into a 2023-edition assessment. A low PFH value alone still does not prove achieved PL e; all applicable architectural, qualitative, systematic and validation requirements remain necessary.
Enter a positive PFH value per hour to see its numerical band in the 2023 PL scale.
This lookup does not calculate Category, MTTFd, DCavg, CCF, systematic measures or achieved PL.
6 × 10-8 per hour is below 10-7. This is only a Table 2 range lookup, not a PL claim.
How is required Performance Level PLr determined?
PLr is assigned to one safety function from the risk assessment or stated by an applicable type-C machine standard. A commonly used ISO 13849 risk-graph route considers severity, exposure and the realistic possibility of avoiding or limiting harm.
Severity of injury
Could the result be slight and normally reversible, or serious and irreversible, including death? Crushing, cutting, entanglement, ejection, stored energy and gravity can turn a routine task into a severe hazard.
Frequency or exposure
Include production, setup, cleaning, jam clearing, changeover, fault recovery and maintenance. Counting only normal automatic operation can miss the periods when people are closest to the hazard.
Possibility of avoidance
Can a person actually recognize the event and escape or limit harm at the real speed, visibility and working position? “The operator can move away” is weak reasoning for fast or unexpected motion.
Do not select PLr from the component catalog. A PLe light curtain, relay or switch may be capable of use in a high-performing subsystem, but its label cannot decide the risk-reduction target for the machine. Also check whether a type-C standard already defines a safety function, PLr, architecture or validation expectation.
What must a safety function specify before calculation?
“The gate is safe” or “use a PLe switch” cannot be tested. A safety requirements specification, often shortened to SRS, turns the risk-reduction decision into an engineering requirement.
Write these items before choosing parts
- Trigger: What event demands the safety response?
- Hazardous part: Which motion or energy must be controlled?
- Reaction and safe state: What must stop, isolate, hold or limit?
- Modes: Is behavior different in automatic, setup or maintenance?
- Time: How quickly must the safe state be reached?
- Reset and restart: What prevents unexpected hazardous motion?
- Interfaces: How does this function interact with E-stop, safe speed and mode selection?
- Acceptance criteria: What inspection and tests will prove the requirement?
Why is Category not the same as Performance Level?
Category B, 1, 2, 3 or 4 describes an architectural approach and behavior under faults. Achieved PL is the result of evaluating that architecture together with component reliability, diagnostic coverage, common-cause failure measures, systematic controls and the complete safety function.
Basic principles
Baseline application of relevant standards and basic safety principles. A single fault can lead to loss of the safety function.
Well-tried approach
A generally single-channel structure using well-tried components and well-tried safety principles. Diagnostics are not implied.
Periodic testing
A checking arrangement tests the safety function. The test timing, demand rate and effectiveness matter to the claimed result.
Fault tolerance
Generally redundant, with defined behavior after a single fault and diagnostic measures appropriate to the design.
High diagnostics
Fault-tolerant architecture with demanding diagnostic and fault-accumulation requirements. It is not an automatic PL e claim.
“The guard-door safety function was evaluated as Category 3, achieved PL d under the stated assumptions, and passed the specified validation tests.”
“It has two channels, so it is Category 3 and therefore PL d.” Shared power, routing, connectors, configuration or environmental exposure can defeat both channels.
Which inputs determine the achieved Performance Level?
The calculation is only as strong as its inputs and assumptions. A buyer should ask where each value came from, which product revision and use condition it covers, and how it will be controlled over the machine lifecycle.
MTTFd
Mean Time to Dangerous Failure is a reliability parameter for a part or channel, often expressed in years. It is not a promised service life. Use current, traceable data and the standard's applicable caps and rules.
B10d
For components such as contactors, valves and switches, B10d data and the real number of operating cycles can be essential. The value is neither a warranty nor an exact replacement date.
DCavg
Average diagnostic coverage asks which dangerous faults are detected, by what mechanism, how quickly, and what the control system does after detection. A status LED is not automatically diagnostic coverage.
CCF
Common-cause failure can defeat channels expected to be independent. Review supply, routing, separation, environment, component diversity, software/configuration and maintenance practice.
PFH or PFHd
The average dangerous-failure frequency positions the numerical result within the PL scale and supports combining subsystems under the applicable method. Keep edition terminology and subsystem boundaries clear.
Systematic failure
Wrong logic, wiring, parameterization, software, specification or change control can defeat a low random-hardware failure rate. Reviews, configuration control and validation are part of the safety argument.
Mission time and use rate connect the numbers to reality
A reliability claim may depend on a defined mission time or useful life. Wear-related components also depend on load and operating frequency. A contactor that switches once per shift and one that cycles several times per minute cannot share an unexamined lifetime assumption.
- Record exact part number, revision, firmware and configuration.
- Record cycles per hour, hours per day and operating days per year.
- Check utilization category, electrical or fluid load and environment.
- Define maintenance, proof-test and replacement controls.
- Review the assessment after substitutions or duty-cycle changes.
How should engineers evaluate the complete safety function?
Keep the calculation inside a controlled design process. These steps turn a PL label into traceable engineering evidence.
Establish the project basis
Name the machine, target markets, applicable law, national standard adoption, type-C standard, customer requirements and ISO 13849 edition.
Perform and document the risk assessment
Define machine limits, hazards, tasks, exposure, modes, foreseeable misuse and the overall risk-reduction strategy.
Define each safety function in the SRS
Record trigger, hazardous part, reaction, safe state, modes, timing, reset/restart, interfaces, fault behavior, PLr and validation criteria.
Select the complete architecture
Include input, logic, outputs, actuators, drives, valves, feedback, communications, energy control and relevant configuration boundaries.
Collect qualified component data
Use current manuals, safety certificates, PFH or PFHd, B10d/MTTFd, mission time, application conditions and configuration evidence.
Evaluate architecture and parameters
Determine Category, reliability data, DCavg, CCF measures, systematic controls and subsystem combination using the project's standard edition.
Compare achieved PL with PLr
Confirm achieved PL is at least the required level, then check every non-PL requirement such as safe state, response time and mode behavior.
Verify and validate
Review drawings and calculations, inspect the as-built machine, then test normal, fault, reset, timing, mode and interface behavior against the SRS.
Release and control changes
Archive assumptions, calculations, software, drawings and test records. Trigger review when parts, code, speed, load, guarding or operating modes change.
What does a PFH calculation prove—and not prove?
The following arithmetic is illustrative and is not presented as an xsz sensor customer project or validated design.
Consider a guarded carton erector with hazardous belts, a servo-driven pusher and pneumatic motion. “The door switch must be PLe” does not yet define what should stop, how quickly, or what prevents restart.
2 × 10-8 + 2 × 10-8 + 2 × 10-8 = 6 × 10-8 per hour
If the project method legitimately combines input, logic and output subsystem values this way, the numerical sum lies in the 2023 PL e PFH range. But the safety function can only claim its achieved PL after the applicable Category, diagnostic, CCF, systematic, software, architecture and validation requirements are also met.
Illustrative arithmetic only: never reuse these values in a real design. Actual subsystem boundaries, values, mission time, fault exclusions, combination method, software scope and edition basis must come from the specific validated application.
What can SISTEMA support—and what cannot it validate?
IFA's SISTEMA software supports the evaluation of safety-related machine controls. It models designated architectures, accepts parameters such as PLr, Category, CCF, MTTFd and DCavg, calculates reliability values and creates a summary report.
SISTEMA can support
- Structured subsystem modeling
- Visible assumptions and parameter changes
- Reliability and achieved-PL evaluation
- Project reports and calculation traceability
- Use of compatible manufacturer libraries
SISTEMA cannot prove
- That the risk assessment is complete
- That guarding distance and stop time are adequate
- That the panel matches the modeled wiring
- That parameters are locked and modes are correct
- That the installed machine passed validation
Match software and standard edition: IFA assigns SISTEMA 1.x to ISO 13849-1:2008, 2.x to the 2015 edition and 3.x to the 2023 edition. The current IFA page lists SISTEMA 3.0.4 Build 5 as of its October 31, 2025 update. A 2.x project can be opened in 3.x, but the converted file is not backward compatible and new messages must be reviewed against the 2023 changes.
What should buyers verify in safety-component documentation?
“Up to PL e, Category 4” normally states a device's maximum capability under defined conditions. Procurement still needs the evidence required to integrate that device into the complete safety function.
| Datasheet item | Question to ask | Why it matters |
|---|---|---|
| Maximum PL / Category | For which exact model, mode, wiring, standard edition and application conditions is the claim valid? | A maximum claim can exceed what the actual architecture is allowed to use. |
| PFH or PFHd | Which function, firmware, mission time, communication path and configuration are included? | Subsystem values must have compatible boundaries before they are combined. |
| B10d / MTTFd | Which load, utilization category, switching rate, pressure and environment support the value? | Generic wear data can make a calculation meaningless. |
| Diagnostics | Which dangerous faults are detected, when are they detected and what external monitoring is required? | DCavg must correspond to the real fault-detection mechanism. |
| Application diagram | Does it cover the exact inputs, reset, outputs, EDM/feedback, drive interface and supply? | A similar-looking drawing is not an approved circuit for another configuration. |
| Environment | What temperature, vibration, IP, EMC, wiring-length, separation and grounding limits apply? | Operating outside the documented scope can invalidate assumptions. |
| Software/configuration | How are safety parameters set, verified, locked, backed up and changed? | Correct hardware cannot compensate for uncontrolled safety logic. |
| Evidence package | Are current manuals, certificates, library data, change notices and support records available? | The project needs an auditable integration path, not only a catalog line. |
How should the completed machine be verified and validated?
Verification asks whether the design and calculation satisfy the specified requirements. Validation asks whether the implemented safety function really fulfills those requirements through analysis and testing.
Validation should cover the as-built function
- SRS review, including PLr, safe state, modes, timing and interfaces
- Architecture, schematic, software and configuration review
- Traceability of PFH, MTTFd/B10d, DCavg, CCF and mission time
- Inspection of actual wiring, firmware, parameters, routing and final actuators
- Functional and fault testing for stop, reset, restart, modes and feedback
- Measured response or stopping behavior where the safeguarding method requires it
- Documented independence appropriate to the project and organization
Never validate by defeating the safeguard on a live production machine. Use qualified personnel, controlled energy-isolation measures, an approved test plan and documented fault-insertion methods. If a test exposes hazardous motion or behavior outside the SRS, stop and treat it as a design issue.
ISO 13849-1:2023 contains updated normative validation requirements. ISO 13849-2:2012 remains published and still contains fault-evaluation tables, while ISO lists a replacement draft under development. Use the editions and national adoption named in the project basis; do not casually merge clauses from different versions.
Which mistakes should stop an ISO 13849 PL claim?
Most weak PL claims do not fail because of advanced mathematics. They fail because the wrong function, boundary, input data or installed behavior was assessed.
| Mistake | Why it is weak | Better approach |
|---|---|---|
| Choosing PL from a catalog | The required target is driven by machine risk and applicable standards. | Define the hazard and function, determine PLr, then select parts. |
| Calling Category 3 “PL d” | Category describes architecture; achieved PL uses several additional factors. | State both separately and show the complete evaluation. |
| PLe component = PLe function | Inputs, outputs, wiring, configuration, CCF or validation can limit the chain. | Model and validate every contributing subsystem. |
| Generic reliability values | Failure and wear data can be product- and use-specific. | Use traceable current data and realistic duty cycles. |
| LED = diagnostic coverage | An indicator may not detect the relevant dangerous failure. | Name the fault, detection method, timing and safe response. |
| Two channels = independent | Shared power, routing, environment or configuration can cause CCF. | Document and inspect actual CCF measures. |
| Ignoring setup and maintenance | Automatic-mode protection may change or disappear in other tasks. | Specify every mode and its authorized-access boundaries. |
| Keeping an old calculation after change | Parts, firmware, speed, loads or guarding can change assumptions. | Use formal impact review and revalidation triggers. |
Which other standards may control the machine-safety project?
ISO 13849 addresses safety-related control parts. It does not replace the overall machinery risk-reduction process, product standards, safeguarding-distance rules, electrical requirements or machine-specific type-C standards.
ISO 12100
Provides the general machinery risk-assessment and risk-reduction method: identify hazards, estimate and evaluate risk, reduce risk and document the process.
Type-C standards
Machine-specific standards can define hazards, safety functions, PLr, architecture, distances or tests more specifically than a general standard.
Component standards
Light curtains, interlocks, emergency stops, safe drives, relays, valves and other safety products have their own applicable standards and safety manuals.
Avoid acronym conversion shortcuts. If a function follows an IEC 62061/SIL route, do not turn a PL label into a SIL claim by visual comparison alone. Use the method, subsystem rules and product data required by the governing standard.
What should a machine-safety RFQ provide for PL review?
A supplier can respond more accurately when the machine builder makes the safety-function boundary and current evidence visible. This also reduces unsuitable substitutions during quoting.
Machine type, hazardous motion or energy, tasks, operating modes, access and target market.
Trigger, safe state, response time, reset/restart behavior, PLr and relevant type-C requirement.
Inputs, controller, outputs, contactors, valves, safe drive, feedback, power and communications.
Schematics, part numbers, manuals, duty cycle, calculation basis, firmware/configuration and validation plan.
Standards and current reference material
- ISO 13849-1:2023 — current Part 1 scope, edition, application boundary and publication status.
- ISO 13849-2:2012 — published validation standard and current revision status.
- ISO 12100:2010 — machinery risk-assessment and risk-reduction principles.
- IFA/DGUV SISTEMA — official tool scope, current release and standard-version mapping.
- IFA Performance Level Calculator — relationship among Category, MTTFd, DC, CCF, PFH and PL.
- IFA: Fourth edition changes — 2023 structure, subsystem, SRS, validation, EMC and software changes.
- OMRON safety design guide — 2023 PL/PFH table and PLr/PL overview.
- Pilz ISO 13849-1 overview — 2023 changes and validation relationship with Part 2.
Checked September 5, 2026. Standards and software can be revised. Reconfirm the applicable edition, national adoption, transition rules and current manufacturer documentation before design release or publication.