Sensors are the main data sources in automation and therefore the basis of Industry 4.0. IO-Link has established itself as the global communication standard for sensor technology in factory automation. However, in order to make sensor data available via IO-Link, the sensor manufacturer requires an IO-Link master device, usually in the form of an IP67 field device, which maps its data to the fieldbus protocols. The system scope scales with the number of supported fieldbus protocols and hardware variants. However, additional requirements are now being placed on the components: Customers often expect an existing web or OPC UA server with 'IO-Link OPC UA Companion Profile', firmware update options and now also secure data transmission; all requirements that increase the necessary system scope.

The hardware structure of the IO-Link device with integrated edge gateway in a 60 mm x 200 mm IP67 housing.

© Hilscher

In general, the data from the field level is tapped at the controller or the fieldbus network. The controller makes its data available via the programming interface or the integrated OPC UA server - but only this data and not special diagnostic data from the peripheral components or even the subordinate sensors. Only an edge gateway, integrated in the network directly in front of the controller, can read all cyclical real-time data. The Edge Gateway can also access field devices and sensors via acyclical services of the fieldbus protocol or via future, integrated OPC UA communication. The Edge Gateway can thus filter all relevant process data and supplement it with metadata. This process information can then be transferred to the ERP and MES system or to the user's cloud via appropriate connectors while complying with security standards.

However, there is also device data and data relating to the network status, which is primarily used for system diagnostics and maintenance. These should be aggregated across devices and manufacturers, network-specific and depending on the selected system architecture. It makes sense and offers further options for 'ownership of data' if these are already separated in the Edge Gateway and displayed in a global Edge Portal. This is done after approval by the 'data owner' and the OEM's restricted view of their own devices or the operator's view of all devices in their machine or system. In this way, the system view creates added value for everyone involved. In the event of servicing, it is interesting to know which devices with which firmware are affected, and also to be able to access these devices remotely for diagnostics or firmware replacement. In addition, functional enhancements could be implemented by loading special modules and device development could be optimized. The system manufacturer is also interested in a possible cross-manufacturer configuration of the system, the display of the device and network status or the automatic maintenance of a system logbook through to the mapping of the peripheral components as a digital twin.

Security is an important aspect: this is also a key requirement for the Edge Portal. This is why security is a cross-system function that must be able to integrate, update or replace all system devices and the associated certificate management. This point in particular shows that the system solution requires a coordinated technology platform consisting of software and hardware.

The chip set of the IO-Link master

Built-in diagnostic functions in the smart IO-Link transceiver.

© Hilscher

In the Hilscher solution, the chip set for the IO-Link master consists of the netX 90 multiprotocol controller and the smart IO-Link transceiver netIOL.

The chip set is characterized by its compactness and high degree of integration, which leads to a significant reduction in components and complexity. An eight-channel Class A IO-Link master module plus an additional digital input can thus be implemented in a housing that is just 30 mm wide with PCB assembly on one side.

The netX 90 has two M4 cores and divides the software into a communication and application part. While the communication is available as scalable standard firmware for Ethernet/IP, Ethercat and Profinet, OEM customers can largely design the application part themselves. Up to four IOL transceivers, each with four channels, are operated via an SPI interface. The computing core of the netIOL controls and monitors the inputs and outputs and carries out the error handling of the IO-Link protocol independently. This achieves the shortest cycle time of the IO-Link protocol of 400 µs at each IO-Link port.

The Edge Connectivity

Edge connectivity in the IO-Link master device is achieved through the additional use of the netX 4000 network controller. It also has two computing cores: a 400 MHz R7 is required for fast reading and filtering of real-time data from the Ethernet communication; a hardened Linux with the Edge software runs on the 600 MHz A9 dual core.

Functionally, the IO-Link master and Edge Gateway work completely independently of each other. Built in a single housing, this results in further cost benefits and simplifies I4.0 integration for both the OEM and the system operator. The device can optionally be retrofitted by replacing the IO-Link master device with the compatible, integrated gateway solution.

The smart IO-Link transceiver

The IO-Link transceiver contains four IO-Link channels, each with an output current of 200 mA. This can be amplified to 2 A using an external FET. Alternatively, this channel can be configured as a digital output or input of type 1, 2 or 3. An additional gate driver is available for switching the sensor supply L+. In addition, each channel has a further digital input and a gate driver. This means that the transceiver can also be operated as a universal IO with up to eight inputs or outputs and four switched L+ supplies. The sensor supplies and digital outputs are protected via individually programmable current limiters of the gate drivers.

Complete galvanic isolation can be achieved with a 4-channel SPI isolator - for example for a Class B IO-Link interface. All currents and voltages of the outputs and inputs as well as the chip temperature at the four output drivers are measured and monitored by the integrated processor. Read out via SPI, they are generally available in the information model of the OPC UA server. The status of the inputs and outputs or their error status is displayed on an LED matrix with up to six LEDs per channel. The transceiver currently requires the use of the netX 90 with its integrated RISC controller for fast SPI communication.

The local configuration of the edge gateway or the IO-Link master device is carried out using a mobile device, app and Bluetooth communication. Depending on the configured rights, Bluetooth communication is switched on via a flashing sequence on the mobile device and indicated by a blue LED. This is designed in the shape and size of an M8 connector and enables simple use in an IP67 metal housing.

An app is also available for configuring the IO-Link sensors.

Security by design

The netX 90 and netX 4000 modules offer a hardware-based root of trust on which mechanisms such as Secure Boot are based. Based on state-of-the-art cryptographic algorithms and key sizes - RSASSA-PSS up to 4096 bits, ECDSA up to 512 bits - Secure Boot enables the integrity and authenticity check of every single software that is started on the system. As the Secure Boot process is completely hardware accelerated, the devices still meet the 'Fast Start Up' of Profinet or the 'QuickConnect' of Ethernet/IP. Confidential information and pre-installed X.509 certificates, which are linked to the unique chip ID of the netX, are securely stored in a TPM chip. This enables secure and authenticated M2M communication based on tamper-proof device identities.

The netX 90 and 4000 devices have hardware-based barriers between the computer cores. This provides an additional layer of protection that prevents attacks from spreading from one core to another. The IP67 system comes with an embedded SSL/TLS stack that enables secure IIOT communication based on OPC UA or MQTT Security. Despite the complexity of SSL/TLS, high performance can be achieved through the use of numerous cryptographic hardware accelerators.

The basis: Microsoft Azure IoT

Microsoft Azure IoT serves as the basis for Edge technology. The decision to use this platform is based on the following aspects:

• To ensure that data sovereignty lies with the gateway operator, the device data should already be handled separately from the process data in the Edge Gateway. While the process data is delivered to different IT/cloud platforms via corresponding connectors, the general management of the devices is carried out by a central solution provided in the public cloud.
• The Edge platform should have an open, simple and well-documented interface that allows any OEM to connect their devices to the platform, even if no netX technology is used.
• The modular software architecture of the edge gateway should be based on Docker-compatible containers that can be easily deployed on the devices from a central location.
• The basic technology on the edge gateways should be freely available as open source and make the use of OPC UA as simple as possible.

The Hilscher solution is based on the 'Microsoft Azure IoT Reference Architecture' with the use of 'Azure IoT Edge Services' and various Azure services and SDKs. It is a hybrid cloud and edge IoT solution for device management and data integration in the Industrial Internet of Things. It consists of central cloud-based device management in the Edge Portal and decentralized data processing in the Edge Gateway.

The public cloud is hosted in data centers in the Microsoft Azure region of Western Europe.

The Edge Gateway

The software architecture and the interaction between Edge Gateway and Portal.

© Hilscher

The gateway is based on a hardened Linux operating system with a collection of services that provide an intelligent edge solution. Operating system-specific functions for configuring the gateway are abstracted via a gateway configuration service. The IoT edge services enable bidirectional communication between the edge gateways and the central edge portal. In compliance with security standards, the Edge Agent enables the gateway to receive and execute Docker-compatible software modules and communicate the results. These modules can be linked by the Edge Runtime to form productive data pipelines that communicate efficiently and independently of each other via a local message broker. A software module simply defines the inputs and outputs of its messages, which can then be combined in a specific sequence via configuration.

The Edge Portal

The Edge Portal connects and manages the field devices from a central location. It enables the monitoring and configuration of the devices as well as the functional extensions of the Edge Gateway by rolling out and executing Docker-compatible software modules. Hilscher provides a module for network diagnostics; additional modules can be created by the OEM or third parties. The portal is an open and flexible white-label platform that can be adapted to the OEM's corporate design or extended with additional functionalities using the REST API and SDKs.

The technology platform

The technology platform, implemented in a system solution

© Hilscher

The netField technology platform aims to enable OEMs to transform their components into an Industry 4.0-compliant system solution at a manageable cost and with the shortest possible time-to-market. Building on the basic technology, the OEM contributes its special requirements and expertise and thus differentiates itself in the market. The chip technology used guarantees long-term availability.

TSN and OPC UA technologies are already included today. Implementation or integration into the system will take place as soon as the specifications are stable and comprehensively standardized.

Author:
Hans-Jürgen Hilscher is Managing Director ofHilscher-Gesellschaft für Systemautomation.