Industrial Internet of Things (IIoT)

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.
• A path for device-to-cloud connections.
• Adoption of cloud-based automation and IoT solutions.

In this issue, we’ll take a closer look at the first three demands listed above.

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.

Hilscher realized that the market needed to support all universes equally, so a flexible adapter solution was developed. The company launched its own family of netX chips that enable a product to be configured for any popular protocol via a simple configuration change.

Gateways and adapters, like the netTAP and cifX PC card families, offer single-solution interfaces capable of serving all protocol universes, whether built into a device by the OEM or implemented in the field by the system integrator or end user.

Bullet-proof cybersecurity

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. Hilscher’s netX 90 and netX 4000 chips support IEC 62443 strategies by providing a range of mechanisms for protecting data integrity.

For instance, the chip architecture is divided between the network-facing parts and the slave-facing segments. These are logically isolated, separating the communications functions from the application tasks. Should a cyber intrusion occur, this isolation limits the effect of a malicious attack.

Cryptography based on FIPS 140-2 is used to support authentication and verification. Hardware-accelerated cryptography is employed in the netX chip to significantly improve I/O cycle times by reducing CPU load and memory footprint. Software upgrades cannot match the performance of this hardware-accelerated solution.

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. Hilscher’s latest netX chips are already compliant with the most recent TSN releases and are ready to adopt the full specification once it is finalized.

Read more: Internet of battlefield things

Two standards that have been around for a couple of decades are becoming important for Industrial Internet of Things: 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. Hilscher netX chips support both OPC UA and MQTT.

The future of automation will be profoundly different, but the changes will be evolutionary rather than revolutionary.