Chapter 2
Chapter 2
Chapter 2
FUNCTIONS OF
SUPERVISORY CONTROL & DATA ACQUISITION (SCADA) SYSTEM
Dr. H.K. VERMA
Distinguished Professor
Department of Electrical and Electronics Engineering
School of Engineering and Technology
SHARDA UNIVERSITY
Greater Noida, India
website:
profhkverma.info
1. Introduction
Before we can identify and discuss the functions of SCADA system, let us briefly overview
the layout, working and components of a SCADA system, which were dealt with in detail in
Chapter-1 on Basics of SCADA:
1.1 Overview
As illustrated in figure 1 below, the controlled process/ plant is notionally partitioned for the
purpose of monitoring and control into certain sections. A small microprocessor-based unit,
called remote terminal unit or RTU, is placed in and interfaced to each section of the plant. There
is a large computer-based central supervisory unit, or the control and monitoring unit, called
master terminal unit (MTU) or master station or supervisory station. It is located in a central or
strategic place, called control room. Each RTU is expected to acquire data (analog values of
controlled variables and status information of remote and locally controlled objects) from the
plant section assigned to this particular RTU and to transmit data to the MTU after necessary
processing of the acquired data. Likewise, each RTU expects to receive control instructions
(relevant to the plant section assigned to it) from the MTU and deliver them to the plant. This
two-way digital communication between RTUs and MTU is carried out on the so-called MTURTU communication sub-system.
The RTU acquires analog values and status information through sensors and status sensors,
respectively. Similarly, it delivers the set points and discrete control commands to automatic
controllers and actuators, respectively. These devices thus act as the interface between the RTU
and the controlled plant. Being located in the field (within the plant), these devices are known as
field devices (FDs). The electrical communication system linking the field devices to the RTU is
called the RTU-FD communication sub-system. Thus, a SCADA system is broadly comprised of
the following five components:
1.2 Functions
A supervisory control and data acquisition (SCADA) system performs the following major
functions:
(i)
Human-machine interface (HMI)
(ii) Electrical communication
(iii) Data acquisition (DAQ)
(iv) Monitoring
(v) Control
(vi) Data collection, storage and retrieval
(vii) Calculation
2
(ii) Very often, a speaker or buzzer is also provided on the operator console for issuing
audio alerts and audio alarms to the operator.
(iii) A large wall-mounted high-definition LED screen is used for displaying boldly a singleline diagram (SLD) of the process flow, called as mimic diagram or simply mimic, and
the screen is traditionally known as mimic board. The purpose of the mimic is to present
at-a-glance picture or overview of the complete process to the operators. It can be either
static or dynamic. A static mimic displays only a static SLD of the process, whereas a
dynamic mimic displays the real-time status of major objects in the plant and the current
measured values of important variables, both laid over the SLD of the process.
(iv) One or more printers are included for generating hard copy of (a) programs, (b) screen
shots, and (c) reports.
(v) The HMI of the earlier SCADA systems used to incorporate a plotter as well for
generating hard copy of trend curves, graphs and drawings. With the advent of highresolution low-cost printers, the plotters have become obsolete.
3. Electrical communication
Electrical communication is required:
(a) Between the MTU and each RTU, and
(b) Between each RTU and the field devices connected to it.
Details of these communications are described below.
3.1 MTU-RTU Communication
Each RTU is expected to acquire data (analog values of important variables and status
information of important objects) from the plant section assigned to this particular RTU and to
transmit data to the MTU after necessary processing of the acquired data. Likewise, each RTU
expects to receive control instructions (relevant to the plant section assigned to it) from the MTU
and deliver them to the plant. This necessitates two-way (or duplex) digital communication
between RTUs and the MTU.
There is no need of providing individual point-to-point communication links between each
RTU and the MTU. Such an arrangement would require the MTU to have one transceiver
(transmitter + receiver) per RTU and the total length of communication cables would also be
very large. This would make the cost of MTU-RTU communication subsystem very high and its
performance and reliability very poor. A much better option, which is now commonly used, is to
provide/ use a single data network linking all the RTUs with the MTU. However, depending on
the geographic size of the controlled process and dispersion of its facilities, the data network may
be a LAN (local area network), MAN (metropolitan area network) or WAN (wide area network).
4
For a public utility spread over a nation or beyond, even the Internet may be used for data
communication between the MTU and the RTUs, subject to data security considerations.
3.2 RTU-Field Device Communication
Each RTU acquires the analog values of controlled and uncontrolled variables of the process
through analog sensors and the status information from remotely and locally controlled objects in
the plant using status sensors. Similarly, it delivers the set points to automatic or feedback
controllers (of the controlled variables) and discrete control commands to various actuators (of
the remotely controlled objects). Thus these devices (analog and status sensors, feedback
controllers and actuators), known as field devices, act as the interface between the RTU and the
controlled process/ plant. The following important points should be noted in regard to the
communication between an RTU and the related field devices:
(a) The communication between simple (non-smart) field devices and RTU is in one direction
only or simplex, as against an essential duplex communication between RTUs and MTU. To
clarify the point further, the information or signal has to travel only from non-smart sensors
to the RTU, but not from RTU to the sensors. Similarly, the information to the unintelligent
controllers and actuators has to come from RTU and no information or signal goes from
these devices to the RTU.
(b) The status information going from the status sensors to the RTU and the control commands
delivered by the RTU to the actuators, both, are essentially discrete (or binary) in nature.
These are sent using binary signals (high/low or 1/0 signals).
(c) The information going from the analog sensors to the RTU is analog in nature. This analog
information is either transmitted as such to the RTU using analog communication (4-20 mA
is the most widely used analog signal) or is first converted to digital value using an analogto-digital converter (ADC) and then transmitted using digital communication techniques.
(d) The set points received by the RTU from the MTU are always digital in nature, because
RTU-MTU communication is always digital. The RTU can deliver it in digital form itself
using digital communication, provided the automatic controller receiving it is also of digital
type. But if the controller is of analog type, the RTU will convert it to analog value (4-20 mA
most likely) using a digital-to-analog converter (DAC) and send this analog signal to the
controller.
(e) Lastly, if smart or intelligent field devices are used, then a two-way digital communication
will be required between them and the RTU. In fact, a local area network (LAN) can be set
up for the communication between such field devices and the RTU, with the attendant
benefits of lower cost, reduced wiring/cabling and higher reliability.
5
5. Monitoring
It is a common practice to monitor (a) status, (b) events, (c) limits and (d) trends. This
function (monitoring) is carried out jointly by RTU and MTU as discussed below.
(ii) Warning Limits: The computer in the MTU monitors critical variables in the process
against certain predefined limits on the basis of the data coming from the RTUs. In case
such a limit is found violated, the computer displays a warning message to the operator
on video monitor. Alternatively, the RTU monitors these variables and, in case of a
violation of limits, communicates this fact to the MTU for warning the operator. The
operator is then expected to intervene and take a planned action before the situation
becomes alarming.
(iii) Alarm Limits: If the operator fails to act on a warning, some critical variables may
cross the farther set of alarm limits. When alarm limits are violated, the computer of the
MTU generates an alarm so that the operator takes an emergency action before the
system becomes unstable or unsafe. An alarm is in the form of sounding a buzzer or
pronouncement on a speaker.
(iv) Safety Limits: In case a certain parameter crosses a predefined limit indicative of
danger to the process, plant or personnel, the concerned RTU or the protection system of
the plant generates a command to shut down a part or whole of the process. Typically,
one or more circuit breakers are tripped by protective relays to shut off power supply to
a part or whole of the process/plant.
5.4 Trend Monitoring
The following trends are generally monitored:
(i) Variation of critical/ important parameters with time , and/ or
(ii) Rate of variation of critical/ important parameters.
These trends usually reveal the working and health of the system much more than do the
absolute values of the system parameters. The trends are calculated in real time by the computer
of the MTU from the data received by it from the RTUs, and are displayed to the operator as
curves on video monitor to enable him to take appropriate action as and when he notices an
abnormal trend.
6. Control
Control instructions (set points and discrete control commands) are sent by MTU to the
RTUs. The set points received by an RTU are delivered by it to the concerned automatic
controllers. The discrete control commands received by an RTU are executed as under:
(a) A simple device control command is delivered by the RTU to the concerned actuator.
(b) When a sequential control command is received by an RTU, it initiates the intended
sequence of actions.
(c) When a regulation command (like raise-lower, or up-down command) is received by
an RTU it is interpreted by the RTU and delivered to the related actuator. For example,
raise command is delivered to the lower terminal of a gate controller for raising a
8
dam gate continuously as long as the raise command continues and lower command
is delivered to the lower terminal of the gate controller for similarly lowering the gate
continuously as long as the lower command is present.
7. Data Collection, Storage and Retrieval
As explained earlier, each RTU acquires certain data from the controlled process/ plant,
processes it appropriately, and then transmits to the MTU at appropriate instants. Some of the
data so received by the MTU is stored in the mass-storage media of the MTU. An operator can
later on retrieve a block of data of his interest from the storage and recreate an event, sequence or
history for visualization and analysis
7.1 Types of Data Stored
Three types of data are stored by the MTU in its mass-storage media:
(a) Disturbance Data: Short duration data, the duration of which ranges typically between a
few seconds to several minutes, is stored for recording a disturbance in the process.
(b) Historical Data: Medium duration data, its duration ranging from a few hours to several
days, is recorded for keeping a history of operation of the process.
(c) Planning Data: Long duration data, recorded typically over a month, a quarter of a year,
one full year, or even a few years, is meant to serve as a vital input for planning.
7.2 Time Stamping of Data
The data received from various RTUs is stored with chronology to recreate a disturbance
event or a historical event. To that end, the individual data must be tagged with the time of its
occurrence, or time-stamped, either at the receiving end (that is by the MTU) or at the
transmitting end (that is by the individual RTUs). Because of variable delays in transmission of
data from different RTUs to the MTU, the first option can distort the sequence of activities
represented by the data. On the other hand, the second option can distort the data if the time
clocks of various RTUs are not synchronized. The best option is synchronize the clocks of all
RTUs and MTU and to time stamp the data at RTUs. If the controlled process is located within
small premises, synchronizing the clocks of all RTUs and MTU becomes a simple task. On the
hand, if the process is spread over a large area (typical in the case of utilities), the time clocks of
all RTUs and MTU are synchronized using GPS (geographical positioning system).
8. Calculation
Calculations are made both in RTUs and MTU. The nature and extent of these calculations
are brought out below:
8.1 Calculations in RTU
The microprocessor of an RTU is required to perform simple calculations or data processing,
such as:
(a) Filtering the data acquired by it to remove noise,
(b) Extraction of desired information, like maximum, minimum, rms or average value or rate
of change, from filtered data,
(c) Conversion of numbers to values in engineering units, and
(d) Compression of data to reduce data-transmission-rate and storage requirements.
8.2 Calculations in MTU
The calculations that need to be made by the computer of the MTU are in general fairly
extensive and complex. These calculations are made for predicting the behavior of the system
(controlled process) through mathematical modeling for certain anticipated conditions and
certain inputs to the system, both for normal and contingency operation. The output of these
calculations is a set control instructions to be sent to different RTUs for each set of system
conditions and inputs. The calculations are usually made on floating-point numbers and in batch
mode.
9. Report Generation
One of the important functions of SCADA software is to generate a vast number of reports
on the basis of the data stored by the MTU. To that end, SCADA software includes a report
generator module, which retrieves data from the MTU database and generates the desired reports
from it. The software module allows the user to choose the format of reports, customize the style
of reports, insert graphics and even perform calculations.
9.1 Purpose of Report Generation
These reports provide an invaluable information support to decision making in:
(a)
(b)
(c)
(d)
10
(c) Screen printouts are taken occasionally when a need to analyse the data off-line arises,
say, following a major disturbance or breakdown.
(d) Operational and statistical reports are generated at longer intervals, say monthly,
quarterly or annually, to serve as information inputs to management and planning
exercises.
9.4 Where to Generate/ Print a Report?
Various reports are generated/ printed at different places as under:
(a) The reports required to be generated periodically and/or on demand, are generated and
printed in the control room. A printer is included as a part of operators console.
(b) As mentioned earlier, a dedicated printer was earlier used for continuous printing of event
and alarm logs. To avoid printing noise in the control room, such printers were often
placed in a separate (preferably sound-proof) chamber close to the control room.
(c) Statistical reports are usually required by the corporate decision makers. In a typical
modern scenario, corporate servers and computers are connected to the MTU server on a
network (LAN or WAN or Internet). Therefore, statistical reports are generated on the
corporate computers and printed in the concerned corporate department.
(d) Some of the reports may need to be generated by a maintenance engineer to help him in
trouble-shooting. He would generally use a laptop computer to access database of
SCADA system and generate the necessary report by plugging it to the SCADA network.
12