Industrial protocols continue their development to succeed in the face of the growing demand for communications in the automation sector.
Today it is difficult to talk about connected devices without referring to the Internet of Things (IoT). But long before the IoT was even conceived, devices in industrial environments were already communicating. As communications increased, this connection trend gave rise to the M2M (machine-to-machine) era. These communications, which in principle were point-to-point, gradually evolved, bringing the production zones and the more purely administrative areas closer together, all of which were connected to each other using a common network. This is what is currently known as Industry 4.0, and now that these production plants are much more accessible from anywhere and at any time, the term Industrial IoT (IIoT) has become fully established. This natural evolution not only reflects how data collection and transfer is increasing exponentially, but also how IIoT will allow control to increase as well. To implement IIoT, trust in communications at all levels is vital. Most of the underlying requirements are already in place, but some are still starting to surface. From an engineering standpoint, getting all that interconnection in a robust and affordable form factor represents the key challenge and is what really motivates developers.
network requirements
As it affects multiple industrial sectors, the IoT in general is being approached from different angles, but what seems clear is that its implementation will need a certain hierarchy. The Internet offers the perfect structure for massive data transfer, but it is not ideal for real-time control, since its protocols include long latency periods. To take a simple example, in a connected home, all electrical appliances could communicate with and be controlled using a local network. In the same way, they could be accessed through the Internet, although it would not be the most practical since, for example, it could take several seconds to turn off a light or change the channel on television. As a consequence of this, the term “avatar device” is gaining importance and what it comes to mean is that each device has its virtual version in the cloud. Locally, the devices are controlled directly through a local network but remote control can be done through the Internet, where there are "avatars" that are the ones that receive the instructions and send them to the real objects. This duplication of objects might seem unnecessary, but it overcomes the limitations of using a non-deterministic network to control objects locally. In an industrial environment, the challenge lies in the need for real-time control, where devices send/receive small packets of data. The essential requirement is that the packets are transmitted reliably in a given time. The first industrial protocols have evolved in terms of delivery times, such as the HART protocol (Highway Addressable Remote Transducer). This protocol has the characteristic of using the previous 2-4 mA point-to-point connections but now supporting analog and digital signals in a single pair of cables. The physical interface uses FSK (Frequency Shifting Key), in which a logical “1” (mark) is a sinusoidal signal with a frequency of 1.2 kHz and a logical “0” (space) is a sinusoidal signal with a frequency of 2.2 kHz. These digital representations can be modulated with the analog current level in a range of 4 to 20 mA, making this a very versatile protocol for industrial applications. In addition, the protocol can be implemented using a microcontroller (MCU) with a suitable HART modem providing the physical interface, such as ON Semiconductor's A5191HRTPG-XTD. This can also be done using a DAC/ADC converter if the microcontroller has an ALU capable of running the necessary algorithm to generate and recognize the FSK frequencies. Although the HART protocol can be used in multidrop configurations as well, it may not be suitable for all types of industrial applications and definitely cannot be used for Internet connections.
The right tool for each case
The use of specific protocols for communications with the Internet in the industrial sector has many limitations, for example latency. Time stamps may be required in an industrial environment, something that is not supported by more common network protocols such as TCP/IP. Ethernet is the "public face" of the Internet, as most use it as an interface. It is true that Internet protocols over Ethernet are not suitable for real-time control, but it is also true that Ethernet can provide a reliable and robust industrial network infrastructure if the proper protocols are used. There are a large number of industry-specific protocols that use Ethernet as an interface. Perhaps the most notable is EtherCAT, an Ethernet-based protocol that is part of the Fieldbus family defined by the IEC 61158 standard. It uses the same physical interface as Ethernet, so it can be implemented using a microcontroller that has an Ethernet MAC, such as example the Infineon XMC4500. Infineon's XMC4000 family is based on an ARM Cortex-M and offers the XMC4800 and XMC4300 which are the first industrial microcontrollers to integrate EtherCAT on an ARM Cortex-M MCU with integrated Flash and mixed-signal capability. In an industrial network topology, the elements that carry the weight of the action (motors, heaters, pumps, actuators...) have traditionally been controlled by PLCs (programmable logic controllers). The trend in IIoT is to connect PLCs to a network using real-time, low-latency protocols, such as those of the Fieldbus family. Despite years of effort, there is still no proper Fieldbus standard, and many of the protocols that reference Fieldbus are not necessarily compatible with each other. Therefore, PLCs need to support multiple protocols in order to function in an industrial environment. Perhaps the most developed Fieldbus protocol is PROFIBUS, but there are many others such as PROFINET, CAN and Modbus. Many microcontrollers integrate CAN interfaces while Modbus can be developed through a UART and implementing the protocol on the MCU.
Software
While most of the control protocols developed in IIoT are relatively easy to implement even on low-cost MCUs, it seems reasonable to expect that we will reach a high level of consolidation. Higher capacity MCUs will be used to handle a wide range of protocols in a network topology. At this point, the use of an operating system (and in the case of industrial control, a real-time operating system or RTOS) is more than beneficial. A real-time operating system running on an MCU places certain requirements on the hardware, which has been reflected in the shift towards 32-bit architectures such as the ARM Cortex family. It is common to see processor and MCU manufacturers working alongside RTOS vendors to ensure that communication protocol stacks and real-time cores work efficiently on the hardware. An example of this is Analog Devices and Micrium. Analog Devices' Blackfin 16/32bit processors have full support of Micrium's μC/OS real-time operating system, with middleware features for TCP/IP, USB, CAN bus and Modbus, for example. The need for these industrial protocols to work on highly integrated processors is reflected in the fact that a large number of RTOS vendors now offer industrial control protocol stacks as middleware for integration with this technology.
Conclusion
Creating an industrial network that provides remote control and maintains control in real time requires a mix of communication protocols. Fortunately, semiconductor manufacturers have fully understood this and today offer a wide range of devices capable of providing the necessary hardware interfaces and processing power to make IIoT a reality. And clearly, the protocols that are currently used in the industrial environment have found their place in the IIoT world.
