14-06-2014, 03:58 PM
Supervisory Control and Data
Acquisition (SCADA) Systems
Supervisory Control.pdf (Size: 1.24 MB / Downloads: 266)
Introduction
The National Communications System (NCS) was established through a Presidential
Memorandum signed by President John Kennedy on August 21, 1963. The memorandum
assigned NCS the responsibility of providing necessary communications for the Federal
Government under national emergency conditions by linking together, improving, and
expanding the communication capabilities of the various agencies.
In April 1984, President Ronald Reagan signed Executive Order (E.O.) 12472,
Assignment of National Security and Emergency Preparedness (NS/EP)
Telecommunications Functions, which broadened the mission and focus of the National
Communications System. Since that time, the NCS has been assisting the President and
the Executive Office of the President (EOP) in exercising wartime and non-wartime
emergency telecommunications and in coordinating the planning for, and provisioning of,
NS/EP communications for the Federal Government under all circumstances. In this
regard, the Office of the Manager, NCS (OMNCS), particularly its Technology and
Programs Division (N2), always seeks to improve the Federal Government's ability to
respond to National Security and Emergency Preparedness situations. As part of this
mission, the N2 division identifies new technologies that enhance NS/EP
communications capabilities and ensures key NS/EP features such as priority,
interoperability, reliability, availability, and security are supported by emerging
standards. In concert with this approach, the N2 manages the Federal
Telecommunications Standards Program. Additionally, the N2 division directs efforts in
both NS/EP management and applications services.
National Security and Emergency Preparedness requirements fall into the areas [1] [2] as
shown in Table 1.1, and are identified in the Convergence Task Force Report [3].
The goal of this Technical Information Bulletin (TIB) is to:
• Examine Supervisory Control and Data Acquisition (SCADA) systems
• Describe how SCADA systems have evolved since being deployed in the 1960s
• Examine how SCADA protocols have evolved from strictly proprietary to the
development of open protocols which allow equipment from various manufacturers
to work together
• Addresses the security aspects of SCADA systems
• Examines the standards that currently exist or are being drafted to help support the
growth of these systems
• Observations, conclusions, and recommendations on how these technologies could
support the NCS and their NS/EP and CIP mission
SCADA Overview
SCADA is an acronym for Supervisory Control and Data Acquisition. SCADA systems
are used to monitor and control a plant or equipment in industries such as
telecommunications, water and waste control, energy, oil and gas refining and
transportation. These systems encompass the transfer of data between a SCADA central
host computer and a number of Remote Terminal Units (RTUs) and/or Programmable
Logic Controllers (PLCs), and the central host and the operator terminals. A SCADA
system gathers information (such as where a leak on a pipeline has occurred), transfers
the information back to a central site, then alerts the home station that a leak has
occurred, carrying out necessary analysis and control, such as determining if the leak is
critical, and displaying the information in a logical and organized fashion. These systems
can be relatively simple, such as one that monitors environmental conditions of a small
office building, or very complex, such as a system that monitors all the activity in a
nuclear power plant or the activity of a municipal water system. Traditionally, SCADA
systems have made use of the Public Switched Network (PSN) for monitoring purposes.
Today many systems are monitored using the infrastructure of the corporate Local Area
Network (LAN)/Wide Area Network (WAN). Wireless technologies are now being
widely deployed for purposes of monitoring.
SCADA systems consist of:
• One or more field data interface devices, usually RTUs, or PLCs, which interface to
field sensing devices and local control switchboxes and valve actuators
• A communications system used to transfer data between field data interface devices
and control units and the computers in the SCADA central host. The system can be
radio, telephone, cable, satellite, etc., or any combination of these.
• A central host computer server or servers (sometimes called a SCADA Center, master
station, or Master Terminal Unit (MTU)
• A collection of standard and/or custom software [sometimes called Human Machine
Interface (HMI) software or Man Machine Interface (MMI) software] systems used to
provide the SCADA central host and operator terminal application, support the
communications system, and monitor and control remotely located field data interface
devices
Figure 2.1 shows a very basic SCADA system, while Figure 2.2 shows a typical SCADA
system. Each of the above system components will be discussed in detail in the next
sections.
Field Data Interface Devices
Field data interface devices form the "eyes and ears" of a SCADA system. Devices such
as reservoir level meters, water flow meters, valve position transmitters, temperature
transmitters, power consumption meters, and pressure meters all provide information that
can tell an experienced operator how well a water distribution system is performing. In
addition, equipment such as electric valve actuators, motor control switchboards, and
electronic chemical dosing facilities can be used to form the "hands" of the SCADA
system and assist in automating the process of distributing water.
However, before any automation or remote monitoring can be achieved, the information
that is passed to and from the field data interface devices must be converted to a form that
is compatible with the language of the SCADA system. To achieve this, some form of
electronic field data interface is required. RTUs, also known as Remote Telemetry Units,
provide this interface. They are primarily used to convert electronic signals received from
field interface devices into the language (known as the communication protocol) used to
transmit the data over a communication channel.
The instructions for the automation of field data interface devices, such as pump control
logic, are usually stored locally. This is largely due to the limited bandwidth typical of
communications links between the SCADA central host computer and the field data
interface devices. Such instructions are traditionally held within the PLCs, which have in
the past been physically separate from RTUs. A PLC is a device used to automate
monitoring and control of industrial facilities. It can be used as a stand-alone or in
conjunction with a SCADA or other system. PLCs connect directly to field data interface
devices and incorporate programmed intelligence in the form of logical procedures that
will be executed in the event of certain field conditions.
PLCs have their origins in the automation industry and therefore are often used in
manufacturing and process plant applications. The need for PLCs to connect to
communication channels was not great in these applications, as they often were only
required to replace traditional relay logic systems or pneumatic controllers. SCADA
systems, on the other hand, have origins in early telemetry applications, where it was
only necessary to know basic information from a remote source. The RTUs connected to
these systems had no need for control programming because the local control algorithm
was held in the relay switching logic.
As PLCs were used more often to replace relay switching logic control systems,
telemetry was used more and more with PLCs at the remote sites. It became desirable to
influence the program within the PLC through the use of a remote signal. This is in effect
the "Supervisory Control" part of the acronym SCADA. Where only a simple local
control program was required, it became possible to store this program within the RTU
and perform the control within that device. At the same time, traditional PLCs included
communications modules that would allow PLCs to report the state of the control
program to a computer plugged into the PLC or to a remote computer via a telephone
line. PLC and RTU manufacturers therefore compete for the same market.
Operator Workstations and Software Components
Operator workstations are most often computer terminals that are networked with the
SCADA central host computer. The central host computer acts as a server for the
SCADA application, and the operator terminals are clients that request and send
information to the central host computer based on the request and action of the operators.
An important aspect of every SCADA system is the computer software used within the
system. The most obvious software component is the operator interface or Man Machine
Interface/Human Machine Interface (MMI/HMI) package; however, software of some
form pervades all levels of a SCADA system. Depending on the size and nature of the
SCADA application, software can be a significant cost item when developing,
maintaining, and expanding a SCADA system. When software is well defined, designed,
written, checked, and tested, a successful SCADA system will likely be produced. Poor
performances in any of these project phases will very easily cause a SCADA project to
fail.
Many SCADA systems employ commercial proprietary software upon which the
SCADA system is developed. The proprietary software often is configured for a specific
hardware platform and may not interface with the software or hardware produced by
competing vendors. A wide range of commercial off-the-shelf (COTS) software products
also are available, some of which may suit the required application. COTS software
usually is more flexible, and will interface with different types of hardware and software.
Generally, the focus of proprietary software is on processes and control functionality,
while COTS software emphasizes compatibility with a variety of equipment and
instrumentation. It is therefore important to ensure that adequate planning is undertaken
to select the software systems appropriate to any new SCADA system.
SCADA Architectures
SCADA systems have evolved in parallel with the growth and sophistication of modern
computing technology. The following sections will provide a description of the
following three generations of SCADA systems:
• First Generation – Monolithic
• Second Generation – Distributed
• Third Generation – Networked
3.1 Monolithic SCADA Systems
When SCADA systems were first developed, the concept of computing in general
centered on “mainframe” systems. Networks were generally non-existent, and each
centralized system stood alone. As a result, SCADA systems were standalone systems
with virtually no connectivity to other systems.
The Wide Area Networks (WANs) that were implemented to communicate with remote
terminal units (RTUs) were designed with a single purpose in mind–that of
communicating with RTUs in the field and nothing else. In addition, WAN protocols in
use today were largely unknown at the time.
The communication protocols in use on SCADA networks were developed by vendors of
RTU equipment and were often proprietary. In addition, these protocols were generally
very “lean”, supporting virtually no functionality beyond that required scanning and
controlling points within the remote device. Also, it was generally not feasible to
intermingle other types of data traffic with RTU communications on the network.
Connectivity to the SCADA master station itself was very limited by the system vendor.
Connections to the master typically were done at the bus level via a proprietary adapter or
controller plugged into the Central Processing Unit (CPU) backplane.
Redundancy in these first generation systems was accomplished by the use of two
identically equipped mainframe systems, a primary and a backup, connected at the bus
level. The standby system’s primary function was to monitor the primary and take over in
the event of a detected failure. This type of standby operation meant that little or no
processing was done on the standby system. Figure 3.1 shows a typical first generation
SCADA architecture.
Deploying SCADA Systems
There are many different ways in which SCADA systems can be implemented. Before a
SCADA or any other system is rolled out, you need to determine what function the
system will perform. Depending on whether you are a utility company or a
telecommunications provider, you have a number of options in creating your systems.
There may be a need to employ different methods that are complimentary to each other.
The way in which SCADA systems are connected can range from fiber optic cable to the
use of satellite systems. The following sections will present some of the common ways in
which SCADA systems are deployed. We will also look at their advantages and
disadvantages.
5.1 Twisted-Pair Metallic Cable
Twisted-pair telecommunications cable is the most popular medium used by utilities and
has existed in its present form for many years. The cables are essentially the same as
those used by the Telephone Company and contain a number of pairs of conductor.
Aerial cables would be more appropriate for installation in the utility’s service area since
the Utility may own a large number of distribution poles from which the cables could be
suspended. The smallest aerial cables can be self-supporting, whereas large aerial cables
have to be attached to supporting wires (messengers) by lashing wire. Table 5.1 shows
the Twisted-Pair Cable advantages and disadvantages.
Fiber Optic Cable
Fiber optic technology has improved considerably since its inception in 1970. The
technology has improved to the point where commercially available fibers have losses
less than 0.3 dB/km. Losses of this magnitude, as well as the development of suitable
lasers and optical detectors, allow designers to consider fiber optic technologies for
systems of 140 km or more without repeaters.
Optical fibers consist of an inner core and cladding of silica glass and a plastic jacket that
physically protects the fiber. Two types of fibers are usually considered: multi-mode
graded index and single-mode step index fiber. Single-mode fiber supports higher
signaling speeds than the multi-mode fiber due to its smaller diameter and mode of light
propagation. Communication services usually supported by optical fiber include voice,
data (low speed), SCADA, protective relaying, telemetering, video conferencing, highspeed
data, and telephone switched tie trunks. Optical fiber cables have similar
characteristics to twisted-pair communications cables in that aluminum tape or steel-wire
armors and polyethylene outer jackets can protect them. However, the inner core is
constructed to accommodate the mechanical characteristics of the fibers. Typically, the
fibers are placed loosely in semi-rigid tubes, which take the mechanical stress. Special
types of fiber optic cables have been developed for the power industry. One type of fiber
cable is the Optical Power Ground Wire (OPGW) that is an optical fiber core within the
ground or shield wire suspended above transmission lines. Another type of optical fiber
cable is the All-Dielectric Self-Supporting (ADSS) cable that is a long-span of all
dielectric cables designed to be fastened to high voltage transmission line towers
underneath the power conductors. A Wrapped Optical Cable (WOC) is also available that
is usually wrapped around the phase conductor or existing ground/earth wire of the
transmission or distribution line. In the Utility’s case, aerial fiber optic cable can be
fastened to the distribution poles under the power lines. Table 5.3 shows the Fiber Optic
Cable advantages and disadvantages.