P7: Functional Safety in High demand - ISO 13849-1 categories

Last edit: 20/08/2025

Introduction

ISO 13849-1 is intended to be used in the design and evaluation of safety-related parts of the control system (SRP/CS) and only the part of the control system that is safety-related falls under the scope of the standard. It applies to SRP/CS for high demand and continuous modes of operation, including their subsystems, regardless of the type of technology and energy used: electrical, hydraulic, pneumatic, or mechanical. ISO 13849-1 does not apply to low demand mode of operation. That does not mean that Low demand is not possible in Machinery; simply a different standard has to be used, like IEC 61511-1.

The ability of safety-related parts of control systems to perform safety functions under foreseeable conditions is indicated by one of five levels, called performance levels or PL. Annex A of ISO 13849-1 contains a method that can be used for the determination of the PLr of a safety function performed by the SRP/CS. Annex A of IEC 62061 could also be used as an alternative.

The required performance level corresponds to the required risk reduction to be provided by the safety function: the greater the contribution to the risk reduction, the higher the required safety performance. The performance levels of safety functions are defined in terms of Average probability of dangerous failure per hour. There are five performance levels, ranging from providing a low contribution to risk reduction for PL a, to a high contribution to the risk reduction for PL e. The defined ranges of probability of a dangerous failure per hour are shown in Table 1

In order to facilitate the design of an SRP/CS and the assessment of the achieved PL, ISO 13849-1 employs a methodology based on the categorization of architectures, with specific design criteria (MTTFD and DCavg,) and specified behaviour under faults conditions. These architectures are allocated one of five levels termed Categories B, 1, 2, 3 and 4.

The first edition of ISO 13849-1 was the evolution of EN 954-1 and it was still based upon the so called deterministic approach. Despite the approach from Reliability theory was introduced in ISO 13849-1 with the second edition, the so called probabilistic approach, the 5 categories defined by EN 954-1 were kept as basic elements of the standard.

One of the differences between EN 954-1 and ISO 13849-1 is that, in the former, the categories were associated to the entire SRP/CS, while in the latter they are used to represent subsystems. This association is clearly stated in the new 2023 edition. For that reason, it is not correct to require a safety System, for example,  to be Category 3, since a system can be designed with the following subsystems:

  • The input subsystem is a Category 3: for example an interlock with 2 Voltage Free Contacts,
  • The logic is a Safety PLC, usually a Category 4.
  • The output is a Category 1: for example a Single contactor.

In EN 954-1 the Category was the indication of the Reliability level of an SRP/CS. Type C Standards were requiring, for example, an SRP/CS Category 3 or Category 1: that was the common language used. In the new edition of ISO 13849-1, the concept is made clear: the Category is a way to achieve the Performance level of a subsystem. Therefore, it is improper to describe an SRP/CS in terms of a Category: a safety system has a PFH and a Performance Level (or a SIL, if IEC 62061 is used) but, necessarily, no Category (nor Architecture).

Physical and Logical representation of the Architectures

The Categories are therefore important to achieve a specific PL for a subsystem. However, the standard clarifies that they show a logical representation of the subsystem structure, which may differ from its physical one.

[ISO 13849-1] 6.1.3.2 Designated Architectures – Specification of Categories

6.1.3.2.1 General. […] The designated Architectures show a logical representation of the structure of the subsystems for each Category.

NOTE 1: For Categories 3 and 4, not all parts are necessarily physically redundant but there are redundant means of assuring that a single fault cannot lead to the loss of the sub-function. Therefore, the technical realization (for example, the circuit diagram) can differ from the logical representation of the architecture.

Another way to state the same concept is that each one of the 5 Categories of ISO 13849-1 describes the required behaviour of the subsystem with respect to its resistance to faults.

Let’s consider the guard locking mechanism of an interlocking device. The market offers interlocking devices that can reach PL e; they have redundant electrical channels, like two Voltage Free Contacts (VFCs) or 2 Output signal switching device contacts (OSSD), but the Guard Locking Mechanism is a single element. That is not an uncommon solution: the reason is that, in mechanical devices with a single channel Architecture, the detection of faults by the control system may not be possible in certain situations or its cost would be unjustifiable. However, It is important that all probable faults are evaluated by the interlocking device manufacturer and that any dangerous failure mode is either eliminated or proven to be technically improbable. This can be achieved by over-dimensioning critical parts of the device and subsequently testing them. If that is done, the single channel locking mechanism can be used in a redundant Architecture, in our example an interlocking device with guard locking, since it achieves the relevant Category 4 behaviour.

Just to state the concept in a different way, where mechanical faults are proved to be technically improbable, continued performance of the safety function in the presence of a single fault is assumed. Of course, the specific Fault Exclusion can only be justified if the device is used within its manufacturer’s specification.

IEC 61508-2 accepts the use of Fault exclusion.

[IEC 61508-2] 7.4.4.1 General requirements

7.4.4.1.1 With respect to the hardware fault tolerance requirements

  […]

  1. when determining the hardware fault tolerance achieved, certain faults may be excluded, provided that the likelihood of them occurring is very low in relation to the safety integrity requirements of the subsystem. Any such fault exclusions shall be justified and documented (see Note 2).

The steps to be followed

The performance level shall be determined for each subsystem and/or each combination of subsystems that provide a safety function. The PL of the subsystem shall be determined by going through the following aspects:

  • the architecture
  • Decompose the Safety Related Parts of the control system into subsystems (5.1.3)
  • Assign a category to each subsystem;
  • Evaluate if the applicable qualitative requirements of the category are met (table 6.1), including:
  • basic safety principles
  • well-tried safety principles
  • well-tried components
  • Evaluate if the required behaviour under fault conditions is met;
  • The MTTFD value for single components (Annex C and D of ISO 13849-1);
  • The Diagnostic Coverage, limited in any case by the selected Category (Annex E of ISO 13849-1);
  • The CCF has to reach at least 65 points (Annex F of ISO 13849-1);
  • The effect of the safety-related software design on the operation of the hardware (Annex J of ISO 13849-1);
  • The effect of measures against systematic failures (Annex G of ISO 13849-1)

Depending upon the Subsystem Category, only some of the qualitative requirements are applicable. Table 2 shows when the different methodologies used to avoid Systematic Failures and Common Cause Failures shall be used, depending upon the category employed.

When a safety function is designed using one or more subsystems, each subsystem can be designed either using PLs according to ISO 13849-1, or using SILs according to IEC 62061 and or IEC 61508. Subsystems designed according to IEC 61508 series may be used but shall be restricted to those designed for high demand or continuous mode that use Route 1H.

Safety in Collaborative Robotics
There is no “Collaborative Robot”. That is one of the first statements you hear from people working in Collaborative Robotics. The reason is because...