The safety installation and wiring guide explains the conventional protective path that must remain intact during any migration. The IO-Link Community overview and Pilz system overview distinguish FS devices, masters and the higher-level safety system.
Wire up a guard door interlock or a light curtain the traditional way and you count conductors: two OSSD signals, 0 V and 24 V, frequently another pair for EDM and reset, sometimes muting and status on top. Each lands on a safety input card. It works, it is well understood, and it has been the shape of machine safety for thirty years. The cost is in the harness — the wiring, the labelling, the fault-finding when something opens a channel and the device simply goes to its safe state without telling you why.
IO-Link Safety is the attempt to fix that without giving up any safety integrity. The idea is simple to state and was hard to standardise: run the safe signals and a diagnostic channel down one IO-Link cable, point-to-point, and still reach the top of the integrity scale. As of 2026 the standard is published, the test specification is out, and the documented systems and product announcements are available. Worth understanding properly before the marketing arrives.
What exactly is IO-Link Safety?
IO-Link Safety is the functional-safety extension of IO-Link — SDCI, the single-drop digital communication interface. The base technology is standardised as IEC 61131-9; the safety layer is standardised worldwide as IEC 61139-2:2022, titled “Industrial networks — Single-drop digital communication interface — Part 2: Functional safety extensions.” That document is the thing to cite. It specifies the extensions to the SDCI of IEC 61131-9 for functional safety, and it is not a single feature but a small stack:
- a standardised OSSDe interface for redundant switching signals;
- a lean functional-safety communication protocol implemented as a “black channel” per IEC 61784-3:2021;
- protocol-management functions for configuration and parameterisation;
- IODD extensions for functional safety; and
- a Device Tool Interface (DTI) for dedicated engineering tools.
The headline number engineers care about: IO-Link Safety supports functional safety up to SIL 3 (per IEC 61508 / IEC 62061) and PL e, Category 4 (per EN ISO 13849-1) — the highest integrity and performance levels a machine safety function normally needs. This is not a watered-down digital convenience layer. It is a full safety transport.
One more property that matters commercially: it is fieldbus-independent and vendor-independent. A safety light curtain from one maker and a safety interlock from another can sit on the same IO-Link Safety infrastructure and interoperate, because the safety behaviour lives in the open standard, not in a proprietary protocol. That is the difference between an open extension and a closed ecosystem.
How is IO-Link Safety different from hardwired safety I/O?
The protocol can reduce device-level wiring and carry diagnostics, but compare the complete FS master, engineering and safety-controller requirements. The achieved integrity is validated for the complete safety function; it is not unchanged merely because a connector fits.
Put the two side by side and the contrast is concrete. A hardwired light curtain gives you two OSSD lines, power, and whatever extra conductors the application needs — and when it trips, all you know is that it tripped. An IO-Link Safety device may communicate richer diagnostic data, depending on its device description. Conventional OSSD devices can also offer auxiliary diagnostics, so compare the actual interfaces rather than assuming hardwired means no information.
What is OSSDe and how does it protect the migration path?
OSSDe denotes equivalent redundant switching signals and is a supported migration mode. It is not the explanation of how every three-wire IO-Link Safety communication link carries safety data. The IO-Link Safety system extensions, port interface and operating modes distinguish switching on pins 4/2 from coded communication. Confirm the exact device and master port's supported mode before wiring.
Why that design choice is smart: it builds on the dual-channel OSSD principle the entire installed base of safety sensors already relies on, rather than inventing a new electrical paradigm. So OSSDe is the bridge. It gives a defined compatibility and migration route from today's OSSD-type light curtains and interlocks toward IO-Link Safety, instead of telling a plant to rip out and replace. Standards that respect the installed base get adopted. Ones that demand a forklift upgrade tend to stall.
Single M12 vs multi-wire — what actually changes on the cable?
The physical layer is deliberately ordinary, and that is the point. IO-Link Safety is a point-to-point protocol — one device per master port — over standard unscreened three- or five-conductor cable with M12 connectors, with a maximum cable length of 20 metres, identical to the standard IO-Link physical layer. Baud rates are the familiar IO-Link set: 4.8 kbit/s (COM1), 38.4 kbit/s (COM2) or 230.4 kbit/s (COM3). No new connector family, no shielding ritual.
The cleverness is in the protocol, not the copper. Because IO-Link Safety is point-to-point rather than a fieldbus, its functional-safety communication protocol is simpler than the safety protocols designed for fieldbus systems — there is no network arbitration to make safe, just one link between a device and a master. The safety layer runs as a black channel over that link per IEC 61784-3:2021, which means the transmission medium itself need not be safety-rated; the protocol catches corruption, loss, delay and misrouting end to end.
One more practical capability: mixed mode. IO-Link Safety can transmit safety-related and standard, non-safety data over the same connection at the same time. A device can stream process or condition data right next to its safe signal, on the same cable, without a second run.
How does device replacement and parameterisation work?
IO-Link uses IODDs for integration, while safety parameterisation requires the approved dedicated device tool described by the IO-Link Community. Data storage may support replacement, but identity, safety parameters and functional acceptance must still be checked using the exact device procedure. A published conformance-test specification is not a certificate for a particular device.
Are there real IO-Link Safety products in 2026?
Yes, and this is the news that makes the topic timely rather than theoretical. Schmersal announced its IO-Link Safety products at SPS 2025, in a press release dated 25 November 2025: the AZM42 solenoid interlock and the RSS362 non-contact RFID safety sensor, with planned market launch toward the end of the first half of 2026. Both integrate via standard three-wire M12 cables and meet PL e (EN ISO 13849-1) and SIL 3 (IEC 61508 / IEC 62061). The AZM42 provides comprehensive real-time diagnostics — supply voltage, temperature, RFID signal quality — while the RSS362 adds intelligent diagnostics and secure bidirectional communication.
Crucially, this is not one vendor going it alone. Pilz, Phoenix Contact, Balluff and Fortress Safety (tGard) are among the other vendors publicly developing or offering IO-Link Safety products. A standard with several suppliers building to it is a standard with a future; a “standard” with one is a product. IO-Link Safety is the former.
Where does DAIDISIKE fit in this?
This article establishes no DAIDISIKE IO-Link Safety-certified SKU. Compare the exact DQC and DX-R1 documents before selecting a conventional output interface; their names do not establish family-wide Type 4 or dual-OSSD capability. OSSDe migration is available only where the particular device and master port document the compatible mode, not merely because an M12 connector fits.
Is IO-Link Safety hype or substance?
It is a published safety communication approach, not an automatic retrofit. Specify it when supported devices, masters, tools and the safety controller meet the application's requirements. Obtain exact certificates, safety manuals and delivery confirmation; retain conventional OSSD protection where that architecture is the validated choice.