Figure 1: Market shares of industrial networks: The study includes estimates from HMS for 2018 based on newly installed nodes in 2017 in the field of factory automation. A node is defined as a machine or device that is connected to an industrial network.

© HMS Industrial Networks

The first generation of fieldbus technology was developed in the 1980s and the requirement for an automation device was that it could transmit its process data via various fieldbuses such as Profibus, Interbus, CAN or Devicenet. The second generation of industrial networks followed in the 2000s with real-time Ethernet protocols such as Profinet, Ethercat and Ethernet/IP, which were able to transmit further information via the TCP/IP protocols originating from IT technology on the same cable in addition to and simultaneously with the process data. Since then, automation devices have had to support either fieldbuses or Industrial Ethernet standards, as fieldbuses still have a very high market share in factory automation around ten years after the introduction of Ethernet technology(Fig. 1).

Another technological upheaval is currently on the horizon: with TSN (Time Sensitive Networking) in accordance with IEEE 802.1, MQTT and OPC UA, new protocols originating from the IT world are preparing to enable the seamless integration of IT systems with production lines - IT/OT integration. The aim is to use a single Ethernet cable to transmit process data - including safe signals (safety) in real time - as well as data relevant to industrial IT, including information for connection to industrial cloud systems. In addition to the functional requirements, protecting automation devices against unauthorized access via the network is becoming increasingly important and security measures in hardware and software must be taken into account at field level when designing the communication interface. As a result, the requirements for the communication interface of an automation device are becoming more diverse and the communication interface is increasingly mutating into a multi-talent.

Common practice: One device, two IP addresses

In order to meet all requirements, it is common practice today to equip an automation device with two network interfaces: one for process data transmission via Industrial Ethernet or fieldbuses and a second interface for handling TCP/IP-based IT functions such as visualization, parameterization, diagnostics and quality data acquisition. This means that an automation device with an Industrial Ethernet interface often has two IP addresses in the network. This approach results in higher development and hardware costs as well as additional expenses for administration and network planning.

Another disadvantage is that it does not meet the requirements of the automotive industry. This is because the Automation Initiative of German Automobile Manufacturers (AIDA) requires that all communication functions of an automation device are handled via a single Ethernet interface and a single IP address.

Goal: One IP address for everything

The requirements for the IT functionality of automation devices vary. Basic IT functions are sufficient for simple devices such as I/O or valves. This is different for complex devices such as robots, welding or screwdriver controls. These devices typically provide far more data than pure process data. As soon as these devices can be integrated into industrial IT systems, they can be meaningfully integrated into data-based business processes - such as predictive maintenance - and thus develop their full potential.

There are two basic solution variants for implementing a modern communication interface that can handle safety and IT functions via a network connection with an IP address for fast real-time communication:

• All-In-One: Multi-network interface with real-time protocols and basic IT functions with a special network processor.
• Splitted operation: Multi-network interface in which real-time protocols and IT functions are handled on separate processors.

The all-in-one solution

The interface with basic IT functions and a special network processor is interesting for automation devices that only provide a small amount of IT-relevant information, such as valve terminals or devices where the microprocessor of the main application must not be loaded with IT functions for performance reasons - for example, in the case of a drive. In these cases, the processor of the interface handles the TCP/IP-based IT protocols such as http, FTP, OPC UA or MQTT in addition to the real-time functions of the Industrial Ethernet protocol. This solution has many advantages, as all communication functions are concentrated in one place, run on one processor and can be largely decoupled from the application software of the automation device via a suitable software interface.

Figure 2: In addition to real-time protocols, modules with basic IT functions also handle TCP/IP-based IT protocols.

© HMS Industrial Networks

Such a communication interface is usually implemented in the form of an optional module, such as the Anybus communication module from HMS(Fig. 2). In such a modular design, tasks are divided: The communication module handles all communication functions and the main processor of the automation device only takes care of the device functions. Such a distinctive communication interface also represents a first 'line of defense' for the security functions of the automation device. The decoupling of communication and application offers further advantages, as only the communication interface needs to be changed if the protocol specifications change or if coupling to other industrial protocols becomes necessary. The application software of the automation device can usually remain unchanged. Manufacturers who have little or no experience with IT functions also benefit from this. With this form of implementation, they can use the basic IT functions of the communication module such as FTP and web server, TCP/IP socket interface and e-mail client without any additional effort. Another user group are manufacturers for whom IT functions are of secondary importance.

The split operation solution

For device manufacturers who have very high demands on the IT functions, it makes sense to shift the implementation of the IT functions and the processing of the IT protocols to the application processor and only have the real-time protocols processed by the communication module. In the industrial environment, it is also important for this device category to meet the AIDA requirement of processing all communication functions via a single Ethernet interface and a single IP address on the network.

An Ethernet controller with an RMII interface can be used to solve this problem. RMII stands for 'Reduced Media Independent Interface'. Via this interface, the Ethernet controller of the communication interface is addressed directly by the device software when processing the IT protocols. The RMII acts as a data switch that separates the real-time protocols - such as Profinet, Ethernet/IP, Ethercat - from the IT protocols. The data switch must be integrated directly into the hardware of the communication interface so that correspondingly fast and high-performance response times are possible. There is also a clear division of tasks with this implementation method: the communication module processes the real-time protocols, the device processor takes over the device functions and the processing of the less time-critical TCP/IP-based IT protocols - such as the display of the device's internal web pages (http), file access (FTP) or communication with the HMI via OPC UA.

Figure 3: Anybus modules with RMII interface handle the real-time protocols and forward the TCP/IP-based protocols to the main application of the automation device via a transparent Ethernet channel.

© HMS Industrial Networks

HMS also provides a corresponding communication module for this method of interface implementation(Fig. 3). As with the variant with integrated basic IT functions, the module with RMII handles the transmission of real-time process data with the familiar Industrial Ethernet protocols such as Profinet, Ethercat, Ethernet/IP, Modbus and Powerlink completely independently. However, the IT protocols are forwarded to the main application of the automation device via the transparent Ethernet channel of the RMII interface. This offers the device manufacturer the greatest possible flexibility and individuality when implementing the IT functions.

The implementation variant with a transparent Ethernet channel is intended for manufacturers who already have a lot of experience in the IT environment and use their own operating system, such as Linux, in their automation device.

In most cases, TCP/IP-based IT protocols are part of the operating system so that device manufacturers can implement the desired IT functions directly in their application. Another user group are manufacturers who have already developed extensive IT functions for their device and are now faced with the challenge of connecting the automation device to new Industrial Ethernet networks. Thanks to the RMII interface, these manufacturers can continue to use their IT functions and still benefit from the multi-network capability of the Anybus concept.

TSN brings new challenges

Figure 4: In the Profinet protocol, TSN will replace the RT and IRT functions in layer 2 in the future.

© Profibus user organization

Device manufacturers who are currently working on the design of the communication interface are well advised to take a look into the future. After all, it has been clear since the last Hannover Messe that TSN will find its way into industrial communication in the coming years. All well-known fieldbus organizations and many PLC manufacturers have announced that they will use TSN as a technology in layer 2 of their respective protocols in the future. For example, the PI user organization is planning to replace IRT and RT communication in Profinet with TSN in the future(Fig. 4). PI has announced the completion of the corresponding extended Profinet specification for mid-2019. By then at the latest, device manufacturers will once again be faced with the challenge of adapting the communication interface of their automation devices to the new protocols. Suitable hardware support and therefore the use of special chips is essential for implementing the real-time functions of TSN. The main reason for this lies in the sophisticated synchronization and scheduling mechanisms of TSN, which cannot be implemented without special hardware solutions (protocol chips). In addition, TSN also uses Gigabit Ethernet, whereas today's industrial Ethernet protocols are mainly based on 100 Mbit technology. Although it can be assumed that the TSN functions - similar to CAN today - will be integrated into numerous commercial microcontrollers in the future, a complete redesign of the hardware and software of the communication interface will be necessary for their use.

Simply retrofit TSN

For the device manufacturer, the transition to the new communication landscape is therefore either associated with a complex hardware and software development project, or they opt for a modular solution based on ready-to-install communication modules.

An alternative to developing a TSN-capable interface in-house is to use ready-to-install communication modules, such as the Anybus modules from HMS. Such modules are ready-to-install bus interfaces for automation devices. They contain all the hardware and software functions of a powerful communication interface. Such modules are available for all common fieldbus and Industrial Ethernet protocols. Modules with TSN integration are already under development.

The great advantage of such modules is their interchangeability. HMS achieves this through a standardized hardware and software interface between the module and the device electronics that is independent of the respective bus protocol. Automation devices with a module slot can therefore easily retrofit new technologies such as TSN by replacing the module.

High-tech in three variants

Figure 5: Anybus technology is available from HMS in the form factors module, brick and chip.

© HMS Industrial Networks

Anybus modules are now available in three form factors: module, brick and chip(Fig. 5). The fastest way for device manufacturers to achieve their goal is with the ready-to-install, encapsulated communication module. In the module, the complete hardware and software of the communication interface, including the network connector, is integrated into a plastic housing. The module is designed as a plug-in module that is inserted into the corresponding slot in the automation device. The bricks give the developer more freedom when selecting the connectors and positioning the communication interface.

Manufacturers who produce their devices in very large quantities and therefore often do without modularity can license the Anybus technology as a chip along with software stacks and thus seamlessly integrate the module core technology into their device electronics.

Author:
Michael Volz is an independent management consultant and works for HMS as a senior advisor in the development of new business areas.