For years, cobot safety documentation and cobot safety reality lived in different buildings. A risk assessment would specify a speed reduction at 1.5 meters and a stop at 0.5 meters, someone would draw a nice zone diagram in the layout package, and then the actual safety logic would boil down to a single safety-rated laser scanner feeding two OSSD channels into a fixed muting zone. It worked, mostly, because most cobot applications didn’t ask the controller to do much. ISO 10218-1:2025, and the -2 update alongside it, close that gap. Speed-and-separation monitoring and power-force limiting are no longer narrative descriptions of intended behavior — they’re parameters that have to live in the safety controller, be traceable to the risk assessment, and hold up to an auditor asking “show me.”
That’s a real shift in where the burden sits. The risk assessment still matters enormously, but it’s no longer the deliverable that proves compliance by itself. The safety PLC program is now direct evidence. If you’re writing ladder or FBD for a Siemens F-CPU, an Allen-Bradley GuardLogix, or a Beckhoff TwinSAFE system, you’re not just implementing an interlock scheme anymore — you’re implementing a documented safety function that has to match, parameter for parameter, what the risk assessment says the robot is allowed to do at each separation distance.
Dynamic zones mean dynamic logic, not a bigger fixed zone
The lazy way to handle speed-and-separation monitoring is to pick the worst-case protective separation distance from ISO/TS 15066’s formula and draw one static zone big enough to cover it at maximum robot speed. That satisfies the math and it’s easy to code — one scanner zone set, one safety-rated input, one speed limit. It also usually kills the throughput case that justified buying a cobot in the first place, which is why almost nobody actually wants this outcome, even though plenty of cells still end up there by default.
The alternative — and what the revised standard’s emphasis on protective separation distance as a function of actual, monitored conditions is really pushing toward — is zone switching keyed to where the operator actually is and how fast the robot is actually moving. That means your safety program has to carry multiple zone sets, switch between them based on validated presence-detection inputs, and re-derive the allowable robot speed dynamically rather than applying one static cap.
Structuring the logic
In practice this looks like a state machine sitting inside the safety task, not a flat chain of interlocks. A reasonable structure:
- Zone state selection — driven by safety-rated presence detection (area scanners, safety-rated vision systems, or a combination) reporting discrete zone occupancy, not continuous coordinates. Most safety vision systems used for this purpose still resolve to zone-in/zone-out logic at the safety layer, even if the underlying sensor is doing more sophisticated 3D detection.
- Speed limit mapping — each validated zone state maps to a specific, pre-calculated maximum robot speed, derived from the ISO/TS 15066 separation-distance formula using the actual approach speeds and reaction times for your specific sensor and stopping performance, not a generic assumption.
- Monotonic transition logic — the safety program should only ever allow speed to step down immediately on zone violation and step up only after a validated dwell time confirms the zone is genuinely clear, not just momentarily unoccluded. This is a common place teams introduce race conditions: a flickering vision signal at a zone boundary can cause speed to hunt up and down, and if your logic isn’t debounced with a safety-rated timer function block, you get a robot that behaves unpredictably at exactly the boundary where a person is most likely to be standing.
- Fallback to safe state — any loss of a valid signal from the presence-detection system (not just a triggered zone) has to force the most restrictive speed or a full protective stop. Undefined sensor states are not “assume clear.”
Each of these has to be a distinct, named safety function in your program — not buried logic inside a machine-state case statement — because auditors and notified bodies increasingly expect to trace each function back to a line item in the risk assessment and forward to a validation test record.
Power-force limiting is a parameter set, not a cobot feature you inherit for free
A lot of integrators still treat power-force limiting as something the cobot arm handles internally, which is only half true. The arm’s built-in torque and force sensing enforces its own limits, but ISO/TS 15066’s biomechanical limits — the transient and quasi-static force and pressure thresholds per body region — are application-specific. They depend on your end effector, the workpiece geometry, and where contact is actually possible in your cell. If your safety program doesn’t independently constrain speed and force based on your actual tooling and the body regions exposed at each zone, you’re relying entirely on the vendor’s default PFL configuration, which was tuned for a generic contact scenario, not yours.
This is where the risk assessment-to-code mapping breaks down most often. Teams complete a thorough biomechanical analysis, get defensible numbers, and then never translate those numbers into distinct parameter sets in the safety controller for different tool/zone combinations. One PFL configuration gets applied cell-wide because it’s simpler to program, and the documentation quietly stops matching the code.
What auditors and notified bodies actually want to see
Paper risk assessments used to be sufficient evidence on their own. Under the current standard, expect scrutiny to focus on:
- Traceability from each risk assessment line item to a specific, named safety function block or rung in the program, not a general claim that “speed monitoring is implemented.”
- Validation test records showing measured stopping distance and response time under real sensor and mechanical conditions, feeding back into the protective separation distance calculation — not just the theoretical formula output.
- Evidence that zone transition logic was tested at boundary conditions, including sensor dropout and rapid occupancy changes, not just steady-state zone occupied/clear cases.
- Version control tying a specific safety program revision to a specific risk assessment revision, since either one changing without the other is the most common finding in re-validation audits.
None of this is exotic functional-safety practice — it’s the same rigor IEC 62061 and ISO 13849-1 have always demanded for safety-related control systems. What’s new is that cobot applications, which used to get a pass because the hardware did the hard part, are now expected to meet that bar explicitly. If your team has been treating cobot safety programming as simpler than a traditional guarded-robot cell, the 2025 revision is the moment that assumption stops holding up in an audit.
The practical takeaway
Budget real engineering time for safety-logic design on cobot cells, not just risk-assessment paperwork and a scanner configuration wizard. The zone-switching state machine, the PFL parameter sets per tool and per zone, and the validation test plan that proves the numbers in your program match the numbers in your risk assessment — that’s now the deliverable. Integrators who build this discipline in now will spend less time re-litigating cell certifications later, when the next audit asks to see the code, not just the drawing.
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.
