Content updated: 2026-09-06.
This is a technology and procurement review, not a report of a DAIDISIKE customer deployment. The relevant changes are published protocol capabilities and identifiable commercial product families; no unverified adoption share, price saving or DQA-to-database integration is claimed. For underlying sensor selection, use the DAIDISIKE safety light curtain range, then return here for communication and diagnostic questions.
The shift, in one sentence
The specification now has two data questions: what must safely stop the machine, and what helps maintain it? Safety curtains have long contained internal evaluation and self-checking; they were not simply passive sensors. Some current products additionally expose diagnostics or support an approved safety communication interface.
The architecture may use a safety relay, safety controller or other approved evaluation; a discrete relay is not universally mandatory. The buyer's task is to preserve the required safety function while choosing a supportable information path, not to replace a proven interface merely because it is wired.
1. OPC-UA over TSN: real, but uneven
The OPC Foundation publishes OPC 10000-15, OPC UA Safety. Its profile information describes Client/Server or PubSub operation with or without TSN. TSN and safety are therefore not interchangeable labels: deterministic transport alone does not supply the safety layer.
A useful dated milestone is the Foundation's December 2025 certification announcement for its Client/Server Safety compliance test tool. That is toolchain evidence, not a claim that every controller brand or light curtain is shipping an interoperable OPC UA Safety interface.
For a purchase, request the actual endpoint versions, supported safety functions, connection roles, safety manual, conformance evidence and system response calculation. A generic OPC UA server that publishes diagnostic status cannot be used as the protective-stop signal. Existing approved safety buses are not made obsolete by the availability of another specification.
2. IO-Link Safety: less hype, more practical
Approved FS device → compatible IO-Link Safety FS master → specified safety evaluation → validated final elements
Supported diagnostic data → authorized maintenance interface → HMI / historian / maintenance system
Functional relationship only, not an installation drawing. An ordinary master or diagnostic gateway does not become safety-rated by sharing a cable or network.
IO-Link Safety is a point-to-point field-device interface using compatible FS devices and FS masters. A master can serve multiple ports, but that is not permission to bus several devices together on one sensor port or to use any ordinary IO-Link master. The IO-Link Safety architecture and OSSDe migration guide separates switching mode, safety communication and ordinary diagnostic data when reviewing an existing device-to-master connection.
A concrete manufacturer example is Pilz's IO-Link Safety system, which identifies the PDP 67 IOLS master and PSENopt II Advanced IOLS light curtains, together with cables and configuration tools. Its description uses a three-core standard cable, not this article's former universal four-wire assumption. Apply the exact product's connection requirements.
The commercial question is whether the approved field arrangement simplifies this particular machine's cabling and maintenance. Automatic parameter restoration or replacement requires the supported toolchain, device identity and validated settings; it must not be assumed to make a replacement immediately safe to run. Compare installation work and commissioning evidence on the actual design, not an invented wire-count or competitor setup-time saving.
3. On-device edge diagnostics: predictive maintenance arrives in safety
On-device diagnostics can make fault finding and condition monitoring more useful, but the available fields and retained history are product-specific. A live signal-strength value, an event counter and a long-term historian are three different capabilities.
- Optical status: ask whether the device exposes per-beam data, overall reception margin or only a contamination warning; record units and the manual's interpretation.
- Alignment: establish whether an alignment indicator is available remotely and whether the history is stored in the sensor or elsewhere. A trend is not a validated universal cleaning threshold.
- Switching and operation counters: useful context if supported, but a solid-state OSSD is not an electromechanical relay with a universal switching-life budget.
- Temperature and fault events: confirm availability, timestamps, update rate and retention; do not assume a standard 30–90 day log or a common self-test interval.
- Maintenance action: assign who reviews the information and what procedure follows. Diagnostics do not replace required periodic tests or authorize suppressing a trip.
A historian or maintenance-system integration needs an actual data model, supported interface and tested mapping. No native IBM Maximo, SAP, Fiix or Limble connector is asserted here. Treat predictive value as something to validate with operating data, not an automatic benefit of the word “edge”.
4. What this means for the buyer in 2026
The standard list of buyer questions for a safety light curtain (resolution, range, response time, IP rating, PL/SIL rating) hasn't gone away. But there are now additional questions that really should be on the spec sheet:
| Question | What a good answer sounds like |
|---|---|
| Which path is safety-related? | Identify approved safety outputs/communication separately from ordinary diagnostic data. |
| What telemetry is actually available? | Provide the exact register/data dictionary, units, update rate and history location. |
| How are updates and replacements controlled? | Identify supported versions, configuration checks, authorization and revalidation. |
| What is the worst-case safety response? | Provide the complete calculation, timeout/fault reaction and applicable operating limits. |
| Which safety data apply? | Provide required reliability and systematic-capability evidence; do not ask for a made-up MTTFd per protocol hop. |
| How is access secured? | Document threat assessment, access/update paths, network controls and recovery. |
| Which master/controller combinations are supported? | Name exact models, versions, interface profiles and acceptance evidence. |
“AI-powered” is not an acceptance criterion. Ask what the algorithm does, which decisions remain outside the safety function, and what evidence supports its claimed maintenance benefit. See AI in safety sensors: diagnostic use versus safety-function claims for that separate decision.
5. The pitfalls — what to watch out for
The following are design-review risks, not reported customer incidents:
Using diagnostic latency as safety timing. If the safety function actually uses approved network communication, include its specified worst-case response and timeout behaviour with sensor, logic, final-element and machine stopping performance. If the network is diagnostic only, its dashboard delay is not a new stop-path term. The introductory ISO 13855:2010 distance worksheet covers only its stated legacy approach case, not the full 2024 assessment; no universal 1–3 ms hop or 350 mm installation is assumed.
Assuming protocol-name compatibility. Confirm the supported profile, version, data definition, safety parameters and approved combination. Test normal, stale-data, communication-loss and recovery behaviour under a controlled acceptance plan. A successful live data display does not validate the safety connection.
Separating safety and security incorrectly. A black-channel safety protocol does not remove cybersecurity responsibilities. Conversely, safety traffic need not universally use a physically separate network: the architecture must follow the actual risk/threat assessment, endpoint requirements and controlled access/update design. Use the machine-safety cybersecurity guide for those questions.
Collecting data without an action process. Before paying for a diagnostic option, name the consumer, supported data path, alarm owner and maintenance response. Condition monitoring must complement—not weaken—the specified inspection and safety-test programme.
6. Where DAIDISIKE sits in this picture
The available DQA catalogue does not substantiate the former blanket Type 4 / PL e / SIL 3, dual-OSSD, Modbus-history or OPC UA integration claims. No DAIDISIKE IO-Link Safety/OPC UA Safety release date, sample availability or future firmware upgrade is promised here. Request the exact model's current documentation.
Three decisions for an existing or proposed installation:
- Keep a documented wired safety function: where the exact approved devices and validation meet the machine's needs, lack of a network interface is not a defect.
- Add diagnostics only: use an explicitly supported auxiliary output or diagnostic channel. A candidate DA31 module is not assumed to be an IO-Link Safety master, gateway or universally compatible evaluator.
- Require networked safety: specify the actual approved sensor/master/controller chain and evidence. Do not substitute DQA, change brackets or transfer a competitor's safety case without a full replacement review.
Send the required safety function, exact interface and diagnostic data needs to DAIDISIKE engineering. If those capabilities are not documented for a candidate, keep it out of the approved design until the evidence exists.
7. Looking ahead to 2027
These are questions to watch, not dated market forecasts or a product roadmap:
Interoperability evidence: look for supported endpoint combinations, conformance tools and practical maintenance support, not a claim that one protocol will become every plant's default.
Usable diagnostics: assess whether manufacturers publish stable data definitions and controlled replacement/configuration procedures that your maintenance systems can consume.
Wireless boundaries: optical synchronisation and radio safety communication are different. ODVA documents CIP Safety's black-channel use over wireless media; therefore “wireless safety is not certified until 2028” is not correct. This does not approve any particular wireless light curtain: use exact endpoint evidence, worst-case timing and application validation.
The bottom line
Specify the safety function first, then the information needed to maintain it. A familiar wired device can remain appropriate; a connected device must demonstrate its actual benefits and supported safety architecture. Neither a protocol name nor a maintenance dashboard is a certificate.
Separate actual product capabilities from roadmap promises, preserve controlled configuration and verify whole-function response before release. The primary sources linked above support protocol scope and named system examples, not adoption percentages or DAIDISIKE customer results.