Bringing edge-based SCADA to mixed legacy systems
Key Highlights
- Edge devices enable localized processing and storage, reducing load on central databases and improving scalability in industrial networks.
- Protocols like MQTT and data formats such as JSON or Sparkplug B facilitate efficient, event-driven data sharing between OT and IT systems.
- Structured naming conventions and flexible data models help maintain data integrity and historical context despite process realignments.
In today’s world of the Industrial Internet of Things (IIoT) and emerging artificial intelligence (AI) solutions, there’s a growing need to share operational technology (OT) data from supervisory control and data acquisition (SCADA) systems, and integrate it with the business information typically found in information technology (IT) systems. Much of this data originates from legacy control hardware performing dedicated functions that aren’t directly compatible with evolving IT environments supporting AI and other initiatives.
What are the key considerations for bridging this data divide to enable new applications in a safe, efficient and economical way? Control spoke with Barry Baker, vice president of Trihedral Engineering, about the benefits of adopting edge-based solutions for existing applications.
Q: Why not simply update the localized controller?
A: While localized control is well served by logical controllers like PLCs or RTUs, they share data in an ISA-95 pyramid model, which has a data flow of Level 0 to Level 5 in a point-to-point fashion. This is in contrast with a need to provide distributed data flows, where many nodes can share data on an event-driven basis with IT systems, commonly achieved with a publish-subscribe model.
This concept isn't new. Industrial protocols such as OPC, DNP3 and CIP have supported this paradigm for some time. However, they're largely used on the OT side due to high performance requirements, which are often achieved with tight coupling to specific brands of industrial hardware. It can be problematic to simply forward data to IT systems that rarely support these protocols, so there’s a need for data translation, where the data acquired by OT protocols is transformed for sharing across the enterprise.
Q: What's the advantage of using edge devices for OT to IT data transfer?
A: The common definition of edge computing is placing computation and data storage closer to the data source, increasing processing performance compared to older, database-centric models, where data is transmitted to a central historian. Subsequent processes read from this database to perform logic. While this model has the benefit of centralized storage of all elements, database performance can be a limiting factor in scalability. Tasking the database to support forwarding to other systems may impact the control system’s performance.
The alternative is to support distributed data flows, where many nodes can share data with IT systems on an event-driven basis. This is commonly done via a transport protocol such as message queuing telemetry transport (MQTT), where data is sent to a broker to which other systems can subscribe.
The data can be encapsulated in protocols such as JSON or Sparkplug B, which may not have the efficiency of industrial OT protocols, but are more easily consumed by IT systems. Since they're not responsible for primary control, these systems are more interested in summary data versus each elementary data change. For example, they might provide running hours, maximum current and temperature for a piece of equipment to monitor efficiency and schedule preventative maintenance, rather than sending many changes of state messages in an hour. In this regard, a SCADA edge node is well-suited for this type of work with common support for varying units of measurement encountered from industrial hardware.
Get your subscription to Control's tri-weekly newsletter.
Q: What are other considerations around data sharing?
A: There's a lot of buzz around unified name space (UNS), as a centralized publisher-subscriber model to share data within an enterprise. The idea of UNS is that data is organized in a heuristic manner, with names following a structured convention, so subscribers can easily discern the origin of varied data elements without intricate knowledge of the SCADA system.
VTScada, our industrial monitoring and control platform, has supported hierarchical naming and data models for many years, as it provides better clarity for users about where the data is sourced if organized and named in a logical fashion. This contrasts with older methods of using an encrypted acronym for an I/O name, which was common in distributed control systems (DCS) that derived it from a control loop drawing. While this naming is logical, it's not a defined standard, but rather follows user conventions.
After supporting this for many years, we encountered the problem of users changing their hierarchy due to process realignment or expansion. An example of this is when a calculated KPI is initially used at a machine level, but is found to be better suited across multiple machines as the process expands. As the hierarchical name is used by the historian, alarms and displays, changing the name could break links to historical data and displays.
In response, we designed a solution that supported the flexibility to rename as the process evolved, without losing historical information. While this may seem trivial, it's an example of the problems that can creep in as new technologies are adopted. In our 40 years of providing SCADA solutions in many industries, we found the one constant is change.
The solution of using an edge-enabled SCADA node is to recognize that, in support of IoT, Industry 4.0 and smart manufacturing, data flows are more distributed versus the classical ISA-95 pyramid data flow. In this regard, the ideal edge device is part of the SCADA system, and performs localized processing, data storage and event-driven updates in a redundant and fault-tolerant manner. In addition, as it shares the OT network, it also must support OT security mechanisms, as well as those required to safely distribute data to other networks and systems.
