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 compatible safety controller. Neither choice alone establishes the achieved PL/SIL. Use the light curtain installation and wiring index for physical integration, then evaluate this page's communication and configuration checks for the selected architecture.
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 relied upon to supply the endpoint protocol's safety integrity. Transport assumptions, timing and configuration nevertheless remain part of the complete system assessment. 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 protocol-specific measures addressing defined communication faults. These measures control residual error probability; they are not a promise of catching every conceivable failure:
- 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 | Slave address and separate connection ID |
| 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; separate Safety Configuration Identifier (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 configuration errors can prevent commissioning. 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 uses a slave address and a separate connection ID; verify both in the supported device/controller configuration.
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 into a compatible safety relay or input module. Commissioning still includes pulse compatibility, fault responses, restart conditions, actuator monitoring where required and total stopping response. A multimeter alone cannot validate short OSSD test pulses or the safety function.
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 compatible safety controller. Available diagnostics depend on the endpoint and data profile: converting two OSSD states does not reveal which beam is blocked. Reset and muting require separately supported and validated logic, not merely a network.
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
A relay can be appropriate when the required function and compatible input/output arrangement fit its documented capabilities. Include the final switching elements and restart prevention in the assessment. Do not call a curtain plus DA31 a complete validated press stop or assume undocumented reset and EDM functions.
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
Confirm the exact light curtain output variant and compatible safety input. For protective laser scanning, ST27 has the confirmed Type 3 / PL d / SIL 2 rating; DLD belongs to ordinary perception. A TCP/IP or serial port is not evidence of native FSoE, PROFIsafe or CIP Safety. Any OSSD-to-network path needs documented safety I/O, controller, protocol configuration and complete-function validation.
Select environmental protection from the actual model evidence, not a generic IP65/IP67/IP69K list. Then record sensor response, safety I/O delay, configured network watchdog, controller cycle and actuator stopping time. Revalidate after replacement, firmware or topology changes.