A controls engineer wiring a light curtain in 2026 has a choice the previous generation didn’t really have: keep the safe signal on a pair of hardwired OSSD outputs into a safety relay, or carry it as a safety telegram over the machine’s fieldbus into a safety PLC. Both are correct. Both can reach the same Performance Level or SIL. The decision is about diagnostics, distance and scale — and to make it well you need to understand what a safety fieldbus actually is.
The black channel: trust nothing, prove everything
The single idea that makes safety networks possible is the black channel. The principle: treat the entire communication path — the cables, the switches, the standard Ethernet frames, the protocol stack — as untrusted. None of it is part of the safety case, so none of it has to be certified. Instead, the two endpoints that genuinely are safety-rated (the safe device and the safety PLC) add their own protected payload inside the ordinary telegram, and they alone verify it.
That protected payload — sometimes called the safety container — uses a small, well-defined set of measures to catch every way a message can go wrong on the wire:
- A consecutive sequence number / counter — detects lost, repeated, inserted or out-of-order frames.
- A watchdog / timeout — the receiver expects a fresh, valid telegram within a defined window; if it doesn’t arrive, that is a delay or loss fault and it goes to the safe state.
- A CRC over the safe payload — a safety-specific checksum, independent of the network’s own CRC, that catches corruption of the safe data.
- A unique connection / address identifier — binds the telegram to exactly one source-and-destination pair, so a mis-routed or duplicated frame cannot be accepted by the wrong node (a masquerade fault).
IEC 61784-3 is the standard that frames all of this — the “functional safety communication profiles” that sit on top of the underlying fieldbus standards. Because the safety lives in the container and not in the network, safe and standard traffic share the same physical cable. That is the whole trick, and FSoE, PROFIsafe and CIP Safety are three implementations of it.
FSoE, PROFIsafe, CIP Safety — same idea, different host
Once you see the black channel, the three big safety protocols stop looking like rivals and start looking like the same mechanism bolted onto three different networks. The honest summary: you rarely choose the safety protocol for its own merits. You choose it because it matches the PLC, drives and I/O ecosystem the machine is already built on.
| Safety protocol | Host network | Typical ecosystem | Safe binding ID |
|---|---|---|---|
| FSoE Fail Safe / Safety over EtherCAT | EtherCAT | Beckhoff and the wider EtherCAT/ETG world | FSoE Slave Address (per connection) |
| PROFIsafe | PROFINET (and PROFIBUS) | Siemens and the PI / PROFINET world | F-destination address (F_Dest_Add) |
| CIP Safety | EtherNet/IP (and other CIP networks) | Rockwell and the ODVA world | Safety Network Number + connection ID (SCID) |
The middle of each row is identical in spirit — sequence number, watchdog, CRC, unique ID — and all three are certifiable to the same functional-safety targets. So a machine standardised on Siemens runs PROFIsafe over PROFINET; a Beckhoff-based machine runs FSoE over EtherCAT; a Rockwell line runs CIP Safety over EtherNet/IP. Mixing is possible with gateways, but the path of least pain is to follow the controller.
F-addresses, SCIDs and connection IDs: the part that bites
The unique-identifier measure deserves its own section, because it is where most safety-network commissioning goes wrong. Every safe participant must carry an identifier that makes its telegrams un-confusable with anyone else’s.
- PROFIsafe uses the F-destination address (F_Dest_Add), assigned per F-device and matched in the safety program. Each must be unique in its scope.
- CIP Safety uses a Safety Network Number together with configuration signatures (the SCID) and a unique connection identifier to bind a producing device to its consumer.
- FSoE assigns an FSoE Slave Address to each safety connection.
The failure mode they all guard against is the same: a telegram that ends up at the wrong node being silently accepted as valid. Assign these IDs deliberately, keep them unique, and write them down in the machine documentation. A duplicated F-address or a mismatched safety signature is the kind of fault that passes a quick visual check and then stops the whole line at commissioning.
Hardwired OSSD vs network-integrated safety
Now the practical fork. An ESPE device such as a Type 4 safety light curtain produces its result as two OSSD outputs — solid-state, pulse-tested signals on OSSD1 and OSSD2. The pulse testing lets the device detect short circuits between the channels, shorts to 24 V or 0 V, and cross-faults. That dual-channel, tested output is the safety “message” in its simplest form: it is just the voltage on two wires.
In a hardwired architecture those two wires go straight into a safety relay or a safety input module. There is no protocol stack, no address to configure, nothing to commission beyond the wiring and a function test. The reaction path is short and deterministic, and any maintenance technician can troubleshoot it with a multimeter.
In a network-integrated architecture the same logical state is captured by a safety input module and then encapsulated into a FSoE / PROFIsafe / CIP Safety telegram that travels over the bus to a safety PLC. You gain device-level diagnostics, remote reset and mute control, far fewer wires over distance, and trivial expansion to more zones. You pay for it with a safety-network configuration to build and maintain, and a class of communication faults to design against (which the black channel handles, but which still has to be set up correctly).
Worth repeating because it is the most common misconception: neither is inherently safer. Both reach the same Performance Level or SIL when designed correctly. The trade is diagnostics and scale against simplicity and determinism.
When hardwired OSSD + a safety relay is still the right call
For a small, self-contained safety function, a safety relay still wins on engineering grounds. One or two light curtains, a short cable run, a single guarded zone, an e-stop or two — wire the OSSD pair into a safety relay and you have a complete, certifiable stop function with no network to commission and nothing to mis-address. A DAIDISIKE Type 4 OSSD light curtain feeding a DA31 safety relay is exactly this: a clean point-of-operation or access guard for a press, with the relay providing the safe stop and the reset logic.
Move up to a safety PLC and a safety fieldbus when the count and complexity justify the configuration overhead: many safety devices, long distances, several independent zones, muting or blanking logic, or a real operational need to stream device-level diagnostics — which curtain beam is blocked, why a scanner field is muted — back to the line controller and the HMI. Our companion guide, Safety Relay vs Safety PLC, walks the decision in detail.
Where DAIDISIKE ESPE fits
DAIDISIKE Type 2 and Type 4 safety light curtains and DLD-series safety laser scanners output dual-channel OSSD. They are not native FSoE / PROFIsafe / CIP Safety nodes, and that is by design — it keeps them protocol-agnostic. The same curtain or scanner drops onto an EtherCAT, a PROFINET or an EtherNet/IP machine without change, because the network choice lives in the external safety controller, not in the sensor. The OSSD pair wires into a safe input on that controller (or a safety relay), and the controller is what speaks the safety bus to the rest of the line.
For washdown and harsh environments the same logic applies: choose the IP65 / IP67 / IP69K curtain or scanner variant for the mechanics and environment, and let the safety controller decide the network. The hardwired-to-safe-input pattern is the same regardless of whether the cell ultimately reports over FSoE, PROFIsafe or CIP Safety.