Ten years ago the safety architecture conversation on a new line was short. You ran a safety relay or a dedicated safety PLC, hardwired the e-stops and light curtains, and kept that wiring physically and electrically separate from whatever fieldbus was running motion and I/O. Clean, boring, and easy to defend in an audit. That world is gone on any line with real cobot density. Once you’ve got four, six, eight collaborative cells sharing a line, each with speed-and-separation monitoring, dynamic safety zones tied to robot position, and safety-rated soft-axis limits that change with the part program, hardwiring all of that becomes its own liability — a rat’s nest of relay logic that nobody wants to troubleshoot at two in the morning.
So the industry answer has been to put safety on the same wire as motion: FSoE (Fail Safe over EtherCAT) or CIP Safety over the same Profinet or EtherNet/IP backbone that’s already carrying your motion and I/O traffic. This isn’t new technology — both protocols have been around for well over a decade and are mature, TÜV-certified mechanisms. What’s new is the density. When you had one cobot cell on a line, running safety over the shared network was a nice-to-have. When you’ve got a dozen cells daisy-chained or star-wired off the same switches carrying servo cyclic data, the architecture decision actually matters, and getting it wrong shows up as jitter, missed safety reaction times, or a commissioning process that doesn’t scale past the first cell.
The black channel argument, and why it’s not a hand-wave
Both FSoE and CIP Safety rely on what the standards call a “black channel” model. The safety protocol assumes the underlying network — the switches, the cabling, the standard EtherCAT or Profinet stack — is untrusted and can corrupt, delay, duplicate, or drop messages. The safety layer adds its own CRC, sequence numbering, timeout supervision, and cross-checking on top of that, independent of whatever the standard network is doing. That’s the entire point: you get to reuse commercial, non-safety-rated infrastructure because the safety protocol itself carries enough integrity checking to detect the failure modes that infrastructure can introduce.
This is where I’d push back on engineers who treat “it’s black-channel, so the network doesn’t matter” as license to stop thinking about network design. The black channel model guarantees that corruption gets detected and the system goes to a safe state — it does not guarantee your safety function’s reaction time stays within your calculated SIL or PL budget under load. If your switch backplane is saturated with motion cyclic traffic and diagnostic chatter, and your safety telegrams get delayed past their watchdog timeout, the system will fail safe. But “fails safe” on a line with eight cobots cycling in overlapping zones usually means an uncommanded stop cascading across cells, and that’s a production and safety-perception problem even if it’s not, technically, a functional safety violation.
Where network loading actually bites
The practical failure mode isn’t corruption — modern industrial Ethernet is reliable at the physical layer. It’s contention. As you add cobot cells to a shared backbone, you’re adding servo drive cyclic traffic (often at 1 ms or faster update rates for coordinated motion), vision system throughput if any cells have machine vision integrated, and now safety telegrams riding alongside all of it. On EtherCAT this is somewhat self-managing because of the deterministic ring topology and how FSoE frames get tunneled inside the standard process data — but you still need to budget your cycle time with safety telegram overhead included, not bolted on after the fact. On Profinet with CIP Safety-style architectures (or PROFIsafe, which is the more common pairing on Profinet), the concern shifts to switch port loading and how many safety devices are sharing a given network segment, especially where you’re mixing IRT motion traffic classes with best-effort safety and diagnostic traffic on the same infrastructure.
The rule of thumb I’d give a controls engineer sizing this out: calculate your worst-case safety reaction time — network transmission time plus safety logic scan time plus actuator response — under the fully loaded network condition, not the empty one. Then add margin, because cobot lines get I/O and vision added after commissioning far more often than they get removed.
When to segment anyway
Running safety over the shared backbone is the right default for most new cobot line builds now — the tooling, the certified stacks, and the integrator familiarity have all matured enough that it’s no longer the exotic choice. But there are specific situations where segmenting onto a physically or logically separate safety network segment still earns its keep:
- Lines where motion traffic is already running close to backbone capacity, particularly high-axis-count multi-robot cells with vision, and adding safety telegram overhead pushes you into contested territory.
- Retrofit situations where the existing standard network wasn’t designed with switch topology or cable diagnostics in mind, and you don’t have confidence in the physical layer’s actual reliability.
- Mixed-vendor cells where the safety protocol choice is dictated by the robot OEM and doesn’t cleanly interoperate with the PLC platform’s native safety stack, making a dedicated safety island simpler to validate than trying to bridge protocols.
- Regulatory or customer-driven documentation requirements where a physically distinct safety network is easier to defend to an auditor unfamiliar with black-channel architectures, even if it’s not technically required.
None of these are universal. They’re judgment calls, and the judgment should be made by someone who’s actually looked at the network load calculations, not by default institutional caution.
Commissioning changes when cells multiply
The single biggest practical shift as cobot density goes up is that safety commissioning stops being a per-cell checklist and has to become a per-line-topology checklist. Validating one FSoE-enabled cobot cell in isolation tells you almost nothing about what happens when it’s the fifth node on a shared EtherCAT segment with four other safety-rated cells and a bank of servo drives. Reaction time budgets, switch port counts, and network diagnostics need re-validation every time you add a cell to an existing shared backbone — not just a functional check that the new cell’s e-stop works, but a re-verification that the aggregate network load hasn’t pushed anyone’s safety function outside its calculated response window.
Practical checklist items worth adding as cell count grows:
- Document and re-verify worst-case network cycle time and safety telegram latency every time a device is added to a shared safety-over-Ethernet segment, not just at initial commissioning.
- Keep a live topology diagram that shows which safety devices share which switches and ports — this is the first thing to check when a new cell’s safety function behaves unexpectedly under load.
- Maintain independent, protocol-level diagnostics (most FSoE and PROFIsafe-capable PLCs expose telegram loss and retry counters) and actually monitor them, rather than only reacting to hard stops.
- Re-run FMEA on the shared network segment whenever total device count or traffic mix changes meaningfully, not just when the safety logic itself changes.
- Treat vendor interoperability between robot OEM safety stacks and PLC-native safety stacks as a first-class commissioning risk, especially in mixed-vendor lines — protocol compliance on paper doesn’t guarantee clean integration in practice.
The uncomfortable truth is that most plants scaling up cobot deployments are still validating safety architecture the way they did for a single cell, and just adding more cells to the same design without re-checking the assumptions. That works right up until it doesn’t — and on a shared network, the failure doesn’t stay contained to one cell. Get the network loading math right up front, decide segmentation deliberately rather than by habit, and build the re-validation step into every future cell addition. That’s the difference between an architecture that scales and one that just accumulates risk quietly until an audit or an incident forces the conversation.
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.
