Functional Safety for Collaborative Robots (Cobots): What Engineering Teams Need to Know

Functional safety for a collaborative robot means designing safety functions that protect a person sharing the robot’s workspace, without the fixed guarding that keeps people away from a traditional industrial arm. The work splits into three pieces: a hazard analysis of the specific cell, a choice of one or more collaborative methods from ISO/TS 15066, and safety-related control functions designed and verified to ISO 13849 or IEC 62061. Get those three to agree and you have a cobot that can work next to a human safely. Skip the hazard analysis and you have a fence-free robot with no argument for why it’s safe.

That last sentence is where a lot of cobot projects quietly go wrong. The robot ships with a “collaborative” label from the vendor, the team assumes the label covers the application, and nobody verifies that the actual cell, end effector, workpiece, and human task stay inside the limits the label assumes.

Why Cobots Change the Safety Problem

A traditional industrial robot is a fast, heavy, powerful machine kept inside a guarded cell. The safety case is straightforward: keep people out while it runs. Interlocked guarding, light curtains, and area scanners do the work. The robot itself doesn’t have to be gentle, because nobody is supposed to be near it when it moves.

A cobot inverts that. The whole point is to remove the fence so a person and a robot can work side by side, hand off parts, and share a task. There is no barrier doing the protecting anymore. The protection has to live inside the robot’s own behavior: how fast it moves, how close it gets, how hard it can push, and how quickly it can stop.

So the safety function moves from the perimeter to the motion itself. Instead of “detect the person and lock them out,” the question becomes “detect the person and modify the robot’s behavior so contact, if it happens, can’t hurt them.” That is a harder function to specify, and a harder one to verify.

The Four Collaborative Methods from ISO/TS 15066

ISO/TS 15066 is the technical specification that sits under ISO 10218 and defines how collaborative operation actually works. It describes four methods. A real cell often uses more than one, in different phases of the task.

Power and force limiting (PFL) gets the most attention because it’s the method that lets a robot and a person genuinely touch. It works by keeping the transient and quasi-static contact forces below the limits ISO/TS 15066 sets for each region of the human body. The forehead tolerates far less than the upper arm, so the limits are body-region specific, and the cell has to be designed against the most exposed region a contact could reach.

PFL is powerful, and it’s also where teams get overconfident. A force-limited arm with a sharp end effector or a pinch point against a fixture is no longer inside the assumptions that made it collaborative. The method limits the energy of the robot. It says nothing about the gripper you bolted onto the end of it.

How ISO 13849 and IEC 62061 Apply to Cobot Safety Functions

Each collaborative method depends on one or more safety functions: a safe stop, a safe speed, a safe separation distance, a force limit. Those functions are safety-related control functions, and that’s where ISO 13849 and IEC 62061 come in.

ISO 13849 assigns each safety function a required Performance Level (PLr), then verifies the achieved Performance Level through category, MTTFd, diagnostic coverage, and common cause failure. IEC 62061 takes the same kind of function and assigns a SIL using a probabilistic failure model. Both standards are valid for machinery; the choice between them usually comes down to the complexity of the function and the team’s existing practice. (For a deeper comparison of the two, our piece on ISO 13849 versus IEC 61508 covers the relationship.)

The point that matters for cobots: the integrity target is not a property of the robot. It comes from the hazard analysis of the cell. A speed-and-separation function protecting a person from a fast arm in a tight space may need a higher Performance Level than the same function in an open layout where the worst-case contact is mild. The robot vendor can tell you the safety rating its built-in functions achieve. Only your hazard analysis can tell you the rating you actually need.

Why the Hazard Analysis Drives Everything

For a fenced robot, the hazard analysis mostly confirms the guarding keeps people out. For a cobot, it does much more. It decides whether collaborative operation is even appropriate, which of the four methods applies in each phase of the task, and what integrity level each safety function has to reach.

An ISO 12100-compliant HARA for a cobot cell has to account for the full picture: the robot’s reach and speed, the end effector, the workpiece (a part with a sharp edge changes the contact risk entirely), the layout, the human task, and the foreseeable misuse. Two cells with the same robot can land at completely different conclusions because the task and tooling differ.

This is also where the work gets heavy. A cobot cell typically carries several safety functions, each tied back to specific hazards, each needing its own integrity argument. Tracking that web of hazard, mitigation, function, and verification across a project is exactly the kind of work that, industry-wide, eats roughly 60% of safety engineering time as documentation rather than design. When those links live in disconnected spreadsheets, every design change forces a manual reconciliation pass, and that’s where gaps appear.

Designing and Verifying Safe Speed and Safe Force

Two functions deserve specific attention because they’re where collaborative cells are most often validated incorrectly.

Safe speed. Speed-and-separation and hand-guiding both depend on a safety-rated speed limit. Designing it means specifying the monitored speed, the detection of an overspeed condition, and the stop that follows, all to the Performance Level or SIL the hazard analysis requires. Verifying it means two things: confirming the monitoring function reacts within its integrity target, and measuring the robot’s actual speed against the limit during validation. A function that monitors the wrong axis, or reacts too slowly for the separation distance you assumed, fails quietly.

Safe force. Power and force limiting depends on keeping contact force and pressure under the ISO/TS 15066 limits. You verify it by measuring, not by trusting the datasheet. A biomechanical force-and-pressure instrument records the transient and quasi-static values at every point on the robot, end effector, and workpiece where a person could be struck or pinched, and you compare each reading against the limit for that body region. Those measurements become evidence in the safety case, sitting next to the reliability calculation that supports the integrity claim.

Neither verification is a one-time event. Change the gripper, the payload, the speed, or the layout, and the contact conditions change with them. The function has to be re-verified, and the safety argument updated to match.

How ASAP Supports Cobot Safety Work

A platform built for the full safety lifecycle should make this web of decisions hold together instead of scattering it across files. ASAP ships pre-configured project templates for collaborative robots, so a cobot cell starts from a structure that already reflects the methods, functions, and standards above rather than a blank page.

From there, the live, ISO 12100-compliant HARA links each hazard to its mitigation and to the safety function that controls it. The reliability modeling carries those functions through their Performance Level or SIL calculations, the kind of work teams used to do in a desktop calculator disconnected from everything else. And the full V-Model traceability keeps the chain intact: when the gripper changes and the force verification has to be redone, the affected hazards, functions, and documentation are already linked, so the update is a traceable revision instead of a manual hunt across spreadsheets.

That structure is the same methodology proven inside Amazon Robotics, where ASAP supports the safety lifecycle across a fleet of more than a million robots. Collaborative cells are one of the harder problems in that fleet, because the protection lives in the robot’s behavior rather than a fence. Getting them right at scale is exactly what the platform was built to do. Safety designed in this way stops being the slow step before launch and becomes part of how the cell gets built in the first place, which is the real advantage: a collaborative robot you can deploy with confidence, faster, because the argument for its safety was assembled alongside it.