Migrate from M2M to IIoT

朗锐智科

Migrate from M2M to IIoT [Copy link]

As the need for industrial automation increased, industrial protocols and M2M machine communications gradually migrated to the IIoT Industrial Internet of Things. Many of today's connected devices would be unthinkable without the Internet of Things. However, devices in industrial environments were already communicating long before the Internet of Things was conceived. As it evolved, it ushered in the era of machine-to-machine (M2M). These early simple point-to-point exchanges quickly evolved, using common networks to bring the shop floor and back office closer together. This has been called Industry 4.0, and now, as these factories become accessible anywhere, the term “Industrial Internet of Things (IIoT)” has taken hold. This natural evolution reflects not only how the collection and transmission of data has grown exponentially, but also how the IIoT is allowing control to follow the same path. Building the IIoT relies heavily on communications. Many of the basic requirements are already in place, while others are just beginning to emerge. From an engineering perspective, incorporating all this interconnectivity into a powerful and affordable form factor is a significant challenge for developers.

Broad Requirements

As a cross-industry initiative, the Internet of Things in general is being tackled from several angles, but it seems clear that its implementation requires a hierarchy. The Internet provides an ideal backbone for massive data transfer, but it is not suitable for real-time control; there are too many delays built into the protocols that enableInternet.

In simple terms, in a connected home, all devices can be connected and controlled using a local network and can be accessed via the Internet. Using the internet when controlling devices locally is possible but impractical; for example, it may take several seconds for a light to turn off, or for a TV to change the channel. Therefore, the concept of “device avatars” is gaining momentum, where each device also has a virtual version in the cloud. Locally, the devices are controlled directly over the LAN. Remote control would be passed over the internet, where it is the avatar that is instructed to change. These changes would then be forwarded to their real-world counterparts. In industrial environments, this is further complicated by the need for “hard real-time” control, with small packets of data being sent/received between devices. The basic requirement here is that packets arrive reliably within a deterministic time. Early industrial protocols have evolved over time, such as the HART protocol (Highway Addressable Remote Transducer). This protocol has the distinction of using traditional 4-20mA point-to-point connections, but now supports both analog and digital signaling over a single pair of wires. The physical interface uses frequency shift keying (FSK) to represent a logical "1" (mark) as a sine wave centered at 1.2kHz, and a logical "0" (space) as a sine wave centered at 2.2kHz. These digital representations can be modulated over analog current levels ranging from 4 to 20mA, making it a common protocol for industrial applications.

Alternatively, the protocol can be implemented using a microcontroller (MCU) with a suitable HART modem providing the physical interface. If the MCU has an ALU capable of running the algorithms required to generate and identify FSK frequencies, this can even be implemented using current DAC/ADC converters.

While the HART protocol can also be used in a multidrop configuration, it still may not be suitable for every industrial application and will almost certainly not be used to connect to the Internet. This "mix and match of appropriate protocols is popular in industrial control, and there is little evidence that it will change any time soon.

The Right Tool for the Job

The use of protocols specifically designed for Internet communications has many limitations in industrial environments. In addition to latency, there may be a need to timestamp events in an industrial environment, a feature that is not supported by commonly used network protocols such as TCP/IP.

Ethernet is the “public face” of the Internet, as it is how most people interface with it. While it is true that the Internet protocols used on Ethernet are not well suited for real-time control, in reality, Ethernet can also 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. The most notable is probably EtherCAT. This is just one of the Ethernet-based protocols that now form part of the fieldbus family defined by the IEC 61158 specification. Since it uses the same physical interface as Ethernet, the EtherCAT protocol can be implemented using a microcontroller with an Ethernet MAC. In industrial topologies, the devices that actually perform the actions (motors, heaters, pumps, actuators, etc.) are traditionally controlled directly 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 fieldbus technology is PROFIBUS, but there are many others, including PROFINET, CAN, and Modbus. Many microcontrollers now have integrated CAN interfaces, while the addition of Modbus can be accomplished via a UART with the protocol implemented in an application running on the MCU. Software Support While many of the protocols deployed for control in the IIoT are relatively simple to implement in low-cost MCUs, it seems reasonable to expect a high level of integration. More powerful MCUs will be used to handle a wider range of protocols in the network topology. At this point, the use of an operating system (and for industrial control, a real-time operating system, or RTOS) can be beneficial. Running an RTOS on an MCU places certain demands on the hardware, now reflected in the move to 32-bit architectures such as the ARM Cortex-M series. It is not uncommon for MCU and processor providers to now work closely with RTOS vendors to ensure that the communication stack and real-time kernel run efficiently on their hardware. Analog Devices' Blackfin 16/32-bit embedded processors are closely supported by Micrium's μC/OS real-time operating system, which features TCP/IP, USB, CAN bus, and Modbus middleware. The demand for these industrial protocols running on highly integrated embedded processors is reflected in the fact that more RTOS vendors now offer protocol stacks for industrial control as middleware integrated into their technology.5pt]Conclusion

Creating industrial networks that provide remote control and maintain real-time control will require a mix of communications protocols. Current semiconductor suppliers understand this and have already provided a range of devices that provide the hardware interfaces and processing power required to make the IIoT a reality. It is also clear that the protocols currently used in the industrial sector will still have a place in the IIoT.