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.