Oops, page not found.

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 objectoriented 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.