Arduino based Framework for Rapid Application Development of a Generic IO-Link interface

. The implementation of IO-Link in the automation industry has increased over the years. Its main advantage is it offers a digital point-to-point plug-and-play interface for any type of device or application. This simplifies the communication between devices and increases productivity with its different features like self-parametrization and maintenance. However, its complete potential is not always used. The aim of this paper is to create an Arduino based framework for the development of generic IO-Link devices and increase its implementation for rapid pro-totyping. By generating the IO device description file (IODD) from a graphical user interface, and further customizable options for the device application, the end-user can intuitively develop generic IO-Link devices. The peculiarity of this framework relies on its simplicity and abstraction which allows to implement any sensor functionality and virtually connect any type of device to an IO-Link master. This work consists of the general overview of the framework, the technical background of its development and a proof of concept which demonstrates the workflow for its implementation.


Introduction
The IO-Link specification has expanded the features that sensors and actuators can have. Its features include self-parametrization, maintenance and generic data structures. Its implementation has increased the available options for developers and manufacturers in the automation industry. However, the development of these devices does not follow a unique workflow and can depend on the manufacturer. This paper proposes a solution to simplify its development and allow rapid-prototyping development. With the creation of an Arduino based framework, all the available features of an IO-Link device are accessible to any developer through an abstraction layer that simplifies its use.

Framework overview
The design of the framework was intended to have an easy-to-use approach, such that the end-user didn't need to understand in a detailed manner the IO-Link specification. Its main objective was to create a tool that enabled a rapid prototyping approach and focused more time on to the development of device applications.
To simplify the workflow a graphical user interface (GUI) was developed. It allows the end-user to set up the device parameters and generate the IODD file. Furthermore, it creates a header file to setup options for the firmware application. Another essential part was the hardware interface that communicates with the IO-Link master. The general overview of the interaction between all the described components is shown in Figure 1. IO

Firmware
The backbone of the system is the firmware, which runs in the background of the enduser's device application. For the selection of the embedded processor the Arduino Framework was used since it's a well-known low-cost and open-source platform that meets the requirements for its use as an IO-Link device. The arduino framework consists of different development boards, for this particular case the Arduino Nano (atmega328p) was used due to its small factor size and enough peripherals (i.e. ADC, GPIO's, I2C/SPI). The microcontroller's peripherals used for the firmware's operation were the UART and two I/O pins to synchronize the data exchange according to the IO-Link specification.
Nevertheless, using this board brought certain limitations. The first one is the maximum baud rate supported for IO-Link. This meant that the COM2 mode transmission was used (38,4 kbit/s). In addition, the EEPROM is used to save non-volatile parameters of the device. Since the writing speed is rated to 3,3 ms per byte [1], this limits the maximum amount of writeable parameters without blocking the device application.

Fig. 2. Microcontroller pinout functions
The firmware is based on the current IO-Link specification described in [2]. It contains the most important features that developers would need to use the main features of the IO-Link technology, which consist of: The firmware operates by executing the respective state machines that manage the IO-Link device's features in the background. Each time a new process cycle occurs, the user's device application is called, which, can update its process data and execute any other defined instructions. The initialization of the firmware is done by passing as arguments the user's subroutine and process input data (if available), afterwards, in the main loop, the IO-Link state machines are executed (see Figure 3).

Fig. 3. Firmware implementation in a sketch file
As aforementioned, to reduce development time, the customizable parameters of the firmware are written to a header file by means of a GUI. This header file contains the identification parameters of the devices as well indicates which IO-Link features the device will have. This implies that the final size of the firmware at compilation time will depend to a great extent on the selected features by the end-user. Table 1 shows a rough estimation of the firmware's size depending on some of these features.

GUI
The main interaction with the framework is done through the GUI. Its main functions are to generate the IODD file and the header file for the firmware. The input parameters are separated by four tabs (i.e. identification parameters, process data, custom parameters and events). The "Identification Parameters" tab includes the obligatory parameters that an IO-Link device must have described in [2] and [3]. Furthermore, an interactive display shows the maximum allowed sampling time for the user´s device application taking in to account the number of custom parameters due to the EEPROM´s limitation and the time it takes to complete an M-Sequence message considering the on-request data size in operation mode and transmission mode (COM2).

Fig. 4. GUI for the framework
The "Process Data" tab manages the structure of the data that is going to be sent from the IO-Link master to the IO-Link device and vice versa. In addition, since some applications may have common functionalities, it is possible to implement some of the smart sensor profiles described in [4]. The "Custom Parameters" tab enables the user to have extra parameters, which are written and read from the EEPROM of the device. Finally, the "Events" tab is used to indicate if the device has any of the standard events described in [2] or add custom events by the user.   The generation of the files is done by clicking a button. Considering that the files need to comply with the IO-Link specification, restrictions were implemented to avoid errors from the user. The GUI notifies the user if the files cannot be created through a notification window that describes any specific error (see Figure 8).

Hardware interface
The hardware components of the framework consist of the Arduino Nano development board and the development of an Arduino IO-Link shield. This shield includes the IO-Link transceiver for the communication between the microcontroller and the IO-Link master. Table 2 shows a comparison of different transcievers in the market. The selection of the transceiver was based on a chip that could offer a minimal design setup and at least 200 mA of output current to power up the microcontroller and the sensor application. The MAX14827 falls short on simplicity and the L6362A does not provide enough output current. Therefore, the TIOL11-5 was the best option for this case since it has the lowest number of pins, enough output current and in addition integrated protection. The electric schematic of the IO-Link shield is shown in Figure 9.

Proof of concept
Different features were tested to demonstrate the functionalities of the framework. The general workflow of the framework is shown in Figure 11. These tests were done with the following hardware: IO-Link shield PCB described in section 5  Fig. 11. General workflow of IO-Link device creation

IO-Link distance sensor
For this example, a distance sensor from Sharp model GP2Y0A21YK0F was implemented. This sensor has an analog output, which corresponds proportionally to the distance measured. Table 3 gives a full description of this device.  The parameters were set to match the required sensor as seen in Figure 13. In addition, diagnostic events were set as seen in Figure 14. The main routine for the Arduino Nano consisted of reading the analog value of the sensor and converting it to the measured distance in centimeters. Due to a low range and far range limitation from the sensor, standard events from the IO-Link specification were implemented so each time a certain threshold was reached the IO-Link master is notified (see Figure 15).  Through the IO-Link master the parameters from the IO-Link device were read (see Figure 16). Afterward, the distance values from the sensor are acquired through the PLC as seen in Figure 17. From the main program of the PLC, it can be seen that the size of the received data in the function block (i.e. "udiRecievedbytes") is the same as the one set in the GUI.

Conclusions
The results provided by the framework demonstrate a methodology for the creation of rapid prototyping IO-Link devices. The end-user only requires a general overview of the IO-Link specification and the description of its device application. Its advantage is that with just a few steps through a GUI any type of application can be created, modified or retrofitted to IO-Link. Thus, it offers a versatile approach for the development of low-cost IO-Link devices on the fly. Furthermore, with its high-level abstraction layer it reduces the required development time. At the same time, this opens up the possibilities for developing new interfaces and applications with IO-Link. The aforementioned advantages can contribute to increase the implementation of IO-Link and its key features.