Engineering Cobots for Functional Safety: How Industrial Robotics Companies Are Moving Beyond the Cage

For most of industrial automation’s history, the safety strategy for robots was architectural: put a fence around them. The robot’s workspace and the human workspace were physically separated, and the safety case was relatively clean. When the fence gate opened, the robot stopped. Risk assessment was bounded because the operational envelope was fixed.

Collaborative robots broke that contract deliberately. The value proposition of a cobot — a Universal Robots UR20, a FANUC CRX-25iA, a KUKA LBR iisy — is precisely that it operates without fixed barriers, in proximity to human workers, adapting to dynamic environments. That proposition is compelling enough that cobot adoption has accelerated sharply across discrete manufacturing, assembly, logistics, and healthcare-adjacent applications. The global cobot market is tracking toward $10 billion by the end of the decade, and the payloads being deployed have grown substantially: UR’s UR30 handles 30 kg, FANUC’s CRX-25iA handles 25 kg, and the days of cobots being limited to sub-10 kg pick-and-place tasks are clearly over.

But the physics of collaboration at higher payloads create a direct tension with the biomechanical limits that ISO/TS 15066 defines for allowable contact forces and pressures on different body regions. Engineering a 25 kg payload cobot that is genuinely safe for close human collaboration — not just compliant on paper — requires a fundamentally different systems engineering approach than designing a traditional industrial robot.

What the Standards Actually Require

ISO 10218 parts 1 and 2 establish the baseline safety requirements for industrial robots and their integration. ISO/TS 15066 extends those requirements specifically to collaborative robot systems, defining four collaboration types and the technical conditions under which each is permissible: safety-rated monitored stop, hand guiding, speed and separation monitoring (SSM), and power and force limiting (PFL).

These aren’t alternative compliance paths — they’re operational modes, and a real cobot deployment may transition between them dynamically. A cobot performing an assembly task might operate under SSM when a human enters the monitored zone, shift to a safety-rated monitored stop if the human approaches a specific threshold, and be designed for PFL during the actual handoff. The safety architecture has to handle these transitions correctly, every time, in real operating conditions.

ISO/TS 15066 Annex A provides the biomechanical data that drives PFL design: maximum allowable transient and quasi-static contact forces and pressures for 29 body regions, ranging from 65 N transient force for the skull/forehead to 160 N for the outer thigh. These limits are not conservative estimates with large safety margins — they’re based on pain threshold data, and they apply to the robot system as certified, not to some idealized geometry. A cobot with a compliant end-effector may pass the same contact scenario that a cobot with a rigid tool fails.

This is the first place where systems engineering for cobots diverges sharply from traditional robot safety engineering: the safety requirements are not separable from the application configuration. The robot, the end-effector, the payload, the human posture, and the task geometry are all part of the safety case. You cannot certify the robot in isolation and then declare the integration safe.

Speed and Separation Monitoring: The Sensor Fusion Problem

SSM is the dominant safety strategy for cobots operating in shared workspaces where the human is not in direct contact with the robot. The concept is straightforward: maintain a minimum protective distance between the robot and any detected human, scaling robot speed as a function of that distance. When separation drops below a threshold, trigger a safety-rated monitored stop.

The implementation is considerably less straightforward. SSM requires a real-time estimate of human position and geometry, a reliable model of robot reachable space accounting for current velocity and braking dynamics, and a fusion architecture that integrates these two streams with deterministic latency. The protective distance formula in ISO/TS 15066 accounts for human motion speed, robot speed, stopping time, position measurement uncertainty, and the physical dimensions of both the robot and the human body region being protected.

Every term in that formula is a system-level parameter, not a component-level parameter. Position measurement uncertainty depends on the sensor modality, the environment, occlusion conditions, and the calibration state of the system. Stopping time depends on the current robot configuration, velocity, and load. The safety system has to bound all of these under worst-case operating conditions — and those worst-case conditions in a flexible deployment are harder to bound than in a fixed cell.

Companies like Pilz, SICK, and Rockwell Automation have developed safety-rated vision systems and lidar configurations that support SSM in validated configurations. But the integration work — mapping sensor coverage to robot workspace, validating the latency budget, managing the transition to stop — is fundamentally a systems engineering problem, not a component procurement problem. The risk assessment has to trace from hazard identification through the SSM architecture to the validated residual risk, and that traceability has to survive configuration changes.

Power and Force Limiting: The Controller Architecture Problem

PFL places the safety function inside the robot’s own motion control system. The robot continuously monitors joint torques and contact forces, and if measured values exceed the configured thresholds, it stops. This is what enables the characteristic behavior of cobots like the UR series or KUKA’s LBR: you can push them, redirect them, and they yield.

Implementing PFL at the controller level requires safety-rated hardware and software architecture to IEC 62061 or EN ISO 13849. The safety function — force and torque monitoring with safe stop output — must achieve the required Performance Level (typically PLd or PLe) or Safety Integrity Level (SIL 2 or SIL 3) as determined by the risk assessment. For robot manufacturers, this means dedicated safety processors, independent monitoring channels, and validated software stacks that are maintained separately from the standard motion control firmware.

The challenge at higher payloads is physics. A 25 kg payload at the end of a 1-meter arm creates significant inertial forces during motion. Even with PFL active, the energy transferred in a contact event depends on velocity at the moment of contact. ISO/TS 15066’s biomechanical limits assume the contact is with the human body — not a rigid fixture the human is holding, not a tool the human is wearing, not a body region that is constrained against a hard surface. The gap between the laboratory conditions under which the biomechanical data was gathered and the actual conditions on a manufacturing floor is a legitimate engineering concern, not a theoretical one.

This is why responsible cobot integrators don’t treat PFL certification as a blanket authorization for close collaboration. They treat it as a safety mechanism that is valid within a defined operational context, and they require a full risk assessment for each deployment that establishes what that context actually is.

The Flexible Deployment Problem

The technical safety architecture of a cobot is difficult but tractable. The harder problem — the one that is reshaping systems engineering practice at leading robotics companies — is the combinatorial complexity of flexible deployment.

A traditional industrial robot is installed in a fixed cell. The risk assessment covers one configuration. The V&V test matrix covers one configuration. If the cell is modified, you run a change analysis and update the documentation. The scope is bounded.

A cobot designed for flexible deployment — moved between assembly stations, redeployed from one product line to another, operated with different end-effectors on different shifts — does not have a fixed configuration. The safety case is not for a system; it’s for a family of systems, and the boundaries of that family need to be defined, managed, and enforced.

This creates a requirements management problem that document-based tools handle poorly. If your safety requirements are captured in a Word document or a flat spreadsheet-based RTM, you can manage one configuration. You cannot efficiently manage the conditional structure of requirements that says: “When deployed in Configuration A with End-Effector B and Payload C in a workspace with property D, the SSM protective distance threshold must be at least E, and the following V&V tests must be executed.” That conditional structure, multiplied across realistic deployment variability, produces a requirements space that is effectively unmanageable in static documents.

The teams doing this well are moving toward graph-based requirements models where safety requirements are explicitly parameterized by deployment context, and where the traceability between hazard, requirement, architectural decision, and V&V test is maintained as a live model rather than a static document. This matters not just for initial certification but for ongoing maintenance: when a new end-effector is qualified, or when a software update changes the robot’s stopping time, the impact analysis needs to propagate through the requirements model automatically, not through a manual review of documents.

How Modern Tooling Supports This

The requirements management tools that dominate industrial safety certification — IBM DOORS and DOORS Next, Polarion, Jama Connect — were designed around document-centric or structured text models. They handle traceability between requirements and test cases effectively in stable, fixed configurations. Several of them have introduced import/export integrations with risk assessment formats and some level of variant management. For a single-configuration cobot deployed in a fixed cell, they work.

The tools start to strain when the deployment model is genuinely flexible and the requirements have deep conditional structure tied to deployment context. Variant management in most legacy tools is implemented as document branching or attribute filtering — workable, but it doesn’t naturally represent the relational structure of “this safety threshold is a function of these system parameters.”

Flow Engineering, built specifically for hardware and systems engineering teams, implements a graph-based model where requirements, design decisions, hazards, and verification activities are nodes in a connected structure rather than rows in a table. For cobot functional safety programs, this architecture has a practical advantage: you can represent the conditional safety constraints directly in the model, query the requirement graph for all requirements that are affected by a given parameter change, and maintain traceability coverage across deployment variants without duplicating the entire requirements set for each configuration.

The deliberate focus of Flow Engineering on hardware-native systems engineering means it doesn’t carry the configuration management overhead of a full PLM platform — teams that need tight integration with mechanical CAD or manufacturing BOM structures will need to evaluate how it fits into their broader toolchain. But for the requirements modeling and traceability work that drives a cobot safety certification program, that focused scope is an asset rather than a limitation.

The V&V Implication

Flexible deployment doesn’t just complicate requirements management — it complicates V&V planning fundamentally. A fixed-cell robot has a finite, enumerable test matrix. A cobot with n deployment configurations and m end-effectors doesn’t have a test matrix of n×m — it has a space of deployment contexts that may not be fully enumerated at design time.

The leading approach in practice is a combination of configuration-level type testing and a structured risk assessment framework that defines what additional V&V is required for each new deployment. The type testing establishes the validated envelope of the robot system. The deployment-level risk assessment determines whether a specific deployment is within that envelope or requires additional testing. This is exactly the structure that ISO/TS 15066 implies, but executing it in practice requires that the safety requirements be structured in a way that supports efficient impact analysis — which brings the argument back to requirements tooling.

The Honest Assessment

The industrial robotics companies doing functional safety engineering well for cobots — and there are several, across both robot OEMs and integrators — are treating it as a systems engineering problem first and a compliance problem second. They are building safety architectures that address the actual physics of high-payload close collaboration, structuring their requirements to accommodate deployment flexibility, and investing in V&V frameworks that can scale with the deployment space rather than requiring full re-certification for every configuration change.

The companies doing it poorly are treating PFL certification as a marketing claim rather than a deployment-specific safety boundary, and they are underestimating the requirements complexity that flexible deployment creates. As cobots take on heavier payloads and more demanding applications, the gap between those two approaches is going to become visible in the field — and the regulatory and liability consequences of that gap are not abstract.

The cage kept industrial robots safe for decades. Engineering collaborative robots that are genuinely safe without it is harder, more interesting, and more consequential. The systems engineering process has to be commensurate with that challenge.