Somewhere on your shop floor there is probably a cobot cell that got a new gripper, a heavier fixture, or a speed bump during a changeover — and nobody re-ran the risk assessment. It’s not negligence, exactly. It’s the natural result of treating “cobot” as a safety category instead of what it actually is: a design approach that has to be verified for each specific application. The robot didn’t stop being collaborative. Your application did.
That distinction is getting harder to ignore as the cobot market pushes into higher payload and higher speed territory. Universal Robots’ UR30, Fanuc’s CRX-30ia, Techman’s higher-payload arms, ABB’s GoFa line stretching upward — these are being marketed, correctly, as cobots. They’re also being bolted into cells with tooling and speeds that a lot of engineers haven’t stopped to actually re-check against ISO/TS 15066. The gap between “it’s a cobot, so it’s safe to run without guarding” and “we validated that this specific configuration meets power-and-force-limiting thresholds” is where the risk lives.
Collaborative Is a Verdict, Not a Feature
ISO/TS 15066 doesn’t certify robots as collaborative. It defines the conditions — biomechanical limits on transferred energy and force at the point of contact, specific to body region — under which a specific human-robot interaction can run without additional safeguarding. Power and force limiting (PFL) is one of four collaborative operation methods in ISO 10218 and ISO/TS 15066, and it’s the one almost everyone means when they say “cobot,” but it’s an application-level pass/fail, not a property stamped on the robot at the factory.
The robot manufacturer gives you a platform capable of operating within PFL limits under certain conditions. What actually determines whether your cell qualifies is the combination of:
- End-effector mass and geometry (a gripper is part of the moving mass, and its shape determines contact area and pinch points)
- Payload mass, because it changes the effective mass at the TCP and the force transferred on contact or clamping
- TCP speed, which drives both transient contact force and quasi-static clamping force calculations
- Whether any part of the tooling or workpiece creates a pinch, shear, or crush point against a fixed structure
- The task itself — what body part could actually be in the danger zone, and for how long
Change any one of those inputs and you have, technically, a new application that needs its own risk assessment. That’s not bureaucratic paranoia. It’s the actual scope boundary of the standard.
Why the 30kg-Class Cobots Are Forcing This Conversation
Earlier-generation cobots — the UR5/UR10 class, the original CRX-10 — made the PFL math relatively forgiving. Low payload, modest speeds, and joint torque limiting meant a lot of applications cleared the biomechanical limits in ISO/TS 15066’s Annex A with room to spare, even with a reasonably chunky end-of-arm tool.
Push payload into the 20-30kg range and raise TCP speeds to stay competitive with small industrial arms doing similar work, and that margin evaporates fast. A heavier payload means more kinetic energy has to be absorbed somewhere if there’s unexpected contact. A faster TCP means the transient contact event — the brief impact before the robot’s force/torque sensing or joint current monitoring can react and stop — can exceed the permissible force or pressure limits for the body region involved, especially at the head, neck, or face, which have much tighter thresholds than a forearm or thigh.
None of that means the UR30 or CRX-30 or a heavily loaded GoFa is unsafe. It means the manufacturer’s PFL capability at the joint level doesn’t automatically transfer into “no guarding needed” once you add your specific gripper, your specific payload, and your specific cycle speed. The robot vendor’s compliance documentation typically covers the bare arm; your integration is what actually gets risk-assessed.
The Quiet Failure Mode: Incremental Change
The riskiest scenario isn’t a green-field deployment — teams doing a new cobot install usually know to check the safety case. It’s the cell that’s been running fine for a couple of years, then goes through an unremarkable-seeming change: a tooling swap for a new part number, a heavier end-effector to handle a bigger SKU, a speed increase pushed through during a throughput project. Each change gets treated as a controls or process tweak, not a safety event, because nobody flagged that it should trigger a fresh look at the risk assessment.
A Practical Re-Check, Not a Full Re-Engineering Project
You don’t need to re-run a full ISO 12100 risk assessment from a blank page every time. You need a trigger-based process that catches the changes that matter. A reasonable set of triggers:
- Payload change of any meaningful magnitude — recalculate transient and quasi-static contact forces at the new effective mass.
- TCP speed increase — even a modest percentage increase can matter more than it looks, because force scales with velocity in the transient-contact biomechanical limit calculations.
- End-effector or fixture redesign — new pinch points, new clamping mechanisms, new rigid edges near the operator zone.
- Any new fixed structure near the robot’s reach envelope — a table edge or fixture corner turns a soft power-limited contact into a crush event.
- Changed task allocation — if an operator now works closer to the robot, or for longer dwell time, the exposure profile changes even if the robot hardware didn’t.
When one of those triggers fires, walk through the actual checklist:
- Recalculate biomechanical contact limits for the specific body regions exposed, using the current payload and speed — not the numbers from the original install.
- Check whether the robot’s inherent PFL response (force/torque sensing, current-based collision detection, speed and separation monitoring if used) still stops fast enough at the new speed to keep transient contact under the Annex A limits.
- Inspect the cell geometry for new or changed pinch, shear, and trap points introduced by the tooling or fixturing.
- Re-confirm task exposure — how close, how often, how long a person is realistically in the collaborative workspace.
- If any limit is exceeded and can’t be brought back in bounds through speed reduction, tooling redesign, or software-limited zones, treat the cell as non-collaborative for that operation and add hard guarding.
When You Actually Need the Guarding
This is the part plants resist, because the whole appeal of a cobot was skipping the light curtain and the fence. But if the recalculated numbers don’t clear the PFL thresholds, reduced safeguarding stops being an option — the standard doesn’t grade on a curve for brand or marketing category. Common outcomes when a cell no longer qualifies as collaborative:
- Area scanners or light curtains at the perimeter, effectively running the cobot as a speed-and-separation-monitoring device rather than a pure PFL system — still collaborative in spirit, but with added safeguarding doing the work the robot’s inherent force limiting can’t.
- Reduced speed and payload in shared-workspace operation, with full speed reserved for a guarded, human-absent state — essentially running two safety-rated operating modes off the same robot.
- Full reclassification as a conventional industrial cell, with fixed guarding and interlocked access, if the throughput requirements make speed and payload reduction impractical. At that point, the “cobot” designation is really just describing the hardware, not the safety architecture — and that’s a legitimate, common outcome, not a failure.
None of these are exotic. They’re standard machine-safety tools that predate cobots by decades. The only real trap is treating the cobot label as a permanent exemption from using them.
Build the Re-Assessment Into Change Management, Not Into Memory
The most effective fix isn’t technical, it’s procedural. Tie payload changes, end-effector swaps, and speed parameter edits in the robot controller to a mandatory safety re-check in whatever change-management or MOC process your plant already runs for process changes. If a control system change to a cobot’s speed or payload settings can happen without a safety sign-off gate, you’ve built a system that will eventually drift out of compliance quietly, one well-intentioned throughput improvement at a time. The 30kg-class cobots aren’t the problem. Treating “collaborative” as a permanent property of the hardware, rather than a conclusion you have to keep re-earning, is.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
