The Industrial Internet of Things (IIoT) and supervisory control and data acquisition (SCADA) can improve operations. Learn how.
by: Arlen Nipper
The term “supervisory control and data acquisition” (SCADA) refers to a set of industrial-software applications that can be configured to support management of almost any kind of discrete or process production. SCADA is found wherever it’s necessary to aggregate the data of a controlled process or to coordinate operations related to that production process.
Will SCADA’s role change or diminish in an industrial automation world increasingly disrupted by the Industrial Internet of Things (IIoT)?
The answer is no. In fact, IIoT improves SCADA even before SCADA is ever connected to the Internet or Cloud. Use of Message Queueing Telemetry Transport (MQTT) message transport protocol, combined with message-oriented middleware (MOM) data brokers, “modernizes” SCADA infrastructures. Given the availability of IIoT connectivity solutions, instead of investing resources in re-engineering, re-integrating, and re-vamping SCADA based on 35-year-old protocols, time can be spent developing applications that take advantage of, for example, the cloud and analytics.
In other words, IIoT technologies can “leapfrog” over legacy infrastructures and the current installed device base with solutions and migration strategies that work in conjunction with them. Already today, field-installed “edge” devices provide connectivity to existing PLCs, transmitters, and other nodes and publish real-time process variables using MQTT.
MQTT is a bi-directional, lightweight, event-driven, message-oriented transport that allows devices to communicate efficiently across constrained networks to backend systems. MQTT eliminates so-called poll/response protocols, and by leveraging mature MOM technologies, IIoT-enabled SCADA makes device data accessible to a wider range of information consumers. Devices no longer directly connect to, and are effectively decoupled from, the SCADA application. SCADA based on MOM principles reduces the latency of critical control and measurement data.
Bandwidth previously required for poll/response is reduced up to 85%. That makes information often left stranded in devices accessible. In addition, it provides a single point of security management for field devices and applications, simplifies infrastructure topology for redundancy, availability, and scalability, and eliminates the dreaded “cutover” from one SCADA version to another. Finally, it provides the device decoupling required for additional IIoT enablement.
Legacy SCADA implementations
Hardware-wise, a SCADA installation typically includes computer workstations, programmable logic controllers (PLCs), and instrumentation for system inputs and outputs (I\O). Another element of a SCADA installation is a distributed database and tag- or point-data elements. Each tag represents a single system input or output value.
The process feedback loop passes through the PLC, while SCADA monitors loop performance. That is, PLCs assume parameter control, while operators monitor results and, for example, change set points. Peer-to-peer communications among the controllers may be lacking.
SCADA has remained basically unchanged over the last 40 years. Hardware and operating systems improved per Moore’s Law, but its infrastructure and how information was put into it from devices and sensors remained largely unchanged.
Most SCADA systems still place the host system squarely in series with any field device using poll/response protocols. These poll/response protocol drivers dictate that devices are connected directly to the SCADA host application.
From an “operations” point of view these systems have proved viable. On the other hand, challenges arise whenever business functions want access to the data that smart devices and sensors furnish. To access it, additional polls must be placed into the SCADA host tables. Additional applications are needed to access the data. Security and access-control parameters need to be in place. Operations must manage the additional polls and avoid any negative effects on update rates.
Even then, SCADA is now gathering data it doesn’t need, just to pass it on to other applications. Over time, and primarily as means to operations coordination, SCADA comes to function more and more like message-oriented middleware, though it was never meant to do so. And as the SCADA host application evolves, it becomes brittle and difficult to manage. The efforts to benefit from additional information gathered from field devices come to a grinding halt.
Past practices of connecting directly to SCADA using poll/response protocols also impede technology adoption. Once a protocol is deployed, users face a quandary when newer technology becomes available. Innovative devices may have protocols not supported by the SCADA. An alternative SCADA host cannot be evaluated in parallel with the current SCADA host on a live system. Connecting devices to applications using poll/response protocols makes point-in-time solutions difficult to update over time.
What can be done
Using field network devices that implement MQTT natively, MOM-based SCADA can be realized, as shown in Figure 3. Components of the legacy poll/response infrastructure are maintained. The primary change to the topology is the inclusion of the MQTT Server.
Legacy devices in the field can be MQTT-enabled using available “edge-of-network” gateway devices that apply the native poll/response protocol and then convert the register/process variable information into MQTT messages published in real-time on a report-by-exception basis.
SCADA devices available today already implement MQTT natively and can be added to an infrastructure immediately. Using MOM means end devices publish all operations data real-time, for consumption by SCADA and other business functions. Again, whether metadata, asset information, diagnostics, configurations, or other metrics, all are available in real time.
The SCADA host is now decoupled from the remote field devices. The system is not limited by a specified poll/response protocol implementation or SCADA host application. There is now a one-to-many relationship between field-device data being published and applications interested in subscribing to that information. The SCADA host can focus 100% on being a SCADA host rather than acting as a fragile middleware component-something it was never intended to be. All connections from remote sites to the MQTT broker are client-side originated and all remote sites-given normal operation─are all connected concurrently.
Field devices became more intelligent in the last decade, but most of that additional intelligence is left stranded! The topology represented in Figure 4 is indicative of a modern SCADA with reduced bandwidth stress and allowing for a larger set of data.
MQTT was first released in 1999 as a SCADA-centric message transport but remained largely unknown in the wider markets. But over the last 4 years its use in IoT-focused solutions has gained considerable acceptance. Just about every message-oriented middleware product on the market today now supports MQTT natively. Open-source tools are available for MQTT, as well as tutorials and technical information. In the last 18 months SCADA device manufacturers, development-platform providers, and end-solution providers have announced some level of support for MQTT.
To provide guidance and best practices about MOM-centric SCADA and migration strategies required for most existing legacy implementations, Cirrus Link Solutions created an open specification called “Sparkplug” that defines an efficient MQTT-based SCADA system. Sparkplug defines the standardized components needed for devices and applications to use MQTT in real-time SCADA effectively in terms of topic namespace, payload definition, and session state management.
Sparkplug reference implementation applications can be executed on a Raspberry Pi hardware platform connected to any open-source MQTT server. Production-quality infrastructures can be built out using solutions already implementing the Sparkplug specification including solutions from Inductive Automation, Node-RED, Advantech, Elecsys, Hilscher, Magnetrol, Moxa, Opto 22, and Tyrion.
With this emerging eco-system available, device makers, SCADA developers, integrators, and end users can now build-out MQTT-enabled infrastructures as a basis for moving away from systems dependent on legacy poll/response. MOM is a well-tested, deployed, and accepted technology within the IT world today. Applying it to SCADA systems using MQTT results in an implementation that is modern and state-of-the-art, using more standard, off-the-shelf components and requiring less customization and application integration around the SCADA host application. Additional field device intelligence can be accessed and brought into line-of- business applications without impacting or modifying the SCADA host application.
Why message-oriented middleware?
In use in the information-technology sector for more than a decade, message-oriented middleware (MOM) decouples applications. Legacy information technology systems worked much like SCADA poll/response protocols do today. Applications were tightly coupled, using protocol definition to determine how application A talked to application B. As a point-in-time solution these worked fine. But over time, tight coupling and strict definitions made it difficult, if not impossible, to update legacy IT applications.
With MOM, on the other hand, applications publish data without concern as to who subscribes to it. Developers focus on creating value-add applications that publish and subscribe within a MOM infrastructure.
In addition, with MOM, the payload of information published is defined by the message topic and not by a protocol, i.e., the payload of a MOM message is agnostic. It could be a binary JPEG file or it could be an XML document. Message transports let developers publish in the format that made most sense for the solution, unconstrained by any protocol definition.
This same infrastructure needs to be employed for IIoT-enabled SCADA. MOM-centric SCADA architectures let devices publish real-time data to a central MOM server. The SCADA host application participates as a subscriber to real-time process variables and a publisher of device commands. It also breaks the vicious cycle of protocol development and support since additional message topics can be created as required for evolving solution requirements.
Some notes on MQTT
MQTT was first used in the 1990s in mission-critical, real-time SCADA in the oil and gas industry. For most of these systems, VSAT technology was the primary communications network, and therefore bandwidth was minimal. MQTT proved attractive for use in SCADA because it is:
- Natively built on top of TCP/IP, with client-side TCP/IP session enablement
- Stateful, with continuous session awareness
- Bandwidth efficient
- Simple to understand and implement.
If you eliminate HTTP as a viable transport for SCADA because it is a stateless transport and bandwidth-heavy, MQTT emerges as a viable transport within the broad IIoT applications arena. In addition, MQTT was originally designed for VSAT SCADA infrastructure. It allows valuable VSAT space segments to be optimized for the number of remote sites within that space segment.
Therefore, once an MQTT client session is established, total metadata overhead for messages is only three bytes. MQTT also takes full advantage of the underlying TCP/IP transport. That means MQTT is extremely lightweight and bandwidth-efficient on the wire, especially for VSAT and cellular network topologies. For factory-floor SCADA this can mean orders of magnitude reductions in network traffic.
MQTT is now a global standard backed by several leading standards bodies including the OASIS, ISO, and IEC.
Arlen Nipper is president and chief technology officer at Cirrus Link Solutions.
Content reprinted in partnership with Control Engineering, CFE Media.