The roles of DCS and SCADA in digital transformation

Both DCS and SCADA systems are undergoing transformations in line with broader digital transformation trends, such as the IIoT.

For decades, industrial control systems have played an important role in industrial automation by allowing process manufacturers to collect, process and act on data from the production floor. Currently, these systems are in transition. Ongoing technological and industry developments have paved the way for DCS and SCADA systems to support digital transformation.

Background

Process manufacturers typically employ DCS and SCADA technologies to monitor and control the operations in their facilities. The DCS was designed to replace individual analog and pneumatic loop controllers, which were cumbersome when applied to very large processes such as refineries. SCADA originated as a solution for operations that span broad geographical areas, for example, pipelines and utilities. Later, a variant that uses an HMI in conjunction with PLCs evolved for plant automation applications.

However, DCS and SCADA systems are now doing much more than simply monitoring and controlling. They are integrating with additional intelligence at every level of the industrial automation architecture to facilitate predictive asset lifecycle management and value chain optimisation while advancing the stakeholder experience and improving security and safety. Although this particular industrial control system transition is already underway, the larger transformation of industrial automation systems has only recently begun.

Distributed control systems

At its core, a DCS is a platform for the automated control and operation of an industrial process or plant. A DCS uses local area networks (LANs) to interconnect sensors, actuators, controllers and operator terminals for process control. While it originally served the need to control large continuous processes such as refining and petrochemicals, it was subsequently extended to batch processes.

SCADA systems

Although SCADA systems originated by serving applications that require broad geographical area coverage, the concept evolved with the inception of PC-based HMIs, which replaced more expensive minicomputers in the 1980s. Instead of a wide area network that interfaces with remote terminal units (RTUs) at locations such as pump stations, a typical in-plant SCADA system uses Ethernet for communication between the HMI and PLCs. In the in-plant category, the SCADA system architecture shares many similarities with DCS architecture. In the remote scenario, a SCADA system can connect corporate operations with multiple plants, each of which uses a DCS. Process manufacturers can use these enterprise-wide systems for data communications without facing geographical restrictions.

Essentially, DCSs and SCADA systems both play important roles in plant automation. Despite this similarity, however, key differences separate these two types of systems.

The differences between DCS and SCADA

The differences extend far beyond the fact that a traditional SCADA system can work with a wide area network whose bandwidth is much lower than in a DCS LAN.

A key distinction is that a DCS uses distributed workstations for operator HMI. Each workstation can communicate directly with controllers on the DCS LAN. In a SCADA system, all communications between HMI workstations and PLCs will funnel through a server. Thus, the server is a single point of failure, the failure of which could render the entire process essentially invisible to all users.

While the architecture of a DCS and a SCADA system might otherwise appear identical, the DCS includes numerous, often subtle features such as redundant electronic circuits, which increase the system availability and minimise downtime. Redundancy extends to remote I/O: all remote I/O electronics and the communication networks between them and the DCS controllers are, or at least could optionally be, redundant.

While SCADA HMIs and servers are typically commercial off-the-shelf (COTS) PCs, a DCS uses non-COTS components that are optimised to the task. In addition, in a DCS, the Windows operating system is kept isolated from the process, which enhances cybersecurity. A deterministic DCS LAN guarantees that a critical message such as a high-priority alarm, will indeed arrive at its destination. The SCADA system typically relies instead on the high bandwidth of the LAN.

Since a single DCS vendor typically supplies the entire system, components such as controllers and workstations are more tightly integrated than they are in a SCADA system. Common benefits include simplicity or reduced engineering costs. Still, for a given process, a DCS will be more expensive than a SCADA system, but in processes for which unplanned shutdowns are very costly, the price difference is justified. While SCADA suppliers could deploy redundant servers or high-availability computing platforms to make those systems more reliable, their availability will not be as high as a DCS.

PLC versus DCS

One advantage of a PLC over a DCS is the processing speed. A PLC typically offers significantly shorter cycle times to scan I/O points and execute control and logic operations. Although DCS and PLC technologies have largely converged, their origins are completely different. While the DCS evolved from analog and pneumatic PID loop controllers, the PLC was originally a replacement for hard-wired relay logic panels. In discrete logic processing, speed is of the essence, and a PLC will perform such logic processing much faster than a DCS would.

The DCS was designed for continuous PID loop control in process industry applications, in which the PLC provides much less of an advantage in cycle processing time. An application with a combination of continuous control and discrete logic control will typically use a DCS for the former and a PLC for the latter. Often, the DCS will integrate with a PLC, which has been supplied on a skid-mounted process unit such as a turbine-driven centrifugal compressor. Some DCS vendors have developed very efficient interfaces for such situations.

DCS, SCADA and the automation pyramid

DCS and SCADA systems both comply with the ISA95 Purdue reference model architecture. The first level — the field level — of the automation pyramid includes devices, actuators and sensors on the production floor. The second level — the control level — uses PLCs and proportional integral derivative (PID) controllers that interface to field-level devices. SCADA systems traditionally act as data funnels, transporting a broad variety of information for process control, asset management, historical analysis and IT applications. A DCS will often use multiple servers — which could be part of, or considered to be, a SCADA system — to communicate with corporate and IT systems.

A modern DCS or SCADA system will interact with several software and hardware components. Each resides in the first and second levels of a manufacturing control operation and pulls together all five levels of the automation pyramid. Because of this, it acts as the glue for digitalisation, quickly facilitating a flow of information through processes from the plant floor to the boardroom.

Figure 1: The automation pyramid. For a larger image click here.

The evolving role of DCS and SCADA with digital transformation

Both DCS and SCADA systems are undergoing transformations in line with broader digital transformation trends, such as the Industrial Internet of Things (IIoT). This transformation comes with the promise of improved industrial automation capabilities and value for process manufacturers.

New challenges that end users have brought to light have prompted vendors to consider how it would be possible to reimagine operational technology (OT) automation systems using COTS and information technology (IT) components. End users require that vendors incorporate best-in-class COTS hardware and software to create automation systems that surpass the reliability, security and end-user value of today’s DCSs.

They also desire a system that enables them to preserve their control strategies by porting them into upgraded or new systems. In addition, end users have requested modularised hardware elements — computing, networking, storage and I/O terminations, for example — to allow for incremental upgrades. Finally, they would like software that has been decoupled from the hardware and I/O to allow execution anywhere in the system.

Figure 2: How digital transformation changes the traditional Purdue model. For a larger image click here.

How is digital transformation changing DCS and SCADA?

Forward-looking process manufacturers are investing in digital transformation, and DCS and SCADA are ultimately part of such efforts. As a result, they are evolving alongside all other process manufacturing technologies. Changes to DCS and SCADA systems fit within the ongoing transformation of the automation pyramid, which is also evolving. IT/OT convergence and virtualisation technologies, for example, are blurring the distinctions between the pyramid’s levels and enabling the migration of some engineering and software applications to the cloud.

With the integration of cloud technologies, process control systems can perform edge computing and serve as robust data sources for the IIoT. Cloud-based environments facilitate the convergence of data across multiple sources and improve data availability to support insightful decision-making and application interoperability.

What are the requirements for SCADA and DCS in digital transformation?

To take advantage of cloud technologies, the IIoT and edge computing, process manufacturers need to modernise their ageing automation systems. On the whole, the drive towards digital transformation has created a need for a more open and secure system architecture and design.

Increasingly open systems

The NAMUR Open Architecture (NOA) and Open Process Automation Forum (OPAF) are driving major open architecture initiatives in industrial automation and prompting a shift away from proprietary architectures. Both initiatives describe vendor-neutral systems that allow the use of state-of-the-art equipment and functions at all times and the continued use of proprietary software applications in the future.

A key OPAF objective is to transition away from vendor lock-in, which has historically been an issue with large DCSs. The requirements for the architecture currently being considered by OPAF are interoperability, modularity, standards conformity, compliance with security standards, scalability and portability.

In the case of NOA, an independent domain called M+O (monitoring and optimisation) is prepared separately from the existing system, and data is directly collected from robots, drones and new sensors, for example, for corrosion, sound and vibration. Furthermore, data in the existing system is imported by OPC UA, and advanced control, analysis and diagnosis can be realised even in the field. From the viewpoint of security measures, compatibility with zone design recommended by IEC62443 is enhanced, and system design and maintenance can be easily performed.

More problematic is a lack of continuous upgrades from some DCS vendors. If their vendor ceases to provide upgrades, manufacturers are compelled to resort to a rip-and-replace approach, in which the old system is completely replaced by an entirely new one. In this scenario, the production loss and costs incurred while transitioning to the new system often far outweigh the system cost. By creating an open, interoperable specification, OPAF aims to foster the development of less expensive and improved process control systems.

Increased security

Digital transformation has created a need for secure network architecture and design in addition to increased openness. Security is especially important as IT/OT convergence and new technologies, such as cloud computing, introduce new security risks.

Since exposing data to the internet presents security risks, it is vital that process manufacturers keep their SCADA systems up to date using contemporary cybersecurity resources. The International Society of Automation’s (ISA) 62443 series of standards — which the International Electrotechnical Commission (IEC) has adopted — and the National Institute of Standards (NIST) 800-16 offer helpful resources and guidelines for network administrators and cybersecurity engineers.

Since their data exchanges typically rely on radio or public communication infrastructure, SCADA systems are more vulnerable to cyber attacks. As they oversee wide area networks, there are more points of entry. Meanwhile, a DCS is also not completely secure from cyber attacks and requires comprehensive measures, particularly on entry points into LANs.

A new standards-based approach to cybersecurity has been designed to encompass IT and OT systems. While OT typically uses the NIST cybersecurity framework, IT requirements and interactions with third parties could involve additional standards, such as ISA/IEC 62443 and ISO 27001.

While integrating IIoT technology, IT/OT convergence implementation teams will continue making decisions regarding the segregation of OT networks from corporate networks, OT network isolation from the internet, least privilege access controls at site and process levels, and cross-site communication restrictions. Meanwhile, cybersecurity domain expertise is evolving to encompass the formerly disparate OT and IT domains.

What does the future look like for DCS and SCADA?

Requirements for open architectures and enhanced cybersecurity, driven by digital transformation, are likely to continue shaping future DCS and SCADA developments. As a result, these systems are currently in transition, but the digital transformation journey for industrial automation systems has only just begun. This journey comes with challenges for process manufacturers — for example, upgrading a legacy system can seem incredibly daunting at the outset. But the potential benefits of digital transformation make addressing such challenges more than worthwhile.

Digital transformation promises to bring a new era in industrial automation. In this era, machines will execute complex control functions with self-learning capabilities and minimal operator intervention. That will allow process manufacturers to reduce accidents and production downtime resulting from human error and achieve optimal plant operation.

Top image: ©stock.adobe.com/au/Gorodenkoff