SCADA Systems Overview

The definition of SCADA is ‘Supervisory Control and Data Acquisition’. It is a system that uses computers, networks, and specialized hardware to monitor and control the physical equipment of an industrial process. The major function of SCADA is for acquiring data from remote devices such as valves, pumps, transmitters etc. and providing overall control remotely from a SCADA Host software platform. SCADA Host platforms also provide functions for graphical displays, alarming, trending and historical storage of data. SCADA systems at their fundamental level are Industrial Control Systems. They are computer based control systems that monitor and control industrial processes that exist in the physical world. SCADA systems can be found in manufacturing facilities, oil production and processing, power plant - energy, a network, a system of traffic lights, pharmaceuticals, water treatment and distribution, and the list goes on. They are the best control method for processes that have large amounts of data that need gathering and analyzing, or are spread over large distances, or require critical control in fast paced processes.

SCADA is application software. This software is installed on a computer called a workstation or node. The software comprises several components, including a development and runtime environment and an I/O server and license. These software components are configured to work seamlessly, forming a fully functional SCADA system.

Generally the SCADA system includes local processors, operating equipment, PLCs, instruments, remote terminal unit, intelligent electronic device, master terminal unit or host computers and a PC with human machine interface. Looking at the overall structure, there are four distinct levels within SCADA:

1. Field instrumentation
2. PLCs and / or RTUs
3. Communication networks
4. SCADA Host software A SCADA system performs the following four functions:
1. data acquisition
2. networked data communication
3. data presentation
4. control
These functions are performed by four kinds of SCADA components:
1. Sensors (either digital or analog) and control relays – These directly interface with the managed system.
2. Remote telemetry units (RTUs) – These are small computerized units deployed in the field at specific sites and locations. They serve as local collection points for gathering reports from sensors and delivering commands to control relays.
3. SCADA master units or HMI – These are larger computer consoles that serve as the central processor for the SCADA system. Master units provide a human interface to the system and automatically regulate the managed system in response to sensor inputs.
4. The communications network – It connects the SCADA master unit to the RTUs in the field.

The very basic components of a SCADA system are signals:

1. DI - Discrete Input
2. DO - Discrete Output
3. AI - Analog Input
4. AO - Analog Output

Discrete signals (also called Digital signals) provide an ON or OFF input to a SCADA system. This is the same binary signal format used in computer processors. Discrete signals have three basic configurations that are used:
· normally open
· normally closed
· normally open-normally closed combined
Analog signals are continuous. A change in signal value reflects change in the parameters being monitored, for example temperature and pressure.
The signals generated by the instruments being monitored by a SCADA system are voltage or current based. Analog signals can be formatted as: 4-20 mA, 0-20 mA, 1-5VDC, 0-5VDC, -10VDC to 10VDC.

There are different types of SCADA systems that can be considered as SCADA architectures of four different generations:
1. First Generation: Monolithic or Early SCADA systems
2. Second Generation: Distributed SCADA systems
3. Third Generation: Networked SCADA systems
4. Fourth Generation: Internet of things technology, SCADA systems

A SCADA system is custom configured using the development environment. A person with knowledge of the process identifies the monitoring parameters and the control capabilities that need to be reflected in the process mimic design. This is called the preparation of static graphics and animation. Objects with animation or those that display data and variables are then linked to a Tag. Tags, which are software instrument IDs, are created simultaneously when preparing the graphics and animation. Tags are saved and populated in the tag database, named similarly to the name of the actual, physical device the Tag represents. The SCADA system communicates with Programmable Logic Controllers (PLC), Remote Terminal Units (RTU), and microprocessor-based electronic devices and instruments. Communication is initiated by configuring a corresponding Data Server or I/O server. As a general rule, a SCADA system may communicate if both the software and partner device is in agreement with a standard communication protocol. Once all configurations are completed, the runtime environment is launched. The operator interacts in real-time with the process in this runtime environment. During the active state of the runtime environment, the I/O server continuously sends and receives data to and from the partner devices. Each available data in the I/O server is passed to the linked Tag, making the data available for display.
All these configurations will be meaningless without a valid license. The License defines the limit of tags that may be declared in the Tag database. A Tag may represent an actual I/O device. For instance, One (1) controller input and One (1) controller output is equivalent to Two (2) Tags; thus, a controller with 250 I/Os in total will require a minimum of 250 SCADA Tag licenses. Other licensing procedures include number of SCADA screens or displays and number of automation objects.

Field instrumentation

Instrumentation is a key component of a safe and optimized control system. Traditionally, pumps and their corresponding operational valves would have been manually controlled i.e. an operator would start/stop pumps locally and valves would have been opened/closed by hand. Slowly over time, these instruments would have been fitted with feedback sensors, such as limit switches, providing connectivity for these wired devices into a local PLC or RTU, to relay data to the SCADA host software. Today, most field devices such as valves have been fitted with actuators, enabling a PLC or RTU to control the device rather than relying on manual manipulation. This capability means the control system can react more quickly to optimize production or shutdown under abnormal events.

PLCs and / or RTUs

Programmable Logic Controllers (PLCs) and Remote Telemetry Units (RTUs) used to be distinctly different devices but over time they are now almost the same. This has been a convergence of technology as manufacturers of these devices expanded their capabilities to meet market demands. Going back about 30 years, an RTU was a ‘dumb’ telemetry box for connecting field instruments. The RTU would ‘relay’ the data from the instruments to the SCADA host without any processing or control but had well-developed communication interfaces or telemetry. In the 1990s control programming was added to the RTU so it operated more like a PLC. PLCs on the other hand could always do the control program but lacked communication interfaces and data logging capability, which has been added to some extent over the past decade. A further development of devices in the field is to offer a specific application that could incorporate a number of instruments and devices with an RTU/PLC.

Communication networks

The remote communication network is necessary to relay data from remote RTU/PLCs, which are out in the field or along the pipeline, to the SCADA host located at the field office or central control center. With assets distributed over a large geographical area, communication is the linking part of a SCADA system and essential to its operation. About twenty years ago the communication network would have been leased lines or dial-up modems which were very expensive to install and maintain, but in the last 10-15 years many users have switched to radio or satellite communications to reduce costs and eliminate the problematic cabling issues. More recently, other communication types have been made available that include cellular communications and improved radio devices that can support greater communication rates and better diagnostics. However, the fact that these types of communication media are still prone to failure is a major issue for modern, distributed SCADA systems.
At the same time as the communication medium changed so too did the protocols. Protocols are electronic languages that PLCs and RTUs use to exchange data, either with other PLCs and RTUs or with SCADA Host platforms. Traditionally, protocols have been proprietary and the product of a single manufacturer. As a further development, many manufacturers gravitated to a single protocol, MODBUS, but added on proprietary elements to meet specific functionality requirements. For the Oil & Gas industry there are a number of variants of MODBUS, including but not limited to, MODBUS ASCII, MODBUS RTU, Enron MODBUS and MODBUS/TCP. This incremental development in using MODBUS protocol variants was seen as an improvement, but it still tied a customer to a particular manufacturer, which is very much the case today.
In recent years, protocols have appeared that are truly non-proprietary, such as DNP (Distributed Network Protocol). These protocols have been created independently of any single manufacturer and are more of an industry standard; many individuals and manufacturers have subscribed to these protocols and contributed to their development. However, these protocols have yet to develop significantly enough to have a broad appeal to the application process and regulation requirements for oil & gas markets.

SCADA Host software

Traditionally, SCADA Host software has been the mechanism to view graphical displays, alarms and trends. Control from the SCADA Host itself only became available when control elements for remote instruments were developed. These systems were isolated from the outside world and were the domain of operators, technicians and engineers. With advancements in Information Technology (IT) this is no longer the case. Many different stake holders now require real time access to the data that the SCADA Host software generates. Consequently, there is a drive for the SCADA Host to be an Enterprise entity providing data to a number of different users and processes. This has encouraged SCADA Host software development to adopt standards and mechanisms to support interfacing to these systems. It also means that IT, traditionally separated from SCADA systems, is now involved in helping to maintain networks, database interfacing and user access to data.
Modern SCADA software that encapsulates telemetry functionality no longer requires types of hybrid PLCs or RTUs, called a Front End Driver (FED) or Front End Processor (FEP), to be used for handling communications with remote devices. They now use software programs called ‘drivers’ that are integrated into the SCADA Host itself. Software drivers contain the different types of protocols to communicate with remote devices such as RTUs and PLCs.
As technology developed, SCADA Host software platforms were able to take advantage of many new features. These included the development of integral databases specifically designed for SCADA Host software requirements, being able to handle thousands of changes a second, for really large systems, yet still conform to standard database interfacing such as Open Database Connectivity (ODBC) and Object linking and Embedding for Databases (OLE DB). These standards are required so that third-party databases can access data from the SCADA Host software. Remote client access to the SCADA Host is another technology that has enabled users to operate and monitor SCADA systems while on the move between or at other locations.

SCADA Security

There is a drive towards operational safety for SCADA Host systems within the oil and gas industry. Traditionally SCADA systems were isolated entities that were the realm of operators, engineers and technicians. This has meant that SCADA Host platforms were not necessarily developed to have protected connections to public networks. This left many SCADA host platforms open to attack as they did not have the tools necessary to protect themselves. However, it’s only been in recent years that an open standard has been produced to provide secure encrypted and authenticated data exchanges between remote assets and a SCADA Host platform. There are a number of standards available that describe how to secure a SCADA system, not just in terms of the technology employed, but in terms of practices and procedures. These practices and procedures would include items of training, SCADA Host access and procedures to follow when SCADA security has been compromised.