STATERA Library · Series 07 · Volume 12 · Chapter 04 · EN
Source: https://github.com/Statera-Library/07_Vol_12_Safety_Architecture/blob/main/Chapter_04_ISO_13849_PL/Chapter_04_ISO_13849_PL_EN.md

Volume 12. Safety Architecture

Chapter 04. ISO 13849 (PL)

04.01. PL a to e Determination

Performance Level determination in ISO 13849-1 provides a structured method for defining the required reliability of safety-related parts of control systems used in machinery and robotic equipment. The Performance Level is expressed as PL a, b, c, d, or e, with PL a representing the lowest risk-reduction capability and PL e the highest. The determination process connects risk assessment directly to control-system design and verification.

The first step is to identify each safety function independently rather than assigning one Performance Level to the entire machine. Typical robot safety functions include emergency stopping, protective stopping, prevention of unexpected motion, speed limitation, safe standstill, collision avoidance, and protective-field monitoring. Each function is evaluated according to the hazardous event it is intended to prevent and the consequences that could occur if the function fails.

ISO 13849 commonly determines the required Performance Level, designated PLr, by evaluating three risk parameters: severity of injury, frequency or duration of exposure to the hazard, and possibility of avoiding or limiting the harm. Severity is classified as S1 for slight, normally reversible injury or S2 for serious, normally irreversible injury including death. This parameter establishes the fundamental consequence associated with failure of the safety function.

Exposure is represented by F1 or F2. F1 applies when exposure to the hazardous situation is seldom or relatively short, while F2 represents frequent or continuous exposure or comparatively long exposure periods. For mobile robots, exposure must reflect actual operating interaction rather than theoretical machine availability. A robot repeatedly traveling through areas occupied by workers may therefore require a higher exposure classification than an isolated automated machine.

The possibility of avoiding the hazard is represented by P1 and P2. P1 is applicable when avoidance or significant limitation of harm is possible under specific conditions, whereas P2 applies when avoidance is scarcely possible. Robot velocity, acceleration, available escape space, warning signals, operator awareness, visibility, and the speed at which the hazardous situation develops can influence this judgment. Conservative assessment is important where autonomous motion is difficult to predict.

Combining S, F, and P through the ISO 13849 risk graph produces the required Performance Level PLr. Lower-risk combinations can lead to PLr a or b, while increasing severity, exposure, and difficulty of avoidance progressively drives the requirement toward PLr c, d, or e. PLr is therefore a design requirement derived from risk assessment rather than a rating selected after hardware has already been chosen.

After PLr has been established, the safety-related control system must be designed to achieve a Performance Level equal to or greater than that requirement. The achieved PL depends on more than component reliability. ISO 13849 considers the control architecture or Category, mean time to dangerous failure of components, diagnostic coverage, common-cause failure measures, and systematic aspects of the design. These factors collectively determine whether the implemented safety function provides adequate risk reduction.

PL a generally represents relatively limited risk-reduction capability and is suitable only where the risk assessment supports a low required Performance Level. PL b provides increased reliability but still corresponds to comparatively modest safety integrity. These levels should not be interpreted simply as inexpensive implementation classes. Their acceptability depends on whether the complete safety function satisfies the PLr derived from the identified hazard and operating conditions.

PL c represents an intermediate level of safety performance and normally requires greater resistance to dangerous failures than PL a or PL b. Diagnostic measures and architectural characteristics become increasingly important as the required Performance Level rises. A designer must consider not only whether individual devices are reliable but also whether faults can remain undetected, whether a single failure can defeat the function, and how the system behaves until repair occurs.

PL d is widely relevant to machinery and robotic safety functions where serious injury is possible and substantial risk reduction is required. Achieving PL d commonly demands architectures with meaningful fault tolerance or diagnostic capability, together with appropriate component reliability and common-cause failure control. Safety sensors, logic devices, communication paths, motor drives, brakes, and output switching elements must be considered as parts of one complete safety function.

PL e provides the highest Performance Level defined by the PL framework and corresponds to the greatest risk-reduction capability. Functions requiring PL e demand highly robust architectures, high diagnostic effectiveness, strong resistance to dangerous failures, and rigorous treatment of common-cause and systematic faults. Merely duplicating components does not automatically achieve PL e because redundant channels can still fail together or contain undetected design weaknesses.

The quantitative interpretation of Performance Levels is associated with the average probability of a dangerous failure per hour, PFHd. PL a corresponds to a PFHd range from 10^-5 to less than 10^-4 per hour, PL b from 3×10^-6 to less than 10^-5, PL c from 10^-6 to less than 3×10^-6, PL d from 10^-7 to less than 10^-6, and PL e from 10^-8 to less than 10^-7. Lower PFHd therefore represents greater safety integrity.

The required PL and achieved PL must remain clearly distinguished throughout engineering documentation. PLr originates from risk assessment, while the achieved PL results from analysis of the implemented safety-related control system. A design is acceptable only when the achieved capability satisfies the required level and all applicable architectural, diagnostic, systematic, and validation requirements are fulfilled. Numerical reliability alone cannot substitute for correct safety-function behavior.

For an AMR, the determination should be performed at the safety-function level and coordinated with the broader mobile-robot safety architecture. A protective stop triggered by safety LiDAR, an emergency-stop circuit, safe-speed monitoring, drive torque removal, and prevention of unintended restart may have different PLr values because their hazardous situations differ. This creates a traceable link between hazard analysis, robot operating conditions, safety requirements, and implementation.

A practical AMR assessment must also consider changing environments. Human exposure can increase when the robot moves from restricted industrial corridors into shared workspaces, while avoidance may become more difficult near intersections, blind corners, docking stations, manipulators, or payload-transfer areas. Consequently, the same basic robot platform can require different safety measures depending on its application, operating mode, speed, payload, and human interaction conditions.

The PL determination ultimately establishes a chain of engineering evidence: a hazard creates a safety-function requirement, risk parameters determine PLr, the safety architecture is designed to satisfy that requirement, and calculation plus validation demonstrate the achieved PL. Within the supplied safety architecture, this topic forms the foundation for the following treatment of Categories B through 4, MTTFd, diagnostic coverage, common-cause failures, SISTEMA analysis, and robot safety-function implementation.

04.02. Category B/1/2/3/4

Category B, 1, 2, 3, and 4 in ISO 13849-1 describe architectural requirements for safety-related parts of control systems. They define how a safety function should respond to component faults and how strongly the architecture must resist the loss of that function. Within the supplied safety architecture, this topic follows Performance Level determination and provides the architectural foundation for later evaluation of MTTFd, diagnostic coverage, and common-cause failures.

A Category is not itself equivalent to a Performance Level. Instead, it describes structural characteristics that contribute to the achieved PL together with component reliability, diagnostic coverage, common-cause failure measures, and systematic design considerations. Progressing from Category B toward Category 4 generally introduces stronger fault resistance, monitoring, redundancy, or fault tolerance, but the final PL must still be demonstrated through the complete ISO 13849 assessment.

Category B provides the basic architecture from which the other Categories develop. Safety-related parts of the control system must be designed, constructed, selected, assembled, and combined according to relevant standards and basic safety principles so that they can withstand expected operating influences. The emphasis is on correct engineering practice rather than diagnostics or fault tolerance, and a component failure can result in loss of the safety function.

In a Category B implementation, the safety function may use a straightforward input, logic, and output chain. For example, a safety-related input device may provide a signal to control logic that commands an actuator or removes hazardous motion. The architecture does not inherently require redundancy or continuous fault detection. Consequently, its achievable risk-reduction capability is limited by the reliability of the components and the possibility that a single dangerous failure can defeat the function.

Category 1 builds upon Category B by requiring the use of well-tried components and well-tried safety principles. The architecture can remain essentially single-channel, but reliability is improved through components and engineering practices with established suitability for the intended safety application. The objective is to reduce the probability of dangerous failure rather than to detect every failure after it occurs.

Because Category 1 generally remains dependent on a single functional channel, a dangerous failure can still cause loss of the safety function. Its advantage over Category B therefore comes mainly from improved resistance to failure rather than fault tolerance. Appropriate component selection, conservative electrical and mechanical design, environmental suitability, protective measures, and established safety principles become particularly important when Category 1 is used.

Category 2 introduces periodic testing of the safety function. In addition to the functional safety channel, a test function checks the safety-related system at suitable intervals. The architecture is intended to detect dangerous faults through these checks so that an appropriate response can be initiated. However, faults occurring between tests can remain undetected, and the safety function may be lost during the interval before the next effective test.

The effectiveness of Category 2 therefore depends strongly on the relationship between the testing frequency, demand on the safety function, diagnostic capability, and system response after a fault is detected. Testing must be sufficiently effective to provide meaningful risk reduction. In robotic equipment, startup tests, cyclic diagnostic checks, monitored outputs, or supervisory safety logic may contribute to this concept when implemented according to the applicable architectural requirements.

Category 3 introduces redundancy and partial fault tolerance. Safety-related functions are normally implemented so that a single fault in one part does not lead to loss of the safety function. Some, but not necessarily all, faults must be detected. This represents an important architectural transition because safety no longer depends entirely on one uninterrupted control path, and redundant channels can maintain the required function following certain failures.

A Category 3 system may therefore contain dual-channel inputs, safety logic with redundant processing paths, and redundant output elements controlling hazardous energy. Diagnostic mechanisms compare or monitor relevant behavior to detect faults. Nevertheless, accumulation of undetected faults can eventually lead to loss of the safety function. Category 3 design must therefore carefully evaluate diagnostic coverage, component reliability, fault combinations, and common-cause failure mechanisms.

For an AMR, a Category 3 concept could involve redundant safety-related paths between protective sensing and drive shutdown. A safety LiDAR or emergency-stop input may be processed through suitable safety logic and connected to independent means of removing drive torque. The engineering objective is not simply to duplicate devices but to ensure that a single fault does not eliminate the intended safety action and that sufficient diagnostic capability exists to reveal relevant failures.

Category 4 represents the strongest fault-tolerant architecture among Categories B, 1, 2, 3, and 4. The safety-related system must be designed so that a single fault does not cause loss of the safety function, and the fault should be detected at or before the next demand on the safety function whenever reasonably practicable. When immediate detection is not possible, an accumulation of faults must not result in loss of the safety function.

This requirement makes Category 4 fundamentally dependent on robust redundancy, high diagnostic effectiveness, appropriate fault reaction, and strong control of common-cause failures. Dual-channel architecture alone is insufficient if both channels can fail from the same power disturbance, environmental stress, wiring defect, software design error, or shared component. Independence, diversity where appropriate, diagnostics, separation, and systematic safety measures must therefore be considered together.

The progression from Category B through Category 4 can be understood as an increasing ability to manage faults. Category B relies primarily on basic safety principles, while Category 1 improves reliability through well-tried components and principles. Category 2 adds testing, Category 3 introduces fault tolerance with partial diagnostics, and Category 4 combines fault tolerance with high diagnostic capability and stronger protection against dangerous fault accumulation.

The Category selected for a safety function must be evaluated together with the required Performance Level, rather than selected solely because a higher Category appears safer. ISO 13849 combines architectural Category with the mean time to dangerous failure of each channel, diagnostic coverage, and common-cause failure measures to determine the achievable PL. Different combinations of these parameters can therefore produce different safety performance even when nominally similar architectures are used.

In robot safety engineering, this distinction is particularly important because one machine can contain several safety functions with different architectural requirements. Emergency stopping, protective stopping, safe-speed monitoring, prevention of unexpected restart, manipulator motion inhibition, and drive torque removal should be evaluated individually. Their architectures must correspond to the risk reduction required by their respective PLr and to the consequences of possible faults.

The architectural assessment should cover the complete safety chain rather than only the safety controller. Sensors, switches, safety LiDAR, wiring, communication interfaces, safety PLC or relay logic, motor drives, contactors, brakes, and energy-isolation elements can all contribute to the safety function. A nominally redundant controller cannot compensate for a single downstream element whose dangerous failure defeats both channels or prevents the required safe state.

For AMRs and mobile manipulators, Category selection also interacts with changing operational conditions. Human-shared areas, docking operations, payload transfer, autonomous navigation, manipulator movement, and maintenance modes can create different safety demands. The architecture must therefore be evaluated against actual operating modes and foreseeable faults, while ensuring that diagnostics and fault reactions remain effective throughout the intended machine lifecycle.

Category B, 1, 2, 3, and 4 consequently provide the structural framework for implementing the PLr established during risk assessment. The next engineering step is to quantify how component reliability and diagnostic capability support that architecture through MTTFd, DC, and CCF evaluation. These parameters allow the conceptual fault-resistance properties of each Category to be translated into an achieved Performance Level that can be calculated, documented, and validated.

04.03. MTTFd/DC/CCF Calculation

Mean Time to Dangerous Failure, or MTTFd, Diagnostic Coverage, or DC, and Common Cause Failure, or CCF, are central parameters used by ISO 13849-1 to evaluate the reliability of safety-related parts of control systems. After the required Performance Level and architectural Category have been established, these parameters quantify how reliably the safety function operates, how effectively dangerous faults are detected, and how well redundant channels are protected against simultaneous failure.

MTTFd represents the expected mean operating time before a dangerous failure occurs in a component or functional channel. It does not predict the actual lifetime of a particular device and should not be interpreted as a maintenance interval. Instead, it is a statistical reliability parameter used to estimate the contribution of hardware components to the probability that a safety-related control function will fail dangerously during operation.

For components with an available dangerous failure rate, MTTFd can fundamentally be expressed as the inverse of the dangerous failure rate, MTTFd = 1/λd. When manufacturers provide suitable reliability or safety data, those values should be used according to the applicable assumptions. For electromechanical components whose reliability depends strongly on operating cycles, parameters such as B10d and the number of operations per year are commonly used to derive an equivalent MTTFd.

B10d represents the number of operating cycles at which 10 percent of a population of components can be expected to fail dangerously. For such components, MTTFd can be estimated using the relationship MTTFd = B10d/(0.1 × nop), where nop represents the mean number of operations per year. Determining nop requires realistic information about operating days, operating hours, and the average time between successive operations of the component.

A safety channel usually contains several components rather than one device. Their dangerous failure contributions must therefore be combined when determining the MTTFd of the channel. Conceptually, the reciprocal values are accumulated, so components with relatively low MTTFd can dominate the result. This makes the reliability of switches, relays, contactors, sensors, output devices, and other elements throughout the safety chain important rather than focusing only on the safety controller.

ISO 13849 groups MTTFd into qualitative ranges for Performance Level evaluation. Low MTTFd corresponds to 3 years or more but less than 10 years, medium corresponds to 10 years or more but less than 30 years, and high corresponds to 30 years or more but not greater than 100 years for the purpose of the simplified evaluation. These classifications are used together with Category and DCavg when estimating the achievable Performance Level.

Diagnostic Coverage describes the effectiveness of diagnostics in detecting dangerous failures. In conceptual form, DC is the ratio between the detected dangerous failure rate and the total dangerous failure rate. A high diagnostic capability means that a greater proportion of potentially dangerous faults can be identified before they combine with other conditions or remain latent long enough to compromise the required safety function.

Diagnostic Coverage is not simply the number of diagnostic mechanisms included in a design. Each diagnostic mechanism must be related to the dangerous failure modes that it can actually detect. Examples can include cross-monitoring between redundant channels, discrepancy monitoring, output feedback, plausibility checking, test pulses, watchdogs, communication diagnostics, sensor monitoring, and verification that an actuator reached the commanded safe state.

When a safety-related system contains several components with different diagnostic coverage values, an average diagnostic coverage, DCavg, is determined using their dangerous failure contributions. Consequently, a component with a significant dangerous failure rate and poor diagnostics can reduce the overall diagnostic effectiveness of the subsystem. Diagnostic design should therefore consider the entire input, logic, and output path rather than assigning a diagnostic value only to the central safety PLC.

For simplified ISO 13849 evaluation, DCavg is commonly classified as none when it is below 60 percent, low from 60 percent to below 90 percent, medium from 90 percent to below 99 percent, and high at 99 percent or greater. These classifications interact directly with the selected Category. Category 3, for example, relies on redundancy with fault detection, while Category 4 requires stronger diagnostic behavior and resistance to dangerous fault accumulation.

Common Cause Failure addresses a different problem. Redundant channels can protect a safety function against individual random faults, but redundancy provides little benefit when the same cause disables both channels. CCF therefore evaluates whether sufficient measures have been implemented to prevent or control failures that simultaneously affect multiple safety-related channels and defeat the intended architectural independence.

Typical CCF mechanisms include shared power disturbances, excessive temperature, vibration, moisture, electromagnetic interference, contamination, common wiring damage, installation errors, and other environmental or design dependencies. Two redundant electrical channels routed through the same vulnerable connector, powered from an inadequately protected common source, or exposed to the same damaging condition may therefore possess less independence than their schematic representation suggests.

ISO 13849 uses a structured scoring approach for CCF measures in relevant redundant architectures. Measures address areas such as physical separation, diversity, protection against overvoltage and environmental influences, use of established engineering practices, and analysis of common-cause mechanisms. A sufficient score must be achieved where the CCF evaluation is applicable. The assessment therefore provides engineering evidence that redundancy has meaningful independence rather than merely duplicated components.

MTTFd, DCavg, and CCF should not be treated as three independent calculations performed only for documentation. They interact with the architectural Category to determine whether the safety-related control system can achieve the required PL. MTTFd represents resistance to dangerous random hardware failure, DCavg represents the ability to reveal dangerous faults, and CCF measures protect redundant channels from being defeated simultaneously by a shared cause.

For an AMR safety function, the calculation boundary should cover the complete path responsible for producing the safe reaction. A protective-stop function may include a safety LiDAR, safety communication or wiring, safety logic, drive safety inputs, power switching devices, and torque-removal mechanisms. Reliability and diagnostics should be assigned to the elements actually participating in that function so that the resulting Performance Level represents the complete safety chain.

Consider an emergency-stop function implemented with dual-channel contacts, safety logic, and redundant drive shutdown paths. The electromechanical devices contribute MTTFd according to their dangerous failure characteristics and operating frequency. Channel discrepancy and feedback monitoring contribute to diagnostic coverage, while separation of wiring, suitable power design, environmental protection, and other independence measures contribute to the CCF assessment.

The same calculation philosophy applies to safe-speed monitoring, protective-field monitoring, prevention of unexpected restart, safe standstill, and manipulator motion inhibition. However, each function can have a different component boundary, operating frequency, diagnostic mechanism, and required PLr. Reusing one calculated MTTFd or DCavg value for every robot safety function without checking the actual architecture can therefore produce an incorrect assessment.

Reliable calculation depends heavily on traceable engineering data. Manufacturer safety manuals, component reliability data, B10d values, operating-cycle assumptions, diagnostic descriptions, subsystem architecture, environmental conditions, and fault-reaction behavior should be documented consistently. Where assumptions are required, they should be explicit and conservative enough to support subsequent verification, validation, maintenance, and modification of the robot.

The completed MTTFd, DCavg, and CCF assessment provides the quantitative bridge between the Category architecture and the achieved Performance Level. Together with systematic safety requirements, it allows the designer to demonstrate whether the implemented safety function satisfies its required PLr. Within the supplied structure, these calculations also provide the direct engineering basis for the following SISTEMA analysis and subsequent application of Performance Levels to individual robot safety functions.

04.04. SISTEMA Tool Usage

SISTEMA is a software tool developed by the German Social Accident Insurance Institute for Occupational Safety and Health, IFA, to support evaluation of safety-related parts of control systems according to ISO 13849-1. It assists engineers in modeling safety functions, organizing subsystems, entering reliability parameters, and determining whether an implemented architecture can achieve the required Performance Level, PLr. It therefore converts safety design assumptions into a structured and traceable calculation model.

SISTEMA does not perform the initial machine risk assessment or automatically determine which safety functions are required. Before creating the model, engineers should identify hazards, define individual safety functions, determine the required Performance Level, and establish the intended control architecture. SISTEMA is then used to evaluate whether the safety-related parts implementing each function provide sufficient reliability and diagnostic performance to satisfy the defined PLr.

A SISTEMA project normally represents the safety-related control system as a hierarchy. At the upper level, the project contains one or more safety functions. Each safety function is decomposed into subsystems representing functional sections such as input, logic, and output. These subsystems are then described through channels, blocks, and individual elements as appropriate. This hierarchical structure makes the calculation correspond closely to the physical safety chain implemented in the machine or robot.

For an AMR protective-stop function, the model may begin with a safety LiDAR as the input subsystem, a safety PLC or certified safety controller as the logic subsystem, and drive safety inputs or torque-removal devices as the output subsystem. The complete chain must correspond to the actual implementation. Omitting a relevant contactor, relay, communication interface, or shutdown element can produce a calculated result that does not accurately represent the real safety function.

The required Performance Level, PLr, is assigned to the safety function based on the preceding risk assessment. Each subsystem is then configured according to its applicable Category, such as B, 1, 2, 3, or 4. SISTEMA uses this architectural information together with MTTFd, diagnostic coverage, and common-cause failure information to evaluate the contribution of each subsystem and calculate the achieved Performance Level of the complete safety function.

Component reliability data should preferably come from appropriate manufacturer documentation, safety manuals, validated libraries, or applicable reliability information. For electronic components, dangerous failure rates or manufacturer-provided safety parameters may be available. For electromechanical components such as switches, relays, and contactors, B10d data and operating frequency may be needed. SISTEMA can use these inputs to support calculation of MTTFd for the relevant channels and subsystems.

Operating assumptions must reflect the actual robot application. When B10d-based components are modeled, the expected number of operations depends on operating days per year, operating hours per day, and the average interval between operations. An emergency-stop contactor that is rarely activated and a brake or switching device operated repeatedly during normal robot missions can therefore produce very different reliability results even when their basic component data appear similar.

Diagnostic Coverage, DC, must also be entered according to the diagnostic mechanisms actually implemented. Cross-monitoring, discrepancy detection, feedback contacts, output monitoring, test pulses, watchdogs, plausibility checks, and actuator-state verification can contribute to dangerous-fault detection. The selected DC values should be supported by the architecture and diagnostic behavior rather than chosen merely to obtain a desired Performance Level in the calculation.

SISTEMA evaluates average diagnostic coverage, DCavg, at the subsystem level using the relevant component and failure information. This is particularly important for Category 2, 3, and 4 architectures, where fault detection contributes directly to achievable safety performance. A subsystem containing highly reliable logic but poorly monitored output elements may therefore be limited by the diagnostic characteristics of those output elements rather than by the safety controller itself.

Common Cause Failure, CCF, must be considered when redundant channels are used. SISTEMA provides a structured method for documenting applicable CCF measures and checking whether the required assessment criteria are satisfied. Physical separation, environmental protection, appropriate design practices, protection against electrical disturbances, diversity where applicable, and analysis of common influences help demonstrate that redundant channels are not vulnerable to the same failure mechanism.

Manufacturer component libraries can significantly reduce data-entry effort. Safety-device suppliers may provide SISTEMA-compatible libraries containing reliability parameters for safety relays, safety PLC modules, sensors, contactors, drives, and other products. However, importing a library entry does not prove that the application is correct. The engineer must still confirm that the selected device variant, operating conditions, architecture, diagnostic assumptions, and safety function correspond to the real system.

Subsystem boundaries should be selected carefully because they affect both calculation clarity and engineering traceability. A practical decomposition follows the functional path from hazard detection to achievement of the safe state. For example, an emergency-stop function can be divided into an E-stop input subsystem, safety logic subsystem, and drive shutdown subsystem. Each subsystem can then be traced directly to electrical schematics, device specifications, safety manuals, and validation tests.

SISTEMA continuously evaluates the modeled parameters and provides indications of the achieved PL and related subsystem characteristics. Engineers can therefore identify which part of a safety chain limits the overall result. If the achieved PL is below PLr, the model can reveal whether improvement is needed in component reliability, diagnostic coverage, architecture, or another safety-related parameter. The tool is consequently useful for design iteration as well as final assessment.

Design improvement should follow physical engineering changes rather than numerical manipulation of the model. If an output subsystem limits the achievable PL, possible engineering responses may include selecting components with better dangerous-failure characteristics, improving diagnostics, introducing an appropriate redundant architecture, or modifying the fault reaction. After the physical design changes, the SISTEMA model should be updated so that the calculation remains consistent with the implemented system.

For AMRs, separate SISTEMA safety functions should generally be created for functions such as emergency stopping, protective stopping, safe-speed monitoring, protective-field monitoring, prevention of unexpected restart, and safe drive torque removal. A mobile manipulator may additionally require functions related to manipulator stopping, motion inhibition, or safe interaction. Each function can have a different PLr, architecture, component set, diagnostic strategy, and achieved PL.

Traceability is one of the most important benefits of disciplined SISTEMA usage. Component identifiers in the model should correspond to electrical drawings, bills of materials, safety manuals, and validation documents. Assumptions regarding B10d, operating cycles, MTTFd, DC, CCF, and subsystem architecture should also be recorded. This allows later reviewers to understand why particular values were used and whether modifications to the robot require recalculation.

The calculated result from SISTEMA should not be treated as certification by itself. The software supports quantitative and architectural evaluation, but the actual safety function must still be implemented correctly and validated under representative operating and fault conditions. Wiring, software configuration, parameter settings, communication behavior, stopping performance, diagnostic reactions, reset behavior, and achievement of the defined safe state must correspond to the assumptions represented in the model.

A disciplined workflow therefore connects risk assessment, PLr determination, Category selection, MTTFd, DC and CCF data, SISTEMA modeling, physical implementation, and validation into one continuous engineering process. Within the supplied safety architecture, SISTEMA serves as the practical calculation bridge between the preceding reliability analysis and the following application of Performance Levels to robot safety functions, enabling the achieved PL to be documented in a repeatable and auditable form.

04.05. PL for Robot Safety Function

Performance Level application to robot safety functions converts risk assessment into specific reliability requirements for the safety-related control system. Under ISO 13849-1, PL is not assigned to the robot as a single overall rating. Each safety function is evaluated independently because emergency stopping, protective stopping, safe-speed monitoring, motion inhibition, and torque removal can involve different hazards, architectures, operating conditions, and required levels of risk reduction.

The process begins by defining the safety function precisely. A useful definition identifies the triggering condition, safety-related inputs, control logic, outputs, required safe state, and conditions for restart. For example, a protective-stop function can begin when a person enters a monitored field and end when hazardous robot motion has been stopped and maintained in the defined safe state. Clear boundaries are essential for subsequent PL assessment.

The required Performance Level, PLr, is determined from the risk associated with failure of that individual safety function. Severity of possible injury, frequency or duration of exposure, and possibility of avoiding the hazard are considered according to the applicable ISO 13849 risk assessment method. Functions associated with severe injury, frequent human exposure, or limited opportunity for avoidance generally require stronger risk reduction than functions associated with less hazardous conditions.

Emergency stopping is a fundamental robot safety function intended to enable rapid intervention when a hazardous situation occurs. Its safety chain can include dual-channel emergency-stop devices, safety wiring or communication, safety logic, and drive or power-control elements that bring hazardous motion to the required state. The PL assessment must include the complete chain rather than considering the emergency-stop pushbutton or safety PLC in isolation.

Protective stopping differs from emergency stopping because it is normally initiated automatically by protective equipment rather than by deliberate human action. An AMR may use safety LiDAR protective fields to detect a person or obstacle and command a controlled or immediate safety-related stop. The sensing device, communication path, safety controller, drive safety interface, and final torque-removal mechanism can all contribute to the achieved PL of this function.

Safe-speed monitoring is particularly important when stopping all motion would unnecessarily restrict robot operation. The safety system monitors whether velocity remains below a defined safe limit and initiates an appropriate reaction when that limit is exceeded. Reliable speed information, safety-related evaluation, diagnostics, and the capability to enforce the safe response must be considered together when determining whether the function achieves its PLr.

Protective-field monitoring provides another important function for AMRs and mobile manipulators. Safety scanners can establish warning and protective zones that change according to robot speed, direction, or operating mode. Entering a protective field can trigger speed reduction or stopping. The safety assessment must consider not only the scanner certification but also field configuration, response time, communication, braking performance, and the complete path to the safe state.

Prevention of unexpected restart ensures that a robot does not automatically resume hazardous motion simply because an emergency-stop device is released or a protective field becomes clear. A deliberate reset or restart sequence may be required depending on the application. The reset function must not itself initiate hazardous movement, and the control architecture must ensure that stored commands, communication recovery, or controller reboot cannot bypass the intended safety behavior.

Safe torque removal is commonly implemented through safety functions in motor drives or through suitable external switching architectures. When activated, the function prevents the drive from producing torque capable of causing hazardous motion. The assessment must include the safety input paths, internal or external shutdown architecture, diagnostic mechanisms, and any additional mechanical effects such as gravity, stored energy, or movement that can continue after torque generation is disabled.

Mobile manipulators require coordinated safety functions because hazards can originate from both the mobile platform and the manipulator. Stopping the AMR base while allowing an arm to continue hazardous movement may not produce a safe state. Conversely, some operating modes may permit controlled manipulator motion while the platform remains stationary. Safety functions must therefore define which axes, actuators, and energy sources are controlled for each hazardous condition.

The selected architecture for each function is evaluated using Category B, 1, 2, 3, or 4 together with MTTFd, diagnostic coverage, and common-cause failure measures. A higher Category does not automatically guarantee that the required PL is achieved. Component reliability, fault detection, redundant-channel independence, systematic safety measures, and the behavior of the complete safety chain determine the final result.

SISTEMA can be used to model each robot safety function as a separate calculation structure. Input, logic, and output subsystems are created according to the actual implementation, and their Category, MTTFd, DC, and CCF characteristics are evaluated. The achieved PL is then compared with PLr. This creates a traceable connection from the original hazard and safety requirement through the physical architecture to the quantitative reliability assessment.

Stopping performance must be integrated with the PL assessment because reliable control logic alone cannot guarantee physical risk reduction. Sensor response time, safety communication delay, controller processing, drive reaction time, brake engagement, robot velocity, payload, floor conditions, and mechanical stopping distance influence whether the safe state is reached before a person can encounter the hazard. Safety reliability and physical performance must therefore be validated together.

An AMR can require different safety behavior according to operating mode. Normal autonomous navigation, docking, charging, maintenance, manual control, payload transfer, and recovery from faults can expose people to different hazards. A safety function should therefore specify the modes in which it is active, its parameters in each mode, and how transitions between modes are controlled so that a lower-integrity operating state is not entered unintentionally.

Environmental and application conditions also affect implementation. Dust, moisture, vibration, electromagnetic interference, reflective surfaces, outdoor lighting, temperature, slopes, uneven terrain, and changing payloads can influence sensors, wiring, braking, and actuators. Although PL evaluation focuses on safety-related control-system performance, the assumptions supporting the calculated PL must remain valid throughout the robot\'s intended operating environment and lifecycle.

Validation confirms that the implemented safety function behaves according to its specification and the assumptions used in the PL calculation. Testing should demonstrate triggering of the function, achievement and maintenance of the safe state, diagnostic reactions, behavior under representative faults, reset and restart behavior, and interaction with other safety functions. The physical robot configuration should correspond to the architecture represented in drawings and calculation models.

Traceability connects each safety function to its hazard, PLr, Category, components, calculations, software or parameter configuration, validation results, and achieved PL. This is particularly important when robot hardware or software is modified. Replacing a safety scanner, drive, contactor, brake, or control module can change reliability or diagnostic assumptions and may require the safety function and its Performance Level calculation to be reassessed.

Applying PL to robot safety functions therefore creates a complete engineering chain from hazard identification to validated risk reduction. Each function receives an appropriate PLr, is implemented through a suitable safety architecture, evaluated using Category, MTTFd, DC and CCF, modeled where appropriate with SISTEMA, and validated on the physical robot. This function-oriented approach provides the foundation for systematic ISO 13849 safety engineering of AMRs, mobile manipulators, and other robotic systems.

---

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go