IO-Link Implementation: Sensor Data Integration and Acceptance

An IO-Link implementation is not complete when a communicating sensor sends a value to a PLC. If nobody governs what the value means, its unit and range, its quality and diagnostics, the device revision and the responsibility for parameter changes, the value cannot be reused safely by MES or cloud applications. When the IO-Link Device, IO-Link Master, IODD, asset register, northbound integration and FAT/SAT are treated as one acceptance package, however, a plant can standardize sensor data collection on existing equipment in controlled steps.

This guide is for production engineering, maintenance, quality and IT/OT teams preparing an RFP, a 90-day proof of concept, a retrofit or a multi-line rollout in Thailand and the wider region. It does not invent market prices or promise a generic ROI. It specifies what to request from suppliers, what to test and what evidence is needed to decide that the system is operable—not merely connected.

Executive conclusion: govern point meaning and responsibility boundaries

IO-Link is a standardized point-to-point communication technology for sensors and actuators. The IEC page describes IEC 61131-9:2022 as SDCI, supporting bidirectional exchange of complex data, transfer of parameters, and delivery of identification and diagnostic information. The IO-Link Community likewise highlights bidirectional communication, extended diagnostics, parameterization and the IODD.

A standard interface does not automatically standardize plant responsibility. Two controls must be built together:

1. Govern every point’s meaning. Link plant, line, asset, sensor position, measurement, unit, physical range, engineering conversion, normal limits, diagnostics, IODD revision, approved parameters and replacement history.
2. Freeze the responsibility boundary. From Device and Master through PLC/Edge, SCADA, Historian, MES, OPC UA, JSON/REST, MQTT and cloud, assign ownership for mapping, time, quality, retry, access, change and monitoring—and prove it in FAT/SAT.

The business value is therefore larger than replacing a conventional sensor with a smart sensor. The objective is to turn a plant-floor point into a replaceable, traceable operational asset whose data cannot be misinterpreted upstream.

Manage the IO-Link Master, Device and IODD as one unit

A Device carries state and identity, not only a value

An IO-Link Device can expose process data, identity, parameters and diagnostics. A temperature sensor may provide more than “25.3”: it can make units, scaling, product identity, communication state, diagnostics and settings available. The exact data depends on the device, IODD, Master and implemented scope. An RFP should therefore list required data by device model instead of asking only whether a product “supports IO-Link.”

Digital data can still be interpreted incorrectly. The same 16-bit field can be signed or unsigned, scaled in tenths, or reserve codes for invalid states. A system may hold the last value while diagnostics are active. If every PLC program decodes these details independently, interpretations diverge across lines. Validate the IODD and vendor implementation, then consolidate conversion into approved function blocks or an Edge model.

A Master is more than a protocol converter

The Master is the boundary that connects point-to-point ports to an upstream network. It can manage port configuration, device recognition, diagnostics, parameter storage, replacement recovery and the connection to an industrial network. Capabilities differ by product. Web interfaces, APIs, JSON, OPC UA, MQTT and cloud connectors are product or gateway functions; they are not guaranteed merely because the device is IO-Link.

An MQTT option on a Master does not mean MES integration is finished. Topic naming, payload schema, timestamp, quality flag, retain, QoS, reconnect behavior, certificates, access and missing-data behavior still need design and acceptance. A JSON/REST interface similarly requires separation between read and configuration access, rate limits, auditability and API version control.

Treat the IODD as a controlled revision

The IODD is a machine-readable description of device data and parameters. Store not only the file but its source, filename, revision, checksum, supported firmware, approval date, installed assets and reason for change. It belongs in an approved repository, not only in an integrator’s download folder.

A replacement from the same product family may have a different firmware or IODD revision. Automatic parameter restoration is useful, but blindly writing an old set can be unsafe or simply wrong. Verify Vendor ID, Device ID, revision, compatibility, target port and approved baseline. Route a mismatch to quarantine or human approval.

Build a point register that makes sensor data meaningful

For a brownfield retrofit, do not migrate every signal first. Start with points that support a specific downtime, quality or maintenance decision.

A point name should identify hierarchy and meaning, not rely on a local abbreviation. Units must be data, not only display text, so bar is not confused with kPa and velocity with acceleration. Keep physical, operational and alarm ranges separate. Quality should distinguish communication loss, device diagnostics, out-of-range data, parameter mismatch and maintenance mode rather than reducing everything to one boolean.

Freeze each responsibility boundary in drawings and tests

“Integration supported” is not an acceptance criterion. Divide the chain into at least four accountable layers.

1. SENSOR to IO-LINK MASTER

Cover device selection, cable, connector, port class, supply, length, environment, IODD, port mode, cycle and diagnostics. At the machine, inspect oil, water, vibration, welding noise, moving sections, cleaning chemicals, temperature and connector torque. Test broken wire, short circuit, replacement, wrong model and parameter mismatch, not only successful communication.

2. IO-LINK MASTER to PLC / EDGE

Define the upstream protocol, engineering configuration, tag mapping, byte order, type, scale, update, error value, link-loss behavior and parameter-write permission. Avoid tightly coupling application logic to vendor addresses. Absorb vendor detail into approved blocks and named structures.

3. PLC / EDGE to MES / CLOUD

Define asset hierarchy, OPC UA NodeIds, information model, JSON schema, MQTT topics, timestamps, quality, store-and-forward, retry, deduplication, TLS certificates and authorization. The OPC UA companion model for IO-Link offers a common representation for Devices and Masters, but it does not decide the relationship to a plant’s asset IDs, product, lot or work order.

4. Operations, change and incident response

Specify what happens when maintenance replaces a Device, engineering changes a parameter, IT renews a certificate or a supplier updates Master firmware. Identify requester, approver, regression tests and rollback. The first-line diagnostic path should show whether teams begin at the sensor, port, Master, PLC, Edge, broker or MES, instead of transferring tickets between organizations.

Choose OPC UA, JSON/REST and MQTT by responsibility

One northbound mechanism does not have to serve every purpose.

OPC UA is attractive when structured device identity, parameters and diagnostics are needed. As discussed in our OPC UA FX and TSN implementation guide, a standard name alone does not guarantee interoperability. Freeze the model, namespace, certificate process and acceptance dataset.

MQTT provides decoupled delivery but does not create meaning. A topic such as factory/line1/master3/port4/value cannot show whether the meaning remained unchanged after replacement. Include asset ID, measurement, unit, timestamp, quality, device revision and schema version in the payload, or link reliably to an asset registry.

When adding Masters to an existing plant, design VLANs, IP management, NTP/PTP, DNS, certificates, firewall and remote maintenance—not bandwidth alone. Our industrial network construction guide explains why ownership of control and monitoring traffic should be explicit.

Standard, Wireless and Safety are purpose-specific options

Use standard wired IO-Link as the baseline

For fixed equipment where wiring is practical, standard point-to-point IO-Link is a clear baseline. It keeps the physical connection visible and avoids a second radio coexistence design. Compare Wireless when a moving axis, rotating element, replaceable tool, high cable labor or frequent changeover creates a defined wired constraint.

Qualify IO-Link Wireless limits on the actual site

Official IO-Link Wireless information describes a 5 ms cycle and, under the profile’s radio and channel-planning conditions, up to 40 Devices per wireless Master and up to three Masters or 120 Devices within a 20 m × 20 m area. This does not guarantee 120 stable devices at 5 ms in every factory. Channel planning, synchronization, obstructions, metal reflections, other radios, antennas, location, payload, packet error and retry all affect the result.

The PoC should measure worst-case latency, packet error, consecutive loss, reconnect time, power or battery maintenance, other-radio operation, door movement and tool movement. Acceptance differs for a control use and a diagnostic use. Wireless can reduce data cabling; it does not remove power, mounting, maintenance, cybersecurity, radio compliance or site standards.

IO-Link Safety does not make an ordinary Device safety-rated

IO-Link Safety uses standard IO-Link as a black channel. Official information identifies IEC 61139-2, applications up to SIL 3 / PL e and mixed standard/safety configurations. “Up to” and the complete chain matter. Connecting an ordinary IO-Link sensor does not create a SIL 3 or PL e function. The Safety Device, Safety Master, higher-level safety control, parameters, response time, safety function, wiring, diagnostics, validation and evidence all belong to the assessment.

Standard, Wireless and Safety are not three generations where one automatically replaces another. A line can rationally use Standard for fixed sensors, Wireless for moving-tool diagnostics and a properly engineered Safety chain for a guard. Select by application, risk assessment, performance, maintenance, applicable standards and site conditions.

Put these 12 items into the RFP

1. Point list: asset, position, measurement, candidate Device, quantity, update and diagnostic use.
2. Device fit: model, IDs, IODD, firmware, environment, connector and spare.
3. Master design: port count, Class A/B, power, enclosure, upstream network and spare capacity.
4. Data dictionary: tag, type, unit, range, scale, quality, timestamp, diagnostics and invalid codes.
5. Parameter governance: baseline, permitted range, backup, restoration, approval and audit.
6. IODD control: source, revision, checksum, compatibility, repository, notification and rollback.
7. Northbound scope: PLC, SCADA, Historian, MES, OPC UA, JSON/REST and MQTT boundaries.
8. Network/security: zones, VLANs, ports, certificates, accounts, logs and remote support.
9. Wireless: survey, coexistence, density, latency, packet error, recovery and battery.
10. Safety: safety function, required SIL/PL, response, validation, change and evidence.
11. FAT/SAT: normal, fault, replacement, link loss, mismatch, upstream data and audit tests.
12. Deliverables: as-built drawing, register, IODDs, backups, code, licenses, training and support.

Do not accept “possible” as a complete response. Ask whether each capability is standard, optional, gateway-based or custom; who owns it; and whether it can be demonstrated with the selected hardware in FAT. Northbound work often falls between the Master supplier, PLC integrator and MES supplier, so name one end-to-end accountable party.

A 90-day PoC that produces operational evidence

Ninety days is a planning frame, not a promised outcome. Limit scope to one machine or cell and perhaps 8–20 points that the team can understand and safely test. That point range is an illustrative scoping assumption, not an industry standard.

Days 1–30: design points and responsibility

• Walk down the machine; confirm decisions, points, wiring and PLC capacity.
• Collect candidate Device/Master data and IODDs; build the dictionary and asset IDs.
• Select Standard, Wireless or Safety by use and risk.
• Agree PLC/Edge/MES ownership, change approval and security zones.
• Approve FAT/SAT criteria, evidence format and correction workflow before building.

Days 31–60: build the bench and execute FAT

• Connect real Devices, Master, PLC/Edge and the receiving application.
• Verify value, unit, scale, quality, timestamp, diagnostics and replacement.
• Inject IODD/firmware mismatch, broken wire, power loss, network loss and broker outage.
• Test OPC UA/JSON/MQTT schema, certificates, rights, retry and deduplication.
• Update the register, as-built, backups, recovery instructions and training material.

Days 61–90: execute site SAT and transfer ownership

• Install during a planned window; inspect wiring, network, grounding and environment.
• Test with real products, cycle, cleaning, changeover and maintenance mode.
• Reconcile the screen with the physical point and route diagnostics to the owner.
• Have plant maintenance execute device replacement and parameter restoration.
• Approve open items, exceptions, residual risk and rollout conditions.

The PoC exit is not “the dashboard is visible.” It is an approved point register, FAT/SAT record, fault behavior, restorable backup, change process, named owner and reusable standard components.

FAT/SAT acceptance matrix: faults reveal the real design

Acceptance limits are project-specific. “Communication succeeded” and “a number appeared” are not pass criteria. If a 100 ms update is required, define point, observation window, maximum or percentile and missing-value handling. Do not use Wireless architecture maxima as site acceptance. Set limits from process needs and test the environment. Validate Safety under the applicable safety lifecycle, separately from general communication tests.

Seven common brownfield failures

1. Replacing every sensor before defining the decision. More data is not value if maintenance, quality or production behavior does not change. Start from a downtime, defect, replacement or inspection use case. Our brownfield IoT retrofit guide explains staged deployment.
2. Leaving IODDs on an integrator laptop. Revision, checksum, compatible model and approval status must be shared assets.
3. Scattering raw decoding across PLCs. Scaling and invalid-state rules then diverge. Use approved blocks and a dictionary.
4. Writing “by IT” for northbound integration. NodeId, topic, schema, time, quality, certificate and retention become ownerless.
5. Always enabling automatic restoration. A wrong or incompatible Device may receive settings. Restore only after positive identity and compatibility checks.
6. Treating Wireless as zero wiring. Power, mounting, maintenance, radio and security remain. Use it where mobility or tool exchange creates value.
7. Assuming the Safety name equals certification. The whole application, chain and validation determine the claim.

Thailand policy and investment context

A Thailand BOI release cites 1,397 projects and more than THB 146 billion in the relevant 2023–2026 H1 automation and digital-modernization context. It is useful evidence of a national modernization direction, but it is not IO-Link market size and does not establish the return of an individual project.

The BOI smart and sustainable industry page describes a minimum investment of THB 1 million, a three-year corporate income tax exemption, normally capped at 50% of investment, and a cap up to 100% where domestic automation machinery represents at least 30%. Eligibility, cost scope, timing, domestic content, evidence and approval must be confirmed case by case. Buying IO-Link equipment does not automatically qualify a project. Confirm current conditions with BOI and advisers, and align the technical RFP evidence with any investment application.

Measure decisions and recovery, not connected-device count

Connected Devices and collected tags are progress measures. Operational outcomes can include:

• time from diagnostic to likely cause;
• time from replacement to normal production;
• detected parameter mismatches and correction time;
• agreement between the register and physical assets;
• data-quality rate including invalid and missing states;
• unauthorized setting changes;
• correct upstream quality propagation during faults;
• reuse of standard blocks, schemas and tests; and
• rollout items applied without redesign.

Build ROI from the plant’s own downtime, maintenance labor, defects, inspections, replacement time, licenses, engineering, training and spares. Compare a measured baseline with PoC results. Keep the time horizon, tax, exchange rate and production assumptions consistent and disclose sensitivity. Do not substitute an external market average for plant evidence.

FAQ about IO-Link implementation

Is IO-Link a fieldbus?

IO-Link is an IEC 61131-9 standardized point-to-point communication interface for sensors and actuators. A Master can connect upstream through several industrial networks, but describing Devices as nodes on one shared IO-Link bus is inaccurate.

Does an IODD guarantee identical behavior on every Master?

No. The IODD is essential for a common description, but supported revision, engineering tool, mapping, vendor features, firmware and profile support still need verification. Freeze the tested combination in FAT.

Should an IO-Link Master connect directly to MES?

It depends. Values for control may go through the PLC, while identity and diagnostics are exposed through Edge/OPC UA and events through MQTT. A direct path still needs a stable model, security, buffering and change control so MES is not coupled to a physical port address.

Does OPC UA for IO-Link eliminate data-model design?

No. It offers a common basis for Devices and Masters. The plant must still model plant, line, asset, product, lot, work order, KPI, retention and authorization.

Will IO-Link Wireless replace every wired connection?

No. It is valuable on moving, rotating, replaceable or hard-to-wire equipment. The 5 ms cycle and device maxima are conditional design values. Test coexistence, worst-case latency and loss on site.

Can a normal IO-Link sensor be used for safety through IO-Link Safety?

Do not assume so. Safety-capable components, the safety controller and application validation must support the required SIL/PL. An ordinary Device does not become safety-rated automatically.

Which points should a brownfield pilot choose first?

Choose points tied to a clear downtime, quality, replacement or inspection decision. Complete one machine’s end-to-end acceptance before scaling.

What should an IO-Link quotation separate?

Separate Devices, Masters, cable/power, network, PLC/Edge engineering, northbound integration, IODD/asset governance, FAT/SAT, shutdown work, training, spares and support. Distinguish standard, optional and custom work.

Summary: create an operating standard for point data

The success of an IO-Link implementation is not the number of compatible products purchased. Every point’s meaning, unit, range, quality, diagnostics, IODD/firmware revision, parameter and replacement history must be traceable. The boundaries from the IO-Link Master through PLC/Edge, OPC UA, JSON/MQTT and MES/Cloud must be fixed in drawings and FAT/SAT, including faults, replacement, retry, access and change. Wireless is an additional option where wiring is constrained. Safety is an additional option for a properly engineered safety chain. Neither automatically replaces standard IO-Link.

If your Thailand plant is preparing an IO-Link RFP, a 90-day PoC, a brownfield retrofit or northbound data integration, you can contact TOMAS TECH while the point register and acceptance matrix are still being designed. We can help align the machine, PLC, network and MES boundaries even for one small pilot cell.

Primary sources

• IO-Link Community — https://io-link.com/
• IO-Link Technology — https://io-link.com/technology
• IO-Link Wireless — https://io-link.com/technology/wireless
• IO-Link Safety — https://io-link.com/technology/safety
• IEC 61131-9:2022 — https://webstore.iec.ch/en/publication/68534
• OPC UA for IO-Link Devices and IO-Link Masters — https://reference.opcfoundation.org/specs/OPC-30120/4.2.6
• Thailand BOI press release — https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&page=press_releases_detail&topic_id=139138
• Thailand BOI Smart and Sustainable Industry — https://www.boi.go.th/index.php?language=en&page=smart_sustainable
• IO-Link Downloads — https://io-link.com/downloads
• IO-Link Wireless Flyer 2025 — https://io-link.com/fileadmin/user_upload/Downloads/About_IO-Link/IO-Link_Wireless_Flyer_2025_Web.pdf
• IO-Link Safety System Description — https://io-link.com/fileadmin/user_upload/Downloads/About_IO-Link/IO-Link_Safety_System_Description_eng_2018.pdf