The Fundamentals of SCADA

A Supervisory Control and Data Acquisition (SCADA) system is a widely distributed computerized system primarily used to remotely control and monitor the condition of field-based assets from a central location. Field-based assets include wells, pump stations, valves, treatment plants, tanks, and reservoirs. For a water distribution network, the common objectives of a SCADA system are to do the following: Monitor the system Obtain control over the system and ensure that required performance is always achieved Reduce operational staffing levels through automation or by operating a system from a single central location Store data on the behavior of a system and therefore achieve full compliance with mandatory reporting requirements for any regulatory agency Provide information on the performance of the system and establish effective asset management procedures for the system Establish efficient operation of the system by minimizing the need for routine visits to remote sites and potentially reduce power consumption during pumping operations through operational optimization Provide a control system that will enable operating objectives to be set and achieved Provide an alarm system that will allow faults to be diagnosed from a central point, thus allowing field repair trips to be made by suitably qualified staff to correct the given fault condition and to avoid incidents that may be damaging to the environment

2004 Bentley Systems, Incorporated. All rights reserved.

The Fundamentals of SCADA

COMPONENTS OF A SCADA SYSTEM

SCADA encompasses the transfer of data between a SCADA central host computer and a number of remote sites (Remote Terminal Units or RTUs), and the central host and the operator terminals. Figure 1 shows a generic SCADA system that employs some form of data multiplexing (MUXs) between the central host and the RTUs. These multiplexers serve to route data to and from a number of RTUs on a local network, while using one or very few physical links on a Wide Area Network (WAN) backbone to pass data back to the central host computer.
Figure 1
Generic SCADA system network

SCADA systems consist of One or more field data interface devices usually called Remote Stations, Remote Terminal Units (RTUs), or Programmable Logic Controllers (PLCs), which interface to field sensing devices and local control switchboxes and valve actuators. A communications system used to transfer data between field data interface devices and control units and the computers in the SCADA central host. The system can be radio, telephone, cable, satellite, and so on, or any combination of these.

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

A central host computer server or servers (sometimes called a SCADA Center, master station, master terminal unit, or MTU). A communications system to support the use of operator workstations that may be geographically remote from the central host computer. A collection of standard and/or custom software [sometimes called Human Machine Interface (HMI) software or Man Machine Interface (MMI) software] systems used to provide the SCADA central host and operator terminal application, support the communications system, and monitor and control remotely located field data interface devices. Each of the preceding components is described in the following subsections.

Field Data Interface Devices Field data interface devices form the eyes and ears of a SCADA system. Devices such as reservoir level meters, water flow meters, valve position transmitters, temperature transmitters, power consumption meters, and pressure meters all provide information that can tell an experienced operator how well a water distribution system is performing. In addition, equipment such as electric valve actuators, motor control switchboards, and electronic chemical dosing facilities can be used to form the hands of the SCADA system and assist in automating the process of distributing water. However, before any automation or remote monitoring can be achieved, the information that is passed to and from the field data interface devices must be converted to a form that is compatible with the language of the SCADA system. To achieve this, some form of electronic field data interface is required. Remote Terminal Units (RTUs), also know as Remote Telemetry Units, provide this interface. RTUs are primarily used to convert electronic signals received from (or required by) field devices into (or from) the language (known as the communication protocol) used to transmit the data over a communication channel. RTUs appear in the field as a box in a switchboard with electrical signal wires running to field devices and a cable link to a communication channel interface, such as a radio (see Figure 2). The instructions for the automation of field data interface devices, such as pump control logic, are usually stored locally. This is largely due to the limited bandwidth typical of communications links between the SCADA central host computer and the field data interface devices. Such instructions are traditionally held within local electronic devices known as Programmable Logic Controllers (PLCs), which have in the past been physically separate from RTUs (see Figure 3). PLCs connect directly to field data interface devices and incorporate programmed intelligence in the form of logical procedures that will be executed in the event of certain field conditions. However, many water systems with SCADA systems have no PLCs. In this case, the local control logic is held within the RTU or in relay logic in the local switchboard.

2004 Bentley Systems, Incorporated. All rights reserved.

The Fundamentals of SCADA

Figure 2
RTU cabinet with RTU (center), radio (top center), and field wiring terminations (left)

Figure 3
Programmable Logic Controller (PLC) performing local control functions, physically separated, but wired to a nearby Remote Terminal Unit (RTU)

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

PLCs have their origins in the automation industry and therefore are often used in manufacturing and process plant applications. The need for PLCs to connect to communication channels was not great in these applications, as they often were only required to replace traditional relay logic systems or pneumatic controllers. SCADA systems, on the other hand, have origins in early telemetry applications, where it was only necessary to know basic information from a remote source. The RTUs connected to these systems had no need for control programming because the local control algorithm was held in the relay switching logic. As PLCs were used more often to replace relay switching logic control systems, telemetry was used more and more with PLCs at the remote sites. It became desirable to influence the program within the PLC through the use of a remote signal. This is in effect the Supervisory Control part of the acronym SCADA. Where only a simple local control program was required, it became possible to store this program within the RTU and perform the control within that device. At the same time, traditional PLCs included communications modules that would allow PLCs to report the state of the control program to a computer plugged into the PLC or to a remote computer via a telephone line. PLC and RTU manufacturers therefore compete for the same market. As a result of these developments, the line between PLCs and RTUs has blurred and the terminology is virtually interchangeable. For the sake of simplicity, the term RTU will be used to refer to a remote field data interface device; however, such a device could include automation programming that traditionally would have been classified as a PLC.

Field Data Communications System The field data communications system is intended to provide the means by which data can be transferred between the central host computer servers and the field-based RTUs. Bandwidth. An important property of a communications channel is its capacity to carry data. The term bandwidth is used to describe this capacity. Originally, the term bandwidth applied to the width, in Hertz, of an analog channel. For example, a telephony voice channel that occupies the nominal band 0.3 to 3.4 kHz has a bandwidth of 3.1 kHz and a radio channel that occupies the spectrum from 929.88875 to 929.8875 MHz has a channel bandwidth of 12.5 kHz. With digital transmission, the term bandwidth has been extended to include the data transmission rate in bits per second (bps). SCADA Communications Availability and Protocols. The availability imposed by the communications infrastructure is an important aspect of the SCADA system. Because SCADA systems are typically deployed over large geographical areas, links to remote SCADA outstations from the central host computer are often multilayered, meaning that there may be several physical and logical paths through which data must be routed before it reaches the intended destination. Such longhaul links may impose a heavy financial consideration on the type of communication systems used and the bandwidth used on those links.

2004 Bentley Systems, Incorporated. All rights reserved.

The Fundamentals of SCADA

As a result of cost constraints, SCADA communications links generally offer less bandwidth and lower reliability than that offered by communications backbones commonly used on a process plant, where there are few geographical constraints and highspeed fiber optic LAN infrastructures may be employed. Process plant communication backbones may exhibit 99.9 percent availability (less than 9 hours outage per year) and bit error rates of better than 10-9 (1 error in every 109 bits). Comparatively on SCADA links, where a combination of data radio, telephone line, and satellite link technology may be employed, the availability may be as low as 99.0 percent (an average of approximately 90 hours outage per year) and bit error rates of 10-6 (1 error in every 106 bits) or greater. The availability discrepancy can be attributed to the fact that the multilayer SCADA links traverse a greater number of media conversion and data routing ports as compared to high-speed optic fiber LAN backbones. Therefore, there are many single points of failure in a diverse SCADA communications network. Communications outages typically result from equipment and power supply failures and human interference. Better availability is possible through the use of redundant communications paths to outstations; however, such designs can contribute significantly to the cost of a communications system and therefore may not be financially viable if the communications link is not crucial to operational security. SCADA communication protocols are designed specifically for the reduced reliability communications links typically employed with SCADA systems and to provide secure transmission of data, guaranteeing reliable delivery of data to the intended destination in most circumstances. The protocols employ error detection and message retry techniques usually by receive/transmit handshaking established through the use of headers and footers attached to the raw data under transmission. Such extra information introduces an overhead to the transmission of data, resulting in a trade off between speed of data transmission and the reliability of the communications link. As a result, the speed of data communications associated with SCADA is regularly slower than that typical of a communications backbone commonly used on a process plant, office, or factory floor application. Not only do the latter boast links using media such as hard wired optic fiber, which usually allows higher speeds of data transmission than available over radio links, but the communications protocols associated with SCADA systems introduce data transmission overheads which further slow the rate of data transfer. Where media such as low bit error rate optic fiber cabling is available, simple communications protocols may be used which do not require substantial transmission overheads. Users of SCADA systems and the resulting data do not need to be aware of the communications protocols used. In fact, the protocols should be transparent to the user. However, it is important to understand that with the use of communications links such as radio, there is a possibility, albeit small, that communication errors will occur. For example, a control command could be sent to the wrong destination. SCADA systems often request confirmation from an operator to confirm that a control action is required. This approach provides some level of protection against a control message being sent to the wrong destination. It is much more likely, however, that the operator has made the error and the control action has been requested of the incorrect outstation. The control confirmation check gives the operator another chance to select the correct outstation for control.

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

An example of a SCADA communications protocol includes DNP 3.0 (Distributed Network Protocol), a vendor independent protocol that incorporates multiple layers of error detection and correction and allows a select/confirm regime for control actions. Modbus is another widely used protocol for SCADA, but it does not offer the same level of data transmission security as DNP 3.0. There are also a large variety of protocols that are proprietary to individual SCADA vendors and offer capabilities similar to those described in this section. Common Communications Media. The following communications media are common: Licensed radio links (UHF and VHF) Unlicensed spread spectrum radio links Public switched telephone networks Mobile telephony Microwave Cable TV networks Dedicated satellite links Dedicated cable, including fiber optics (for very short distance communication) Corporate WAN computer communications systems For highly critical sites, it is not uncommon for combinations of these different media to be used to ensure high reliability of communications to the site. Selection of the preferred communications media depends on several important factors: The remoteness of the field equipment site The required reliability of the communications media (primarily determined by the perceived operational importance of the remote site) Availability of communications options Cost of each option for the particular application Availability of power (power company, battery, solar, or other) The communications systems used for SCADA are often split into two distinct parts: a Wide Area Network backbone (WAN) and numerous Local Area Networks (LANs). The interface between the two parts is commonly achieved through some form of multiplexing. Wide Area Network Backbone. The WAN connects the central host computer to the multiplexers. It may comprise cable, radio, or satellite data communications links depending on the geographic distribution of the SCADA system. The WAN links are generally full duplex (they provide simultaneous data transmission in both directions) and may be configured in a star or loop topology.

2004 Bentley Systems, Incorporated. All rights reserved.

The Fundamentals of SCADA

The star and loop topologies employ dedicated point-to-point communications links between multiplexers. The star configuration (as shown in Figure 1) does not provide WAN redundancy. The loop configuration (see Figure 4) links adjacent multiplexers and provides alternative communications paths for redundancy, therefore providing higher reliability. Looped WANs require data traffic routers, and links must be dimensioned to carry all WAN traffic.
Figure 4
Looped WAN configuration

In some cases, a WAN is not needed. An example is a simple SCADA system where all RTUs are connected directly to the central host computer via a single multi-drop communications link. These systems therefore effectively only contain an RTU local area network. Multiplexers. Generally, some form of multiplexing is required to connect a WAN backbone to a local network of RTUs. Multiplexers allow different data streams to share a single data link, as shown in Figure 5. Multiplexers combine communications paths to and from many RTUs into a single bit stream, usually using time division multiplexing (TDM) or other such bit stream manipulation techniques. The multiplexers must be able to combine the traffic to and from tens or sometimes hundreds of RTUs for transmission over the SCADA WAN.

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

Figure 5
Basic data multiplexer configuration

A simple form of multiplexer is to use a data traffic router together with a point-tomultipoint radio, as shown in Figure 6. In this diagram, LR refers to Local Radio, PMR to Point to Multipoint Radio, and ROUT to data router.
Figure 6
Data router with point-to-multipoint radio

The multiplexer may itself be a SCADA processing device that manages the local network and not only combines the data, but also reduces the amount of data that must be interchanged with the central host. The SCADA system may employ a tree network with multiple hierarchical levels of multiplexer processors, as shown in Figure 7. Local Networks. Local networks connect the RTUs to the multiplexers, or directly to the SCADA central host computer if there is no need for a WAN connection. Like the WAN, the local network may comprise cable, radio, or satellite data communications links depending on the geographic distribution of the SCADA system. The links may be private or rented from a telephone company.

2004 Bentley Systems, Incorporated. All rights reserved.

10

The Fundamentals of SCADA

Figure 7
SCADA network with multiple MUX levels

A common local network configuration is based on point-to-multipoint radio. The radio links are generally half duplex or simplex, both of which allow transmission in only one direction at any time. Half duplex links use different frequencies in each direction, and simplex networks use a single frequency. In the configuration shown in Figure 7, the links are configured in a star topology. The local network may also be a LAN or multidrop circuit. Most local networks use a logical bus topology. In the bus topology, all stations share a common transmission medium and some form of network access protocol must be employed. Such protocols include ordered polling of each RTU, token passing, and data packet collision detection and avoidance mechanisms. Communications Protocols. Communications protocols define the method by which data is transmitted along a communication link. As long as the transmitting device follows a predefined set of rules for sending the data, the device at the receiving end is able to unravel the signal into meaningful data. For example, a protocol will define information such as the length of time that each data packet is sent, the size of the signal, and the required destination for the data. An open system is one that allows for communications between different types of devices (as supplied by different vendors, for example). Proprietary systems are by definition closed and allow communications only between devices of the same type (as supplied by a single vendor, for example).

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

11

Open systems avoid the disadvantages associated with using proprietary systems, such as complete dependence on a single vendor and lack of information on how the protocol functions. However, in order to realize the benefits of open systems, detailed communications protocol standards are required to specify all aspects of the interconnection between computers and other devices.

The Central Host Computer The central host computer or master station is most often a single computer or a network of computer servers that provide a man-machine operator interface to the SCADA system. The computers process the information received from and sent to the RTU sites and present it to human operators in a form that the operators can work with. Operator terminals are connected to the central host computer by a computer network so that the viewing screens and associated data can be displayed for the operators. Recent SCADA systems are able to offer high resolution computer graphics to display a graphical user interface or mimic screen of the site or water supply network in question. Figure 8 shows the types of display screens offered by most systems. Some examples include System overview pages displaying the entire water distribution system and often summarizing SCADA sites that might be operating abnormally Site mimic screens for each individual RTU location showing up to the minute site information and offering an interface to control items of equipment at that site Alarm summary pages displaying current alarms, alarms that have been acknowledged by an operator, and alarms that have returned to normal but remain unacknowledged by an operator Trend screens enabling an operator to display the behavior of a particular variable over time Historically, SCADA vendors offered proprietary hardware, operating systems, and software that was largely incompatible with other vendors SCADA systems. Expanding the system required a further contract with the original SCADA vendor. Host computer platforms characteristically employed UNIX-based architecture and the host computer network was physically removed from any office computing domain. However, with the increased use of the personal computer, computer networking has become commonplace in the office and as a result, SCADA systems are now available that can network with office-based personal computers. Indeed, many of todays SCADA systems can reside on computer servers that are identical to those servers and computers used for traditional office applications. This has opened a range of possibilities for the linking of SCADA systems to office-based applications such as GIS systems, hydraulic modeling software, drawing management systems, work scheduling systems, and information databases.

2004 Bentley Systems, Incorporated. All rights reserved.

12

The Fundamentals of SCADA

Figure 8
The type of display screen offered by most SCADA systems

Operator Workstation Communications System For water supply SCADA systems, several operators may require simultaneous access to the SCADA central host computer to view the performance of the system. SCADA systems are often designed to accommodate this requirement by including communications channels between the central host and the remote workstations accessed by the operators. Operator workstations are most often computer terminals that are networked with the SCADA central host computer. The central host computer acts as a server for the SCADA application and the operator terminals are clients that request and send information to the central host computer based on the request and action of the operators. The communications system in place between the central host computer and the operator terminals is a Local Area Network. SCADA LANs enable multiple users in a relatively small geographical area to exchange files and messages, as well as access shared resources, such as the central host computer. Historically, SCADA LANs have been dedicated networks; however, with the increased deployment of office LANs and Wide Area Networks (WANs) as a solution for interoffice computer networking, there exists the possibility to integrate SCADA LANs into everyday office computer networks. The foremost advantage of this arrangement is that there is no need to invest in a separate computer network for SCADA operator terminals. In addition, there is an easy

2004 Bentley Systems, Incorporated. All rights reserved.

Components of a SCADA System

13

path to integrating SCADA data with existing office applications, such as spreadsheets, work management systems, data history databases, GIS systems, and water distribution modeling systems. However, there are several disadvantages that should be considered before integrating SCADA operator terminal LANs with office LANs: Corporate networks are often only supported during office hours while SCADA LANs are most often required 24 hours per day, 7 days per week Communications links associated with SCADA may present a networking security breach into the corporate computer network because some links may bypass the office networks usual security precautions During office hours, data traffic on the network associated with the corporate network may seriously slow the networking of the SCADA operators SCADA network traffic generated during emergency operation procedures may seriously slow the corporate computer network Linking the SCADA system with the office LAN provides ways for hackers or terrorists to interfere with operation of the system

Software Systems An important aspect of every SCADA system is the computer software used within the system. The most obvious software component is the operator interface or MMI/ HMI (Man Machine Interface/Human Machine Interface) package; however, software of some form pervades all levels of a SCADA system. Depending on the size and nature of the SCADA application, software can be a significant cost item when developing, maintaining, and expanding a SCADA system. When software is well-defined, designed, written, checked, and tested, a successful SCADA system will likely be produced. Poor performances in any of these project phases will very easily cause a SCADA project to fail. Many SCADA systems employ commercial proprietary software upon which the SCADA system is developed. The proprietary software often is configured for a specific hardware platform and may not interface with the software or hardware produced by competing vendors. A wide range of commercial off-the-shelf (COTS) software products also are available, some of which may suit the required application. COTS software usually is more flexible, and will interface with different types of hardware and software. Generally, the focus of proprietary software is on processes and control functionality, while COTS software emphasizes compatibility with a variety of equipment and instrumentation. It is therefore important to ensure that adequate planning is undertaken to select the software systems appropriate to any new SCADA system. Such software products are used within the following components of a SCADA system: Central host computer operating system: Software used to control the central host computer hardware. The software can be based on UNIX or other popular operating systems.

2004 Bentley Systems, Incorporated. All rights reserved.

14

The Fundamentals of SCADA

Operator terminal operating system: Software used to control the central host computer hardware. The software is usually the same as the central host computer operating system. This software, along with that for the central host computer, usually contributes to the networking of the central host and the operator terminals. Central host computer application: Software that handles the transmittal and reception of data to and from the RTUs and the central host. The software also provides the graphical user interface which offers site mimic screens, alarm pages, trend pages, and control functions. Operator terminal application: Application that enables users to access information available on the central host computer application. It is usually a subset of the software used on the central host computers. Communications protocol drivers: Software that is usually based within the central host and the RTUs, and is required to control the translation and interpretation of the data between ends of the communications links in the system. The protocol drivers prepare the data for use either at the field devices or the central host end of the system. Communications network management software: Software required to control the communications network and to allow the communications networks themselves to be monitored for performance and failures. RTU automation software: Software that allows engineering staff to configure and maintain the application housed within the RTUs (or PLCs). Most often this includes the local automation application and any data processing tasks that are performed within the RTU. The preceding software products provide the building blocks for the applicationspecific software, which must be defined, designed, written, tested, and deployed for each SCADA system.

DATA ACQUISITION MECHANISMS

Data acquisition within SCADA systems is accomplished first by the RTUs scanning the field data interface devices connected to the RTU. The time to perform this task is called the scanning interval and can be faster than two seconds. The central host computer scans the RTUs (usually at a much slower rate) to access the data in a process referred to as polling the RTUs. Some systems allow the RTU to transmit field values and alarms to the central host without being polled by the central host. This mechanism is known as unsolicited messaging. Systems that allow this mechanism usually use it in combination with the process of polling the RTU to solicit information as to the health of the RTU. Unsolicited messages are usually only transmitted when the field data has deviated by a prespecified percentage, so as to minimize the use of the communications channels, or when a suitably urgent alarm indicating some site abnormality exists.

2004 Bentley Systems, Incorporated. All rights reserved.

Data Acquisition Mechanisms

15

Control actions that are performed by using the central host are generally treated as data that are sent to the RTU. As such, any control actions by an operator logged into the central host will initiate a communication link with the RTU to allow the control command to be sent to the field data interface device under control. SCADA systems usually employ several layers of checking mechanisms to ensure that the transmitted command is received by the intended target.

PROCESSING OF DATA FROM THE FIELD

Data can be of three main types: Analog data (real numbers), which will be trended (placed in graphs) Digital data (on/off), which may have alarms attached to one state or the other Pulse data (for example, counting revolutions of a meter) is analog data normally accumulated or counted. Such data are treated within the SCADA operator terminal software displays as analog data and may be trended. The primary interface to the operator from the operator terminal is a graphical user interface (GUI) display that shows a representation of the plant or equipment in graphical form. Live data are shown as graphical shapes (foreground) over a static background. As the data changes in the field, the foreground is updated. For example, a valve may be shown as open or closed, depending on the latest digital value from the field. The most recent analog values are displayed on the screens as numerical values or as some physical representation, such as the amount of filled color in a tank to represent water level. Alarms may be represented on a screen as a red flashing icon above the relevant field device. The system may have many such displays, and the operator can select from the relevant ones at any time. Data from the field are processed to detect alarm conditions, and if an alarm is present, it will be displayed on dedicated alarm lists on the application software running on the central host computer. Any abnormal conditions that are detected in the field are registered at the central host as alarms, and operators are notified usually by an audible alert and by visual signals on the operator terminal computers. Operators can then investigate the cause of the alarm by using the SCADA system. Historical records of each alarm and the name of the operator that acknowledged the alarm can be held within a self-contained archive for later investigation or audit requirements. Where variables in the field have been changing over time, the SCADA system usually offers a trending system whereby the behavior of a particular variable can be plotted on a graphical user interface screen.

LEVELS OF CONTROL
SCADA communications systems may be deployed over a wide geographical area and hence it can be expected that communications link availability and speed will be lower than that typical for a link between a computer and a PLC via a hard-wired Ethernet Local Area Network (LAN).

2004 Bentley Systems, Incorporated. All rights reserved.

16

The Fundamentals of SCADA

Computerized control systems that are commonly used at water or wastewater treatment plants are an example of where high-speed Ethernet LANs are employed as the communications backbone. The control systems are similar to SCADA systems but are more closely related to those systems developed for manufacturing or factory floor applications. These are often referred to as Distributed Control Systems (DCS). They have similar functions to SCADA systems, but the field data interface devices are usually located within a confined geographical area. The communications LAN will normally exhibit up to 99.98 percent availability, with substantially greater bandwidth than employed in a SCADA system. A DCS system also will usually employ a significant amount of remote loop control, where the required value of a field variable is calculated based on the feedback received from a measured variable in the field. In the case of DCS systems, this calculation is often performed within the central host computer. In comparison, loop control required to operate a remote pump station, for example, will regularly be housed within a local loop control device which calculates the required value of the field variable locally and therefore separately from the central host computer. For example, consider the example of a valve position based on the level of water in a reservoir. Figure 9 illustrates a common control problem.
Figure 9
Valve position control

Consider in this case that the position of the valve depends on the level of water in the reservoir. An operator may control the process by issuing a Set Point, which is the desired level at which the tank should stay. Once the level deviates from the level set point, the controller detects the deviation and sends a signal to the valve position actuator to move the valve to reduce the error. The level of the tank is continuously monitored to enable the controller to trim the valve position. Within plant floor DCS systems, it is common for this controller to reside within the central host computer. The communication system connecting the local RTU and the central host is fast and reliable and it is convenient to house the bulk of the computing power within a centralized location.

2004 Bentley Systems, Incorporated. All rights reserved.

Handling of Data During SCADA Failures

17

By contrast, SCADA systems generally cover large geographic areas and rely on a variety of communications systems that are normally less reliable than a LAN associated with a DCS. Loop control based in the central host computer is therefore less desirable. Instead, the controller application is housed in the RTU. The SCADA operator is able to alter the tank level set point remotely and perhaps may be allowed to manually drive the valve open and closed when the control loop is disabled. However, the automatic control of the valve is most often resident in the RTU. If communication to the remote site is lost, it is desirable that the local automatic control system continue to operate; therefore, the RTU is an autonomous unit which could control the valve without constant direction from the central host computer. Of course, there is always the temptation to allow a great percentage of the automation functions to be centralized within a SCADA system. This approach has many advantages, most notably: Computing power can be centralized in an office environment, reducing the cost of field devices which must be designed to operate in sometimes harsh conditions Engineering staff are much more readily able to continuously improve and update control programs, ensuring that there is a standardization of control algorithms across the SCADA network Expensive redundancy system failure proofing can be located in a central location The important thing to consider is the reliability of the communication link between the SCADA central host and the site. Where a critical control algorithm is required and the controller must be located remotely, the communication link must be designed to contribute effectively to the reliability of the entire system. The cost associated with this requirement may be prohibitive enough to warrant placing the automatic control function at the site. SCADA allows for many options by which assets and devices at remote sites may be controlled. It is not uncommon for modern SCADA systems to employ a combination of the previously mentioned mechanisms.

HANDLING OF DATA DURING SCADA FAILURES

Different SCADA systems cope differently with a failure event. Some systems rely primarily on the inherent redundancy of the SCADA system, and others may use some form of storage mechanism to archive data that may be recovered once the SCADA system has returned to normal operating capacity. These options are summarized as follows: Storage of data in the RTUs: Some SCADA systems rely on the capacity of the RTU to store data collected from the field under normal operation and then periodically transmit that data as an unsolicited message or when polled by the central host. In times of SCADA system failure, the capacity of the RTU is used to archive information until a backup central host is brought online or the original system has recovered.

2004 Bentley Systems, Incorporated. All rights reserved.

18

The Fundamentals of SCADA

System redundancy: Most SCADA systems incorporate some form of redundancy in their design, such as dual communications channels, dual RTUs, or dual central host computers. Such systems may be designed for such redundant equipment to be online (hot standby) to ensure a seamless transfer upon SCADA system failure, or offline (cold standby) where the backup mechanism must be manually brought online to operational capacity. Most SCADA systems employ a combination of the preceding mechanisms to ensure data continuity during failure events.

ERRORS AND ACCURACY ISSUES

As previously discussed, SCADA systems for water distribution systems generally use low bandwidth communication channels. Data from the field may therefore need to be compressed by the field devices before being transmitted to the central host to avoid overtaxing the capacity of the communications media to transmit information. The result may be that data from the field include some form of error that must be considered before analysis. Common sources of error include Compression algorithms employed by the RTU prior to transmitting time series data to the central host Compression algorithms employed by any data archive software that may be used to store old data from a SCADA system Interpolation by the trending system of a SCADA system. Such errors are not immediately obvious from the data trends received from a SCADA system and may appear as unexplained unusual behavior of an analog variable that may lead a data user to mistakenly suspect an error with a measuring instrument located in the field. Through understanding of the particular mechanisms inherent in the data collection system, it is possible to explain the unexpected behavior of a variable and compensate for the error within the data finally used for model validation purposes.

REFERENCES
Barnes, M., and Mackay, S. (1992). Data Communications for Instrumentation and Control. Instrument Data Communications (IDC), Australia. Cisco Systems, Inc. (2000). CCIE Fundamentals: Network Design and Case Studies. Cisco Press, Second Edition, Indianapolis, Indiana. Citect version 5 Users Guide (1998). CI Technologies Pty. Ltd., Pymble, Australia. Haime, A. L. (1998). Practical Guide to SCADA Communications. SCADA at the Crossroads Conference Workshop, The Institution of Engineers Australia, Perth, Western Australia. Williams, R. I. (1992). Handbook of SCADA Systems for the Oil and Gas Industries. Elsevier Advanced Technology Limited, 1st Edition, Great Yarmouth, United Kingdom.

2004 Bentley Systems, Incorporated. All rights reserved.