Walk into most plants running mixed human-robot cells and ask to see the safety logic documentation. What you’ll usually get is a laminated e-stop wiring diagram from commissioning, a PLd-rated relay somewhere in a panel, and a safety program that was written after the standard control logic — added on, not designed in. It works. It passed validation. And it will be a genuine headache the first time someone wants to move the cell six feet, swap a light curtain for a safety-rated lidar zone, or bump the cobot from a 3 kg payload to a 12 kg one.
That gap is about to matter a lot more. Payloads and speeds on collaborative robots have climbed steadily, and speed-and-separation monitoring (SSM) using safety-rated cameras and lidar is displacing fixed light curtains and hard-guarded zones as the default way to keep people and robots sharing space safely. That’s a good thing for throughput and floor layout flexibility. It’s also pushing safety logic complexity into territory that most controls engineers who came up on hardwired e-stops and single-function light curtains have never had to program.
The real problem isn’t the hardware, it’s the architecture
Safety-rated PLCs — GuardLogix in the Rockwell world, the F-CPU and TIA Portal Safety environment on the Siemens side, TwinCAT Safety on Beckhoff — all handle dual-channel I/O, cross-monitoring, and discrepancy timing about as well as each other at this point. Cat 3 and Cat 4 architectures with PLd or PLe performance levels are well-trodden ground. That’s not where plants get burned.
Where they get burned is treating the safety program as a fixed artifact tied to one specific cell layout instead of a set of reusable, parameterized safety functions. If your muting logic, your zone definitions, and your SSM distance calculations are hard-coded against one arrangement of guards, sensors, and robot reach, then every layout change — a new fixture, a relocated infeed conveyor, a second cobot added to the cell — forces you back into the safety program to rewire logic that should have been a parameter change.
Design safety zones as data, not as logic
The practitioner move here is to separate zone geometry and speed thresholds from the safety function logic itself. Modern safety PLC environments support this reasonably well: you can build safety function blocks for “monitored zone active,” “reduced-speed zone active,” and “protective stop” as reusable instances, then feed them zone-specific parameters — minimum protective distance, robot maximum speed in that zone, sensor mapping — from a configuration table rather than embedding those values in rung logic or SCL code.
This matters directly for ISO/TS 15066’s protective separation distance calculation. That distance is a function of operator approach speed, robot stopping performance, sensor detection capability, and intrusion distance — and it changes whenever any of those change, including something as simple as a resurfaced floor changing an operator’s walking speed assumption. If your PLd-rated SSM logic recalculates that distance from parameters rather than having it baked into a one-off ladder rung, you can update the cell for a layout change without touching validated logic paths, which is the difference between a documentation update and a re-validation event.
Build the safety program in layers, and know which layer changes
A workable structure looks like three layers:
- The safety I/O and diagnostic layer — dual-channel wiring, discrepancy timing, cross-fault detection for e-stops, guard door switches, and safety-rated sensor inputs. This layer is genuinely stable. It’s tied to physical devices and wiring, and once validated against the required performance level, it shouldn’t need to move.
- The safety function layer — reusable, certified function blocks for muting, zone monitoring, SSM distance checks, and safe robot speed limiting. These should be built once, validated once, and instantiated per zone or per device with parameters, not rewritten per project.
- The configuration layer — the zone geometry, speed thresholds, muting sequence timing, and sensor-to-zone mapping that actually describes your specific cell. This is the layer that should change when the floor layout changes, and it’s the layer you want your validation checklist to focus revalidation effort on.
Most shops don’t draw this line at all, which means a layout tweak forces engineers back into function-block-level logic that’s already gone through fault injection testing and diagnostic coverage analysis — work you do not want to redo casually.
Muting logic is where the corner-cutting happens
Muting — temporarily suspending a safety function to let material pass through a guarded opening, like a conveyor feeding parts into a cell — is consistently the weakest part of safety programs I see referenced in field discussions and technical guidance from safety component manufacturers. It’s tempting to write muting logic as a sequence of timed conditions specific to one conveyor and one part geometry. That’s brittle. A parameterized muting function block that takes sensor sequence, timeout windows, and muting lamp/indicator requirements as configuration inputs, validated once against your safety component supplier’s application guidance, holds up far better when the part changes or a second infeed gets added.
Validating without a full re-certification cycle
You don’t need to re-run a full ISO 10218 / ISO/TS 15066 risk assessment from scratch every time something changes on the floor — but you do need a disciplined way to decide what triggers what level of review. A practical checklist:
- Did the change touch the I/O layer? New sensor, new e-stop, new safety relay — this requires wiring verification, discrepancy timing checks, and diagnostic coverage confirmation against your required performance level (PLd/PLe per ISO 13849-1).
- Did the change touch the function layer? Any edit to a validated safety function block (not just its parameters) means re-running fault injection and functional testing on that block, and updating your safety validation report.
- Did the change stay in the configuration layer? New zone geometry, new speed limit, new part triggering muting — this should be a parameter update plus a re-verification of the protective separation distance calculation and a functional walk-test of the zone, not a full software re-validation.
- Did the risk assessment inputs change? New task, new operator interaction, new tooling on the robot end-effector — this always warrants revisiting the ISO 12100 risk assessment regardless of which logic layer was touched, because the hazard analysis, not the code, is the actual basis for your safety rating.
- Is your documentation traceable? Every parameter in the configuration layer should map back to a line in your risk assessment and your separation distance calculation. If an auditor — or your own safety engineer eighteen months from now — can’t trace a speed threshold back to why it’s that number, you’ve built a maintenance liability, not a safety system.
None of this is exotic engineering. GuardLogix, TIA Portal Safety, and TwinCAT Safety all support function-block reuse and parameterized instances; the constraint has never really been the platform. It’s been the habit of treating functional safety as a compliance checkbox handled at the end of a project instead of a control architecture decision made alongside the mechanical and robot cell design. As cobot cells get faster, heavier, and more dynamic with vision-based zone monitoring, that habit stops being merely inefficient and starts being the thing that makes your safety system harder to trust every time the floor changes around it.
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.
