IIoT, cloud computing changing control system architectures

The Purdue Enterprise Reference Architecture incorporated in the ISA-95/IEC 62264 standard, on which the majority of control system architectures and subsequent standards including wireless, cybersecurity, safety, etc. are based, originated in 1989. Despite being in use for almost 30 years, many people still believe that it is based on physical layers, when it actually defines the functions to be performed at each level of the architecture. At the time the model was developed, and in most cases today, it is still true that form follows function, and the various pieces of hardware tend to correlate closely to their assigned function. The IEC 62443/ISA-99 cybersecurity zone and conduit concept also tends to encourage the maintenance and separation of each of the function-based layers.

With the changes in processing and computing capability we’ve seen at the different levels of the enterprise, particularly Level 1, and the introduction of cloud-based systems, it is my understanding that ISA-95, as part of their regular review of the document, is revisiting the architecture model, with particular emphasis on Level 1 and Level 0.

Another ISA standards body, ISA-112 SCADA Systems, also needed an architecture model on which to base their work. The present version of this model, which adds more granularity to the ISA-95 model, is shown here.

When creating this model, ISA-112 deliberately chose to use letters to show the different layers, in part to avoid confusion with the Purdue model (shown for reference on the side) but also to help the committee relate the physical equipment against the function(s) that equipment needs to perform.

SCADA architecture model

In this model by the ISA-112 SCADA Systems standards committee, letter are used to label layers to avoid potential conflict with ISA-95 and other similar models. Routers and firewalls between layers are not shown, nor are other system-specific servers, applications and workstation. Remote-hosted external applications (cloud) could not be configured to attach to devices at any level with appropriate firewalls, tunneling and routing.

*Note that although this shows a Purdue level 5, the true Purdue model only has levels 0 to 4 because it did not anticipate external applications.

In general, layers A through D will tend to be at the remote site, which could be anything from a single point and RTU to a remote compressor or pump station complete with its own “mini” control system with wireless SCADA connections to associated well pads, isolation valves or remote storage facilities, thus making “site n” a small SCADA system, or at least a data concentration site on its own.

Similarly, levels F and G identify the typical SCADA components that reside on the central SCADA server(s), typically in the main control center. Alarms and Historian have been identified as two typical databases residing at this level, though as indicated by the “database” box on the right, they are by no means the only ones; they are just the ones that the committee believes require particular attention since, from a SCADA perspective, they will have some unique constraints and items to be considered when developing a system.

The other addition to the proposed SCADA model is the concept of cloud computing, presently shown as the “external applications” cloud at the top. Though a link is only shown to the databases at the SCADA server, there is the potential to link to elements at any level, with, of course, the appropriate cybersecurity protocols.

Lastly, the red lines on either side of level J are intended to show the clear demarcation between the OT (SCADA related systems), IT and public or external networks as a reminder to pay particular attention to the cyber requirements when crossing between different layers and systems.

The virtualization of systems per Open Process Automation Forum (OPAF) and arguably IIOT, is changing control system architectures once more, with the biggest impact at the top (nonexistent Level 5 at the top of the model) and again at Level 1, with basic regulatory control moving closer to the process itself. Because more functionality in these models will reside in software versus the hardware-based representation, the case can be made that the function-based reference model will become even more important since the physical hardware could potentially be flattened into fewer layers residing in the cloud and a couple virtual machines for the hardware above the sensor layer(s).

Next month we will continue the discussion on how SCADA and control systems are evolving by having a look at how LTE and 5G are adding another dimension to the ways future systems could potentially develop and be even more tightly integrated with their associated supply chains.

About the author: Ian Verhappen