Like all computer-based systems, today’s supervisory control and data acquisition (SCADA) systems are evolving. Driving this evolution is the pervasive Internet, commonly known as the Internet of Things (IoT), or in our case, the Industrial IoT (IIoT).
Several my friends and colleagues claim that IIoT principles are really an extension of the good practices we've been deploying on SCADA systems for years. Our challenge is how to adapt them to the new reality of the increased ease with which new sensors and data source can be connected—and all their attendant cybersecurity concerns.
3GPP, a coalition of telecommunications standards organizations, has developed a specification that contains more than 200 use cases across various industries for how 5G should be used. We already have many SCADA installations using cellular technology for backhaul. 5G will only make gathering data easier than ever before, once the full capabilities of 5G are available and understood.
The challenge for SCADA systems of the future will be how to manage all the potential incoming data sources. We know we're all data hoarders: our initial reaction is: as long as we have the bandwidth, collect everything we can—just in case it might be useful some day. The relatively low cost of cloud-based storage reinforces the idea of collecting everything all the time.
The providers of these data clouds and tools encourage us to do so, and our corporations can claim that, because we have this data in the cloud, we're doing something with IoT. Having the data and turning it into information involves lots of work, including cleaning the data, developing models and insights, verification, and finally deployment—but that's is a different challenge and a story for another time.
The International Society for Automation’s ISA112 SCADA Systems committee (of which I'm a member) is creating an updated SCADA system specification to represent the different elements that need to be considered during the development process. A simplified sketch of it (without cybersecurity isolation requirements between the layers) can be viewed at www.isa.org/isa112. The committee also recently released an associated SCADA System Lifecycle diagram, which can be accessed at the link above. It's the basis for a more detailed document under development, and is already being used/referenced in several projects. Separate chapters and clauses are being prepared for each of the elements shown in the lifecycle diagram by the active members of the committee.
Enter open source
MQTT and Sparkplug B, now being developed under the auspices of OASIS and the Eclipse Foundation, respectively, are also remaking SCADA architectures. Almost all the new controllers intended for the SCADA market of late include support for MQTT, particularly those designed for “open architectures.” There are also several open-source data brokers available to manage MQTT messaging to be sure the different nodes in the SCADA network can communicate.
There are also open-source configuration tools such as Node Red to help setup networks and monitoring tools like Redfish to manage the traffic for traditional, hybrid IT and software-defined data centers across IT/OT systems, including limited support for the cybersecurity requirements defined in IEC 62443.
Based on the above, it almost looks like it's possible to “roll your own” SCADA system from all these different open source components. I suppose you could, but the challenge becomes one of managing and supporting the result, which means SCADA and control system suppliers still have a significant role to play in ensuring reliable control systems regardless of the degree to which they're based on, or more accurately, support the new open-system standards.
Editor’s note: Ian Verhappen currently works for SCADA supplier Willowglen Systems, and opinions expressed in this column are his own, not necessarily those of his employer.
[sidebar id= 1]
