Functional Safety for Robots: What Safety-Rated Means

Limited reference overview — not technically reviewed. No qualified robotics or safety professional has reviewed this page. It is written from publicly available catalogue records and is published as a starting point for your own reading, not as safety guidance. It contains no clause numbers, no force or pressure limits, no performance levels and no safety integrity levels, and it is not a compliance document. Conformity is determined by a competent assessor working from the standards themselves.

The question functional safety answers

Risk assessment decides what protective measures an application needs. Functional safety decides whether a given implementation of one can be depended upon. Those are different questions, and the second is where a great many well-intentioned robot installations are weakest.

A protective measure that works most of the time is not a protective measure. The discipline exists to put a number on "most of the time" and to require that number to be adequate for the risk.

This page explains the concepts. It is not a compliance document and reproduces no requirements. It specifies no performance level or safety integrity level for any application, because that determination is an output of risk assessment and belongs to a competent engineer. The standard text governs throughout — principally IEC 61508 and ISO 13849 — and where this page and the standards themselves differ, the standards are correct and this page is wrong.

What "safety-rated" means

A safety-rated function is one whose reliability has been engineered and demonstrated to a defined level, not one that merely behaves correctly when tested. Establishing it involves:

A defined safety function. Precisely what must happen, on what trigger, within what time. "The robot stops" is not a safety function; "motion ceases within a specified time of the light curtain being broken, and cannot restart until deliberately reset" approaches one.
A required reliability level, derived from the risk, expressed as a performance level under ISO 13849 or a safety integrity level under IEC 61508.
An architecture that can achieve it, typically involving redundancy so that no single component failure defeats the function.
Diagnostics that detect failures that would otherwise accumulate silently. An undetected failure in a redundant channel means you are running single-channel without knowing.
Quantified reliability data for the components in the chain, end to end from sensing through logic to the final element.
Validation that the implemented function behaves as specified, including on fault injection.

Performance levels and safety integrity levels

Two frameworks address the same concern with different vocabulary. ISO 13849 expresses it as performance levels, lettered from lower to higher required reliability. IEC 61508 and its sector derivatives express it as safety integrity levels, numbered. Machinery work in robotics most commonly uses performance levels; process and instrumented systems more often use safety integrity levels.

What matters conceptually is the same in both: the required level is an output of risk assessment, not a product feature you select. A component rated to a level is capable of being used in a function at that level; it does not confer the level on your application. The rating belongs to the whole chain, including how you wired, configured and validated it.

No specific level is stated on this page for any application, deliberately. That number comes from your assessment.

Why a software stop is not a safety function

This is the single most consequential misunderstanding in the category, and it is worth being blunt about.

Application software that commands the robot to stop is doing something useful, and it is not a safety function. It runs on the same compute, through the same operating system and the same control path as the behaviour that may have caused the problem. If the application has hung, the command never issues. If the network has dropped, it never arrives. If the policy believes everything is fine, it is never sent at all.

A safety function is implemented in a path whose correctness does not depend on the thing it is supervising. In practice that means safety-rated inputs, safety logic independent of the application controller, a final element that removes energy or enforces standstill, and diagnostics covering the chain. Software may request a stop; it may not be the stop.

The same holds for every learned component. A policy cannot be relied on to recognise that it must not act, because the circumstances in which it is most wrong are exactly those in which its self-assessment is also wrong.

Stop categories, briefly

Different situations need different stops, and conflating them causes real problems. Broadly: removing power immediately is the most definitive and the most disruptive, and on a machine that holds a load or maintains balance it can be actively dangerous. A controlled stop that brings motion to a halt and then removes power trades a little time for a safer deceleration. Holding standstill with power maintained allows fast resumption and requires the standstill itself to be monitored to a required reliability.

For a humanoid or any balancing platform the choice is not academic: cutting power to a machine that is standing up produces a falling machine. The appropriate stop is a design decision made during assessment, not a preference.

What this means for a capability layer

For software built to run on robots others manufacture, the implications are concrete and limiting, and that is appropriate:

The safety function belongs to the machine and to the party responsible for operating it. A third-party layer does not implement it and does not overrule it.
The capability layer's obligation is to declare the conditions under which it must not act, and to stop requesting action when they hold.
Those conditions have to travel with the capability. A capability deployed without its envelope is not the same capability.
The machine must be able to refuse an update that would put it outside a validated configuration, which makes version identity a safety-relevant property rather than an operational convenience.
Telemetry must be good enough to reconstruct what happened, because a safety case that cannot be audited after an incident is not much of a safety case.

Questions worth asking

Which safety functions exist, and what level is each one rated to?
Is the safety logic independent of the application controller?
What is the measured stopping performance, including detection and reaction time?
What diagnostic coverage exists, and how is a detected fault surfaced?
Which stop category applies in which situation, and why?
What was validated, by whom, and does a software update invalidate it?

If the answers arrive as a product datasheet rather than as a safety case, that is the answer.

Why redundancy and diagnostics go together

Redundancy alone does not deliver reliability, and this is the point most often missed when people specify a safety function.

Two channels protect against a single failure only while both are working. If one fails and nobody notices, the function is running single-channel and is now exactly as reliable as one component — while appearing, on paper, to be redundant. The failure that eventually matters is the second one, and it arrives against no protection at all.

This is why diagnostic coverage sits alongside redundancy rather than behind it. The system has to test its own channels, compare them, detect disagreement, and surface a detected fault as a fault rather than continuing quietly. A redundant architecture with poor diagnostics accumulates undetected failures until it is not redundant, and the operator has no way of knowing which state it is in.

The practical question to ask of any safety function is therefore not "is it redundant" but "how would you know if half of it had failed, and what happens when it does".

Common mistakes

Treating a rated component as a rated function. The rating belongs to the whole chain — sensing, logic, final element, wiring and configuration — not to the part with the certificate.
Assuming stopping time instead of measuring it. Separation distance depends on it, and the measured figure includes detection and reaction delay, not just mechanical braking.
Letting application software hold a safety responsibility because it happens to work in testing.
Omitting the reset. How a system resumes after a stop is part of the safety function, and an automatic restart into an occupied space is a serious defect.
Not revisiting after a software change. A behaviour change can invalidate the assumptions the assessment rested on.

Sources

ISO — official standards catalogue

Functional safety for robots