Industrial protocols continue to prosper in demand for networking in automation, says Simon Duggleby, Product Marketing Manager, Electronics Division, RS Components.
It is difficult to talk about connected devices today without referencing the Internet of things (IoT). But long before the IoT was conceived, devices in the industrial environment were already communicating. As the trend grew it ushered in the age of M2M (machine-to-machine).
Those early, simple point-to-point exchanges quickly evolved, to bring the shop floor and back office closer together using a common network. This became known as Industry 4.0 and now, as those plants are becoming accessible from anywhere, we have the IIoT (industrial Internet of things).
This natural evolution doesn’t just reflect how the collection and transfer of data is growing exponentially, but also how the IIoT is allowing control to follow the same path.
Building the IIoT relies heavily on communications at many levels. Much of the underlying requirements are already in place, but others are only beginning to emerge. From an engineering viewpoint, bringing all of that interconnectivity into a robust and affordable form-factor represents the kind of challenge that motivates developers.
As a cross-industry initiative, the IoT in general is being addressed from several angles, but it seems clear that its implementation will require hierarchy. The Internet offers the ideal backbone for mass data transfer, but it isn’t ideal for real-time control; there is too much latency built in to the protocols that enable the Internet.
In simple terms, in a connected home all the appliances can be connected and controlled using a local network, as well as being accessible over the Internet. It would be possible but impractical to use the Internet when controlling devices locally; it may take several seconds for a light to turn off, or a TV to change channel, for example.
Consequently, the concept of ‘device avatars’ is gaining momentum, where every device also has a virtual version in the cloud. Locally, the devices are controlled directly over a local area network. Remote control would be delivered over the Internet, where it is the avatars that are instructed to change. These changes would then be relayed to their real-world counterparts. This duplication of effort may seem frivolous but it overcomes the limitations of using a nondeterministic network for controlling devices locally.
In an industrial environment the challenge is compounded by the need for ‘hard real-time’ control, where small packets of data are sent/received between devices. The underlying requirement here is that the packets arrive reliably, in a determined time. Early industrial protocols have evolved to deliver this, such as HART (Highway Addressable Remote Transducer). This protocol has the distinction of using legacy 4-20mA point-to-point connections, and it now supports both analogue and digital signalling over a single pair of wires.
The physical interface uses frequency shifting keying (FSK), representing a logical ‘1’ (mark) as a sinewave with centre frequency of 1.2kHz, and a logical ‘0’ (space) as a sinewave with a centre frequency of 2.2kHz. These digital representations can be modulated on top of the analogue current level between 4 and 20mA, making it a versatile protocol for industrial applications.
Furthermore, the protocol can be implemented using a microcontroller (MCU), with a suitable HART modem providing the physical interface, such as the A5191HRTPG-XTD from ON Semiconductor. This may even be achieved using current data convertors if the MCU can run the algorithm needed to generate and recognise the FSK frequencies.
While the HART protocol can also be used in a multi-drop configuration, it may still not be suitable for every industrial application, and almost definitely wouldn’t be used for networking to the Internet. This mix and match of protocols is typical in industrial control, and there is little sign of it changing any time soon.
The right tool for the job
The use of protocols intended specifically for Internet communications has many limitations in an industrial environment. As well as latency, it may be necessary to time-stamp events in an industrial environment, a feature that isn’t supported in common networking protocols such as TCP/IP.
Ethernet is the ‘public face’ of the Internet, as it is the way most people interface to it. While it is true that the Internet protocols used over Ethernet are not suitable for real-time control, it is also true that Ethernet can, in fact, provide a robust and reliable industrial network infrastructure when the right protocols are used.
There are a number of protocols targeting the industrial sector that use Ethernet as an interface. Most notable, perhaps, is EtherCAT. This is just one of the Ethernet-based protocols that now form part of the Fieldbus family as defined by the IEC 61158 specification. Because it uses the same physical interface as Ethernet, the EtherCAT protocol can be implemented using a microcontroller that has an Ethernet MAC, such as the XMC4500 from Infineon. The XMC4000 family is based on the ARM Cortex-M, and Infineon now offers the XMC4800 and XMC4300 which are the industry’s first microcontrollers to integrate an EtherCAT node on an ARM Cortex-M MCU with on-chip Flash and mixed-signal capabilities.
In an industrial topology, the devices that actually carry out the actions (motors, heaters, pumps, actuators etc) are traditionally directly controlled by a PLC (programmable logic controller). The current trend in the IIoT is to network PLCs using low latency, real-time protocols such as those in the Fieldbus family.
However, despite the name and years of effort, there is still no common Fieldbus standard, and the many protocols that reference it are not necessarily interoperable. As a result, PLCs need to support multiple protocols in order to operate in a more networked industrial environment.
Perhaps the most widely deployed of the Fieldbus technologies is Profibus, but there are many others including Profinet, CAN and Modbus. Many microcontrollers now integrate CAN interfaces, while adding Modbus can be achieved using a UART and implementing the protocol in the application running on the MCU.
Although many of the protocols deployed for control in the IIoT are relatively simple to implement in even a low-cost MCU, it would seem reasonable to expect a high level of consolidation to take place; more capable MCUs will be used to handle a wider range of protocols in a networked 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 likely to be beneficial. Running an RTOS on an MCU imposes certain requirements on the hardware, which is now reflected in the shift towards 32bit architectures such as the ARM Cortex-M family.
It is not unusual for MCU and processor providers to work closely with RTOS vendors to ensure communication stacks and real-time kernels run efficiently on their hardware, such as Analog Devices and Micrium. Analog Devices’ Blackfin 16/32bit embedded processors are closely supported by Micrium’s μC/OS real-time operating system, which features middleware for TCP/IP, USB, CAN bus and Modbus, for example.
The need for these industrial protocols running on highly integrated embedded processors is reflected in the fact that a wider number of RTOS vendors now offer protocol stacks for industrial control as middleware for integration into their technology.
Creating an industrial network that provides remote control and maintains real-time control will require a mixture of communication protocols. Fortunately, semiconductor providers understand this and already offer a range of devices capable of delivering the hardware interfaces and processing power needed to make the IIoT a reality. It is also clear that protocols currently used in the industrial arena will still have a place in the IIoT.