From telemetry to the enterprise — the evolution of the 21st century SCADA system

The SCADA system of the early 21st century is vastly different from the system it was in its earliest beginnings, just 50 or so years ago.

Early SCADA systems were called ‘telemetry’ systems, and were attempts to simply monitor a parameter or two over long distances. The idea that the operator, back at the plant, could actually see everything going on in a remote station was literally unthinkable. Yet all of the needs and requirements, as well as most of the benefits of modern SCADA systems, were present in the early 1970s-style telemetry systems — at least in embryo. The ability to see system status immediately was done by the representational ‘mimic wall’, while changes could be noted in ‘near real time’ by manually changing lights or indicators as roving operators called in new data.

SCADA stands for Supervisory Control and Data Acquisition. Why ‘supervisory’ control? In early SCADA implementations, such as those in the water and wastewater industries in the 1960s and 1970s, the connection between the control room, or ‘SCADA head end’ and the remote station was considered so tenuous that real operational control was considered impossible. Early SCADA implementations were really designed for acquisition of data at remote sites. In oilfield pipeline SCADA, flows and pressures were the critical information, just as they are in the water and wastewater industries. One or two critical alarms were usually attempted, such as building entry, or other very critical parameters like ‘tank low’ or ‘tank high’ or ‘pump fail’. Why so few parameters? In most cases, a SCADA system was lucky if it could deliver back four or five pieces of critical information from each remote station. Even pump run times were difficult to transmit over early SCADA systems.

Traditional markets and drivers

SCADA took shape in industries that didn’t have relatively closely-spaced facilities, the way most process industries do. The key SCADA markets from the very beginning were those with distributed locations:

• Water distribution systems
• Wastewater and stormwater collection systems
• Flood control and drainage systems
• Irrigation systems
• Electric utilities
• Oilfield pipelines
• Natural gas pipelines
• Remote stations on large industrial plants.

There are two interconnected drivers that have been the main impetus for the development and use of SCADA systems over the past 50 years. First, operators want to achieve better control of their distributed processes. Second, managements want to cut and control costs.

Figure 1: A network diagram for a 500,000 point plus system from Olympic Dam.

Costs that have skyrocketed in the past 50 years include energy and manpower. Without a SCADA system, remote stations, such as pumping stations, must be operated locally, using either flow or pressure or some other locally derived parameter value to control operations. These controls must operate independently of other stations, even those connected to the same distribution grid. Ways needed to be found to operate stations as much as possible at ‘off-peak’ hours to reduce energy costs, and this could only be done with a central ‘head end’ where data acquisition provides for control.

The other main cost that has increased is that of manpower. Prior to the modern SCADA era, a typical distribution system, whether water, wastewater, irrigation or oil and gas, would have operators in trucks ‘driving the system’ to collect data, make changes, note maintenance requirements and do inspections. This activity must be done on a continuous basis, and, in the 1970s, the typical water utility would have anywhere from six to eight operators out continuously driving the system.

It is no longer economically possible to have operators driving from station to station just to do operational inspections. It costs far too much, and the number of available trained operators is quite low, and jobs are going begging. It is also not possible to optimise a distribution system if you do not have information from all your stations in as close to real time as possible.

From leased lines to radio

Early SCADA systems used leased telephone pairs, one per signal, one per alarm. The very high cost of doing this, first in bringing the wires to the remote station, and then the leasing charges, as well as the telcos’ reluctance to dedicate sufficient switchgear capacity, sent SCADA operators looking for other solutions. In the 1970s, they turned to radio. The problem they immediately found is that in the 1970s, bandwidth was much narrower than it has become in the early 21st century, and that in any urban area, anywhere in the world, licensed frequencies became the SCADA equivalent of ‘unobtainium’.

From analog to digital

This situation was made easier by the transition in the 1970s from analog frequency shift keying (FSK) tone telemetry to digital signals. Later, with the advent of commercial off-the-shelf (COTS) microprocessors, and with compression and encryption technologies, it became possible to send multiple signals, multiple alarms and analog values, across a single frequency (or a single leased line where radio wasn’t an option).

Finally, SCADA systems could begin to provide what the early visionaries expected them to: the ability to instantly see and make changes in the control of a utility’s entire distribution system. Early digital systems, however, weren’t as robust as a relay connected to a single FSK tone channel. Radio SCADA systems went off line regularly, due to any number of causes, including sunspots. Leased lines broke or were cut by construction crews. Forty years ago, circuit boards were nowhere as reliable as they are today. Failures were commonplace.

Early SCADA systems were therefore designed to leave as much of the control functions to the remote station as possible. Remote terminal units (RTUs) were developed that would keep a station running and store some small amounts of data during communications interruption with the ‘head end’. Typically, a digital SCADA system would still be connected to the system mimic wall, and very often service and control still had to be accomplished by driving the system.

The HMI

With the advent of operating systems with graphical user interfaces, it became possible to create a human machine interface (HMI) that would replace the mimic wall, and that would do much to make driving the system unnecessary.

From the very beginning, HMI software was substantially more than just the software necessary to visually represent the system status in real time. In reality, HMI software was a software version of the entire SCADA head end. Most early SCADA software systems included virtual control devices, such as hand-off-auto stations, pump sequencers, alarm modules, and all of the features that used to require proprietary circuit boards. SCADA systems now could be as big as the microprocessor could handle, as a function of scan time.

In the 21st century, SCADA systems with 500,000 nodes are considered commonplace, and it is expected that a 1,000,000 node SCADA system will make an appearance by 2015.

Figure 2: Software development tools allow modern SCADA systems to present clean, user-friendly graphical interfaces.

Proprietary RTUs and PLCs

In the beginning, everything in a SCADA system was proprietary. RTUs consisted of multiple or single board chassis, with proprietary circuitry, and proprietary communications with the head end.

The advent of the PLC got SCADA engineers thinking about the value of COTS equipment, and the development of Modbus made it practical to use a Modbus-enabled PLC off the shelf as a replacement for a proprietary RTU. Coupled with the development of virtual SCADA HMIs, this brought the world of COTS to the SCADA marketplace for both remote station equipment and head-end computers.

The final piece of the puzzle came with the concomitant development of single tag databases and programmable automation controllers (PACs) to replace hardwired unsophisticated PLCs. PACs were designed from the beginning to work properly with single tag databases, so the ability of a SCADA package to provide seamless data integrity from the field device level to the data historian package was assured.

Modern SCADA networking

SCADA systems migrated from fully proprietary systems in the 1970s to almost completely open systems in the early 21st century, partly because they began to use open protocol networking systems. The development of ethernet, and then the use of TCP/IP over ethernet, made it possible to move vast quantities of data in a completely COTS fashion in an open, non-proprietary way.

A modern SCADA system connects to its field and its enterprise through a combination of OPC and TCP/IP over either ethernet or wireless, in a communication medium and communication protocol agnostic way. Newer systems use Microsoft .NET services and XML to improve the capabilities of OPC and networking communications.

The convergence of SCADA and DCS

SCADA was developed for use in distributed systems, like water distribution and wastewater collection systems, or oil and gas pipelines, or in electric utilities. Within process industry plants the same issues that gave birth to modern SCADA pushed the development of what is known as the distributed control system (DCS), a digital form of PLC.

DCS systems were designed to be almost entirely proprietary, and remain so to this day, in contrast with the open and COTS functionality of the design of a modern SCADA system.

While SCADA systems are subsuming more and more of the original functionality of the DCS, including in-plant closed loop control, alarm management, process optimisation and data analysis, DCS vendors are producing systems that look arguably just like SCADA systems, but which they are continuing to call DCS.

For everything except the most critical control functions in the petrochemical industry, there is now no longer a difference between the capabilities of a DCS provided by a classical controls vendor and a SCADA system put together by a control system integrator.

Capabilities of modern systems

Modern SCADA systems have enormous capabilities that their pioneers would never have envisioned 50 years ago.

A modern SCADA system includes its own design software, so that the end user can develop his own consistent user interface graphics using object libraries that are also EEMUA and ASM compliant. Operators can use a complete set of tools to design their own system in a modern SCADA software package, including templates, wizards and genies, in powerful easy-to-use systems.

Using high-speed ethernet and TCP/IP connections, operators can get literally thousands of status points from a remote station, and even full motion video, if the bandwidth of the connection is wide enough.

Figure 3: A modern SCADA alarm and trend analysis tool.

Today

Today, operators can see and analyse maintenance and process optimisation data, do alarm management and asset management, and change performance characteristics without ever leaving the control room.

SCADA is now global, and end users often have systems in widely separated parts of the world. A modern SCADA system must have the ability to present data easily and with trivial changes in many different languages.

The ‘data historian’ of a modern SCADA system is more than a database with some structured queries. It must also have the ability to assist the operator with high-level data visualisation tools, which include root cause analysis, process and batch comparators, sequence of events visualisation and alarm visualisation techniques.

Along with data visualisation tools, a modern SCADA system should be supplied with a fully integrated reports package that provides essential tools for the operator and the engineer to produce detailed information on plant floor conditions.

A modern SCADA system must also have a fully featured alarm management package that allows the engineer and the operator to configure the process alarms, and isolate and identify faults in the system. The alarms should include analog values, status alarms, SPC alarms, and the system should include the ability to define and customise alarms

Citect Pty Ltd
www.citect.com