For most of the last decade, “cobot” meant something specific in the risk assessment: a light arm, a light payload, and a power-and-force-limiting (PFL) safety case that let you skip the fence. That assumption is getting old fast. Universal Robots’ UR20 and UR15, Fanuc’s CRX-20iA and CRX-25iA, and Techman’s higher-payload lines have pushed collaborative robots into a payload and reach class that used to belong exclusively to guarded industrial arms. The marketing still says “collaborative.” The physics increasingly disagrees.
This matters right now because a lot of plants are hitting layout refresh cycles at the exact moment these bigger arms have become the default recommendation from integrators and OEMs. The old cell was validated against a 5 kg or 10 kg payload cobot. The new quote is for a 20 kg arm with more reach, because it’s faster, it’s more capable, and frankly it’s what’s on the showroom floor now. The mistake is assuming the safety case travels with it.
The assumption that quietly broke
ISO/TS 15066 power-and-force limiting was never a blanket exemption for “robots labeled collaborative.” It’s a biomechanical limit — contact force and pressure thresholds tied to specific body regions, verified for a specific robot, at a specific speed, carrying a specific end-effector and payload. The PFL compliance built into a UR5e or a CRX-10iA at rated speed and light tooling does not automatically extend to a UR20 moving a 15 kg fixture at the same nominal “collaborative” speed setting. Mass and velocity both go into the transient and quasi-static contact force calculations. Turn up either one and you can blow past the ISO/TS 15066 biomechanical limits even while the robot vendor’s control system is technically still running in a “collaborative” mode.
The second thing that changes with payload-class inflation is reach. A UR20’s working envelope is meaningfully larger than a UR5e’s. That changes where the effective danger zone sits relative to fixed structures, adjacent stations, and human walkways — which means the speed and separation monitoring (SSM) zones you laid out years ago, if you used SSM at all, are probably wrong for the new arm even if nothing else in the cell moved.
Three things to re-check before you assume a drop-in fit
1. End-effector and payload mass budget
Every PFL validation is only as good as the total moving mass it was tested against — robot arm plus gripper plus part plus any tooling. When plants upgrade robot class, it’s common to also upgrade the end-effector to take advantage of the extra payload capacity: a bigger gripper, a heavier tool changer, a part that used to require two stations now handled in one. Each of those additions eats into the same force budget the original risk assessment assumed. Re-run the numbers with the actual as-built tooling mass, not the robot’s rated payload spec. The rated payload is a ceiling for the robot’s structure and motors, not a green light for the safety case.
2. Speed and separation monitoring zones
If your original layout relied on SSM — using safety-rated scanners, light curtains, or vision systems to slow or stop the robot as a person approaches — the zone geometry was almost certainly modeled against a specific reach envelope and stopping distance. A longer-reach arm needs a bigger protective zone, and a higher-payload arm generally has a longer stopping distance at a given speed because of inertia. If you haven’t recalculated stopping distance and re-drawn the warning and protective zones for the new arm’s mass and reach, the sensor field you installed years ago may no longer cover the actual hazard zone. This is the kind of gap that doesn’t show up until an incident investigation, because the robot is still doing exactly what its controller says it’s doing.
3. Task-based contact scenarios, not just the robot spec sheet
ISO/TS 15066 wants you to assess actual contact scenarios — transient contact to a forearm, quasi-static contact to a hand pinched against a fixture — not just confirm the robot can run in a “reduced” mode. A heavier arm carrying a bigger part changes which contact scenarios are even physically possible in your cell. A pinch point that was survivable with a 3 kg gripper on a light cobot may not be survivable with a 12 kg gripper and part combination on a 20 kg-class arm, even at identical joint speeds. This is exactly the kind of thing that gets missed when a re-tooling project treats the robot swap as a mechanical integration problem instead of a full safety re-validation.
When the honest answer is “this needs a fence”
Here’s the position I’ll take plainly: a meaningful share of the “cobot” applications going in right now with UR20/UR15, CRX-20/25iA-class, and comparable higher-payload arms are not actually collaborative applications anymore. They’re guarded industrial robot cells that happen to use a robot with collaborative-capable hardware. That’s not a failure — it’s a legitimate design choice, and these arms are genuinely good machines for it. But it means the safety architecture needs to match the reality: perimeter guarding, safety-rated interlocks, and a risk assessment that doesn’t lean on PFL as the primary protective measure because the numbers don’t support it at the mass and speed the application actually needs to run.
The tell is usually in the tuning. If your integrator has to run the “collaborative” robot at a fraction of its rated speed and payload just to keep contact forces under ISO/TS 15066 limits, you’ve bought a fenced-application robot at a collaborative-application price, and you’re leaving throughput on the table for a safety case that’s marginal at best. In that scenario, adding guarding and running the arm at real speed is usually the more honest engineering answer, and often the more productive one.
What this means for your next layout refresh
Treat every payload-class or model upgrade as a new risk assessment, not a parts swap. Re-verify the vendor’s PFL certification actually covers your as-built payload and tooling mass — most vendors publish force/pressure data across a range of configurations, and it’s worth checking where your application actually lands on that curve rather than assuming compliance because the model name says “cobot.” Re-draw SSM zones from stopping-distance calculations done with the new arm’s actual mass and speed, not carried over from the old layout. And be willing to conclude, when the numbers say so, that the application has graduated out of collaborative territory entirely. A well-guarded cell with a fast robot beats a slow, marginal “collaborative” cell that’s collaborative in name only.
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.
