Successfully Integrating IO-Link: A Technical Guide for Newcomers
The decision has been made: the new sensor or actuator product is to become IO-Link capable. This often happens due to market adjustments or direct customer requirements. However, anyone faced with the task of integrating IO-Link into an existing or new system architecture for the first time quickly encounters a series of fundamental questions.
This article highlights the most common technical and organizational challenges in IO-Link integration and shows how you can achieve a certified product in a predictable and resource-efficient manner.
System Architecture: What Should Be Considered When Selecting Hardware?
One of the first hurdles is assessing the technological maturity of the existing platform. The basic technical structure for IO-Link essentially comprises the microcontroller (MCU), the IO-Link transceiver (PHY), and the peripherals.
What you need to look out for:
Memory space (Flash/RAM): The IO-Link stack requires resources on the MCU. Is the existing controller sufficiently dimensioned, or is an upgrade necessary?
Non-Volatile Memory (NVM): IO-Link devices must be able to store certain parameters permanently. An NVM (e.g., EEPROM) is mandatory.
Make-or-Buy: Will you develop the stack yourself or integrate a ready-made IO-Link stack? An early make-or-buy decision saves months of development time.
The Data Model: Process Data vs. Parameters and the IODD
An IO-Link product may only be marketed as such if it meets the strict requirements of the IO-Link specification.
Process data (cyclic): These are the actual measurement or control values that are transmitted continuously and in real time (e.g., temperature value or switching status).
Parameters / Diagnostic data (acyclic): These are configuration data, roles, rights, or events. These are only requested or written by the master as required.
DataStorage: An essential feature of IO-Link is data storage (DataStorage). If the user replaces a sensor in the field, the master can automatically download the parameters to the new device.
The IODD (IO Device Description): All these data types, parameters, and diagnostic information must be described in a standardized way in the IODD file. Without an error-free IODD, the product cannot be integrated into customers’ control systems later on.
Certification and Testing: Why and How?
An IO-Link product may only be marketed as such if it meets the strict requirements of the IO-Link specification.
Membership in the IO-Link Community: To be allowed to use the IO-Link trademark rights (logo) and to issue the official manufacturer’s declaration, companies usually have to acquire a manufacturer ID. Membership in the consortium is the standard way to do this and also provides access to tools and standards.
Why test so early? A failed certification run at the end of development costs a lot of money and time. It is essential to carry out pre-compliance tests during development.
The Certification Check: Before the official market entry, a diagnostic report should be created to identify weaknesses in hardware and software at an early stage.
Many development teams spend weeks familiarizing themselves with the basics and checking whether integration is even worthwhile. Our IO-Link Pathfinder Workshop is specifically designed for this initial phase, targeting technical project management, product management, and development.
In a compact 4 hours (split into 2×2-hour remote sessions), we will work together to develop a clear roadmap for your IO-Link development.
Any questions?
- +49 761 21443640
- +49 761 21443636
- info@teconcept.de
Would you like to have a look at your existing architecture and check without obligation whether the IO-Link Pathfinder is the right next step for your team?