IO-Link Data Definitions

There is no question that over the last ten years, IO-Link has moved from obscurity to become one of the most important connectivity options for manufacturers. Its acceptance is on par with how fast EtherNet/IP was accepted by the Allen-Bradley community or PROFINET IO was accepted by the Siemens community.

There are lots of reasons for that:
1. Ease of use. Standard cables and connectors.
2. Price. IO-Link sensors are price competitive with HART and 4-20ma sensors.
3. Power on the cable. No additional POWER cables to run.
4. Adapter platforms to bring the IO-Link sensor data into EtherNet/IP, PROFINET IO, EtherCAT, and other networks and then into programmable controllers.

Getting I/O into a controller has always been the focal point of industrial automation. In the beginning, every device had a wire run back to a PLC rack and we used tens of thousands of wires to automate a machine. Over the years, there have been numerous ways to reduce the labor, cost and I/O integration time: DH+, RIO, DeviceNet, PROFIBUS, ASI and more. None have been as fully accepted into the market as IO-Link, probably because it is not an offering from a single large vendor. As independent technology, it’s controller neutral.

One of the very interesting things about IO-Link is the IODD (device description) file. This is the equivalent of EDS files for EtherNet/IP devices and GDML files for Profinet IO. Just like these other technologies, IODD files provide information on the identity and functionality of the device. For identity, the IODD describes product variants of products – some devices have slightly different parameters, processes, diagnosis data, and communication. A benefit of this system is that the various characteristics of sensors and actuators don’t result in an unnecessarily high number of device description files. For functionality, the Device Function data provide a description of the device’s parameters, process data, diagnosis data and configuration of the user interface.

Like many of these other tools, a checker, the “IODD Checker,” validates the structure of the data in the IODD and ensures that the rules of the IODD specification are followed. And unlike other tools of this nature, the IODD is stamped by the Checker. In fact, validation by the checker is mandatory. The IO-Link Engineering tools only accept stamped IODDs.

Another interesting fact about IODD files is that there is a central repository for them on the internet. Vendors typically post the IODD files for all their sensors on their website but also post them in the repository, which means that users have a quick and easy place to access them. This is a vast improvement over other competitive technologies. With DeviceNet, PROFIBUS, and others, you have to go find the vendor’s website and search it to find where the configuration files are. Having them all in one repository is incredibly helpful to the user.

There is one weakness that I believe is being addressed. There are hundreds of vendors offering adapters from IO-Link to PROFINET IO, EtherNet/IP, and other networks. Somehow, the data in the IODD file must get into the destination controller. It’s not readily apparent that this is a simple and efficient process. For the sensor data to be useful to a controller, it needs to understand the identity and functionality of the sensors and sensor data that comes in over the IO-Link channel. To truly make IO-Link useful and automatic in the future, there needs to be an automated process to get that done.

I’m looking forward to learning more about how that process is going to be managed.