The Industrial Internet of Things (IIoT) shows promise for the generation and use of Big Data in automation, but it is delivering little, as of yet. This is partly because deployment costs are high, and the benefits are not clear-cut. It’s also because the concept is not well defined. More importantly, the unique demands of automation are not easily solved with commercial IoT solutions.
So just what are these demands that are not easily address with commercial IoT? They can be summarized as:
- The need for real-time communications.
- Strict compliance to cybersecurity standards and practices.
- The ability to leverage new and evolving standards, such as Time-Sensitive Networking (TSN), Open Platform Communications (OPC) Unified Architecture (UA), and MQTT.
In this blog, we’ll take a closer look at these demands.
The need for real-time networks
Data communications are the foundation of modern automation. The digital age first welcomed fieldbus and then Ethernet, bringing device-to-controller and controller-to-controller connectivity. Deterministic—that is, predictable—performance is essential and real-time requires additions to the Ethernet specification. Note the word “additions.” If the nirvana of plant-floor to top-floor communications is to be successfully reached, a real-time solution has to be compatible with raw Ethernet.
Several ways of achieving that have been developed and industrial Ethernet has become one of the driving forces behind modern automation systems. However, there are several versions of industrial Ethernet, none of which are compatible; and that has led to the same diversification of solutions as with fieldbus.
Users often find themselves captured inside a particular communications universe as a result. This is not intrinsically bad since all vendors support product ranges—from field devices to programmable logic controllers (PLCs) and distributed control systems (DCSs)—that deliver excellent results. However, two difficulties result: third parties have to support all universes and end users do not have an open field to deal with.
The openness and transparency of cloud-based systems brings big security risks. But several approaches exist that can be used to protect against malicious attacks. IEC 62443 defines a set of criteria to which systems can be designed. For instance, the chip architecture should be divided between the network-facing parts and the slave-facing segments. These shouldbe logically isolated, separating the communications functions from the application tasks. Should a cyber intrusion occur, this isolation limits the effect of a malicious attack.
Supporting standards: TSN, OPC, and MQTT
Since it’s unlikely that the various communication universes will ever merge into a single protocol solution, perhaps a way of synchronizing data transfers might help. That’s the underlying premise of TSN.
TSN is vendor neutral. It’s a set of IEEE 802 Ethernet sub-standards intended for real-time Ethernet architectures. TSN achieves determinism by using time synchronization and a schedule that is shared among network components. By defining queues based on time, TSN guarantees strict latency (i.e., delay) through switched networks. The promise for TSN users is a common physical layer, with the various fieldbus protocols becoming application layer issues. The full TSN specification is still emerging.
Two standards that have been around for a couple of decades are becoming important for IIoT: OPC UA and MQTT. OPC UA, with its clever information model concept (and now with TSN included via OPC UA TSN), promises network transparency literally from plant floor to cloud. And not just for raw data but also for information (i.e., data that carries meaning). MQTT is a light messaging protocol that will also be important in this context, though probably linked with middleware products that can add the semantics needed by higher-level systems.
The future of automation will be profoundly different, but the changes will be evolutionary rather than revolutionary.