SCADA 1

SCADA:
SCADA stands for supervisory control and data acquisition. It generally refers to industrial control
systems: computer systems that monitor and control industrial, infrastructure, or facility-based
processes, as described below:

 Industrial processes include those of manufacturing, production, power generation, fabrication,

and refining, and may run in continuous, batch, repetitive, or discrete modes.
 Infrastructure processes may be public or private, and include water treatment and distribution,
wastewater collection and treatment, oil and gas pipelines, electrical power transmission and
distribution, Wind Farms, civil defense siren systems, and large communication systems.
 Facility processes occur both in public facilities and private ones, including buildings, airports,
ships, and space stations. They monitor and control HVAC, access, and energy consumption.

A SCADA's System usually consists of the following subsystems:

 A Human-Machine Interface or HMI is the apparatus which presents process data to a human
operator, and through this, the human operator monitors and controls the process.
 A supervisory (computer) system, gathering (acquiring) data on the process and sending
commands (control) to the process.
 Remote Terminal Units (RTUs) connecting to sensors in the process, converting sensor signals
to digital data and sending digital data to the supervisory system.
 Programmable Logic Controller (PLCs) used as field devices because they are more
economical, versatile, flexible, and configurable than special-purpose RTUs.
 Communication infrastructure connecting the supervisory system to the Remote Terminal
Units.

Human Machine Interface:

A Human-Machine Interface or HMI is the

apparatus which presents process data to a
human operator, and through which the human
operator controls the process.

An HMI is usually linked to the SCADA

system's databases and software programs, to
provide trending, diagnostic data, and
management information such as scheduled
maintenance procedures, logistic information,
detailed schematics for a particular sensor or machine, and expert-system troubleshooting guides.

The HMI system usually presents the information to the operating personnel graphically, in the form of
a mimic diagram. This means that the operator can see a schematic representation of the plant being
 SCADA 2

controlled. For example, a picture of a pump connected to a pipe can show the operator that the pump
is running and how much fluid it is pumping through the pipe at the moment. The operator can then
switch the pump off. The HMI software will show the flow rate of the fluid in the pipe decrease in real
time. Mimic diagrams may consist of line graphics and schematic symbols to represent process
elements, or may consist of digital photographs of the process equipment overlain with animated
symbols.

The HMI package for the SCADA system typically includes a drawing program that the operators or
system maintenance personnel use to change the way these points are represented in the interface.
These representations can be as simple as an on-screen traffic light, which represents the state of an
actual traffic light in the field, or as complex as a multi-projector display representing the position of
all of the elevators in a skyscraper or all of the trains on a railway.

An important part of most SCADA implementations is alarm handling. The system monitors whether
certain alarm conditions are satisfied, to determine when an alarm event has occurred. Once an alarm
event has been detected, one or more actions are taken (such as the activation of one or more alarm
indicators, and perhaps the generation of email or text messages so that management or remote
SCADA operators are informed). In many cases, a SCADA operator may have to acknowledge the
alarm event; this may deactivate some alarm indicators, whereas other indicators remain active until
the alarm conditions are cleared. Alarm conditions can be explicit - for example, an alarm point is a
digital status point that has either the value NORMAL or ALARM that is calculated by a formula
based on the values in other analogue and digital points - or implicit: the SCADA system might
automatically monitor whether the value in an analogue point lies outside high and low limit values
associated with that point. Examples of alarm indicators include a siren, a pop-up box on a screen, or a
coloured or flashing area on a screen (that might act in a similar way to the "fuel tank empty" light in a
car); in each case, the role of the alarm indicator is to draw the operator's attention to the part of the
system 'in alarm' so that appropriate action can be taken. In designing SCADA systems, care is needed
in coping with a cascade of alarm events occurring in a short time, otherwise the underlying cause
(which might not be the earliest event detected) may get lost in the noise. Unfortunately, when used as
a noun, the word 'alarm' is used rather loosely in the industry; thus, depending on context it might
mean an alarm point, an alarm indicator, or an alarm event.

DDE:
DDE is the acronym for Dynamic Data Exchange. DDE is a communication protocol designed by
Microsoft to allow applications in the Windows environment to Send/receive data and instructions
to/from each other. It implements a client-server relationship between two concurrently running
applications. The server application provides the data and accepts requests from any other application
interested in its data. Requesting applications are called clients. DDE is often used to gather and
distribute "live" data such as production measurements from a factory floor, scientific instrument
readings, or stock price quotations. Client applications can use DDE for one-time data transfers or for
ongoing data exchanges in which updates are sent as soon as new information is available. DDE can be
used to dispatch control instructions to process-connected instruments. For example, in a factory
automation system, DDE client applications may send control temperature set points to ovens.

DDE compliance is a standard feature for Windows applications needing data links to other
applications. For example, DDE-compliant applications include, Microsoft Excel, Lotus 1-2-3 for
Windows, and InTouch, etc. Network extensions are available to allow DDE links between
 SCADA 3

applications running on different computers connected via networks or modems. For example,
NetDDE supports DDE between applications running on IBM PCs connected via LAN or modem and
DDE-aware applications running on non-PC based platforms under operating environments such as
VMS and UNIX. To obtain data from another application, the client program opens a channel to the
server application by specifying two things: the server's application name and the topic name of
interest. Once a channel is open, items in the topic can be read or written. For example, in the case of
Excel, the application name is "Excel." The topic name is the name of the spreadsheet that contains the
data. The item name is the specific cell on the spreadsheet containing the data. With InTouch, the
application name is "View." When reading or writing a tag name in the InTouch database, the topic
name is always the word "Tag name." The item name is the actual tag name defined in the InTouch
database. When a client application sets up a link to another DDE program, it asks the server
application to advise the client whenever a specific item's value changes. These data links remain
active until either the client or server terminates the link or the conversation. This is an efficient means
of exchanging data because once the link has been established no communication occurs until the
specified item changes. InTouch uses DDE to communicate with I/O device drivers and other DDE
application programs.

SCADA Features:
Performance features are:

Object-Oriented Graphics: Easy-to-configure applications mean faster development times.

Objects and groups of objects can be moved, sized and animated quickly and easily. Powerful object-
oriented design tools make it easy to draw, arrange, align, layer, space, rotate, invert, duplicate, cut,
copy , paste and erase objects. InTouch now supports Microsoft's powerful standard ActiveX
technology, allowing standard ActiveX objects to be used with InTouch. InTouch supports any video
resolution supported by Windows, and multi-monitor configurations are supported.

Animation Links: Animation links may be combined to provide complex size, color, movement,
and/or position changes. Animation links include discrete, analog and string touch inputs; horizontal
and vertical sliders; discrete and action push buttons; show and hide window push buttons; line, fill
and text color links for discrete and analog values and alarms; object height and width links; vertical
and horizontal position links, rotational links, and more.

Distributed Alarming: This capability supports multiple alarm servers or 'providers'

simultaneously, which gives operators the ability to view alarm information from multiple remote
locations at the same time. The distributed alarm functions let users implement 'point-and-click' alarm
acknowledgment, alarm scroll bars and many other features for networked use.

Distributed Historical Trending: InTouch allows you to dynamically specify

different historical file data sources for each of the pens on a trend chart. These historical file sources
can be other InTouch databases or any IndustrialSQL Server database. Since InTouch permits the use
of up to 16 pens per trend chart, users can have an unprecedented amount of historical data available
for viewing at any given time.
 SCADA 4

The Symbol Factory:

The Symbol Factory is a collection of wizards and nearly 300 bitmaps of medium complexity for use
in InTouch. The Symbol Factory can also store any third-party wizard, Wonderware wizard, or
InTouch object. This provides you with convenient access your wizards and graphic objects.

the InTouch program directory for the wizards to function properly. If you add an InTouch object that
has animation links associated with it, to the Symbol Factory, the links are also stored with the object.
Any tagnames associated with the object are automatically converted to placeholder tagnames. Since
tagnames can be up to 32 characters long, you can include long descriptions for each placeholder
tagname to aid other users of this symbol.

Tags and the tag database:

In the tag database, you define the data you want RSView32™ to monitor. Each entry in the database
is called a tag. A tag is a logical name for a variable in a device or in local memory (RAM). For
example, a tag can represent a process variable in a programmable controller. The current value of a
tag, when required, is updated from the device it is connected to and stored in computer memory—
referred to as the value table—so it is immediately accessible to all parts of RSView32. For example,
graphic displays use tag values to control animation or update a trend, alarm monitoring compares
current tag values to pre– defined limits, and data logging stores tag values to create a historical
record.

RSView32 uses the following types of tags:

Tag Type of data stored Analog Range of values. These tags can represent variable
states such as temperature or the position of rotary controls.

Digital 0 or 1: These tags can represent devices that can only be on or off, such as switches, contacts,
and relays.

String ASCII string, series of characters, or whole words (maximum of 82 characters).

These tags can represent devices that use text, such as a bar code scanner which uses an alphanumeric
product code. System Information generated while the system is running,
including alarm information, communication status, system time and date, and so on.

Data sources: When defining an analog, digital, or string tag, you must specify a data
source. The data source determines whether the tag receives its values externally or internally.

Device: A tag with Device as its data source receives its data from a source external to RSView32. The
data can come from a direct programmable controller driver or from an OPC® or DDE server. Tags
with Device as the data source count toward the total tag limit you purchased (150, 300, 1,500, and so
on).
 SCADA 5

Memory: A tag with Memory as its data source receives its data from the RSView32 internal value
table. A memory tag can be used to store values internally. Tags with Memory as the data source do
not count toward the total tag limit.

Unsigned Integer Unsigned 16–bit integer 0 to 65,535

Integer Signed 16–bit integer -32,768 to 32,767
Long Integer Signed 32–bit integer -2,147,483,648 to -2,147,483,647
Floating Point Single–precision (32–bit) floating point -3.402823E+38 to - 1.175494E-38, 0,
1.175494E-38 to 3.402823E+38

Byte Unsigned 8–bit integer 0 to 255

3–Digit BCD 3–digit binary–coded decimal 0 to 999

Adding alarms to tags:

Analog and digital tags can have alarms associated with them. At runtime, RSView32 scans the tag
values in the tag database and compares them to the limits you set for the tags. If a tag value crosses
a limit, an alarm is triggered. When a tag has an alarm configured for it, an X appears in the Alm
column of the Tag Database editor’s spreadsheet and the Alarm button in the editor’s form is
highlighted (enabled).

Key concepts:
An alarm occurs when something goes wrong. It can signal that a device or process has ceased
operating within acceptable, predefined limits or it can indicate breakdown, wear, or a process
malfunction. Set up a system of alarms in the Tag Database editor by linking alarms to tags you want
monitored. When the tag values are updated in the value table, they are compared to the limits you
assigned when you configured the alarm. If a tag value exceeds the configured limits, an alarm of a
preset severity is triggered.

Alarm acknowledgment:
If an alarm appears in the alarm summary or some other alarm display, an operator can acknowledge
the alarm. Acknowledging an alarm does not correct the condition causing the alarm, but indicates that
an operator is aware of the alarm.

A tag, not an alarm, is acknowledged. A single tag might have caused several alarms. For example, a
tag representing temperature might have triggered Warm, Hot, and Overheat alarms by the time it is
acknowledged. The tag could also have gone in and out of alarm several times before being
acknowledged. One acknowledgment is all that is required for all previous and current alarms for a tag,
so alarm log files often show fewer acknowledgments than alarms.