IO-Link’s 2026 JSON integration update expands how sensor and device information can be used beyond the controller while keeping machine control straightforward.
The timing is relevant. The IO-Link Interop workshop on 22–23 September 2026 brought international device, tool and integration vendors together to test interoperability, including IO-Link Wireless, system integration and JSON REST API connections. Earlier this year, the IO-Link Community released Version 2 of its JSON mapping specification with expanded MQTT functions and machine-readable OpenAPI and AsyncAPI descriptions.
The engineering point is not to bypass the PLC. Control data should still go where deterministic control belongs. The useful change is that diagnostics, parameters and device information can be exposed in a more standard way to edge software, maintenance systems and plant applications without inventing a different data model for every sensor vendor.
Keep control data and information data separate
An IO-Link device can produce more than the cyclic value used by the machine. A pressure sensor may also expose device identity, range, status, operating hours, diagnostic events and configuration. A condition sensor may have health indicators that are useful to maintenance but unnecessary in the scan cycle.
I would keep the architecture simple. Cyclic process data stays with the controller for machine operation. Diagnostics and parameters are available to engineering and maintenance tools. Selected device data can move through JSON/REST or MQTT to an edge application, database, CMMS, MES or analytics layer.
This avoids turning the controller into a general-purpose data broker. If a cable and controller path already works for the control function, leave it alone. Use the additional integration path for information that has value outside the control loop.
What Version 2 changes
| Change | Engineering use |
|---|---|
| IO-Link Wireless included in the JSON mapping | The same structured data model can be used for suitable wireless devices such as mobile, rotating or difficult-to-wire assets. |
| Expanded MQTT topic structures | Process data, parameters and events can be separated more cleanly for event-driven edge and IIoT applications. |
| OpenAPI description | REST interfaces can be described in a machine-readable form, reducing hand-written integration work. |
| AsyncAPI description | MQTT interfaces can be described and checked more consistently across software teams. |
The IO-Link Community says the specification is now fully machine-readable through OpenAPI and AsyncAPI. That matters because integration code, interface checks and documentation can increasingly follow the specification instead of being maintained as separate spreadsheets.
JSON does not replace OPC UA
IO-Link already has an OPC UA companion specification. JSON/REST and MQTT solve a different integration problem. The IO-Link Community describes JSON as a lightweight option for IT and cloud integration, while OPC UA provides a richer industrial information model and service architecture.
Where MQTT fits
MQTT is useful when an edge application needs selected device events or measurements without repeatedly polling every endpoint. That does not mean every IO-Link value belongs in a broker. Publish only the data that has a defined consumer and retention purpose.
For example, a maintenance application may need device health, diagnostic events and a small set of condition indicators. MES may need equipment state and selected quality-related values. Engineering may need parameter backups and device replacement information. Keeping those uses separate makes the data path easier to secure and easier to troubleshoot.
Wireless is useful, but not automatically better
Including IO-Link Wireless in the JSON mapping is useful because mobile equipment, rotating parts and difficult-to-wire locations are real engineering cases. It should still be treated as an application decision rather than a default replacement for cable.
If a fixed sensor can be wired reliably, I would normally keep the cable. Wireless earns its place when movement, installation cost or mechanical constraints justify it. The important point is that the higher-level data model can remain consistent across wired and suitable wireless IO-Link devices.
What I would specify on a new machine
- Keep deterministic machine control in the PLC. Do not add an IT-facing data path to the control loop unless there is a specific engineered reason.
- Choose IO-Link masters with documented higher-level interfaces. Check exactly which JSON/REST, MQTT and OPC UA functions are implemented rather than assuming every master exposes the same services.
- Use device descriptions properly. IODD information is what gives device data meaning beyond raw bytes.
- Define ownership of parameters. Decide whether the PLC, engineering station, edge application or maintenance system is authoritative for configuration changes.
- Expose only useful information. More tags do not automatically create more value. Start with diagnostics and parameters that support a real maintenance, quality or production workflow.
- Secure the IT-facing interface. Network segmentation, authentication, access control and logging still matter even when the underlying field connection is simple.
Why this matters for brownfield plants
Many existing factories already have reliable PLC control but poor visibility at sensor level. IO-Link is useful in that situation because it can improve diagnostics and parameter access without requiring the whole machine-control architecture to be redesigned.
The JSON and MQTT work makes that field information easier to consume by modern software. It does not remove the integration engineering. Someone still has to decide which data matters, how it is named, where it is stored and which system is allowed to write back.
That is where I would start: preserve working control, add the missing device visibility, and connect only the information that supports a defined operational use case.
Sources
- IO-Link Community — IO-Link Interop 2026, 22–23 September 2026
- IO-Link Community — New machine-readable specification for JSON mapping
- IO-Link Community — Standardised vertical integration using JSON, REST, MQTT and OPC UA
Engineering support
CANS works on PLC/SCADA integration, industrial communications, edge connectivity, condition monitoring and plant digitalisation. If you are deciding how IO-Link data should connect into an existing machine, MES, CMMS or analytics platform, contact CANS or WhatsApp us.
Recent Comments