| Myth | Reality |
|---|---|
| ISO 13849 certifies an entire robot as “safe.” | ISO 13849 rates individual safety functions (like an e-stop or a safety-rated speed limit), not the robot as a whole. A single robot can have several functions at different Performance Levels. |
| Performance Level e is always the goal. | The required Performance Level is set by a risk assessment of the specific hazard, not by an assumption that higher is always better. Over-engineering a low-risk function wastes cost and complexity. |
| ISO 13849 and ISO 10218 are competing standards. | ISO 10218 (industrial robot safety) explicitly references ISO 13849 to define how reliable the robot’s safety control circuits must be. They work together, not in competition. |
| Meeting a Category number is the same as meeting a Performance Level. | Category (B, 1, 2, 3, 4) describes the control system architecture; Performance Level (a-e) is the resulting reliability figure. You need both the right architecture and the right component reliability data to hit a target PL. |
Why This Standard Confuses Even Experienced Engineers
Ask five robotics engineers to explain ISO 13849 in one sentence and you will likely get five different, slightly wrong answers. Part of the confusion comes from the fact that ISO 13849 does not describe robots directly — it describes the safety-related parts of any machine’s control system, and industrial robotics is just one of many domains that lean on it. The other part of the confusion comes from the sheer number of interlocking concepts: Performance Levels, Categories, diagnostic coverage, mean time to dangerous failure, and common cause failure all have to click together before the standard makes sense.
This piece is a plain-English walkthrough of ISO 13849, written specifically for people building or specifying robots rather than for safety engineers writing certification paperwork. We will cover what a Performance Level actually measures, how the Categories describe circuit architecture, how ISO 13849 interacts with ISO 10218 for industrial robots specifically, and where teams most often trip up when applying it.
What ISO 13849 Actually Regulates
ISO 13849-1, “Safety of machinery — Safety-related parts of control systems,” is a general machinery safety standard that applies wherever a control system is responsible for reducing risk to an acceptable level. That includes emergency stop circuits, light curtains, two-hand control devices, safety-rated speed and separation monitoring, and any other function whose failure could directly lead to injury.
The standard does not ask “is this machine safe?” It asks a narrower, more answerable question for each individual safety function: “how likely is this specific circuit to fail in a way that removes the protection it is supposed to provide?” That likelihood is expressed as a Performance Level, and it is derived from a combination of the control system’s architecture (the Category), the reliability of its components, how much of a failure the system can detect and react to (diagnostic coverage), and how well it resists a single fault taking out multiple redundant channels at once (common cause failure protection).
Performance Levels: A to E, in Plain Terms
A Performance Level (PL) is a discretized measure of the probability that a safety function fails dangerously per hour, ranging from PL a (least reliable, still useful for low-risk functions) to PL e (most reliable, reserved for functions guarding against severe, likely, and hard-to-avoid hazards). The required PL for any given safety function is not chosen arbitrarily; it comes out of a risk graph or equivalent risk assessment that weighs the severity of potential injury, how often people are exposed to the hazard, and how possible it is to avoid the harm once something starts to go wrong.
| Performance Level | Typical risk profile | Example use case |
|---|---|---|
| PL a | Low severity, rare exposure | Non-critical indicator interlock |
| PL b | Low-to-moderate severity | Light-duty Class I robot functions |
| PL c | Moderate severity, occasional exposure | Guard door interlock on a mid-size cell |
| PL d | Serious injury possible, frequent exposure | Standard industrial robot e-stop and safety-rated monitored stop (Class II) |
| PL e | Severe/irreversible injury, high exposure, hard to avoid | Safety functions protecting against high-energy hazards with no fallback |
A practical way to internalize this: PL is not a badge you slap on an entire robot. A single robot cell might have its main e-stop circuit rated at PL d, a light curtain interlock at PL d, and a low-consequence status light circuit at PL b, because each function carries a different level of risk if it fails.
Categories: The Architecture Behind the Number
Where Performance Level answers “how reliable,” Category answers “what does the circuit look like.” ISO 13849-1 defines five architecture categories — B, 1, 2, 3, and 4 — that describe how a safety-related control system is structured to tolerate faults.
| Category | Architecture summary | Fault tolerance |
|---|---|---|
| B | Basic single-channel design using standard components | No specific fault tolerance beyond basic component ratings |
| 1 | Single channel built from well-tried components and principles | Improved reliability through component choice, still single-channel |
| 2 | Single channel with periodic automatic self-checking | Faults are detected at test intervals, not instantly |
| 3 | Dual-channel redundant design | A single fault does not lead to loss of the safety function |
| 4 | Dual-channel redundant design with continuous fault detection | An accumulation of undetected faults will not lead to loss of function |
Category alone does not determine Performance Level. A Category 3 architecture built from poorly rated components can still land at a lower PL than expected, and conversely a well-chosen Category 2 design can sometimes outperform a badly implemented Category 3 one on paper. The final PL calculation folds in component-level Mean Time To Dangerous Failure (MTTFd), Diagnostic Coverage (DCavg), and Common Cause Failure (CCF) scoring, all of which are documented in ISO 13849-1’s annexes and supporting software tools that most safety engineers use rather than calculating by hand.
From Risk Assessment to Performance Level
A risk graph weighs injury severity, exposure frequency, and avoidability to output a required Performance Level. The safety function’s architecture (Category), component reliability (MTTFd), diagnostic coverage, and common cause failure resistance are then combined to calculate the achieved Performance Level, which must meet or exceed the required one.
How ISO 13849 Plugs Into ISO 10218 for Industrial Robots
ISO 10218 is the industrial robot-specific safety standard, split into Part 1 (robot manufacturer requirements) and Part 2 (robot system integration requirements). Rather than reinventing control system reliability math, ISO 10218 leans directly on ISO 13849 to specify how robust a robot’s safety functions need to be. Industrial robots are commonly split into two classes for this purpose: Class I robots, which are limited in payload, speed, or force and carry reduced requirements, and Class II robots, which cover the broader population of general-purpose industrial arms and typically require Performance Level d for critical safety functions such as the protective stop and emergency stop circuits.
This relationship matters practically because it means a robot manufacturer cannot simply claim compliance with ISO 10218 without also demonstrating, function by function, that the safety-related parts of the control system meet the Performance Levels ISO 10218 calls for. The two standards are deliberately layered: ISO 10218 tells you what safety functions a robot needs and what class of robot you are dealing with, while ISO 13849 tells you how to prove those functions are reliable enough.
Where This Differs From the Humanoid-Specific Conversation
It is worth being precise about scope here. This explainer is about the general-purpose functional safety framework that applies to industrial robot arms, mobile platforms, and fixed automation broadly, centered on ISO 13849’s Performance Level and Category mechanics. Bipedal humanoid robots introduce an additional layer of hazard — dynamic balance, fall risk, and human-scale proximity in unstructured environments — that goes beyond what a fixed-base industrial arm has to contend with. Readers specifically interested in how ISO 10218, ISO/TS 15066, and IEC 61508/60204-1 apply to humanoid fall-risk scenarios should see our companion piece, Humanoid Safety Standards: What ISO and IEC Require, which covers that ground in depth. The mechanics of Performance Levels and Categories described here still apply underneath a humanoid’s safety architecture, but the risk assessment inputs look different.
Common Implementation Pitfalls
| Pitfall | Why it happens | Consequence |
|---|---|---|
| Treating Category as the whole answer | Teams assume architecture alone determines PL | Under-documented MTTFd and DCavg data invalidates the claimed PL |
| Ignoring common cause failure | Redundant channels share a power supply or wiring harness | A single event can defeat both channels simultaneously |
| Skipping periodic validation | PL is treated as a one-time certification event | Component wear-out silently degrades the achieved PL over time |
| Applying one PL to an entire robot | Simplification for marketing or documentation convenience | Under-protects genuinely high-risk functions, over-engineers low-risk ones |
Common mistake
Teams sometimes assume that once a system integrator installs a robot with a manufacturer-rated PL d safety function, the entire cell automatically inherits that rating. In reality, once the robot is integrated with additional guarding, sensors, or interlocks at the system level, the achieved Performance Level of the combined cell has to be recalculated for the newly assembled safety chain, not simply assumed from the robot’s own datasheet.
What worked
Teams that avoided rework built a function-by-function safety requirement table early in the design process, listing each safety function, its required Performance Level from the risk assessment, the chosen Category, and the supporting MTTFd and diagnostic coverage data before any hardware was finalized. That table became the single source of truth during certification review, instead of trying to reconstruct the reasoning after the fact.
Why Documentation Discipline Matters as Much as Design
A recurring theme in ISO 13849 audits and third-party certification reviews is that the underlying engineering was often sound, but the paper trail behind it was not. Assessors do not simply take a manufacturer’s word that a safety function achieves PL d; they expect to see the risk assessment that set the requirement, the architecture diagram showing the Category, the component datasheets with MTTFd figures, the diagnostic coverage analysis, and a common cause failure checklist, all tied together into a single technical file. When any one of those pieces is missing or inconsistent with the others, the entire Performance Level claim becomes difficult to defend, even if the actual hardware would have passed testing.
This documentation burden tends to fall hardest on smaller robotics companies and system integrators who are used to iterating quickly on non-safety-related features. A software team accustomed to shipping frequent updates to a navigation stack can find the pace mismatch jarring when the safety-related control functions require a formal change assessment every time a component substitution or firmware revision touches the safety chain. Building a lightweight but rigorous change-control process around safety-related functions specifically, separate from the general engineering change process, tends to resolve this friction without slowing down the rest of the program.
It is also worth noting that ISO 13849 compliance is not a purely internal exercise. Notified bodies, insurers, and customers in regulated industries increasingly expect to see this documentation as part of due diligence before a robot is deployed at scale, particularly in collaborative or shared-workspace applications where the consequences of an undocumented safety gap are more severe. Treating the technical file as a living document that gets updated alongside the hardware, rather than a one-time deliverable produced at the end of a certification push, tends to save considerable rework later in a product’s life.
Practical Steps for Applying ISO 13849
- Run a documented risk assessment for every distinct safety function, not just the robot as a whole.
- Determine the required Performance Level for each function using a risk graph or equivalent method from ISO 13849-1.
- Select a Category architecture (B, 1, 2, 3, or 4) that can plausibly achieve the required PL, then validate it with real component reliability data.
- Calculate MTTFd, diagnostic coverage, and common cause failure resistance for the actual implemented circuit, not a generic reference design.
- Document the achieved Performance Level against the required Performance Level for each function, and keep that record current as components or suppliers change.
- Re-validate after any system integration step that adds new sensors, guarding, or wiring to the safety chain.
Frequently Overlooked Considerations
- Software safety integrityISO 13849-1 includes specific requirements for safety-related software design and validation, which teams sometimes treat as secondary to the hardware architecture.
- Mission time limitsPerformance Level calculations assume a maximum mission time (commonly 20 years); components used beyond that window need re-validation.
- Proof test intervalsCategory 2 and higher architectures with diagnostic self-checking rely on a defined test interval; skipping scheduled tests silently erodes the achieved PL.
- Cross-standard alignmentIEC 62061 offers an alternative functional safety route using Safety Integrity Levels (SIL); mixing PL and SIL language in the same documentation without a clear mapping causes confusion during audits.
- Field modification riskAny field change to wiring, sensors, or firmware on a safety-rated circuit can invalidate the original PL calculation if it is not re-assessed.
Glossary
- Performance Level (PL)
- A discretized rating from a to e describing the probability of dangerous failure per hour for a specific safety-related control function under ISO 13849-1.
- Category
- One of five architecture classifications (B, 1, 2, 3, 4) in ISO 13849-1 describing how a safety-related control system is structured to tolerate faults.
- MTTFd
- Mean Time To Dangerous Failure, a reliability metric for individual components used as an input to the Performance Level calculation.
- Diagnostic Coverage (DCavg)
- A measure of how effectively a control system’s self-checking mechanisms detect faults before they cause a dangerous failure.
- Common Cause Failure (CCF)
- A single event, such as a power surge or shared wiring fault, that could simultaneously defeat multiple redundant channels in a safety system.
Key Takeaways
- ISO 13849 rates individual safety functions on a Performance Level scale from a to e, not the entire robot at once.
- The required Performance Level comes from a documented risk assessment weighing injury severity, exposure frequency, and avoidability.
- Category (B, 1, 2, 3, 4) describes control system architecture; it is one input into the Performance Level calculation, not a substitute for it.
- ISO 10218 relies directly on ISO 13849 to define how reliable an industrial robot’s safety functions must be, commonly requiring PL d for Class II robots.
- Common cause failure protection and diagnostic coverage are as important as redundancy itself, and are frequently underestimated.
- Integrating a robot into a larger cell requires recalculating the achieved Performance Level for the newly combined safety chain.
- Performance Level claims degrade over time without scheduled proof testing and re-validation after field modifications.
FAQs
What does ISO 13849 actually certify?
ISO 13849 does not certify an entire machine or robot as safe. It rates the reliability of individual safety-related control functions, such as an emergency stop or a safety-rated speed limiter, on a Performance Level scale from a to e based on architecture, component reliability, and fault detection.
What is the difference between a Performance Level and a Category?
Category (B, 1, 2, 3, 4) describes the architecture of a safety-related control system, such as whether it is single-channel or redundant. Performance Level (a-e) is the resulting reliability figure calculated from that architecture combined with component data, diagnostic coverage, and common cause failure resistance.
How does ISO 13849 relate to ISO 10218?
ISO 10218 is the industrial robot-specific safety standard and directly references ISO 13849 to define how reliable a robot’s safety functions must be. ISO 10218 sets requirements like which Performance Level a given robot class needs, while ISO 13849 defines how to calculate and validate that Performance Level.
What Performance Level do most industrial robots need?
Class II industrial robots, which cover most general-purpose industrial arms, typically require Performance Level d for critical safety functions such as emergency stop and protective stop circuits. Lighter, slower Class I robots may only require Performance Level b.
Can a single robot have safety functions at different Performance Levels?
Yes. Each safety function is assessed independently based on the specific risk it addresses, so a single robot cell commonly has some functions rated PL d and others rated lower, depending on the severity and likelihood of the hazard each one guards against.
Does adding redundant channels automatically raise the Performance Level?
Not by itself. Redundancy (moving to Category 3 or 4) helps, but the achieved Performance Level also depends on component reliability data, diagnostic coverage, and protection against common cause failure. Poorly implemented redundancy can still fail to reach the target PL.
Why does system integration affect a robot’s safety rating?
When a robot is integrated into a larger cell with additional guarding, sensors, or wiring, the safety chain changes, and the Performance Level achieved by the manufacturer’s robot alone no longer describes the combined system. Integrators must recalculate the achieved PL for the assembled safety function.
How is ISO 13849 different from the humanoid-specific safety standards discussion?
ISO 13849 provides the general Performance Level and Category framework used underneath any robot’s safety architecture, industrial or humanoid. Humanoid-specific guidance layers additional risk considerations, such as dynamic balance and fall risk, on top of this same underlying framework.
References
- Intertek, “Functional Safety for Robotics: ISO 13849 Demystified”
- ISO, “ISO 10218-1:2025(en), Robotics — Safety requirements — Part 1: Industrial robots”
- Omdia, “Functional Safety in Industrial Robots”
- ScienceDirect, “Evolution of safety requirements in industrial robotics: Comparative analysis of ISO 10218-1/2 (2011 vs. 2025) and integration of ISO/TS 15066”
Teams selecting perception hardware that feeds into these safety functions may also want our guide to LiDAR, radar, and camera trade-offs for autonomy, and our broader look at the robotics standards landscape. Middleware teams building the control software behind these safety functions should review ROS 2 in production environments, while fleets pushing safety-relevant firmware updates should read our guide to over-the-air updates without breaking safety cases. Organizations weighing the financial exposure of these safety decisions should also see liability and insurance for autonomous machines.
