As automation engineers look toward the future and their work on Industrial Internet of Things (IIoT) projects, three concerns often surface: security, working with IT and scalability.
- Security is vital. We want to get valuable data out of control systems and equipment without allowing access to those systems.
- IT departments are busy and have other priorities. They’re understandably reluctant to poke holes in firewalls or create special networks for control needs.
- Scalability. We can acquire data from local systems and remote equipment, but IIoT demands vast amounts of data from far-flung sites. How do we scale data acquisition?
To address these concerns, let’s step back and understand how computers and similar devices exchange information on a network. For example, how does a YouTube video get to your phone or a value from a field sensor get to your human-machine interface (HMI)?
To better understand this, let’s compare two network communication models: request-response and publish-subscribe.
The standard model for computers communicating on a network is request-response. A client device or software requests data or services and a server computer or software responds by providing the data or service.
When you watch a YouTube video on your phone, your web browser or YouTube app is the client that requests the video over that giant network, the Internet. YouTube’s web server responds by serving the video page to you.
In automation, a typical client is an HMI on a PC and the server is a programmable logic controller (PLC) or programmable automation controller (PAC) connected to field sensors. The HMI requests data from the controller, and the controller responds.
Request-response is like a client sending an empty truck to be filled with data. The server fills the truck and sends it back.
Each client must open a direct connection to each server. Because clients don’t know when data might change, they request data at regular intervals. So each PC HMI opens a direct connection to each controller and repetitively sends requests, and servers repetitively respond. There’s nonstop truck traffic over all of these connections.
If the server has the capacity to respond and the network can handle the traffic volume, request-response is a proven, reliable communication method. It's particularly useful for communications over a secure internal network. But if you have multiple servers with multiple clients, the volume of traffic can quickly become a problem.
A different way for devices to communicate on a network is publish-subscribe, or pub-sub. Here, a central source called a broker (or server) receives and distributes all data. Pub-sub clients can publish data to the broker or subscribe to data on the broker, or both.
Clients that publish data send it only when it changes (also known as report by exception). Clients that subscribe to data automatically receive it, but only when it changes. The broker stores no data; it simply moves it from publishers to subscribers.
Compared with request-response, the number of connections shrinks, replaced by one lightweight link from each device to the broker. This link stays open, and only two things travel over it: changed data and a tiny heartbeat so the broker knows the client is still there.
In our truck analogy, there are fewer roads and fewer trucks and all trucks are full. A client publishing data sends a full truck to the broker. The broker doesn’t unload the truck; it routes it intact to subscribers.
For IIoT, pub-sub makes sense because it efficiently moves data among several sources and destinations. It also makes sense because its lightweight, single link minimizes difficult client-server connections and works on low-bandwidth, expensive or unreliable networks—like monitoring remote equipment.
Pub-sub with MQTT and Sparkplug
The pub-sub transport protocol MQTT (www.mqtt.org) is an OASIS standard and an ISO standard with an industrial history. It was invented in 1999 for an oil and gas pipeline application to reduce expensive communications via satellite lines.
To industrialize MQTT further, Cirrus Link Solutions released the Sparkplug spec in 2016 (www.cirrus-link.com/oem-device-data-integration). Sparkplug added binary encapsulation, device state and topic definition to make MQTT easier to implement and more suited to critical applications.
In addition to the pub-sub advantages of fewer connections, less traffic and report by exception, MQTT and Sparkplug offer these advantages for IIoT:
- Compressed payloads and stateful communications for remote devices with irregular connections.
- Automatic reconnection and data transport for offline devices.
- An important security advantage: outbound connections from clients to the broker.
The bottom line
With pub-sub in mind, let’s review our three IIoT concerns: security, IT and scalability.
Security and IT concerns are both minimized with outbound connections from pub-sub clients to the broker. All firewalls block inbound traffic (for example, an external client requesting data from an internal server), but typically allow outbound connections. Since all MQTT/Sparkplug data is outbound, VPNs and port forwarding are not required. Often, you can securely move data where you need it with little assistance from IT.
The scalability problem is minimized by efficient, stateful data communications and lower network traffic in an MQTT/Sparkplug pub-sub architecture. Masses of data can flow freely among many sources and destinations.
To increase security, reduce reliance on IT and scale data communications for IIoT, automation engineers are taking a closer look at MQTT/Sparkplug.
For more information on how Opto 22 is helping you keep up with these industrial technology developments, see Opto 22’s groov EPIC system with Ignition Edge Onboard for MQTT/Sparkplug communication at info.opto22.com/groov-epic-intro-offer.