INDUSTRIAL CONTROL NETWORKS:SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA) NETWORK

SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA) NETWORK

Introduction

Supervisory control and data acquisition (SCADA) networks are large-scale industrial control and measurement systems primarily used to control and monitor the condition of field-based assets remotely from a central location. SCADA networks are used pervasively in a wide range of industries, including electricity power generation and transmission, chemical and petrochemical industries, highways and transport, oil and gas and steel production, as well as research and development. Modern SCADA systems exhibit predominantly open-loop control characteristics and utilize predominantly long-distance communications, although some elements of closed-loop control and or short-distance communications may also be present. A SCADA system performs four functions.

(1) Data acquisition

The systems to be monitored by SCADA generally have hundreds or thousands of field devices (or field instrumentation) such as sensors, actuators, switches, valves, transmitters, meters and drivers. Some devices measure inputs into the system (for example, water flowing into a reservoir), and some measure outputs (such as valve pressure as water is released from the reservoir). They may measure simple events that can be detected by a straightforward on-off switch, called a digital input. In industrial control applications, such digital inputs are used to measure simple states. Alternatively, they may measure more complex situations where exact measurement is important. Analog devices, which can detect continuous changes in a voltage or current input are used for these cases. They can track fluid levels in tanks, voltage levels in batteries, temperature and any other factor that can be measured in a continuous range of input. For most analog factors, there is a normal range defined by a bottom and top level.

Modern SCADA systems usually require real-time data acquisition i.e. data must be collected in such a way that it can be processed or stored by a computer instantly. Data acquisition normally involves an input scanner or switch, an analog-to-digital converter, and signal conditioners that can be either energy sensors or conditioning processes so that the data signals directly in engineering units are transmitted. Data acquisition systems can also form part of a process control system which, through the use of appropriate software, provides direct digital control of an industrial process. They can also be used for data logging and process or alarm monitoring.

(2) Data communication

Many control applications need to monitor multiple systems from a central control station, thus necessitating a communications network to transport all the data collected from the field instrumentation. Early SCADA networks communicated over radio, modem or dedicated serial lines, but currently most systems put SCADA data on Ethernet or over the Internet. Real SCADA data are encoded into protocol format. Older SCADA systems depended on closed proprietary protocols, but today the trend is towards open, standard protocols and protocol mediation. The remote telemetry (or terminal) unit (RTU) or the programmable logic controller (PLC) is needed to provide an interface between the field instrumentation and the SCADA network. The RTU or PLC encodes field inputs into protocol format and forwards them to the SCADA master station; in turn, the RTU receives control commands in protocol format from the master, and transmits electrical signals to the appropriate control relays and then downward to field instrumentations.

(3) Data presentation

The SCADA system continuously monitors all field instrumentation and alerts the operator when there is an “alarm”, that is, when a control factor is operating outside what is defined as its normal range. The master presents a comprehensive view of the entire managed system, and can present more detail in response to user requests. A human machine interface (HMI) presents process data to a human operator, and allows the human operator to control the process. An HMI may also be linked to a database, to provide trending, diagnostic data, and management information such as scheduled maintenance procedures, logistic information, or detailed schematics. SCADA is popular due to its compatibility and reliability. Its use ranges from small applications, such as the control of the temperature of a room, to extremely large applications, such as the control of nuclear power plants.

(4) System control

SCADA systems can regulate all kinds of industrial processes automatically. For example, if too much pressure is building up in a gas pipeline, a SCADA system could automatically open a release valve. Electricity production can be adjusted to meet demands on the power grid. Even these real-world examples are simplified; a full-scale SCADA system can adjust a managed system in response to multiple inputs.

SCADA systems generally cover large geographic areas with the controller application housed in the appropriate terminal that is controlled by an operator working centrally. Reliable communication links between the SCADA central host and the field-level devices are therefore crucial to the efficient operation of such systems. 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 high enough to warrant placing the automatic control function at the site.

SCADA systems are coming in line with standard networking technologies, with Ethernet and TCP/ IP-based protocols replacing the older proprietary standards. Although certain characteristics of frame- based network communication technology (determinism, synchronization, protocol selection, environ- ment suitability) have restricted the adoption of Ethernet in a few specialized applications, it is now broadly accepted in the majority of situations. With the emergence of software as a service in the broader software industry, some vendors have begun offering application-specific SCADA systems hosted on remote platforms over the Internet. This removes the need to install and commission systems at the end-user’s facility and takes advantage of security features already available in Internet technology. Some concerns inherent in this approach include security, Internet connection reliability, and latency.

SCADA systems are becoming increasingly ubiquitous. Thin clients, web portals, and web-based products are gaining popularity with most major vendors.

SCADA components and hardware

SCADA encompasses the transfer of data between a central host or master station and a number of remote field sites. System architecture can range from simple local control to a large-scale distributed control system. Figure 10.5 shows a generic SACDA system that consists of a central host or master terminal unit (MTU) with HMI; a number of the RTUs which connect with the field-level instrumentations; and networks for data communication between the MTU and RTUs.

The overall form of a SCADA system, is for a central host or MTU to receive a field data from the RTUs. The received data are then processed by central software. Once this processing is complete, the central host then logs alarms and displays the data on its HMI screens.

(1) Central host or master station or MTU

The central host or master station or MTU is a single computer or a cluster of computer servers that provide an interface to the SCADA system for human operators that processes the information received from the RTUs and presents the results in a human-readable form. The host computer then sends commands to the RTU sites for use by field instrumentation.

The primary operator interface is a graphical user interface (GUI) showing a representation of the plant or equipment. Live data are shown as graphical shapes (foreground) over a static background. As the data change in the field, these shapes are updated. For example in a water supply system, a valve may be shown as open or closed, depending on the latest digital value from the field instrumentations.

The most recent analog values are displayed on the screens as numerical values or as some physical representation. 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.

If an alarm is triggered, it will be displayed on dedicated alarm lists. Any abnormal conditions that are detected in the field instrumentation are registered at the central host as alarms, and operators are notified, usually by an audible alert and visual signals. Historical records of each alarm and the name of the operator who acknowledged the alarm can be held within a self-contained archive for later investigation or audit requirements. Where variables change over time, the SCADA system usually offers a trending system to follow its behavior.

(2) Field data interface devices

These devices provide information about how the field instruments are running. To be useful, 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 (or protocol) of the SCADA system. To achieve this, some form of electronic field data interface is required.

(a) Remote terminal units (RTUs)

RTUs are primarily stand-alone data acquisition and control units. A typical RTU configuration is shown in Figure 10.6, which includes the hardware modules such as control microprocessor and associated memory, analog inputs, analog outputs, counter inputs, digital inputs, digital outputs, communication and I/O interfaces, power supply, together with an RTU rack and enclosure. Small RTUs generally have fewer than 10 to 20 analog and digital signal inputs; medium-sized RTUs

have 100 digital and 30 to 40 analog signal inputs. Any RTU with more signal inputs than this is referred to as large.

RTUs are used to convert electronic signals received from (or required by) field instrumentation into (or from) the communication protocol that is used to transmit the data over a network. RTUs appear in the field as a box in a switchboard with electrical signal wires running to field instrumentation and a cable linked to a communication channel interface, such as a telephone cable, a field bus, or a radio.

The instructions for the automation of field data interface devices are usually stored locally since the limited bandwidth typical of communication links to the SCADA central host makes central storage impractical. 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. PLCs connect directly to field instruments and incorporate programmed intelligence in the form of logical procedures that will be executed in the event of certain field conditions. More recent systems have no PLCs and local control logic is held within the RTUs, or in relay logic in the local switchboard.

(b) Programmable logic controllers (PLCs)

PLCs have their origins in industrial automation and therefore are often used in manufacturing and process plant applications. SCADA systems, on the other hand, have origins in early telemetry applications, where it was only necessary to receive 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 and telemetry have become more commonly used, the need to influence the program within the PLCs via a remote signal has arisen. This is in effect the “supervisory control” part of the SCADA acronym. A simple local control program could be stored within a RTU and perform the control within that device. At the same time, PLCs started to include communications modules to allow reporting of the state of the control program. PLC and RTU manufacturers therefore compete for the same market.

As a result of these developments, the distinction 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.

(3) Communication networks

Most industrial applications use networks to enable communication between the central host and the RTUs. Control actions performed at the central host are generally treated as data that are sent to the RTUs, so any control action will initiate a communication link with the RTUs to allow the command to be sent to the field device. Modern SCADA systems usually employ several layers of checking mechanisms to ensure that a transmitted command is received by its intended targets.

There are two commonly used communication models in the SCADA networks: a polled approach and a contention approach.

(a) Polled communication model (master-slave)

This can be used in a point-to-point or multi-point network configuration and is probably the simplest communication model to use. The master is in total control of the communication system and makes repetitive requests for data to be transferred to and from each one of a number of slaves. The slaves do not initiate the transactions but rely on the master. The approach is essentially half-duplex. If a slave does not respond in a defined time, the master then retries (typically up to three times) and then marks the slave as unserviceable before trying the next slave node in the sequence. It is possible to retry the unserviceable slave again on the next cycle of polling. Figure 10.7 illustrates polling communication models between the SCADA master and SCADA RTUs/PLCs. Figure 10.7 is an automatic meter reading SCADA system, which uses the POTS telephone service of TC2800 RS-232 and RS-422 and RS-485 multidrop fiber-optic multiplexer, and the TC1900 RS-232 telephone extender.

(b) Contention communication model (peer-to-peer)

A contention method such as carrier sense with multiple access/collision detection (CSMA/CD) can be used for communications control. There is no controlling master, and individual stations have to contend (complete) for access to the transmission medium. In such an arrangement, collisions are unavoidable and stations have to deal with them. In a situation where a RTU wants to communicate with another one, a technique used is to respond to a poll by the master station with a message with a destination address other than that of the master station. This approach can be used either in a master- slave network or a group of stations all having equal status. Collisions are avoided by listening to the medium before transmitting. The systems rely on recovery methods to handle collision problems.

Typically these systems are very effective at low capacity rates; but as soon as the traffic rises to over 30% of the channel capacity there is an avalanche-type collapse of the system and communication becomes unreliable and erratic. The technique is used solely on networks where all RTUs/PLCs have access to the same media within radio range or on a common cable link.

Unnecessary transfer of data is reduced by exception reporting. This approach is popular with the CSMA/CD method but it could also offer a solution for the polled approach, where there is a considerable amount of data to transfer from each slave. The remote station monitors its own inputs for a change of state or data. When this occurs, the remote station writes a block of data to the master station. Each analog or digital point to be reported back to the central master station has a set of exception reporting parameters associated with it, such as high and low alarm limits for individual analog values.

A practical approach to combining the master slave with CSMA/CD is to use the concept of a slot time for each station. Assume that the architecture includes a master and a number of slaves that need to communicate with the master station. No communication between slaves is required (except for possibly through the master). The peroid of time over which each station is allowed to transmit is called a slot time. There are two types of slots; a slave or a few slaves transmitting to a master, and a master transmitting to a slave. A slot time is calculated as the sum of the maximum of modem setup time (for example, 30 milliseconds) plus radio transmit time (for example, 100 milliseconds) plus time for protocol message to transmit (for example, 58 milliseconds) plus muting time (for example, 25 milliseconds) for each transmitter. The master commences operations by polling each slave in turn. Each slave will synchronize on the master message and will transmit an acknowledge message. Hereafter, slaves will only transmit by using CSMA/CD during the master receiving time slots, which alternate with the master transmission time slots. Once a slave node detects a state change, it will transmit the data on the first available master receive time slot. If two remote slaves try to transmit in the same time slot, the message will be corrupted and the slaves will not receive a response from the master. The slaves will then randomly select a subsequent master receiver time slot and attempt a retransmission of the message. If the master continues to get corrupted messages, it may elect to do a complete poll of all remote slaves as the CSMA/CD type mechanism is possibly breaking down due to excessive traffic.

(4) Field instrumentation

These refers to those devices that are connected to equipment being controlled and monitored, which convert physical parameters to electrical signals at the field level. Typical field instrumentations are: sensors, actuators, switches, transmitters, meters, detectors, relays, valves and drivers.

Data acquisition within SCADA systems is accomplished by the RTUs first scanning the connected field instrumentation. The time to perform this task is called the scanning interval and can be less 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 have deviated by a pre-specified percentage, so as to minimize the use of the communications channels, or when a suitably urgent alarm indicating some site abnormality exists.

SCADA software and firmware

An important component of every SCADA system is the computer software used within the system. Depending on the size and nature of the application, SCADA software can be a significant cost item. When software is well-defined, designed, written, checked, and tested, a successful SCADA system is likely to result.

Much SCADA is software configured for a specific hardware platform. A wide range of general SCADA software products are also available, some of which may suit the required application. These are usually more flexible, and compatible with different types of hardware and software. It is therefore important to select the software systems appropriate to any new SCADA system.

SCADA systems typically implement a distributed database which contains data elements called tags or points. A point represents a single input or output value monitored or controlled by the system. Points can be either “hard” or “soft”. A hard point represents an actual input or output within the system, while a soft point results from logic and mathematical operations applied to other points. Points are normally stored as value-timestamp pairs, i.e. a value and the timestamp when it was recorded or calculated. A series of value-timestamp pairs gives the history of that point. It is also common to store additional metadata with tags, such as the path to a field device or register in an interface device to field level, design time comments, and alarm information.

SCADA software products provide the building blocks for the application-specific software, which must be defined, designed, written, tested, and deployed separately for each system. Such software products are used within the following components of a SCADA system:

(a) The central host computer operating system, used to control the central host. This can be based on UNIX, Windows NT or other operating system.

(b) The operator terminal operating system, which is also used to control the central host computer

hardware, is usually the same type as the central host computer operating system. It usually deals with the networking of the central host to the operator terminals.

(c) The central host computer application, which is the software responsible for handling the transmission and receiving of data between the RTUs and the central host. This software usually includes some expert systems defined for application-specific functions. It also provides a graphical user interface offering site mimic screens, alarm pages, trend pages, and control functions.

(d) The operator terminal application software, which enables users to access the information on the central host computer application. This software can also include some expert systems defined for application-specific functions. It is usually a subset of the software used on the central host computers.

(e) Communication protocol drivers, which are usually based within the central host and the RTUs, and are 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 at the central host end of the system. The communication models and protocols for the SCADA system will be discussed in subsection 10.2.4.

(f) Communications network management software, which is required to control the communications network and to allow it to be monitored for attacks and failures. SCADA communication security and system reliability will be the topic of subsection 10.2.5.

(g) RTU automation software, which allows engineering staff to configure and maintain the application housed within the RTUs (or PLCs). This often includes the local automation application and any data processing tasks that are performed within the RTUs (or PLCs).

SCADA communication protocols

In 1988, the International Electrotechnical Commission (IEC) began publishing a standard entitled “IEC 870 Telecontrol Equipments and Systems”, of which one part was “Part 5 Transmission Protocols”. This part was developed in a hierarchical manner and published in a number of sub-parts, taking from 1990 to 1995 to completely define an open protocol for SCADA communications. The protocol was defined in terms of the open systems interconnection model (OSI) using a minimum subset of the layers: the physical layer, data-link layer, and application layer. This protocol standard included the definition of message format at the data-link layer, and a set of data formats at the application layer so that it could be used to create systems capable of interoperation.

This IEC standard was subsequently renumbered with a prefix of 60, and so the current IEC standard for transmission protocols is IEC 60870-5. The IEC 60870-5 was defined primarily for telecommunication of control information within electrical power systems, so having data formats specifically related to this application. Although it includes general data types that could be used in any SCADA application, the use of IEC 60870 has since been mostly confined to the electricity power industry.

During the same period, the protocol entitled Distributed Network Protocol Version 3.3 (DNP3) was developed by Harris Control Division of Distributed Automation Products and released to the industry-based DNP3 User Group in November 1993. DNP3 has gained significant acceptance since then, both geographically and over different industries. DNP3 is supported by a large number of vendors and users in electrical power, water infrastructure, and other sectors in America, Africa, Asia, Australia and New Zealand. In Europe, DNP3 competes with IEC 60870-5, but the latter is confined to the electrical power grid industry, whereas DNP3 has found wider application in the energy, water, and security industries, and so on.

Both protocols were designed specifically for SCADA applications, and were thus widely sup- ported by manufacturers of SCADA systems. They involve acquisition of information and sending of control commands between physically separate computer devices. They are designed to transmit relatively small packages of data in a reliable manner, with the messages arriving in a deterministic sequence. In this respect, both DNP3 and IEC 60870-5 differ from general purpose protocols such as file transfer protocol (FTP) because FTP can send large files, but in a way that is generally not as suitable for SCADA control.

Besides DNP3 and IEC 60870 protocols, there is little push for utility communications architectures (UCA), although the concepts are likely to become routine in the SCADA industry. In 1999, the IEEE published UCA Version 2, as an IEEE standard to address issues that were identified in field testing of the original specification, and to embrace the Internet suite of protocols, which had become widely accepted since the publication of UCA Version 1. However, it is envisaged that DNP3 and UCA will complement each other in the near future.

(1) DNP3 protocols

DNP3 is a telecommunications standard that defines communications between a master station and other intelligent electronic devices. DNP3 supports multiple-slave, peer-to-peer and multiple-master communications with possible polled and quiescent operational modes. Quiescent operation, referred to as reporting by exception, is so called because polls to check for changes are not required. This is because the master station can rely on the outstation to send an “unsolicited response” when it has a change that needs to be reported. In a quiescent system, generally a periodic background poll is still used, perhaps at hourly intervals, to guard against undetected communications failure. If this was not done, the master station would have no way of detecting a communications failure with the outstation.

The capability to support peer-to-peer and quiescent operation requires that stations which are not designed as master stations are able to initiate communications. This is sometimes referred to as balanced communications, meaning that any station can act as a primary (or sending) and as a secondary (responding) station at the same time. Despite the ability for slave (non-master) stations to initiate communications within DNP3, only master stations can initiate requests for data, or issue commands, to other stations. Thus, although the term balanced is applied to the communications system, the differentiation between master and slave stations remains. Sometimes the terms master and outstation are more applicable.

Architectures may also use protocol converters, for instance in the case of a hierarchical topology, where the outstation devices only use DNP3, and the SCADA master station might use a different communications system. In the case of DNP3 devices with a network port, DNP3 is encapsulated within TCP/IP Ethernet packages. Although this does add an overhead, it does provide an effective means of using existing corporate network to accommodate the SCADA system.

DNP3 provides time-stamping of events with resolution of events down to one millisecond. For events to match up correctly across a system, it is essential that the clocks in all outstations are synchronized with that of the master station. Synchronizing of an outstanding clock is done by sending a time and date object (object 50, variation 1) to the outstation. There is, however, a finite delay in transmission from the master to the outstation, and if this is not accounted for when setting the clock, its time would be in error by this transmission time. This error can be increased by store- and-forward delays introduced by a variety of devices along the transmission path, including (a) time in modern buffers; (b) time in data radio buffers; (c) time in intermediate repeater store-and-forward buffers.

In addition to these, it is also necessary to add the possibility of processing delays between the application level and the lower levels, or “stack delays” at both master and outstation. The data-link functionality is required to record the time of transmission or receipt of the first bit of any delay time message. When transmitting the message, the data-link layer triggers a freeze of the master station clock, which is stored as “master send time”. Similarly, when a slave station receives a delay time message it must store a freeze of the local clock as “RTU receive time”.

DNP3 provides for measurement of the round trip delay time by the procedure defined as “Function Code 23 Delay Measurement”. This procedure follows these steps:

(a) master sends “Function Code 23 Delay Measurement”;

(b) master records the start of transmission time as “Master send time”;

(c) outstation records the receipt time as “RTU receive time”;

(d) outstation commences to send a response and records this time as “RTU send time”;

(e) outstation calculates its internal processing turnaround time “RTU turn around” which is equal to the difference by minus the “RTU receive time” from the “RTU send time”;

(f) outstation includes in the response a time delay object (object 52, variation 1 or 2) having the value

of the turnaround time that is “RTU turn around”;

(g) master freezes its clock as “Master receive time” once receiving the response.

The master station now calculates the one-way propagation delay by this formula: Delay ¼ ((“master send time” “Master receive time” “RTU turn around) / 2). This delay time is now adjusted by the following steps:

(a) master sends a write-request containing the time and date objects (object group 50, variation 1); the time value is the master clock time at commencing to send this message “Master send” plus the calculated delay;

(b) outstation receives the first bit of the message at time “RTU receive”;

(c) outstation now sets the outstation time by the following calculation: (“Adjustment” ¼ “Current RTU time” “RTU receive”) and (“New RTU time” ¼ “Time in time and date object” þ “Adjustment”).

To obtain interoperability between different manufacturers’ versions of a protocol, it is necessary to ensure that all implementations support the same data objects and functions. This would require standardization of a significant subset of data object types, and an RTU interfacing to a number of devices could require yet more. In DNP3, these issues are addressed through the definition of three subset levels.

(a) DNP3-L1 is layer 1, which gives the simplest level of DNP implementation. It is intended for use between a master station or intermediate device such as a data concentrator, and a small intelligent electronic device such as a relay, a meter, or a stand-alone controller. Normally any inputs and outputs are local to the device.

(b) DNP3-L2 is layer 2, which defines a larger subset of DNP features than the level 1. It is intended to lie between a master station or data concentrator, and an RTU or a large intelligent electronic device. Normally any inputs and outputs are local to the device.

(c) DNP3-L3 is layer 3, which defines the largest subset of DNP features. It does not require support of all the possible DNP features, but it covers those most frequently required. This is implemented typically between a master station and a large advanced RTU. The inputs and outputs of subset level 3 devices would typically be remote as well as local.

(2) IEC 60870-5 protocols

IEC 60870-5 is a collection of standards produced by the International Electrotechnical Commission (IEC) to supply an open standard for the transmission of SCADA telemetry control and information. This standard provides a detailed functional description for telecontrol equipment and systems for controlling geographically widespread processes, which are mostly SCADA systems. Although it was primarily aimed at systems in electrical power industries, is also intended for general SCADA applications. IEC 60870-5 has been merged with TCP/IP to provide a communication protocol over standard computer networks.

The IEC 60870 standard is structured in a hierarchical manner, comprising six parts plus a number of companion standards. Each part is made up of a number of sections, each of which has been published separately. In addition to the main parts, there are four companion standards providing the details of the standard for a particular field of application. These companion standards extend the main definition by adding information objects specific to a given field of application.

The structure of the IEC 60870 standard is illustrated in Figure 10.8. This shows the main parts, the sections, and companion standards connected to transmission protocols. The companion standards are IEC 60870 Telecontrol Equipment and Systems Part 5 Transmission Protocol

Sections of Part 5

5 1 Transmission Protocols

5 2 Link Transmission Protocols

5 3 Structure of Application Data

5 4 Definition of Application Information Elements 5 5 Basic Application Functions

publishing in IEC-60870-5-101 to IEC 60870-5-104. IEC 60870-5-101 completes the definition for the transmission protocol. IEC 60870-5-4 defines the transport of IEC 60870-5 application messages over networks. Therefore, the key point to note is that this standard has been progressively developed and issued from IEC-60870-5-101 to IEC 60870-5-104.

(a) System topology

IEC 60870-5-101 supports point-to-point and multidrop communication links carrying bit-serial and low-bandwidth data communications. It allows use of either balanced or unbalanced communication. With unbalanced communication, only the master can initiate communications by transmitting primary frames. This simplifies system design because there is no need to support collision avoidance.

IEC 60870-5 assumes a hierarchical structure in which any two stations communicating with each other, have one designated as the controlling station, and the other as the controlled station. This is also a defined “monitor direction” and a “control direction”. Thus monitored data such as analog values from the field are sent in the monitoring direction, and commands are sent in the control direction. If a station sends both monitored data and commands, it is acting as both a controlled and a controlling station. This is defined as dual-mode operation, which is accommodated by the protocol, but requires that use is made of originator addresses.

All communications are initiated by master station requests. Although IEC 60870-5-101 supports balanced communication, this is limited to point-to-point links only. Support for unsolicited messages from a slave does not cover multidrop topology and must employ a cyclic polling scheme to interrogate the secondary stations.

In summary, balanced communication can: (1) initiate a transaction; improve the efficiency of communication system usage; (2) encounter collision problems because two stations can transmit their messages simultaneously; thus collision avoidance and recovery are required; (3) perform the communications limited to point-to-point only.

Unbalanced communication can: (1) send primary messages by master station only; (2) perform communication between multidrops; (3) have no collision while two or more stations transmit their messages at the same time; thus collision avoidance is not required; (4) have a simpler data-link layer function on the slave side in the service data unit of the application layer.

(b) Message structure

The IEC 60870-5-101 message structure is formed by a data-link layer frame carrying link address and control information, a flag indicating whether Class 1 data is available, and optional application data. Each frame can carry a maximum of one application service data unit for the application layer. Figure 10.9(A) shows the data-link frame structure, and the structure of the service data unit of the application layer.

In the case where user data is not required in the frame, either a fixed-length frame or a single character acknowledgment may be used. These provide for efficient use of communications band- width. Figure 10.9(B) shows a fixed-length frame and a single control character.

(c) Addressing

Under IEC 60870-5-191, addressing occurs both at the link and at the application level. The link address field may be 1 or 2 octets for unbalanced and 0, 1 or 2 octets for balanced communications. As

balanced communications are point-to-point, the link address is redundant, but may be included for security. The link address FF or FFFF is defined as a broadcast address, and may be used to address all stations at the link level. At the application level, the service data unit in this layer contains a 1 or 2 octet common address. This is defined as the address of the controlling station in the control direction, and the address of the controlled station in the monitoring direction. The common address of the service data unit combined with the information object address contained within the data itself combine to make the unique address for each data element.

As in DNP, there may be more than one logical or common address for each device in a SCADA system. As for the link level, the address FF or FFFF is defined as a broadcast address. Therefore to send a broadcast message it is necessary to include this address in both the data link and application address fields. Optionally, originator addresses can be carried within the service data unit of the application layer (not shown in Figure 10.8). The information object address is 1 to 3 octets in length, and can be provided either just once within a service data unit of the application layer, or for each separate information object. This allows for efficient transmission of blocks of sequential information.

(3) UCA protocols

UCA is specified and published in the IEEE-SA Technical Report on Utility Communications Architecture- Version 2.0-IEEE-SA IEEE-SA TR 1550-1999. It is designed to apply across all of the SCADA systems for the power, gas, and water facilities, including customer interface, distribution, transmission power plant, control center, corporate information systems, and so on.

The UCA Version 2.0 models, services, and protocols for substation devices are currently being used as the basis for IEC 61850. The initial drafts of IEC 61850 were distributed to IEC member countries for balloting in mid 2000. Many parts of the UCA have also been progressed through the standards process as IEC international standards. The UCA approach to communication between control centers, power plants, and SCADA masters was developed as the Inter-Control Centre Communications Protocol that was later taken up by IEC TC57 working group 7 and standardized as IEC standards 60870-6-503 and 60870-6-802. These standards define methods for synchronizing databases, as well as to perform scheduling, accounting, and other messaging.

It is important to note that UCA is an architecture, rather than a simple protocol. UCA Version 2.0 incorporates a family of basic communications protocols to meet the requirements of a wide range of facility environments. The selection and organization of these protocols has been designed to provide considerable flexibility in choosing the appropriate technology to meet the price and performance criteria of a facility system, while maintaining consistency at the device and data level to reduce integration and vendor product costs. In addition, the UCA includes detailed object models, which define the format, representation, and meaning of utility data. This modeling effort goes far beyond the scope of any other utility communications approach and provides for an unprecedented level of multivendor interoperability. The combination of broad scope and detailed object modeling makes the UCA specifications more complex than a typical protocol document.

UCA differs from most previous utility protocols in its use of object models of devices and device components. These models define common data formats, identifiers, and controls for substation and feeder devices such as measurement unit, switches, voltage regulators, and relays. The models specify standardized behavior for the most common device functions, and allow for significant vendor specialization to allow for future innovation. The models have been developed through an open process including a broad spectrum of vendor and utility participation. These standardized models allow for multivendor interoperability and ease of integration. Modern protocols (such as those found in UCA) make use of the reduced bandwidth costs and increased processor capabilities in the end devices to carry metadata: standardized names and type information for the most common device information which can be used by applications for online verification of the integration and configuration of databases throughout the utility. Examples of measurement metadata are unit, offset, scale, dead band for reporting, and description. This feature significantly reduces the cost of data integration and data management and reduces down-time due to configuration errors.

SCADA security and reliability

There are two important issues, namely communication security and system reliability, that significantly impact the application of SCADA networks. The first concerns protecting the communication contents and processes in the SCADA networks from attacks by unauthorized persons and even terrorists. The second issue provides an indication how a SCADA system performs for a specific period under given operating conditions.

(1) SCADA communication security

Common vulnerabilities for SCADA networks are thought to arise from three potential sources.

Firstly, many SCADA networks are not isolated or independent networks. In reality, most are linked, or even merged with other computer or industrial control networks. The connections between SCADA and other networks are not necessarily protected by strong access control. Many of the interconnections between SCADA and other networks require compatibilities with different communication standards to move data successfully between two unique systems. Due to the complexity of integrating disparate systems, network engineers often fail to address the added burden of accounting for security risks so access controls are usually minimal.

Secondly, some SCADA networks are designed with insecure network architectures. The architecture is critical in offering the appropriate amount of segmentation between SCADA and other networks, and these interconnections may not be secured by firewall or private network systems consistent with other networks.

Thirdly, many SCADA networks lack real-time monitoring which may lead to vast amounts of data from network security devices overwhelming utility information security resources, which render monitoring attempts futile. When intrusion detection systems are implemented, network security staff can only recognize individual attacks, as opposed to organized patterns of attacks over time.

The most effective communication security strategies for SCADA networks blend regular, periodic security assessments with an ongoing attention to design network architecture and the implementation of real-time monitoring. The following steps highlight major step needed to enhance the SCADA communication security.

(a) STEP 1: regular vulnerability assessments

Many utilities fail to assess the vulnerabilities of their SCADA on a regular basis. In addition to assessing operational systems, corporate networks and customer management systems should also be assessed to reveal unintended gaps in security, including unknown links between public and private networks, and firewall configuration problems.

(b) STEP 2: expert security architecture design

An overwhelming number of security technologies, networking devices, and configuration options are available to utility companies. While firewalls can help protect networks from malicious attacks, improper configuration and/or product selection can seriously hamper the effectiveness of a security policy. In order to minimize risks associated with network architecture design, utilities should be used by information security professionals to ensure that evolving network architectures do not risk information security.

(c) STEP 3: correctly managed security

As companies deploy network security technologies throughout their networks, the proper management and monitoring of these devices is becoming increasingly complex. Many organizations are outsourcing these functions to highly specialized, managed security companies. Managed security services ensure that all security devices are configured properly and fully patched, while monitoring the actual activity on each device to detect malicious activity in real time. They enable corporations or organizations to maintain a real-time security monitoring capability at a relatively low cost, and simultaneously increase the value of existing information security devices by enhancing their performance and capabilities.

(2) SCADA system reliability

For a telemetry system, long-term operational success is dependent upon two factors. The first is reliability, that is, the quality and performance of the system equipment over time. The second factor is the performance of the communication links between the central control and the remote site units.

From a reliability perspective, a telemetry system is a complex engineered system that has many possibilities for failure. These include failure due to components within products; to subsystems; to design flaws; from software applications; to human factors or operating documentation; to environmental conditions; or because redundant equipment fails. This range of possibilities indicate the difficulty of making an analysis that encompasses all these factors, so a reliability analysis is at best an approximation of the worst factors. Reliability prediction techniques used throughout various industries are mostly confined to the mapping of component failures to system failure and do not address these additional factors. Methodologies are currently evolving to model redundancy unit failures, human factor failures and software failures, but there is no model that will provide the level of precision that the existing reliability predictions can achieve based on hardware component failures.

To estimate SCADA reliability rates, an analysis should be conducted of all equipment in the network. For any equipment, the impact of its failure during operation is measured by an index derived from the mean time between failure (MTBF). Table 10.5 lists the orders of worst-case MTBF in hours for typical SCADA network equipment.

Therefore, it may be necessary to establish redundant items of equipment in the following areas:

(a) the computer display, keyboards, archiving systems, control software and printers, etc. in an operator station at the central control site;

(b) communication media,either landline connections or radio links;

(c) telemetry front-end equipment that connects to the communications medium at the master station and RTU end;

(d) the system power supply, which may be uninterruptible;

(e) all RTUs in field sites.

In addition to setting up redundant items for key system areas, there are three main activities that could improve SCADA reliability:

(a) System design

This includes: reduction in system complexity; duplication to provide fault tolerance; de-rating of stress factors; qualification testing and design reviews; feedback of failure information to provide reliability improvement.

(b) System manufacture

This includes two control activities. The first is the control of materials, tools, methods, changes and environment. The second is the control of work methods and standards.

(c) Field use

This includes: adequate operating and maintenance instructions and training; feedback of field failure information; replacement and spares strategies (for example, early replacement of items with a known wear-out characteristic).

Computations and circle diagrams:Maximum Quantities

Environmental sensors:Surveying and security

PC Hardware Interfaces: A Developer's Reference - Serial Interface—The COM Port

Operator-Caused Overheating

Troubleshooting control circuits:Basic control circuits

The DC Machine

Amplifier Basics:Amplifier Coupling

Tape Recording:Recording Formats—Analogue Machines

Audio Principles:The Sine Wave

Data Compression: MPEG-4 and Digital Audio Production

Electrical Measurements—Meters:reading Meter scales

Digital Audio Production:Disks and Other Peripheral Hardware