Machine Safety · Functional Safety

ISO 13849 Performance Level (PL a–e): A Practical Guide to Machine Safety

A practical introduction to Performance Level, PLr, PFH, Category, MTTFd, DCavg, CCF and the engineering process used to evaluate safety-related control functions under ISO 13849-1.

When a machinery risk-reduction measure depends on a control system, the safety-related parts of that control system need to perform their intended safety function with an appropriate level of reliability. ISO 13849-1 provides one of the principal methodologies used to design and evaluate those safety-related control functions.

The standard uses five Performance Levels — PL a, PL b, PL c, PL d and PL e. Moving from PL a toward PL e represents progressively more demanding safety-related performance and progressively lower permitted frequencies of dangerous failure.

Performance Level is not determined by failure probability alone. The evaluation also considers the architecture of the safety-related control system, component reliability, diagnostic capability, measures against common-cause failures and measures intended to prevent systematic failures.

Another important distinction is between PLr — the required Performance Level established for a safety function — and the achieved PL demonstrated by the implemented safety-related control system.

ISO 13849 at a glance

These concepts appear repeatedly throughout this guide.

  • Current Part 1
    ISO 13849-1:2023, fourth edition.
  • Performance scale
    PL a through PL e.
  • PLr
    Required Performance Level for a defined safety function, determined from risk assessment and applicable requirements.
  • Achieved PL
    The Performance Level demonstrated by the designed and evaluated safety-related control function.
  • PFH
    Average frequency of a dangerous failure per hour.
  • Main evaluation factors
    Category, MTTFd, DCavg, CCF, systematic measures and the requirements applicable to the complete safety function.
How to use this guide

The article begins with the basic PL and PLr concepts, then moves through risk assessment, architecture and reliability, PL versus SIL, IEC 61496 ESPE Types, verification and validation, SISTEMA, and the main changes introduced in ISO 13849-1:2023.

On This Page

Table of Contents

Use the links below to jump directly to a topic in this guide.

Understanding the Concept

What Is a Performance Level?

A Performance Level describes the ability of a safety-related control function to perform its intended safety action reliably under foreseeable conditions.

Identifying a machinery hazard is only the beginning of the risk-reduction process. If a protective measure depends on a control system, the relevant safety-related parts of that control system need to provide sufficient performance for the required safety function.

ISO 13849-1 expresses this performance using five levels: PL a, PL b, PL c, PL d and PL e. The scale progresses toward increasingly demanding safety-related performance and lower permitted frequencies of dangerous failure.

The final Performance Level is not simply a numerical reliability value. It also reflects the architecture of the control system, component reliability, diagnostic capability, resistance to common-cause failures and measures against systematic failures.

Performance Level is evaluated for a safety function

A safety function often involves several parts of the control system. A useful conceptual model is to divide the function into input, logic and output.

  • Input Detect the relevant condition The input portion provides safety-related information about a condition that requires protective action.
  • Logic Evaluate the information The logic portion processes the safety-related input and determines the required control response.
  • Output Achieve or maintain the safe state The output portion acts on the machine so that the required protective action can be achieved.

PLr and achieved PL describe different things

One of the most useful distinctions in ISO 13849 is the difference between the level that is required and the level that the completed design actually achieves.

PLr — Required Performance Level

The Performance Level required for a defined safety function, established from risk assessment and applicable machinery requirements.

Achieved PL

The Performance Level demonstrated by the implemented safety-related control function after architecture, reliability, diagnostics and the other applicable requirements have been evaluated.

Achieved PL ≥ Required PLr
Performance Levels

PL a to PL e and the PFH Ranges

ISO 13849-1 defines five Performance Levels using ranges of the average frequency of a dangerous failure per hour, abbreviated PFH.

Moving from PL a toward PL e represents progressively greater safety-related performance. Quantitatively, the permitted average frequency of dangerous failure becomes lower as the Performance Level increases.

PFH is expressed in failures per hour and is therefore commonly written using scientific notation. For example, 1 × 10−7 per hour is one order of magnitude lower than 1 × 10−6 per hour.

The PFH range is an important quantitative part of the Performance Level concept, but it is not the only requirement that determines whether a safety-related control function achieves a particular PL.

Performance Level and PFH

ISO 13849-1:2023 defines the following PFH ranges for Performance Levels a through e.

Performance Level Average Frequency of a Dangerous Failure per Hour
PL a 1 × 10−5 ≤ PFH < 1 × 10−4
PL b 3 × 10−6 ≤ PFH < 1 × 10−5
PL c 1 × 10−6 ≤ PFH < 3 × 10−6
PL d 1 × 10−7 ≤ PFH < 1 × 10−6
PL e PFH < 1 × 10−7

What does a lower PFH mean?

A lower PFH represents a lower average frequency of dangerous failure attributable to the safety-related control function. It is therefore one quantitative measure of the dependability required from that function.

PFH should not, however, be interpreted as a prediction of when an accident will occur. It is a probabilistic functional-safety measure used in the evaluation of the safety-related control system.

Example of reading the scale

PL d covers PFH values from 1 × 10−7 per hour up to, but not including, 1 × 10−6 per hour. A design cannot be classified as PL d merely because one component falls within that range; the complete ISO 13849 requirements still apply.

Why PFH alone does not establish the Performance Level

ISO 13849 combines quantitative reliability with architectural and qualitative requirements. The resulting Performance Level therefore depends on more than the calculated dangerous-failure frequency.

The evaluation also considers factors such as Category, MTTFd, DCavg, common-cause-failure measures and requirements intended to prevent systematic failures.

These factors are discussed in more detail later in this guide.

Key takeaway

PFH provides the quantitative backbone of the PL scale, but an achieved Performance Level is demonstrated through the complete ISO 13849 design and evaluation process — not from PFH alone.

Required Performance Level

How Is the Required Performance Level (PLr) Determined?

PLr is established for a defined safety function. It represents the level of safety-related control performance required to contribute the necessary risk reduction.

The process begins with the machinery risk assessment and the definition of the safety function — not with the selection of a particular safety device or control architecture.

The important question is therefore not simply “What PL does this machine need?” but: what safety function is required for the identified hazard, and what level of performance must that function achieve?

A machine can contain several hazards, operating modes and safety functions. Those functions do not necessarily have the same PLr, so the required Performance Level should be considered function by function.

The S–F–P risk parameters

The ISO 13849 risk graph considers three principal parameters: severity of possible injury, frequency and/or duration of exposure to the hazard, and the possibility of avoiding the hazard or limiting the harm.

S

Severity of injury

Consider the reasonably foreseeable consequence if the hazardous event occurs.

S1 — slight, normally reversible injury.

S2 — serious, normally irreversible injury, including death.

F

Frequency and/or exposure to the hazard

Consider how often a person is exposed to the hazardous situation and how long the exposure lasts.

F1 — seldom to less frequent and/or exposure time is short.

F2 — frequent to continuous and/or exposure time is long.

P

Possibility of avoiding the hazard or limiting harm

Consider whether a person could realistically avoid the hazardous event or limit the resulting harm.

P1 — possible under specific conditions.

P2 — scarcely possible.

PLr determination sits inside a wider risk-reduction process

The risk graph is a structured method for determining the required Performance Level of a safety function. It should not be treated as a substitute for the complete machinery risk assessment.

Identify the hazard and hazardous situation

Determine what can cause harm, who may be exposed and the reasonably foreseeable consequences.

Define the required safety function

Describe what the safety-related control system must do to contribute the required risk reduction.

Determine PLr

Consider applicable machine-specific requirements and apply the appropriate risk-evaluation method to the defined safety function.

Design and evaluate the safety-related control system

The implemented function is then designed, evaluated, verified and validated to demonstrate that its achieved PL is sufficient for the required PLr.

Parameter P requires more than asking whether someone can “step away”

The possibility of avoiding the hazard or limiting harm can be one of the more difficult risk-graph judgements. ISO 13849-1:2023 provides more structured guidance for this assessment.

The evaluation can consider five practical factors:

  • whether the machine is operated by a specialist or by a non-specialist / layperson;
  • the speed of the machine part or process capable of producing the hazardous event;
  • the physical possibility of avoiding the hazard;
  • the possibility of recognising or sensing the hazard in time; and
  • the complexity of the operation or interaction.
ISO 13849-1:2023 Parameter P should reflect realistic conditions, not an optimistic assumption.

The assessment should consider how the person actually interacts with the machine and whether avoidance remains credible under the foreseeable conditions of the hazardous situation.

The five-factor guidance helps make the P1/P2 judgement more structured than a simple yes-or-no question.

Key takeaway

Determine PLr for a defined safety function within the complete machinery risk-assessment process. Consider applicable machine-specific requirements and use the S–F–P risk graph as a structured decision aid rather than as a stand-alone safety calculator.

Achieved Performance Level

What Determines the Achieved Performance Level?

The achieved PL depends on the complete safety-related control function. No single Category, component rating or reliability figure is sufficient on its own.

After PLr has been determined, the safety-related control system must be designed and evaluated to establish the Performance Level it actually achieves.

For self-developed subsystems, several ISO 13849 parameters are particularly important: Category, MTTFd, DCavg and CCF.

Requirements relating to systematic failures, software, component selection, environmental influences and correct implementation also form part of the safety argument.

Category describes architecture and fault behaviour

ISO 13849 uses Categories B, 1, 2, 3 and 4 as designated architectures. They describe structural principles and how the safety-related control subsystem is expected to behave when faults occur.

Moving from Category B toward Category 4 generally introduces more demanding requirements relating to component reliability, testing, fault tolerance and fault detection.

But the Category number is not itself the achieved PL.

  • Cat. B Basic safety principles

    The safety-related parts are designed, constructed, selected, assembled and combined in accordance with the relevant standards so that they can withstand the expected influences, using basic safety principles.

  • Cat. 1 Well-tried principles and increased component reliability

    Category 1 builds on Category B and uses well-tried safety principles together with well-tried components where required. The architecture remains fundamentally single-channel, so resistance to dangerous failure relies heavily on component reliability.

  • Cat. 2 Safety function with periodic or demand-related testing

    Category 2 introduces a test function that checks the safety function at defined intervals or under defined conditions. A dangerous fault can exist between tests, so the effectiveness and timing of testing are important parts of the architecture.

  • Cat. 3 Single-fault tolerance with partial fault detection

    A single fault must not cause loss of the safety function. Single faults should be detected at or before the next demand whenever reasonably practicable. Because not every dangerous fault necessarily has to be detected, an accumulation of undetected faults can still lead to loss of the safety function.

  • Cat. 4 Single-fault tolerance with more demanding fault behaviour

    A single fault must not cause loss of the safety function and should be detected at or before the next demand. Where detection is not possible, the accumulation of undetected faults must not result in loss of the safety function.

Category 3 vs Category 4 The key distinction is not simply “two channels versus two channels.”

Both Categories are commonly implemented with redundant structures, but redundancy alone does not define the Category.

Category 3 permits situations in which some dangerous faults remain undetected and their accumulation can eventually cause loss of the safety function. Category 4 places a stronger requirement on fault detection and fault accumulation so that the required safety function is preserved under the defined fault conditions.

MTTFd: resistance to dangerous random failure

MTTFd means Mean Time To Dangerous Failure. It is a statistical reliability parameter used in ISO 13849 to characterise the resistance of a channel or relevant component arrangement to dangerous failure.

It should not be interpreted as guaranteed physical product life. An MTTFd value is an input to the functional-safety calculation rather than a promise that a component will operate for that number of years before failing.

Two subsystems with similar architectures can therefore produce different achieved Performance Levels if the reliability of their components or channels differs significantly.

DCavg: effectiveness of dangerous-fault detection

Diagnostic Coverage describes the extent to which diagnostics detect dangerous failures. ISO 13849 uses DCavg to represent the average diagnostic coverage for the relevant parts of the subsystem.

Diagnostics can include cross-monitoring, plausibility checks, output monitoring, test pulses or other measures depending on the technology and architecture.

Higher diagnostic coverage can improve the safety performance of a suitable architecture, but DCavg cannot establish a PL independently of Category, reliability and the other applicable requirements.

CCF: keeping redundancy from failing for the same reason

Redundant channels provide little benefit if one shared cause can defeat them at the same time. ISO 13849 therefore requires consideration of Common Cause Failure (CCF) where relevant.

Measures against CCF can address matters such as:

  • physical or functional separation;
  • protection against environmental influences;
  • electrical, mechanical and electromagnetic independence;
  • suitable component or technology diversity where appropriate;
  • systematic analysis of potential shared failure causes; and
  • competence and engineering practices appropriate to the design.

ISO 13849-1:2023 places clearer emphasis on considering CCF at subsystem level rather than assuming that one generic CCF assessment automatically covers every part of a complex safety function.

Random hardware failure is only part of the picture

A safety function can fail even when the probabilistic hardware calculation looks satisfactory.

Specification mistakes, unsuitable component application, software errors, incorrect parameterisation, wiring errors, integration mistakes or uncontrolled modifications can introduce systematic failures.

ISO 13849 therefore includes requirements and guidance intended to prevent or control these failures throughout specification, design, implementation, verification and validation.

Conceptual relationship

Architecture + component reliability + diagnostics + fault independence + systematic integrity → achieved safety performance

This is a conceptual summary, not the ISO 13849 calculation formula. The actual Performance Level must be established using the methodology and requirements of the standard.

Key takeaway

The achieved PL belongs to the implemented safety function or subsystem as evaluated. It cannot be inferred from the Category number, the presence of redundancy, or the rating of one individual safety component.

Worked Example

A Generic Example: From PLr to an Evaluated Safety Function

A simplified example helps show how risk assessment, safety-function definition, subsystem data and Performance Level evaluation fit together without tying the process to a particular product.

Consider a machine with hazardous motion located behind an interlocked access guard. Opening the guard while hazardous motion is possible requires a safety-related control response.

For this example only, assume that the machinery risk assessment and any applicable machine-specific requirements have established PLr d for the relevant safety function.

Step 1 — Define the safety function

Before carrying out reliability calculations, the intended behaviour needs to be defined clearly.

A simplified safety-function description for this example might be:

When the access guard is opened, hazardous machine motion shall be brought to or maintained in the defined safe state in accordance with the specified response requirements.

A real Safety Requirements Specification would contain additional information such as operating modes, triggering conditions, safe state, required response time, reset and restart behaviour, fault reaction and relevant interfaces.

Step 2 — Identify the parts that implement the safety function

For explanation purposes, many safety functions can be understood using the familiar input–logic–output sequence:

  • Input Detect that the access guard is no longer in the condition required for hazardous machine operation.
  • Logic Evaluate the safety-related input and issue the required safety-related control response.
  • Output Act on the machine so that hazardous motion is stopped or prevented in accordance with the defined safety function.
Input, logic and output are a conceptual description — not a rule requiring three separate physical devices.

A real implementation may contain several subsystems, integrated functions or different technologies. ISO 13849-1:2023 focuses on the safety function as a combination of the subsystems that actually contribute to it.

Step 3 — Determine how each subsystem is evaluated

Not every subsystem has to be evaluated in exactly the same way. The available safety-related data depends on whether the subsystem is being designed by the machine builder or has already been evaluated and validated by its manufacturer.

Self-developed subsystem

Where the machine manufacturer or integrator develops the subsystem architecture, the ISO 13849 evaluation can require parameters such as Category, MTTFd, DCavg, CCF and the relevant qualitative requirements.

Previously evaluated or manufacturer-validated subsystem

A subsystem can already have documented safety-related characteristics such as PL capability and PFH together with defined conditions and limitations of use. Those data can be incorporated into the evaluation of the overall safety function in accordance with the applicable standard and the manufacturer’s documentation.

This distinction is important. Engineers should not automatically open every validated subsystem and invent new internal Category, MTTFd or DCavg values when the subsystem is intended to be used through its declared safety-related data.

Step 4 — Evaluate the complete safety function

The safety function is then evaluated as the combination of the contributing subsystems.

Their dangerous-failure contributions, safety-related capabilities, architecture and applicable qualitative requirements need to be considered using the ISO 13849 methodology.

It is not sufficient to identify the subsystem with the highest individual PL and apply that rating to the entire function. Likewise, a strong input subsystem cannot compensate automatically for inadequate performance elsewhere in the safety-related chain.

Step 5 — Compare the achieved PL with PLr

After the relevant quantitative and qualitative requirements have been evaluated, the achieved Performance Level is compared with the required Performance Level defined in the Safety Requirements Specification.

For this example:

Required PLr = d

The completed safety-related control function therefore needs to demonstrate an achieved Performance Level sufficient for that requirement.

A calculation that produces a lower achieved PL means that the design does not satisfy the assumed PLr and needs to be reconsidered.

Step 6 — Use calculation tools where appropriate

Engineering tools can make the evaluation easier, particularly when a safety function contains several subsystems or detailed reliability data.

SISTEMA, provided by the German Institute for Occupational Safety and Health (IFA), supports ISO 13849 evaluation by modelling safety-related structures and calculating values including the attained Performance Level.

Step 7 — Verification and validation still follow

Reaching the required calculated PL is not the end of the process.

The design needs to be verified against its specified requirements, and the implemented safety function needs to be validated to confirm that it performs as intended under the relevant operating and fault conditions.

This includes more than reliability mathematics. The real implementation can involve wiring, configuration, software, interfaces, fault reaction, stopping behaviour and restart behaviour that need to be checked as part of the complete safety argument.

Do not assign a Category or PL simply by counting devices or channels.

Two switches, two outputs or two contactors do not automatically establish Category 3, Category 4, PL d or PL e. The architecture, fault behaviour, diagnostic coverage, reliability, CCF measures and the other applicable requirements must support the claimed result.

Key takeaway

Start with the hazard and the defined safety function, establish PLr, identify the contributing subsystems and their valid safety-related data, evaluate the complete function, and then verify and validate the implementation. Product ratings and software calculations support that process; they do not replace it.

Functional Safety Frameworks

Performance Level vs SIL: How Should They Be Compared?

ISO 13849-1 uses Performance Levels, while IEC 62061 uses Safety Integrity Levels. Both frameworks use PFH when evaluating dangerous random hardware failure, but PL and SIL should not be treated as interchangeable labels.

Machinery engineers commonly encounter both ISO 13849-1 and IEC 62061. The two standards address functional safety of machinery control systems from different methodological perspectives.

Their quantitative results can be compared because both use the average frequency of dangerous failure per hour, or PFH, as an important reliability measure.

That common metric is useful, but it should not be stretched into the claim that every PL has a completely identical SIL equivalent. The surrounding architecture, design rules, systematic requirements and validation methodology remain standard-specific.

PL and SIL belong to different methodologies

Performance Level — ISO 13849-1

ISO 13849-1 uses PL a through PL e and combines quantitative reliability with designated architectures, diagnostic coverage, MTTFd, common-cause-failure measures and requirements relating to systematic integrity.

Safety Integrity Level — IEC 62061

IEC 62061 uses SIL 1 through SIL 3 for machinery safety-related control functions. Its methodology evaluates probabilistic hardware integrity together with architectural constraints and systematic safety integrity.

Comparing the quantitative PFH ranges

The table below is best read as a PFH correspondence guide, not as a universal conversion table between two complete standards.

ISO 13849 PL ISO 13849-1:2023 PFH IEC 62061 Context
PL a 1 × 10−5 ≤ PFH < 1 × 10−4 No direct SIL 1–3 correspondence across the complete PL a range.
PL b 3 × 10−6 ≤ PFH < 1 × 10−5 Falls within the IEC 62061 SIL 1 PFH band.
PL c 1 × 10−6 ≤ PFH < 3 × 10−6 Falls within the IEC 62061 SIL 1 PFH band.
PL d 1 × 10−7 ≤ PFH < 1 × 10−6 Corresponds quantitatively to the IEC 62061 SIL 2 PFH band.
PL e PFH < 1 × 10−7 Corresponds to the highest machinery safety-integrity region associated with SIL 3, while the IEC 62061 SIL 3 PFH band is normally expressed as 1 × 10−8 ≤ PFH < 1 × 10−7.

“PL d equals SIL 2” is useful shorthand — but incomplete

PL d and SIL 2 occupy the same quantitative PFH interval, so the shorthand comparison is useful when discussing dangerous random hardware failure.

It does not mean that a system designed and evaluated under ISO 13849-1 can simply be relabelled as an IEC 62061 SIL 2 system, or vice versa.

Each standard has requirements governing matters such as subsystem architecture, hardware fault tolerance, diagnostics, systematic failures, software, verification and validation. Those requirements remain part of the applicable methodology.

Category is not a third equivalent scale

ISO 13849 Categories B, 1, 2, 3 and 4 describe designated architectures and fault behaviour. They do not form another integrity scale that can be placed beside PL and SIL in a simple three-column conversion chart.

For example, the statement:

Category 3 = PL d = SIL 2

is an oversimplification.

Category 3 can be part of a design that achieves PL d, but the achieved PL also depends on reliability data, diagnostic coverage, common-cause-failure measures and fulfilment of the other applicable ISO 13849 requirements.

Cross-standard subsystem use is possible — but controlled

Modern machinery safety design can combine previously validated subsystems developed under different functional-safety standards. ISO 13849-1:2023 explicitly recognises previously validated subsystems according to IEC 62061, the IEC 61508 series and relevant safety-related product standards.

Where SIL-based subsystems are incorporated into an ISO 13849 safety function, their PFH and integrity capability can be used within the conditions defined by the standard. This does not mean that an ISO 13849 Category must always be assigned to the imported subsystem.

ISO 13849 or IEC 62061?

The appropriate framework depends on the machinery application, applicable standards, technologies involved, engineering approach and the safety lifecycle adopted for the project.

It is no longer accurate to reduce the choice to “ISO 13849 for mechanical systems and IEC 62061 for electrical systems.” Both standards now support broad machinery control-system technologies and can be used in sophisticated functional-safety designs.

Whichever methodology is selected, it should be applied coherently and documented clearly.

Current standards context

ISO 13849-1:2023 is the current fourth edition of Part 1. IEC 62061:2021 is the current base edition of the machinery functional-safety standard, with subsequent amendments.

In IEC 62061, the dangerous random hardware failure bands for machinery are commonly expressed as SIL 1: 10−6 to <10−5, SIL 2: 10−7 to <10−6, and SIL 3: 10−8 to <10−7 per hour.

Three points worth remembering

  • PL and SIL can be compared through PFH, but the two complete methodologies are not interchangeable.
  • PL d and SIL 2 have a particularly direct quantitative PFH correspondence, while PL e should be read using the current ISO 13849-1:2023 definition of PFH <10−7.
  • Category is an ISO 13849 architectural concept, not an additional SIL/PL conversion scale.
Key takeaway

Use PFH correspondence to understand the relationship between Performance Level and Safety Integrity Level, but follow the design, calculation, verification and validation requirements of the functional-safety standard actually being applied.

Electro-Sensitive Protective Equipment

IEC 61496 Type 2, Type 3 and Type 4: How Do They Relate to PL and SIL?

IEC 61496 classifies electro-sensitive protective equipment by Type. These Type classes define safety-related capability of the protective equipment, but they do not determine the achieved PL or SIL of the complete machine safety function.

IEC 61496-1 provides general requirements and tests for electro-sensitive protective equipment, commonly abbreviated ESPE.

Different sensing technologies are then addressed by subsequent parts of the IEC 61496 series. For example, active opto-electronic protective devices — AOPDs — used for applications such as safety light curtains are addressed by IEC 61496-2.

One of the most useful aspects of the Type classification is that it establishes the maximum safety-integrity capability for which an ESPE Type can be used.

Type class and application capability

The relationship is best expressed using “up to” rather than treating Type, PL and SIL as interchangeable labels.

IEC 61496 Type ISO 13849 Application Capability IEC 62061 Application Capability
Type 2 Up to PL c Up to SIL 1 / SIL CL 1
Type 3 Up to PL d Up to SIL 2 / SIL CL 2
Type 4 Up to PL e Up to SIL 3 / SIL CL 3

Why is Type 3 important?

Earlier editions of the IEC 61496 framework were commonly associated with Type 2 and Type 4 ESPEs. The fourth edition of IEC 61496-1, published in 2020, introduced Type 3 as an additional class.

Type 3 provides capability for applications up to PL d / SIL 2. This fills the gap between the maximum application capability of Type 2 and Type 4.

It also demonstrates why Type selection should follow the required performance of the safety function rather than the assumption that the highest Type must always be selected.

Example Assume a defined safety function has PLr d.

A Type 2 ESPE has application capability only up to PL c and therefore cannot provide the required ESPE capability for that PLr d safety function.

A Type 3 ESPE has capability up to PL d and can therefore be suitable from the ESPE performance-class perspective.

A Type 4 ESPE can also be used because its capability extends up to PL e. However, neither Type 3 nor Type 4 automatically proves that the complete safety function achieves PL d.

Type is not the same as resolution or detection capability

A second common misunderstanding is to treat the IEC 61496 Type class as though it described the physical detection resolution of an ESPE.

These are different characteristics.

  • Type addresses safety-related design, fault behaviour and integrity capability.
  • Detection capability or resolution describes the size or characteristic of an object that the sensing system is intended to detect.
  • Protective-field dimensions describe the physical sensing area provided by the equipment.

A particular resolution therefore does not establish whether an ESPE is Type 2, Type 3 or Type 4.

Device capability and system capability are separate questions

When selecting an electro-sensitive protective device, two questions should be kept separate.

  • Is the ESPE Type suitable for the required PLr or SIL of the application?
  • Does the complete safety-related control function actually achieve the required performance after all contributing subsystems are evaluated?

The first question concerns the capability of the protective equipment. The second concerns the complete machine safety function.

Passing the first test does not automatically answer the second.

IEC 61496 does not determine the complete safeguarding layout

IEC 61496 specifies requirements for the protective equipment itself and its safety-related performance and interface behaviour. It does not, by itself, determine every aspect of how the safeguard must be applied to a particular machine.

Matters such as the required safety function, machine risk assessment, positioning of the protective equipment, safety distance and other application-specific measures need to be addressed through the relevant machinery safety standards and engineering process.

Standards context

IEC 61496-1:2020 is the fourth edition of Safety of machinery — Electro-sensitive protective equipment — Part 1: General requirements and tests.

IEC 61496-2:2020 contains particular requirements for equipment using active opto-electronic protective devices (AOPDs), the sensing principle commonly associated with safety light curtains and related optical protective equipment.

Key takeaway

IEC 61496 Type defines the application capability of the electro-sensitive protective equipment: Type 2 up to PL c / SIL 1, Type 3 up to PL d / SIL 2, and Type 4 up to PL e / SIL 3. The achieved PL or SIL of the complete safety function must still be established separately.

Completing the Safety Process

Verification, Validation and SISTEMA: What Does Each One Do?

Calculating an achieved Performance Level is important, but the calculation is only one part of demonstrating that a safety function has been designed and implemented correctly.

Functional safety requires a traceable connection between the original safety requirements, the engineering design, the quantitative evaluation and the behaviour of the implemented machine.

This is why verification, validation and tools such as SISTEMA should not be treated as interchangeable activities.

A calculation can show that the numerical and architectural assumptions of a design are capable of achieving the required Performance Level. It cannot, by itself, prove that the real machine has been wired, programmed, configured and integrated correctly.

Verification and validation answer different questions

In practical engineering terms, the distinction can be understood as follows.

Activity Main Question Typical Evidence
Verification Does the design and its evaluation satisfy the requirements and design criteria that were specified? Design review, architecture checks, calculations, subsystem data, software review and confirmation of the achieved PL.
Validation Does the implemented safety function actually satisfy the specified safety requirements? Analysis and testing of the implemented function, including normal operation, relevant fault conditions and specified safety behaviour.

Verification: checking the engineering result

Verification provides evidence that the safety-related design has been developed and evaluated in accordance with the defined requirements and the applicable ISO 13849 methodology.

Depending on the safety function, verification can include confirming:

  • that the safety function and its requirements have been defined clearly;
  • that the selected PLr is the requirement being addressed;
  • that subsystem structures and interfaces are represented correctly;
  • that manufacturer data and reliability values are being used within their stated conditions;
  • that Category, MTTFd, DCavg, CCF and other relevant parameters have been evaluated where applicable;
  • that software and systematic requirements have been addressed; and
  • that the achieved Performance Level is sufficient for the required PLr.

Verification is therefore broader than simply reading the final PL value from a calculation tool.

Validation: confirming the implemented safety function

Validation examines whether the implemented safety-related control function actually fulfils the specified safety requirements.

ISO 13849 validation uses analysis and testing. The two approaches complement one another; analysis does not remove the need for appropriate functional testing.

Depending on the safety function and its specification, validation can include examination of:

  • initiation of the required safety action;
  • achievement and maintenance of the defined safe state;
  • response to relevant faults;
  • reset and restart behaviour;
  • operating modes and mode transitions;
  • specified response or stopping times;
  • wiring and interface behaviour;
  • software and parameter settings; and
  • environmental or operating conditions that form part of the Safety Requirements Specification.

What changed with validation in ISO 13849-1:2023?

Earlier editions were often used together with ISO 13849-2 for the detailed validation process.

In ISO 13849-1:2023, the normative validation requirements were revised and incorporated into Clause 10 of Part 1. This makes validation a more visible part of the same safety-function design lifecycle covered by ISO 13849-1.

The change also strengthens the relationship between the Safety Requirements Specification and the later validation process: validation needs a defined set of requirements against which the implemented safety function can be examined.

Current standards status ISO 13849-2:2012 has not simply disappeared.

ISO 13849-2:2012 remains a published ISO standard at present. It specifies validation by analysis and testing of specified safety functions, achieved Category and achieved Performance Level.

The fault-evaluation tables used for detailed fault consideration also remain in Part 2 rather than being reproduced fully in ISO 13849-1:2023.

A revised Part 2 is under development. Until a replacement is published and applicable, the current published status and the relevant contents of ISO 13849-2:2012 should not simply be ignored.

Where does SISTEMA fit?

SISTEMA — the Safety Integrity Software Tool for the Evaluation of Machine Applications — is provided by IFA to support engineering work with ISO 13849.

It allows an engineer to represent safety functions and subsystems, enter relevant safety-related data and calculate quantities used in evaluating the attained Performance Level.

SISTEMA can support the quantitative evaluation

It can structure the model and work with parameters such as PLr, Category, MTTFd, DCavg, CCF and subsystem PFH data where appropriate.

SISTEMA does not determine the machinery risk automatically

The engineer still needs to identify hazards, define the safety function and establish the required PLr using the applicable risk-assessment process and standards.

SISTEMA does not prove that the physical machine is correct

Incorrect wiring, unsuitable software parameters, interface errors, installation mistakes or incorrect input data can exist even when the software model produces an acceptable PL result.

SISTEMA does not replace validation

The implemented safety function still needs the required analysis, testing and documented validation against its Safety Requirements Specification.

Documentation connects the complete process

Good functional-safety documentation should make it possible to trace the engineering decisions from the original hazard and safety function through to the final validation evidence.

A project record can therefore include:

  • the machinery risk assessment;
  • the Safety Requirements Specification;
  • the determined PLr;
  • subsystem architecture and safety-related data;
  • calculations and engineering assumptions;
  • software and configuration information where relevant;
  • verification records; and
  • validation plans, test results and conclusions.

This traceability becomes particularly important when a machine is modified later, because engineers need to understand which original assumptions and safety requirements may have been affected.

Specify → Design → Evaluate → Verify → Validate → Document
Key takeaway

Verification checks whether the engineering design and evaluation satisfy their defined requirements. Validation uses analysis and testing to confirm that the implemented safety function fulfils its Safety Requirements Specification. SISTEMA can support the quantitative evaluation, but it does not replace either activity.

2023 Revision

What Changed in ISO 13849-1:2023?

The fourth edition retains the familiar Performance Level framework, but significantly updates how safety functions are specified, structured, designed, evaluated and validated.

ISO 13849-1:2023 should not be understood as a replacement for the PL a-to-e concept. Performance Level, PLr, Category, MTTFd, diagnostic coverage and common-cause failure remain important parts of the methodology.

The larger change is in the surrounding engineering process. The standard presents the safety function more clearly as a combination of contributing subsystems and gives greater structure to specification, software, validation and functional-safety management.

For engineers familiar with ISO 13849-1:2015, the 2023 edition is therefore an evolution and substantial modernisation of the methodology rather than an entirely different system.

1. Stronger focus on the safety function and its subsystems

One of the clearest structural changes is the stronger focus on implementing a safety function as a combination of several subsystems.

This makes the system-level view more explicit. Instead of treating an individual safety device as though it were the complete safety function, the engineer considers all of the subsystems that contribute to the required safety behaviour.

Those subsystems can include self-developed structures as well as previously evaluated subsystems with declared safety-related data.

2. Safety-function specification and the SRS were strengthened

Clause 5 gives greater attention to the specification of safety functions and to the Safety Requirements Specification (SRS).

The intention is to establish clearly what the safety function must do before the engineer attempts to prove that the design achieves the required Performance Level.

Depending on the safety function, relevant requirements can include:

  • the required safety behaviour;
  • PLr;
  • relevant operating modes;
  • triggering conditions;
  • safe-state requirements;
  • response times;
  • fault-reaction behaviour;
  • reset and restart requirements; and
  • interfaces with other safety functions.

Annex M provides supplementary information intended to support the development of the Safety Requirements Specification.

3. Several subsystem design rules were clarified

Clause 6 contains revised and clarified requirements for the design of safety-related subsystems.

Among the changes is an optimised definition of Category 2, together with clarification relating to fault consideration, fault exclusion and the use of well-tried components.

The revision reinforces a principle that applies throughout ISO 13849: the Category identifies architectural and fault-behaviour characteristics, but it does not independently determine the final Performance Level.

4. Common Cause Failure is considered more explicitly by subsystem

Annex F expands and clarifies measures against Common Cause Failure (CCF).

An important practical change is the clearer expectation that anti-CCF measures are considered at subsystem level. Different subsystems can have different technologies, layouts, environmental exposures and shared failure mechanisms.

The engineer should therefore not assume that one generic CCF assessment automatically represents every subsystem in a complex safety function.

5. Safety-related software requirements were revised and expanded

Clause 7 contains improvements and clarifications relating to safety-related software.

The 2023 edition addresses software as part of the complete safety-related engineering process rather than treating hardware reliability as sufficient by itself.

Annex N supplements those requirements with information on avoiding systematic failures through software design and includes a simple example relating to software validation.

This is particularly relevant because a system can satisfy its random-hardware reliability targets and still fail to perform its intended safety function because of specification, programming, parameterisation or modification errors.

6. Validation requirements are now incorporated into Part 1

ISO 13849-1:2023 introduces a dedicated validation Clause 10. Normative validation requirements from ISO 13849-2 were revised and incorporated into Part 1.

This brings validation more visibly into the same lifecycle as specification, design and Performance Level evaluation.

It also reinforces the importance of the SRS: validation needs defined requirements against which the implemented safety function can be examined through analysis and testing.

7. Guidance for determining PLr — especially parameter P — changed

Annex A retains the familiar S–F–P risk-graph principle but revises the treatment of parameter P, the possibility of avoiding the hazard or limiting the harm.

The 2023 edition provides more structured guidance so that the P1 or P2 decision reflects realistic operating conditions rather than a simplistic question about whether an operator could theoretically move away.

Factors can include operator characteristics, hazardous movement speed, physical possibility of avoidance, recognition of the hazard and operational complexity.

8. Functional Safety Management received more explicit guidance

Annex G.5 expands the guidance on Functional Safety Management.

The objective is to provide a systematic approach to the design and implementation of safety-related control systems and to reduce errors introduced through specification, implementation and later modification.

A functional safety plan can document relevant activities, responsibilities, resources and procedures throughout the project lifecycle. The appropriate form and depth depend on factors such as the complexity, scale and novelty of the project.

9. EMC immunity receives additional practical attention

Annex L provides further information on achieving sufficiently high electromagnetic immunity for safety-related control systems.

This matters because electromagnetic disturbance can become a common or systematic influence on safety-related electronics, interfaces and communication paths.

Functional safety therefore cannot be evaluated only through reliability numbers while ignoring the real electromagnetic environment in which the safety function must operate.

10. Several informative annexes provide additional engineering guidance

The revised annexes make supporting engineering information more explicit in several areas.

  1. Annex F — Common Cause Failure

    Clarifies measures against CCF and their assessment at subsystem level.

  2. Annex G.5 — Functional Safety Management

    Provides guidance for organising the functional-safety process and documenting responsibilities and activities.

  3. Annex L — EMC

    Provides additional information intended to support adequate electromagnetic immunity of safety-related control systems.

  4. Annex M — Safety Requirements Specification

    Provides supplementary information for defining and documenting safety-function requirements.

  5. Annex N — Safety-Related Software

    Provides information relating to avoidance of systematic software failures and includes a simple software-validation example.

  6. Annex O — Safety-Related Component Values

    Provides additional guidance for communicating and using safety-related component data, aligned with the approach used in VDMA 66413.

What did not fundamentally change?

The central idea remains familiar: define a safety function, establish the required PLr, design the safety-related control system, evaluate the achieved Performance Level, and verify and validate that implementation.

Parameters such as Category, MTTFd, DCavg and CCF continue to be important when evaluating self-developed subsystems.

What changed most visibly is the structure around those calculations: clearer safety-function specification, greater use of the subsystem concept, stronger software and validation treatment, and more explicit lifecycle and management guidance.

Current edition ISO 13849-1:2023 is the fourth edition of Part 1.

It was published in April 2023 and replaced ISO 13849-1:2015 as the current international edition.

The standard applies to safety-related parts of control systems for high-demand and continuous modes, including their subsystems, regardless of technology such as electrical, hydraulic, pneumatic or mechanical.

Key takeaway

ISO 13849-1:2023 retains the Performance Level framework but makes the complete functional-safety lifecycle more explicit. The biggest practical changes are not simply new PL numbers; they concern how safety functions are specified, divided into subsystems, designed, managed, evaluated and validated.

Common Misunderstandings

Common Mistakes When Interpreting ISO 13849

Many functional-safety errors begin when one parameter, one device rating or one calculation result is treated as though it represented the entire safety function.

ISO 13849 is easier to apply when its concepts remain in the correct order: define the safety function, determine PLr, design the contributing subsystems, evaluate the achieved PL, and then verify and validate the implemented function.

The misunderstandings below usually appear when one part of that process is taken out of context.

Misunderstanding

“PL e is the highest level, so every safety function should use PL e.”

PL e is the highest level in the ISO 13849 Performance Level scale, but functional-safety design is not based on selecting the highest possible PL for every application.

The required level is PLr, established for a defined safety function from risk assessment and applicable machine-specific requirements.

Better interpretation

The design objective is for the achieved PL to satisfy the required PLr. Higher performance can be used where appropriate, but PL e should not be assigned automatically.

Misunderstanding

“Category 4 automatically means PL e.”

Category 4 describes a demanding designated architecture and fault behaviour, but Category alone does not establish the achieved Performance Level.

Reliability, diagnostics, common-cause-failure measures and the other applicable ISO 13849 requirements still need to support the claimed result.

Better interpretation

Category 4 can support high Performance Levels, but Category 4 is not another name for PL e. Likewise, Category 3 should not simply be translated into PL d.

Misunderstanding

“If one component is PL e, the complete safety function is PL e.”

A component or validated subsystem can have capability suitable for use in a PL e safety function, but the complete function can contain several contributing subsystems and interfaces.

Input sensing, logic, output control, wiring, software, configuration and other relevant parts can all influence the achieved Performance Level.

Better interpretation

Use the declared safety-related data of each applicable subsystem, then evaluate the complete safety function. The highest-rated component does not set the PL for everything connected to it.

Misunderstanding

“Type 4 means the safety function is PL e.”

IEC 61496 Type 4 describes the capability of electro-sensitive protective equipment for use in applications up to PL e / SIL 3.

It does not establish the Performance Level of the complete machine safety function.

Better interpretation

Type 4 identifies ESPE capability. The achieved PL still depends on the complete safety-related control function.

Misunderstanding

“PFH tells me how many years a machine will operate before an accident.”

PFH is the average frequency of dangerous failure per hour used in functional-safety evaluation.

It is not a countdown to an accident and it is not equivalent to mechanical service life, warranty life or expected replacement interval.

ISO 13849-1:2023 defines PL e as PFH < 1 × 10−7 per hour, but that value remains a probabilistic functional-safety parameter rather than a prediction of when an accident will occur.

Better interpretation

PFH helps quantify dangerous random failure of the safety-related control function. It should not be converted directly into an accident timetable.

Misunderstanding

“If SISTEMA calculates PL d, the machine is certified PL d.”

SISTEMA is an engineering tool for modelling and evaluating safety-related control functions according to ISO 13849.

The result depends on the structure, assumptions and safety-related data entered into the model. The software does not inspect the physical machine or certify the installation.

Better interpretation

A SISTEMA result can provide important engineering evidence, but it does not replace risk assessment, correct implementation, verification or validation.

Misunderstanding

“The whole machine has one PLr.”

PLr belongs to a defined safety function. One machine can contain several hazards and several safety functions, each requiring its own consideration.

Access protection, prevention of unexpected restart, mode selection, stopping functions and other safety functions can have different requirements.

Better interpretation

Determine PLr function by function rather than assigning one universal PLr number to the entire machine.

Misunderstanding

“PL d, SIL 2 and Category 3 are three equivalent labels.”

PL d and SIL 2 have a direct quantitative relationship because both use the PFH interval from 1 × 10−7 to less than 1 × 10−6 per hour.

But ISO 13849 and IEC 62061 remain different functional-safety methodologies. Category is different again: it describes an ISO 13849 architecture and fault-behaviour concept.

Better interpretation

Compare PL and SIL through their quantitative safety-integrity requirements where appropriate. Do not treat Category as a third interchangeable conversion scale.

Misunderstanding

“Once the PL calculation passes, validation is finished.”

A reliability calculation evaluates important quantitative and architectural aspects of the safety-related control function. It does not demonstrate that the real implementation behaves correctly.

Wiring errors, incorrect parameters, software mistakes, unsuitable reset behaviour or interface problems can exist even when the calculation itself is correct.

Better interpretation

Calculation supports the safety argument. Validation uses analysis and testing to confirm that the implemented safety function fulfils its specified requirements.

Misunderstanding

“Because ISO 13849-1:2023 includes validation, ISO 13849-2 is obsolete.”

ISO 13849-1:2023 incorporated revised normative validation requirements into Part 1, but that does not mean Part 2 simply disappeared.

ISO 13849-2:2012 remains a published standard at present, and its fault-evaluation tables continue to provide useful reference material while a revised Part 2 is under development.

Better interpretation

Read the 2023 Part 1 validation requirements together with the current standards status and the relevant fault-evaluation information in Part 2.

A useful test for oversimplification

Be cautious whenever a functional-safety claim is reduced to one device rating, one Category, one PL/SIL conversion or one software calculation. ISO 13849 evaluates a defined safety function through the combined effects of specification, architecture, reliability, diagnostics, fault behaviour, systematic measures, verification and validation.

Frequently Asked Questions

ISO 13849 Performance Level FAQ

Concise answers to common questions about PL, PLr, Category, MTTFd, DCavg, SIL, IEC 61496 Type and SISTEMA.

What does PL mean in ISO 13849?

PL means Performance Level. ISO 13849-1 uses five Performance Levels — PL a, PL b, PL c, PL d and PL e — to express the safety-related performance achieved by a defined control-system safety function.

The achieved PL depends on the applicable architecture, reliability, diagnostic capability, measures against common-cause failures and other requirements of the standard.

What is the difference between PL and PLr?

PLr is the required Performance Level for a defined safety function. It comes from the machinery risk assessment together with applicable machine-specific requirements and standards.

Achieved PL is the Performance Level demonstrated by the designed and evaluated safety-related control function.

The basic design objective is: achieved PL ≥ required PLr.

Is PL e the highest Performance Level?

Yes. PL e is the highest level in the ISO 13849 Performance Level scale.

Under ISO 13849-1:2023, PL e is associated with PFH below 1 × 10−7 per hour. However, that PFH condition does not by itself establish PL e; the complete applicable requirements of ISO 13849 still need to be fulfilled.

PL e should also not be selected automatically simply because a machine appears dangerous. The required PLr must first be established for the relevant safety function.

Does Category 4 always achieve PL e?

No. Category 4 describes architecture and fault behaviour, but Category is only one part of Performance Level evaluation.

Reliability, diagnostic coverage, common-cause-failure measures and the other applicable ISO 13849 requirements must also support the result.

For the same reason, Category 3 should not automatically be interpreted as PL d.

Is PL d equivalent to SIL 2?

PL d and SIL 2 have a particularly direct quantitative relationship because both use the dangerous-failure PFH interval from 1 × 10−7 to less than 1 × 10−6 per hour.

However, ISO 13849 and IEC 62061 remain different functional-safety methodologies. Sharing a PFH range does not make all of their design, architectural, software, verification and validation requirements identical.

It is better to speak of a quantitative PFH correspondence than to treat PL and SIL as universally interchangeable labels.

What does MTTFd mean?

MTTFd means Mean Time To Dangerous Failure. It is a statistical reliability parameter used in the evaluation of dangerous random hardware failure.

It should not be interpreted as guaranteed service life or as a statement that a component will physically operate for a certain number of years before failing.

What does DCavg mean?

DCavg means average Diagnostic Coverage. It describes the effectiveness of diagnostics in detecting dangerous failures in the relevant subsystem.

Diagnostic coverage contributes to the achieved safety performance, but it must be considered together with architecture, reliability and the other applicable ISO 13849 requirements.

Does a Type 4 safety light curtain automatically make a safety function PL e?

No. Under IEC 61496, Type 4 electro-sensitive protective equipment has capability for use in applications up to PL e / SIL 3.

That describes the capability of the protective equipment. The complete safety function can also include logic, outputs, interfaces, wiring, configuration and other safety-related subsystems.

The achieved PL of that complete function therefore still needs to be established separately.

What does SISTEMA calculate?

SISTEMA is an engineering tool provided by IFA to support the evaluation of safety-related machine controls according to ISO 13849.

It can model safety-related control structures and calculate reliability values including the attained Performance Level. Relevant inputs can include PLr, Category, MTTFd, DCavg, CCF and other safety-related data.

SISTEMA does not perform the machinery risk assessment, inspect the physical installation or certify the machine.

Is ISO 13849-1:2023 the current edition, and is ISO 13849-2 still relevant?

Yes. ISO 13849-1:2023 is the current fourth edition of Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design.

The 2023 edition incorporates revised normative validation requirements into Part 1.

That does not mean ISO 13849-2:2012 simply became irrelevant. Part 2 remains published at present, and its fault-evaluation material can still be relevant while a revised edition is under development.

Keep the concepts in the right order

Hazard and risk assessment → define the safety function → determine PLr → design and evaluate the contributing subsystems → establish the achieved PL → verify and validate the implementation.

Primary References

References & Sources

This guide is based primarily on current ISO and IEC standards information and practical resources published by IFA / DGUV.

The summaries in this article are intended to help explain the relationship between Performance Level, PLr, subsystem design, PFH, Category, SIL, ESPE Type, verification and validation.

For machinery design, conformity assessment or formal functional-safety work, the applicable standards and machine-specific requirements should always be consulted directly.

  1. International Organization for Standardization ISO 13849-1:2023 — Safety of machinery — Safety-related parts of control systems — Part 1: General principles for design

    Current fourth edition of ISO 13849-1. It specifies methodology and requirements for the design and integration of safety-related parts of control systems performing safety functions, including their subsystems and safety-related software.

    Official ISO publication →
  2. International Organization for Standardization ISO 13849-2:2012 — Safety of machinery — Safety-related parts of control systems — Part 2: Validation

    Current published edition of Part 2. It addresses validation by analysis and testing of specified safety functions, achieved Category and achieved Performance Level.

    ISO currently indicates that a revised Part 2 is under development.

    Official ISO publication →
  3. International Electrotechnical Commission IEC 62061:2021 + AMD1:2024 + AMD2:2026 — Safety of machinery — Functional safety of safety-related control systems

    Current consolidated IEC publication for machinery functional-safety control systems. It addresses the design, integration, verification and validation of safety-related control systems and uses Safety Integrity Levels.

    Official IEC publication →
  4. International Electrotechnical Commission IEC 61496-1:2020 — Safety of machinery — Electro-sensitive protective equipment — Part 1: General requirements and tests

    Fourth edition of the general IEC 61496 standard for electro-sensitive protective equipment. It specifies general design, construction and testing requirements for non-contact ESPE used as part of safety-related systems.

    Official IEC publication →
  5. International Electrotechnical Commission IEC 61496-2:2020 — Safety of machinery — Electro-sensitive protective equipment — Part 2: Particular requirements for equipment using active opto-electronic protective devices (AOPDs)

    Particular requirements for AOPD-based ESPE, including the sensing technology commonly used in safety light curtains and related optical protective equipment.

    The standard concerns the ESPE and its interface with the machine; it does not prescribe the detection-zone dimensions or safeguarding position for every individual machine application.

    Official IEC publication →
  6. IFA / German Social Accident Insurance SISTEMA — Safety Integrity Software Tool for the Evaluation of Machine Applications

    IFA software and supporting resources for evaluating safety-related machine controls in the context of ISO 13849-1. SISTEMA supports modelling designated architectures and calculating reliability values including the attained Performance Level.

    Official IFA SISTEMA resources →
  7. IFA / German Social Accident Insurance Performance Level Calculator — Practical illustration of EN ISO 13849 relationships

    IFA practical resource illustrating how Category, MTTFd, diagnostic coverage, PFH and Performance Level relate within the designated-architecture methodology.

    Official IFA Performance Level resources →
  8. IFA / German Social Accident Insurance Safety of machine controls to EN ISO 13849 — IFA practical resources

    IFA technical resources covering risk evaluation, safety-related control design, verification, SISTEMA and practical application of EN ISO 13849.

    View IFA practical resources →
Standards status Standards and publication status reviewed in 2026.

ISO 13849-1:2023 remains the current fourth edition of Part 1. ISO 13849-2:2012 remains the current published Part 2 while a revised edition is under development.

IEC 62061 is currently available as the consolidated publication IEC 62061:2021 + AMD1:2024 + AMD2:2026.

IEC 61496-1:2020 and IEC 61496-2:2020 remain the current fourth editions of their respective publications.

Technical references and standards status last reviewed: 2026.