IO-Link and IO-Link Wireless: Master Architecture, IODD, Process Data and Integration with OPC UA and MQTT (2026)

The last meter of a factory is still the least digital one. A fieldbus may carry gigabits to the cabinet, yet the proximity switch at the end of the cable reports a single bit, and nobody knows whether it is dirty, drifting, or about to fail. IO-Link exists to close that gap. It is a point-to-point, three-wire digital link that turns an ordinary sensor or actuator into a device with an identity, parameters, diagnostics and a typed data stream, without replacing the cable or the field wiring habits of the plant.

Why it matters now: IO-Link is standardized as IEC 61131-9, a wireless extension was published as IEC 61139-3:2023, and the community has published ways to reach the data from IT systems through JSON, REST, MQTT and an OPC UA companion specification. The sensor is no longer a dead end for data.

You will leave with a working mental model of the stack: how the master and the device talk, what the three kinds of data are, how an IODD turns bytes into meaning, where IO-Link Safety and IO-Link Wireless fit, and how to move all of it into PLCs, historians and brokers without creating a maintenance trap.

What this covers: the physical and data-link layer, process data versus ISDU parameters versus events, IODD, master architecture and device replacement, IO-Link Safety, IO-Link Wireless, integration paths to fieldbus, OPC UA, MQTT and REST, an example ISDU read, failure modes, and a rollout checklist.

Context and Background

Before IO-Link, a smart sensor meant a vendor-specific serial port or an analog 4-20 mA loop plus a laptop cable for configuration. Analog signals need shielded cable, are sensitive to noise, and carry exactly one value. Binary switches carry one bit. Anything richer, such as a configuration or a temperature reading from inside the sensor head, was reachable only through proprietary tools, which made device replacement a manual and error-prone job.

IO-Link was designed to be the opposite: a single, vendor-neutral, low-cost interface. The technology is described by the IO-Link Community, which is managed by PI (PROFIBUS and PROFINET International), and it is standardized as IEC 61131-9, titled as a single-drop digital communication interface (SDCI) for small sensors and actuators. The IO-Link Wikipedia summary lists the key physical facts: unshielded cable of three or five conductors, no longer than 20 meters, M12 connectors, and 24 V supply with a maximum of 200 mA for the device on pins 1 to 3.

Two properties explain its adoption. First, IO-Link is backward compatible with standard binary I/O: pin 4 of the connector (named C/Q in the standard) can behave as a plain digital input or output, called SIO mode, so a port can serve a conventional switch. Second, the IO-Link layer is independent of the fieldbus above it. The master is the translator: it speaks IO-Link on its ports and PROFINET, EtherCAT, EtherNet/IP or another network on its upstream side, as covered in our comparison of PROFINET, EtherCAT and OPC UA FX over TSN.

The incumbents in the same slot are worth naming plainly. Analog current loops and HART remain common in process plants, and AS-Interface serves binary and simple analog devices on a two-wire bus. IO-Link is not a bus: it is a star of point-to-point links, one device per port. That choice trades wiring efficiency for simplicity, diagnostics per port, and the ability to hot-swap a device without disturbing its neighbours.

The IO-Link Community states that the specification covers measured values and setpoints, device parameters, diagnostics and error messages, and master configuration, down to the application interface (IO-Link integration overview). That scope matters, because it is why a single IODD file can drive a configuration screen, a PLC function block and a cloud decoder at once. The remainder of this post follows data upward from the wire to the cloud.

IO-Link Architecture: Master, Device and the Three Kinds of Data

Direct answer: An IO-Link system has a master with one or more ports and a device on each port, linked by a 3-wire unshielded cable up to 20 m. The master cyclically exchanges process data with the device, reads and writes parameters acyclically through ISDU (Indexed Service Data Unit), and collects events. The master then bridges all of it to a fieldbus or an IT network.

Figure 1: An IO-Link master terminates point-to-point device links and bridges upward to a fieldbus for control and to JSON, MQTT or OPC UA for IT consumers.

The figure shows the two upward paths from the master. The control path goes to a PLC through the fieldbus and carries cyclic process data. The information path goes to edge and cloud through a web interface, a broker or an OPC UA server, and carries parameters, diagnostics and the same process data. The two paths coexist, and a well-designed plant uses both from the same port without the sensor knowing.

Physical layer: three wires, three speeds, one pin

The device cable has a minimum of three connections: L+ (24 V), L- (0 V) and C/Q. Port class A uses connectors with at most four pins, where pins 2 and 5 are undefined and left to the application. Port class B uses a five-pin M12 and provides an additional power supply on pins 2 and 5, intended for actuators that draw more current than the 200 mA available on the sensor supply (Wikipedia). The master uses female connectors and the device male.

Communication happens on the C/Q line. IO-Link defines three transmission rates: 4.8 kbaud (COM1), 38.4 kbaud (COM2) and 230.4 kbaud (COM3). A device supports exactly one of them, and the master detects which during startup. The Wikipedia entry states a minimum transmission time of 400 microseconds at 230.4 kbaud. Practical products reflect this: a Balluff radar sensor documentation lists COM3, 230.4 kbaud, a minimum cycle time of 10 ms and a 12-byte process data input, with IO-Link revision 1.1 (Balluff communication parameters). The device minimum cycle time, not the baud rate alone, usually sets how fast a given sensor updates.

The cycle time actually used on a port is the larger of the master’s minimum and the device’s minimum, a rule that the Balluff basics page states explicitly. Process data width can be set anywhere between 1 bit and 32 bytes per direction, and the IO-Link Community notes that even at the 32-byte maximum, cycle times below 3 ms are achievable (IO-Link: Did you know). The consequence for design is simple: the payload you ask for sets the update rate you get, so do not map 32 bytes of process data if you need five bytes at 1 ms.

Data link layer: M-sequences

The master and the device exchange fixed-format frames called M-sequences. Every frame carries process data and, in a rotating fashion, a few bytes of “on-request data” that carry acyclic traffic. The IO-Link Community explains that process data is sent completely in every M-sequence, which gives deterministic response times, while parameter and event data are spread across multiple M-sequences because they are less time-critical. The M-sequence type of a device is declared in its communication parameters, as the Balluff example shows with a code of 0x1B for 2 bytes of on-request data in both Preoperate and Operate.

This design has a visible consequence. A large acyclic transfer, such as a firmware-sized parameter block or a 200-byte table, is chopped into 1 or 2 byte pieces over many cycles. At a 10 ms cycle that is slow, and it is the reason bulk parameter operations feel sluggish compared with the process data stream, which never stalls.

The three kinds of data

IO-Link separates traffic by purpose, and each class has its own behavior and its own failure modes.

Process data is the cyclic payload: the measured value, switching states, or setpoints, up to 32 bytes in each direction. It is accompanied by a validity flag so the master can tell a stale or invalid value from a real zero. This is the data your PLC reads.

Service data (parameters via ISDU) is acyclic. ISDU stands for Indexed Service Data Unit, and it addresses a parameter by index and subindex. Vendor name, product name, serial number, firmware revision and application-specific tags live at standardized indices, while the rest of the index space holds device-specific parameters described by the IODD. The FEIG application note, which drives an IO-Link device from a PLC function block, shows the usual pattern: set a Get flag and an index to read, set a Put flag, index and length to write, and note that a write fails if the supplied length does not match the length the device defines (FEIG acyclic data note). In that example, index 20 returns the product text.

Events are asynchronous diagnostic messages that the device raises with a flag in the cyclic channel; the master then reads them from the device event memory. Events cover errors, warnings and notifications, for example a lens contamination warning. Each event also drives a device status, which the Balluff documentation lists as five states: operating properly, maintenance required, out of specification, functional check, and failure. These map neatly to the NAMUR-style condition model that process engineers know, and they are what an asset-health dashboard should key on.

Startup and the parameter server

At power-up, the master sends a wake-up current pulse; the device leaves SIO mode and listens. The master then reads the device’s communication parameters, enters the Preoperate state to read identification and, where configured, to compare or download stored parameters, and finally switches the port to Operate for cyclic exchange.

Figure 2: IO-Link startup and cyclic operation. Identity and parameters are settled in Preoperate before any process data is trusted.

The Data Storage function, often called the parameter server, is what makes device replacement boring. According to the Balluff documentation, the master saves a device’s parameter data, controls uploads when settings change intentionally, and downloads them to a replacement device, so a device can be swapped without re-parameterizing it. Behavior depends on the specific master, so test it: whether the master requires a matching vendor and device ID, whether it downloads automatically or waits for a confirmation, and what happens when the stored image and the device disagree are all implementation choices that you must verify per product.

Block parameterization is the other relevant function: several parameters are written inside a session opened and closed by system commands, and the device validates the whole set only at the end. That lets interdependent values, such as a switching window with a lower and upper bound, be written together without passing through an invalid intermediate state.

IODD, Versions and How Meaning Gets Attached to Bytes

Bytes on the wire mean nothing without a description. The IODD (IO Device Description) is the XML file that supplies it. The Wikipedia entry notes that device parameters and descriptions use IODD files written in XML, and the IO-Link Community describes the IODD as the data model of an IO-Link device used for application-level integration. In practice an IODD declares the vendor ID and device ID, the process data layout (which bits are a boolean, which bytes form a 16-bit signed value, scaling and units), every parameter with its index, subindex, type, range, default and access rights, the events with their codes and text in several languages, and menus that tell an engineering tool how to present the parameters.

The identity pair is the key to everything. A device reports its VendorID (assigned by the community) and DeviceID during startup. A tool, a master or an edge gateway uses that pair to select the right IODD. This is why the Balluff documentation lists vendor ID 0x378 and a distinct device ID for each variant. Without a matching IODD, you are left with raw hexadecimal strings, and a quick look at any integration forum shows that raw hex is exactly where many projects stall.

What the IODD buys you, and what it does not

The IODD makes three jobs mechanical. A configuration tool can generate a parameter screen with no device-specific code. A PLC engineer can map process data bits to named tags. An IT gateway can decode the process data into engineering units, which is how the Apache StreamPipes IO-Link adapter and the United Manufacturing Hub “sensorconnect” input produce readable JSON; the latter documents fetching IODD files by vendor and device ID from an IODD API, with a configurable fallback URL per device (UMH sensorconnect).

What the IODD does not give you is semantic standardization across vendors. Two vendors’ temperature sensors may each describe a perfectly valid IODD, yet use different names, scaling and parameter layouts. The community addresses that with the Common Profile and the Smart Sensor Profile, which use proxy function blocks so application programmers can access profile functions regardless of master or device manufacturer (IO-Link integration overview). Profiles are the path to interchangeability; the IODD alone is the path to documentation.

Specification versions to know

The base specification is the “IO-Link Interface and System Specification”. The community download page lists V1.1.3 (the 2020 package) and V1.1.4 (the 2024 package), the latter file being dated June 2024. I could not extract the changes between those two versions from the download page, so I will not describe them. The widely deployed protocol revision on the wire is 1.1, shown as revision ID 0x11 in product documentation; devices with the older 1.0 revision exist. Distributor explainers such as DigiKey’s IO-Link 1.1 features article cover what 1.1 added, but I could not retrieve its body, so I do not list those features here. The practical rule: check each device’s revision and each master’s supported revisions, because a 1.1 master is expected to handle 1.0 devices but a 1.0 master may lack functions that 1.1 devices assume.

IO-Link Safety: Functional Safety Over the Same Cable

Many machines need a safe signal, such as an emergency stop, a light curtain or a safe position, next to the diagnostic one. Classic safety devices use two channels and output signal switching devices (OSSD) wired to a safety relay or safety input. IO-Link Safety adds a safety layer above the unchanged IO-Link stack, using the black channel principle: the safety protocol protects the data end to end and does not trust anything in between, including the standard master and the fieldbus.

According to the computer-automation.de report, IO-Link Safety (system extensions) version 1.0 was published in April 2017, the standardized master interface (SMI) was added in version 1.1, and the safe communication concept was confirmed by TÜV SÜD. Each safety message carries safe process data plus a safety code that lets the receiver verify timely arrival, correct sender and data integrity. Two PDU formats exist: one for up to 3 octets with a short safety code, and one for up to 25 octets with a longer code.

The architecture introduces an FS-Master and an FS-Device. The FS-Master unifies what used to be several fieldbus-specific safety module types, and it follows the SMI, which defines services for configuration, parameter storage, acyclic communication, diagnostics and cyclic process data. A splitter/composer separates safe PDUs from non-safety process data, so one port carries both. Safe protocol parameters, such as the monitoring time, are held in the configuration manager.

The report also describes OSSDe signaling, an extension of OSSD outputs for compatibility, with test pulses following ZVEI CB24I type C class 1 and the second signal on pin 2 of the M12 connector. A safe device can therefore switch conventionally on a classic safety input or communicate securely through an FS-Master. I am deliberately not quoting SIL or performance level claims here: the source does not state them, and any product’s rating belongs to its certificate, not to the protocol description. Per Wikipedia, safety design rules reference IEC 61508 and ISO 13849.

Design implication: IO-Link Safety reduces wiring and gives per-device diagnostics, but it makes safety commissioning a software task. The safety parameters, the FS-Master configuration and the fieldbus safety profile (for PROFINET, PROFIsafe) all become part of the validated configuration, and any change needs the same change control as a hardwired safety circuit.

IO-Link Wireless: Architecture and Real Limits

IO-Link Wireless (the IO-Link Community writes it with a hyphen, while search queries often say “iolink wireless”) replaces the last cable with a radio link, aimed at moving parts, rotating tables, tool changers and retrofits where cable is costly. It was published as an international standard, IEC 61139-3:2023, “Industrial networks – Single-drop digital communication interface – Part 3: Wireless extensions”, in November 2023 per the PI announcement. The announcement says the IEC edition is based on a further developed version of the IO-Link Wireless system extensions V1.1 originally published in 2018.

The community’s wireless page gives the key numbers (IO-Link Wireless): operation in the 2.4 GHz ISM band split into 80 channels of 1 MHz each, a 5 ms cycle time, up to 40 wireless devices per master, devices grouped into tracks of 8 using time-division multiplexing, and each master transmitting 5 tracks in parallel using frequency-division multiplexing. Up to three wireless masters can operate in the same area, supporting up to 120 devices in a 20 by 20 m production cell. Wikipedia adds the mechanism: the downlink is a multicast W-frame in assigned time slots, the uplink has devices transmitting one after another in a fixed scheme, and robustness comes from frequency hopping and channel blacklisting. I could not verify the radio range, the transmit power, or the number of retransmissions from official sources, so I leave them out.

Figure 3: IO-Link Wireless groups 40 devices into five parallel tracks of eight. The master is wired upward like any other IO-Link master.

What wireless changes in the design

The wireless master is still an IO-Link master from the integration perspective. It maps wireless devices to logical ports and exposes the same process data, ISDU and events upward, so PLC and IT integration stay the same. What changes is the failure model.

A wired port fails visibly: the cable breaks, the port loses communication, and the diagnostic is binary. A wireless link degrades: interference in a busy 2.4 GHz environment, shared with Wi-Fi and Bluetooth, can push the link into repeated hops and reduced availability before it drops. Frequency hopping and blacklisting mitigate this, but they do not remove the need for a site survey. The fixed 5 ms cycle is also a ceiling: a sensor that needs 1 ms updates is not a wireless candidate.

Power is the second difference. A wireless device has no 24 V from the cable, so it uses a battery or a local supply, and the 200 mA budget of the wired link disappears. Battery life, replacement logistics and the alarm when the battery is low become part of the asset-management process. For this reason wireless is best used for non-critical measurement and for mechanically awkward places, and wired stays the choice for anything safety related or fast.

Dimension	IO-Link (wired)	IO-Link Wireless
Topology	Point to point, one device per port	Up to 40 devices per master in 5 tracks of 8
Medium	3 or 5 wire unshielded cable, max 20 m	2.4 GHz ISM, 80 channels of 1 MHz
Timing	Cycle set by device minimum, down to sub-3 ms with 32 byte PD	Fixed 5 ms cycle per the community page
Power	24 V, max 200 mA on class A	Local supply or battery
Safety	IO-Link Safety v1.x available	Wireless safety is a separate research and standardization topic, not covered here
Failure mode	Hard fail, clear diagnostic	Gradual degradation, needs RF survey
Standard	IEC 61131-9	IEC 61139-3:2023

The “Wireless safety” cell is intentionally cautious: the Helmut Schmidt University site lists IO-Link Wireless Safety as a research topic, and I did not find a published product-ready specification in the sources I reviewed, so treat any vendor claim in this area as needing its own verification.

Integration: From the Master to the PLC, the Broker and the Twin

Integration is where IO-Link projects succeed or become hobby projects. There are three destinations with different needs: the PLC wants deterministic cyclic data, the engineering team wants parameters and replacement, and the IT side wants contextualized time series. One master can serve all three, but each path has its own rules.

Path 1: Master to PLC through the fieldbus

The IO-Link integration page lists specifications for PROFINET (with PROFIsafe), EtherNet/IP (CIP), EtherCAT, AS-Interface, CiA, SERCOS, IO-Link JSON and OPC UA. It also says PROFINET has the most consistent implementation, and that work was underway to make its mapping certifiable in the PROFINET test system. Treat that as a signal rather than a guarantee: on a PROFINET controller the master is a modular device whose submodules map to ports, while on EtherCAT or EtherNet/IP the mapping differs in how acyclic ISDU access is exposed (typically through a vendor function block or a CoE or CIP service).

The practical routine is to import the master’s device description file (for PROFINET, a GSDML) into the PLC project, choose the process data length per port to match the device, and use the vendor’s function block for ISDU. Process data arrives as a byte array. Decoding it into typed tags is a manual step unless your engineering tool reads the IODD, so keep a record of the byte-order and scaling for each device type.

Cyclic cost scales with the byte count you map. Each port’s input and output size is part of the fieldbus configuration, and a master with eight ports each mapped at 32 bytes loads the cyclic frame more than the same master mapped at 4 bytes per port. Map what the control program uses; fetch everything else acyclically or through the IT path.

Path 2: Master to OPC UA

The OPC Foundation published OPC 30120, “OPC UA for IO-Link Devices and IO-Link Masters”, version 1.0, as a companion specification created with the IO-Link Community. The reference documentation describes an information model with an IOLinkMasterType (methods such as Restart and ResetStatisticsOnAllPorts), an IOLinkPortType (ResetStatistics and UpdateConfiguration), and an IOLinkDeviceType that offers ReadISDU and WriteISDU methods, SystemCommand, and parameter upload and download. IODD-driven ObjectTypes are generated through the IOLinkIODDDeviceType, and an IODDManagement object handles device variants and IODD files. The specification enumerates seventeen use cases (UC.001 to UC.017), including configuration, diagnostics and firmware update (OPC 30120 reference).

Two server profiles are defined. The IO-Link Base Profile is for resource-constrained servers and excludes IODD file handling; it builds on the Micro Embedded Device 2017 server profile. The IO-Link Advanced Profile includes everything in Base and adds IODD handling, building on the Embedded 2017 UA Server profile. This split is the practical decision point: a small embedded master can expose ports, ISDU methods and events, while a larger gateway or edge server can expose a fully typed address space derived from IODDs.

For architects already running OPC UA, the benefit is that sensor parameters, diagnostics and process data appear in the same address space and security model as the machine. Our guide to OPC UA security policies, certificates and trust lists applies unchanged, and a master that cannot do certificate management properly is a weak point worth knowing about before you buy it. I did not verify which commercial masters implement which profile; check the vendor’s conformance statement.

Path 3: Master to JSON, REST and MQTT

IT systems often do not want an OPC UA stack. The community therefore specifies “JSON Integration for IO-Link”, described as lightweight and much less resource-intensive than OPC UA, with JSON carried over a REST API or MQTT. The community page gives no version number for it, and I did not retrieve the specification text, so the endpoint structure below is not claimed to be that specification. What is verified is a vendor implementation: ifm masters expose a JSON interface where a data point such as /iolinkmaster/port[1]/iolinkdevice/pdin/getdata can be fetched with an HTTP GET, or by a POST with a body holding code (here “request”), a correlation ID cid and the address adr, and the response returns the same cid, a data object with a value field (a hexadecimal string for process data) and a code of 200 for success (Cybus guide for ifm masters).

The returned hexadecimal string is the process data, undecoded. Turning it into temperature: 41.3 requires the IODD, so a gateway needs an IODD lookup keyed by vendor and device ID. Stacks such as the UMH sensorconnect plugin do this and emit JSON with named fields and port metadata, including port mode, port number, vendor ID, device ID, product name and serial number.

Figure 4: The IODD feeds the decoder; the master offers either a JSON poll path through an edge gateway to MQTT or an OPC UA server path, and both converge on time series storage and the digital twin.

Choosing a payload and namespace for MQTT

Once decoded, the data should be published with a stable topic and payload design, not whatever the gateway emits by default. A topic structure that mirrors enterprise, site, area, line, cell and device lets consumers subscribe by scope. Our posts on Sparkplug B versus plain MQTT topics and on Sparkplug B versus OPC UA PubSub cover the trade: Sparkplug gives birth and death certificates, state handling and typed metrics at the price of a stricter model, while plain topics are simpler and looser.

For IO-Link specifically, the useful modeling decisions are these. Publish identity (vendor, device ID, serial number) once as retained or birth data, not in every sample. Publish process data on change or at a fixed interval, with a quality flag derived from the process data validity bit. Publish the device status (the five states) as its own metric, since it drives alerts. Publish events as discrete messages with the event code and time stamp. Keep ISDU parameters out of the high-rate stream and expose them on request or through change notifications.

Walk-through: Reading an ISDU Over a Master’s JSON Interface

The following Python example reads two standard device identification parameters through an ifm-style JSON interface. It shows the request and decode pattern. The data point name for acyclic reads and the master address are assumptions for illustration: confirm them against your master’s operating instructions, as the vendor documentation I retrieved does not cover acyclic syntax. The index numbers 16, 18 and 20 are the standard vendor name, product name and product text indices (index 20 is confirmed as product text by the FEIG note; the others I am stating from the IO-Link specification and recommend you verify).

import json, urllib.request

MASTER = "http://192.168.0.1"   # master address: placeholder
PORT = 1

def post(adr, data=None, cid=4711):
    body = {"code": "request", "cid": cid, "adr": adr}
    if data is not None:
        body["data"] = data
    req = urllib.request.Request(
        MASTER, data=json.dumps(body).encode(),
        headers={"Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=3) as r:
        return json.load(r)

def read_pdin(port):
    adr = f"/iolinkmaster/port[{port}]/iolinkdevice/pdin/getdata"
    return post(adr)["data"]["value"]          # hex string

def read_isdu(port, index, sub=0):
    # Service name per ifm documentation: verify for your master
    adr = f"/iolinkmaster/port[{port}]/iolinkdevice/iolreadacyclic"
    r = post(adr, {"index": index, "subindex": sub})
    if r.get("code") != 200:
        raise RuntimeError(f"ISDU read failed: {r.get('code')}")
    return bytes.fromhex(r["data"]["value"])

raw = read_pdin(PORT)
print("process data hex:", raw)
for idx, name in ((16, "vendor"), (18, "product"), (20, "text")):
    print(name, read_isdu(PORT, idx).decode("ascii", "replace"))

Three details carry the real lesson. First, errors are in-band: a transport success (HTTP 200) can still hide a device-level failure, so check the application code in the body. Second, ISDU reads are slow because they travel in the on-request slot; do not put them inside a tight loop at 100 ms. Third, the process data is hex, so decode it with the IODD and never with hand-written constants spread across scripts.

Decoding with an IODD, in outline

A minimal decoder parses the IODD XML, finds the process data input record, and applies each field’s bit offset, bit length and type. IODD tools and open-source engines exist, such as the Rust crate ioddengine listed in search results, but I did not evaluate its completeness, so test any decoder against your actual device files. Two pitfalls are worth stating. IO-Link process data is big-endian by convention in the standard, and subindex bit offsets are counted from the least significant bit, which trips up first implementations. Scaling, such as a gradient and an offset, is part of the IODD and must be applied to get engineering units. Both statements come from my reading of the specification and should be verified against your device’s IODD before you rely on them.

Worked numbers: how much data is this?

An example sizing helps decide the gateway load. Suppose a line has 4 masters of 8 ports, so 32 devices, each exposing 4 bytes of process data polled at 100 ms through JSON. That is 320 requests per second if each device is read separately, which a typical small master web server may not sustain, and the hex string itself is trivial in size. Polling the master’s whole-tree call once per second would cut request count but may carry more bytes per call. These are illustrative figures, not measurements; the real limit depends on the master’s firmware, and you should load test one master before scaling out. A better pattern for fast data is the PLC path, with the PLC publishing selected tags, while the JSON path serves slower diagnostics.

Trade-offs, Gotchas, and What Goes Wrong

Vendor interpretation of a standard. The master side has rich optional behavior: Data Storage policies, port configuration modes, event handling and how ISDU is exposed upward are differently implemented. A project that swaps master brands mid-stream often discovers that its replacement workflow, IODD import or JSON paths differ. Test the swap before the first commissioning.

Hex without context. The most common failure is data that flows but is not understood. If your pipeline cannot guarantee the right IODD for every vendor ID and device ID, including after a device firmware update changes the device ID or variant, data will silently decode wrongly. Version your IODD repository and alert on an unknown pair.

Device variants and restarts. The Balluff documentation notes that a variant is selected via ISDU, but the change takes effect only after a communication restart, and that a compatibility mode lets the master’s port configuration select the variant. A device that reports a variant different from the one in the engineering project can trigger a Data Storage mismatch at a bad moment.

Parameter server surprises. An automatic download to a replacement device is convenient, and also the easiest way to overwrite a deliberate tweak or to push an old parameter set into a device with newer firmware. Decide whether replacement should be automatic or confirmed, document it, and record parameter images in version control rather than trusting only the master.

Cable and EMC assumptions. The 20 m limit and unshielded cable are specified, but a long unshielded run beside a VFD motor lead is still a risk. Use shielded cable where noise sources are close, and keep to manufacturer guidance.

Port budget. The 200 mA limit applies per sensor port, and class A ports do not offer the extra supply of class B. A heated or high-current device on a class A port can sit outside the supply budget, and the symptom is intermittent restarts rather than a clear error.

Wireless over-use. Wireless looks attractive for retrofits, but the fixed cycle, battery maintenance and RF congestion make it a poor choice for fast loops. Use wired for control, and wireless for monitoring unless a site survey proves otherwise.

Security. IO-Link itself has no authentication on the wire; physical access to a port is trust. Masters with web interfaces and unauthenticated JSON endpoints are network assets: segment them, disable unneeded services, change default credentials and, where an OPC UA server exists, prefer its secured endpoints.

Practical Recommendations

Start by classifying each sensor’s data by consumer. If the control program needs it, it goes through the fieldbus. If it is for health, quality or analytics, it goes through the IT path. If it is both, take it through the PLC and let the PLC publish what it needs, so the control timing stays independent of the web interface.

Treat the IODD as a controlled asset. Store IODD files per vendor and device ID, record the firmware revision they correspond to, and make decoding fail loudly on an unknown pair. If the gateway fetches IODDs from an external service at runtime, mirror it locally, because a production line should not depend on an internet lookup.

Choose OPC UA when you already operate a secured OPC UA estate and want typed, method-capable access, including parameter write and firmware workflows. Choose JSON over REST or MQTT for lightweight read-mostly telemetry and for edge stacks that lack a UA client. Whichever you choose, model the namespace once and keep it stable.

Plan device replacement as a process: enable Data Storage deliberately, keep a spare with known firmware, and write down who confirms a download.

Pre-commissioning checklist:

• Confirm each device’s IO-Link revision, baud rate, minimum cycle time and process data length against the master’s capabilities.
• Import the correct IODD and record vendor ID and device ID in the asset register.
• Set process data mapping to the smallest width the application needs.
• Define the Data Storage policy and test a device swap on a spare port.
• Check the 200 mA budget and port class for each device.
• Decide the OPC UA, JSON or MQTT path, and secure the master’s network interfaces.
• For safety devices, validate the FS-Master configuration under change control.
• For wireless, complete a site survey and a battery plan.

Frequently Asked Questions

What is IO-Link and is it a fieldbus?

IO-Link is a point-to-point communication interface for sensors and actuators, standardized as IEC 61131-9. It is not a fieldbus because each device has its own port on a master instead of sharing a bus. The master connects to a fieldbus or Ethernet network upstream. Over an unshielded three-wire cable of up to 20 m it carries process data, parameters and events, and the same port can also operate as a plain digital input or output in SIO mode.

What is the difference between IO-Link and IO-Link Wireless?

IO-Link Wireless replaces the cable with a 2.4 GHz radio link. According to the community, it uses 80 channels of 1 MHz, a 5 ms cycle and up to 40 devices per master in tracks of eight, and it is standardized as IEC 61139-3:2023. The upper layers of data, parameters and events stay IO-Link, so the integration stays similar. The trade-offs are the fixed cycle time, battery supply and radio coexistence.

What is an IODD and why do I need it?

An IODD is an XML device description that defines a device’s identity, process data layout, parameters, events and presentation menus. Tools use the vendor ID and device ID to select it. Without it you only see raw bytes. With it, a gateway can decode process data into engineering units and a configuration tool can build a parameter screen automatically. Keep IODD files versioned alongside the device firmware.

How do I get IO-Link data into OPC UA or MQTT?

For OPC UA, use a master or gateway implementing OPC 30120, which models masters, ports and devices and offers ISDU read and write methods. For MQTT, poll the master’s JSON interface or use a gateway, decode with the IODD, and publish to a stable topic structure. Many projects route fast data through the PLC and use the IT path for diagnostics and parameters.

What is ISDU in IO-Link?

ISDU, the Indexed Service Data Unit, is the acyclic channel used to read and write device parameters by index and subindex. It travels in the small on-request slot of each cycle, so large transfers take many cycles and are slow compared with process data. Standard indices carry identification such as product text, while device-specific parameters are described in the IODD. Writes need the correct length, or the device rejects them.

Does IO-Link support functional safety?

Yes. IO-Link Safety adds a safety layer over the unchanged IO-Link stack using the black channel principle. Version 1.0 appeared in April 2017 according to trade press, with a standardized master interface in version 1.1. Safe data carries a safety code in PDUs of up to 3 or 25 octets. A device’s achievable safety integrity depends on its certification, so check the certificate rather than the protocol description.

Further Reading

Internal:

• Sparkplug B vs plain MQTT topics for the namespace and payload design that decoded IO-Link data should follow.
• PROFINET vs EtherCAT vs OPC UA FX over TSN for the fieldbus layer above the master.
• Sparkplug B vs OPC UA PubSub for choosing the northbound transport.

External:

• IO-Link Community: Wireless and Integration, the primary community pages used here.
• OPC 30120: OPC UA for IO-Link Devices and IO-Link Masters, the companion specification reference.
• IO-Link Safety overview from computer-automation.de.

Claims not verified from primary text in this research: the exact differences between specification V1.1.3 and V1.1.4, IO-Link 1.1 versus 1.0 feature details, standard ISDU indices other than 20, endian and bit-offset conventions, and the exact ifm acyclic read service name.

By Riju — about