Practical No:

AIM: - To study SCADA

OBJECTIVE:

To study various components of SCADA

To study various features of SCADA
To study Hardware and Software requirements of SCADA

THEORY:Components of SCADA
The typical components of a SCADA system with emphasis on the SCADA software are indicated in
the diagram below:

SCADA Hardware
A SCADA system consists of a number of remote terminal units (RTUs) collecting field data and
sending that data back to a master station, via a communication system. The master station displays
the acquired data and allows the operator to perform remote control tasks. The accurate and timely
data allows for optimization of the plant operation and process. Other benefits include more efficient,
reliable and most importantly, safer operations. These results in a lower cost of operation compared
to earlier non-automated systems.
On a more complex SCADA system there are essentially five levels or hierarchies:
Field level instrumentation and control devices
Marshalling terminals and RTUs
Communications system
The master station(s)
The commercial data processing department computer system
The RTU provides an interface to the field analog and digital sensors situated at each remote site.
The communications system provides the pathway for communication between the master station
and the remote sites. This communication system can be wire, fiber optic, radio, telephone line,

microwave and possibly even satellite. Specific protocols and error detection philosophies are used
for efficient and optimum transfer of data. The master station (or sub-masters) gather data from the
various RTUs and generally provide an operator interface for display of information and control of
the remote sites. In large telemetry systems, sub-master sites gather information from remote sites
and act as a relay back to the control master station.
SCADA Software
SCADA software can be divided into two types, proprietary or open. Companies develop proprietary
software to communicate to their hardware. These systems are sold as turnkey solutions. The main
problem with this system is the overwhelming reliance on the supplier of the system. Open software
systems have gained popularity because of the interoperability they bring to the system.
Interoperability is the ability to mix different manufacturers equipment on the same system.
Citect and WonderWare are just two of the open software packages available in the market for
SCADA systems. Some packages are now including asset management integrated within the
SCADA system. The typical components of a SCADA system are indicated in the following
diagram.

Typical SCADA System

Features of SCADA
Typical key features expected of the SCADA software are listed below. These features depend on the
hardware to be implemented.
User interface
Keyboard
Mouse
Trackball
Touch screen

Graphics displays
Customer-configurable, object orientated and bit mapped
Unlimited number of pages
Resolution: up to 1280 1024 with millions of colors.
Alarms
Client server architecture
Time stamped alarms to 1 millisecond precision (or better)
Single network acknowledgment and control of alarms
Alarms are shared to all clients
Alarms displayed in chronological order
Dynamic allocation of alarm pages
User-defined formats and colors
Up to four adjustable trip points for each analog alarm
Deviation and rate of change monitoring for analog alarms
Selective display of alarms by category (256 categories)
Historical alarm and event logging
Context-sensitive help
On-line alarm disable and threshold modification
Event-triggered alarms
Alarm-triggered reports
Operator comments can be attached to alarms.
Trends
Client server architecture
True trend printouts not screen dumps
Rubber band trend zooming
Export data to DBF, CSV files
X/Y plot capability
Event based trends
Pop-up trend display
Trend gridlines or profiles
Background trend graphics
Real-time multi-pen trending.
Short and long term trend display
Length of data storage and frequency of monitoring can be specified on a per-point basis
Archiving of historical trend data
On-line change of time-base without loss of data
On-line retrieval of archived historical trend data
Exact value and time can be displayed
Trend data can be graphically represented in real-time.
RTU (and PLC) interface
All compatible protocols included as standard
DDE drivers supported
Interface also possible for RTUs, loop controllers, bar code readers and other equipment
Driver toolkit available
Operates on a demand basis instead of the conventional predefined scan method.

 Optimization of block data requests to PLCs

Rationalization of network user data requests
Maximization of PLC highway bandwidth.
Scalability
Additional hardware can be added without replacing or modifying existing equipment
Limited only by the PLC architecture (typically 300 to 40 000 points)
Access to data
Direct, real-time access to data by any network user
Third-party access to real-time data, e.g. Lotus 123 and Excel
Network DDE
DDE compatibility: read, write and exec
DDE to all IO device points
Clipboard
Database
ODBC driver support
Direct SQL commands or high level reporting
Networking
Supports all NetBIOS compatible networks such as NetWare, LAN Manager, Windows for
Workgroups, Windows NT (changed from existing)
Support protocols NetBEUI, IPX/SPX, TCP/IP and more
Centralized alarm, trend and report processing data available from anywhere in the network
Dual networks for full LAN redundancy
No network configuration required (transparent)
May be enabled via single check box, no configuration
LAN licensing is based on the number of users logged onto the network, not the number of nodes
on the network
No file server required
Multi-user system, full communication between operators
RAS and WAN supported with high performance
PSTN dial up support.
Fault tolerance and redundancy
Dual networks for full LAN redundancy
Redundancy can be applied to specific hardware
Supports primary and secondary equipment configurations
Intelligent redundancy allows secondary equipment to contribute to processing load
Automatic changeover and recovery
Redundant writes to PLCs with no configuration
Mirrored disk I/O devices
Mirrored alarm servers
Mirrored trend servers
File server redundancy
No configuration required, may be enabled via single check box, no configuration.
Client/server distributed processing
Open architecture design
Real-time multitasking

 Client/server fully supported with no user configuration

Distributed project updates (changes reflected across network)
Concurrent support of multiple display nodes
Access any tag from any node
Access any data (trend, alarm, report) from any node.
SCADA Software Package
While performance and efficiency of the SCADA package with the current plant is important, the
package should be easily upgradeable to handle future requirement. The system must be easily
modifiable as the requirement change and expandable as the task grows, in other words the system
must use a scalable architecture. There have been two main approaches to follow in designing the
SCADA system in the past. They are centralized and distributed.
Centralized: A single computer or mainframe performs all plant monitoring and all plant data is
stored on one database that resides on this computer.
The disadvantages with this approach are simply:
Initial up front costs are fairly high for a small system
A gradual (incremental) approach to plant upgrading is not really possible due to the fixed size of
the system
Redundancy is expensive as the entire system must be duplicated.
The skills required of maintenance staff in working with a mainframe type computer can be fairly
high.

Centralized processing
Distributed: SCADA system is shared across several small computers (usually PCs). Although the
disadvantages of the centralized approach above are addressed with a distributed system, the
problems are:
Communication between different computers is not easy, resulting in configuration problems
Data processing and databases have to be duplicated across all computers in the system, resulting in
low efficiencies

 There is no systematic approach to acquiring data from the plant devices if two operators require
the same data, the RTU is interrogated twice

Distributed processing
An effective solution is to examine the type of data required for each task and then to structure the
system appropriately. A client server approach also makes for a more effective system.
A client server system is understood as follows:
A server node is a device that provides a service to other nodes on the network. A common example
of this is a database program. A client on the other hand is a node that requests a service from a
server. The word client and server refer to the program executing on a particular node.
A good example is a display system requiring display data. The display node (or client) requests the
data from the control server. The control server then searches the database and returns the data
requested, thus reducing the network overhead compared to the alternative approach of the display
node having to do the database search itself.
A typical implementation of a SCADA system is shown in the figure below.

Client server approach as applied to a SCADA system

There are typically five tasks in any SCADA system. Each of these tasks performs its own separate
processing.
Input/output task
This program is the interface between the control and monitoring system and the plant floor.
Alarm task
This manages all alarms by detecting digital alarm points and comparing the values of analog alarm
points to alarm thresholds.
Trends task
The trends task collects data to be monitored over time.
Reports task
Reports are produced from plant data. These reports can be periodic, event triggered or activated by
the operator.
Display task
This manages all data to be monitored by the operator and all control actions requested by the
operator.

A large SCADA application

Redundancy
If any processes or activities in the system are critical, or if the cost of loss of production is high,
redundancy must be built into the system. This can be done in a number of ways. One of the
approach is to use the clientserver approach, which allows for different tasks (comprising the
SCADA system) to run on different PC nodes. For example, if the trend task were important, this
would be put in both the primary and secondary servers. The primary server would constantly
communicate with the secondary server updating its status and the appropriate databases. If the
primary server fails, the standby server will then take over as the primary server and transfer
information to the clients on the network.
System Response Time
These should be carefully specified for the following events. Typical speeds that are considered
acceptable are:
Display of analog or digital value (acquired from RTU) on the master station operator display (1 to
2 seconds maximum)
Control request from operator to RTU (1 second critical; 3 seconds noncritical)
Acknowledge of alarm on operator screen (1 second)
Display of entire new display on operator screen (1 second)
Retrieval of historical trend and display on operator screen (2 seconds)
Sequence of events logging (at RTU) of critical events (1 millisecond)

It is important that the response is consistent over all activities of the SCADA system.
Hence the above figures are irrelevant unless the typical loading of the system is also specified under
which the above response rates will be maintained. In addition no loss of data must occur during
these peak times.
A typical example of specification of loading on a system would be:
90% of all digital points change status every 2 seconds (or go from healthy into alarm condition).
80% of all analog values undergoing a transition from 0 to 100% every 2 seconds.
The distributed approach to the design of the SCADA system (where the central site/master station
does not carry the entire load of the system) ensures that these figures can be easily achieved.
Expandability of the system
A typical figure quoted in industry is that if expansion of the SCADA system is anticipated over the
life of the system the current requirements of the SCADA system should not require more than 60%
of the processing power of the master station and that the available mass storage (on disk) and
memory (RAM) should also be approximately 50% of the required size.
It is important to specify the expansion requirements of the system, so that
The additional hardware that will be added will be of the same modular form, as that existing and
will not impact on the existing hardware installed.
The existing installation of SCADA hardware/control cabinets/operator displays will not be
unfavorably impacted on by the addition of additional hardware. This includes items such as power
supply/air conditioning/SCADA display organization.
The operating system will be able to support the additional requirements without any major
modifications.
The application software should require no modifications in adding the new RTUs or operator
stations at the central site/master station.
Distributed Network Protocol
The distributed network protocol is a data acquisition protocol used mostly in the electrical and
utility industries. It is designed as an open, interoperable and simple protocol specifically for
SCADA controls systems. It uses the master/slave polling method to send and receive information,
but also employs sub-masters within the same system. The physical layer is generally designed
around RS-232, but it also supports other physical standards such as RS-422, RS-485 and even fiber
optic. There is large support within the SCADA industry to use DNP as the universal de facto
standard for data acquisition and control.
The DNP is well developed as a device protocol within a complete SCADA system. It is designed as
a data acquisition protocol with smart devices in mind. These devices then can be coupled as a multidrop fieldbus system. The fieldbus DNP devices are integrated into a software package to become a
SCADA system. DNP does not specify a single physical layer for the serial bus (multi-mode)
topology. Devices can be connected by 422 (four wire), 485 (two wire), modem (Bell 202) or with
fiber optic cable. The application program can integrate DNP with other protocols if the SCADA
software permits. Using tunneling or encapsulation the DNP could be connected to an intranet or the
Internet.