08 Aug 2016

Migrating from M2M to the IIoT Industrial Internet of Things

Simon Duggleby, RS Components, looks at how industrial protocols & M2M machine communications is migrating to the IIoT as demand increases for industrial automation.

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, at any time, the term ‘Industrial IoT (IIoT)’ has taken hold.

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, while 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.

Wide-ranging requirements

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 may be connected and controllable 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 non-deterministic 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 over time to deliver this, such as the HART protocol (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 sine wave with centre frequency of 1.2kHz, and a logical ‘0’ (space) as a sine wave with a centre frequency of 2.2kHz. These digital representations can be modulated on top of the analogue current level in the range of 4 to 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 DAC/ADC converters if the MCU has an ALU capable of running 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 appropriate protocols is endemic in industrial control, and there is little evidence 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 notably, 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. 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.

Software support

While 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 32-bit architectures such as the ARM Cortex-M family.

It is not unusual for MCU and processor providers to now 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.

Page 1 of 1

About the author

Simon Duggleby is Semiconductor Marketing Manager, RS Components. He has a Master's Degree in Electronics and Computer Systems Engineering from Loughborough University. Since graduating, he has worked in the field of electronics distribution, first as an Applications Engineer with Abacus ECD (now part of the Avnet Group), then joining RS Components in 2009 as a Technical Marketing Engineer. For the past two and a half years, Simon has been responsible for steering the marketing strategy of the Semiconductor product category at RS.

RS Components and Allied Electronics are the trading brands of Electrocomponents plc, the global distributor for engineers. With operations in 32 countries, we offer more than 500,000 products through the internet, catalogues and at trade counters to over one million customers, shipping around 44,000 parcels a day. Our products, sourced from 2,500 leading suppliers, include electronic components, electrical, automation and control, and test and measurement equipment, and engineering tools and consumables.

Most popular articles in Wireless technology

  • IoT Device Management: Why You Need it and How it Works
  • Long-range wireless networks can get a bandwidth boost from picocells
  • Implementing ZigBee Light Link for Lighting Control
  • Designing for the IoT: Overcoming the antenna challenge
  • IoT and MEMS in Connected Agriculture
  • Share this page

    Want more like this? Register for our newsletter

    The Developing Role of Electronic Component Distributors Ian Poole | Electronic Notes
    The Developing Role of Electronic Component Distributors
    The service that electronic component distributors has provided over the years has changed very significantly. Nowadays, distributors provide a very effective service, meeting the many needs of development, manufacturing and service organisations small and large.

    Radio-Electronics.com is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on Radio-Electronics.com, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy