Distinguished Professor
Department of Electrical and Electronics Engineering School of Engineering and Technology SHARDA UNIVERSITY
Greater Noida, India 

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.

1.1 Overview

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:

(i) Remoteterminalunits(RTUs)

(ii) Master terminal unit (MTU) 

(iii)MTU-RTU communication subsystem (iv)Field devices (FDs)
(v) RTU-FD communication subsystem.

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

(viii) Report generation

2. Human-Machine Interface (HMI) 

2.1 What is HMI?

The SCADA system is designed to monitor and control the process/ plant automatically most of the time. However, for various reasons provisions are made for human operators to continuously watch its operation and to intervene as and when felt necessary by them. This requires an interface between the SCADA system and the human operators. The same is provided as a standard practice in the MTU located in the control room. The MTU is built and functions around a computer. Therefore, the human-SCADA interface is realised through human-computer interface, commonly known as human-machine interface (HMI) and sometimes as graphic operator interface (GOI).

2.2 Role of HMI

The human-machine interface (HMI) enables the operator:

(a) to ‘watch’ the process/plant being monitored and controlled by SCADA system, and

(b) to ‘intervene’ as and when considered necessary by him.

2.3 What Does HMI Comprise?

In order to perform the above role, the HMI comprises suitable hardware (input/output devices or computer peripherals as discussed below) and the related software drivers (or data- transfer software):

A. Input Devices for HMI: The input device almost always used for HMI is the standard (ASCII) keyboard, one on each operator console. The operator can use it for entering (a) data and (b) instructions for intervention in the computer control.

B. Output Devices for HMI: The following output devices are used for HMI:

(i) The mostly used output device is the video monitor or video display unit (VDU) along with a mouse, one monitor-mouse pair on each operator console. Colour LCD monitors are now preferred to achieve a better visual impact in presenting status, events, alarms and trends to the operator.

(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 single- line 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 high- resolution 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).

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 analog- to-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.

4. Data Acquisition (DAQ)

Data are acquired and processed by RTUs and transmitted to MTU on the MTU-RTU data network.

4.1 What Data are Acquired?
As briefly mentioned under the review of SCADA system, two types of data are continuously acquired by the RTU:

(a) Analog Values: Values of the uncontrolled as well as controlled variables, which are almost always analog in nature, are acquired continuously using suitable analog sensors (or transducers), signal conditioners and a microprocessor-based data acquisition circuit. The sensors are naturally placed at the locations where the variables are located. The signal conditioners may be located close to the sensors or inside the RTU or in front of the RTU. In the last case, the external signal conditioner processes the electrical signal coming from a sensor before inputting it to the RTU. In case of a smart sensor, the signal conditioning circuit is integrated with a micro-sensor in a single chip. Data acquisition circuit is an internal and important component of the RTU.

(b) Status Information: Information about the states of remotely as well as locally controlled objects, which is essentially discrete or binary in nature, is also acquired continuously. This is done using suitable status sensors and a data acquisition circuit.

4.2 When are Data Transmitted?

The data acquired as above is processed in the RTU to extract the information as required by the MTU. Details of the data processing will be taken up under the “calculation” function of RTU. The extracted information (or processed data) is transmitted by the RTU to the MTU on five occasions:

(i) Periodically at a pre-determined rate (this rate is often different for different data).
(ii) Whenever an event takes place (event means a change larger than a predefined change
from the normal or the previous value of a variable or a change in the state of an object).
(iii) On start-up of the plant or process.
(iv) Whenever the process or plant is restarted.
(v) In response to a demand made by MTU.

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.

5.1 Status Monitoring

As one its important functions, the RTU determines the status of two-state objects from the status information acquired continuously by it (as already discussed under Data Acquisition). It takes some finite time for the object to change from one stable state to the other stable state. Thus the object is in an intermediate but unstable state during the change-over. The method of determining the status should be such that the decision of the RTU is not vitiated by this intermediate state. Very often, this is achieved by introducing a delay in making the decision, which is a little more than the operating time of the object. The status of important objects monitored by the RTU in this way is transmitted by it to the MTU for displaying to the operator on video monitor.

5.2 Event Monitoring

Generally it is the RTU which is responsible for detecting events and intimating to the MTU. The RTU compares the current value of a variable against its previous, normal or reference value. If the change exceeds a predefined increment or decrement, an event is said to have taken place. Similarly, the RTU compares the current status of an object against the previous, normal or reference state of that object. If the change is of a predefined type, an event is said to have occurred. Moreover, the event can be one of the following types:

(i) Instantaneous Event: It means an abrupt change or a change without any intentional delay. This type of event is communicated at once by the RTU to the MTU.

(ii) Delayed Event: It means a change with an intentional delay. It is communicated by the RTU only when the change is completed.

(iii) Sequential Event: It means a sequence of activities or changes. This type of event is communicated by the RTU on the completion of the sequence.

In each case, as and when an intimation of the occurrence / completion of an event is received by the MTU, it stores the same in its computer memory and annunciates or displays suitably to the operator on speaker/ buzzer/ video monitor of HMI.

5.3 Limit Monitoring

Four sets of limits are monitored in a well-designed SCADA system:

(i) Reasonability Limits: Every feedback controller is expected to monitor and maintain the value of the variable controlled by it within a pair of upper and lower limits, called reasonability limits. In case the value of the variable tends to rise above the upper limit or fall below the lower limit, the controller take corrective action to keep the value within the limits.

(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 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) Operation of the whole system

(b) Maintenance of the whole system

(c) Management of the business related to the controlled process

(d) Technical and business planning, both short-term and long-term.

9.2 Types of Reports

A good report generator (software) is capable of generating the following types of reports. However, the exact nature, number, format and contents of the reports depend on the user’s need and liking and the purpose of such reports.

(a) Status Report: Reflecting the analog values of important variables, states of important objects, set points, limit settings, etc., at a specified time.

(b) Trend Report: Reflecting the trends of the variation or the rate of variation of certain selected variables over a specified period.

(c) Event Report or Event Log: A log of the events recorded over a specified period.

(d) Alarm Report or Alarm Log: A log of the alarms generated over a specified period.

(e) Communication Report or Communication Log: A log of the communications taken place between the MTU and the selected RTUs over a specified period.

(f) Display Printout or Screen Printout: A printout of a selected screen/ display on a VDU.

(g) Operational Reports: Reports on other operational aspects of the system, like a record of data preceding and following an event or disturbance, energy consumption by different parts of the process/ system over a specified period, record of production over a specified period, and so on.

(h) Statistical Reports: Reports showing statistical information or presenting information based on statistical analysis of the operational data recorded by the MTU.

9.3 When to Generate Reports?

These reports are generated variously on continuous, periodic or on-demand basis as under:

(a) Some of the reports, like status, trend, event or alarm reports, are generated periodically, for example, every 8, 12 or 24 hours. In addition, reports of the most recent events and alarms are generated on demand following a disturbance or breakdown in the system.

(b) An earlier practice was to generate continuous logs of events and alarms on a dedicated printer. This practice resulted in gross wastage of paper and printing ink, as most of the printed output would never be looked into. The reason for this practice was that the electronic/ magnetic memories were not considered very reliable or were too expensive. This practice is now largely obsolete because of the changed condions.

(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 periodicallyl and/or on demand, are generated and printed in the control room. A printer is included as a part of operator’s 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 reportsk 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.


🕶 JcGreg AdPlugIT


We have done above subject for high rise and commercial building BMS and FDAS. Industrial HMI and Automation. Marine vessel instrumentation. Wind, Solar, and Biomass Power Plant local and remote SCADA- generation capacity of 12KW to 50MW.

You may be looking for a System Integrator (SI). We offer our experience and expertise.

Looking forward to serve you.

Jess C.Gregorio

InSpecIT Inc.

Unit 719/722 City & Land Mega Plaza Bldg.

ADB Ave. cor. Garnet Road, Ortigas Center

San Antonio, Pasig City, Philippines 1605

We do SCADA, BMS, FDAS, FMS, HMI, and Control System Integration.

Follow our Flipboard Magazines

Subscribe to our Technology Newsletter.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s