Re-engineering SCADA Systems for the New Network Environment

Data communications networks are evolving into a new environment for supervisory control and data acquisition (SCADA) systems, an environment that can present significant challenges to systems designers. Frame relay, Ethernet and IP (Internet) protocols along with higher speed SCADA equipment are the new networking paradigm.

Increasing demand for speed will not likely end. With changing requirements and protocols, system designers must consider the challenges presented by a future without speed limits. Currently, the average lifetime for industrial SCADA equipment is more than 10 years. Networking technology changes much faster than that.

SCADA systems-whether of the latest design or legacy systems-can usually be migrated to the latest frame relay, Ethernet and IP networks, or 9,600 bps fast-poll modems. But to migrate successfully, system designers must have an awareness of certain issues, including those associated with legacy SCADA protocols, as well as potential problems such as incompatibilities that may come into play with newer network technologies. These include transmission delays, time gaps in data, control lead requirements, and equipment available to accommodate merging technologies.

Living with Legacy Protocols

SCADA protocols have been in operation for decades, and are now widespread and highly reliable. There is substantial embedded value in the current protocols; they have been developed to share certain characteristics that make them very robust in older, legacy networks.

At the same time, SCADA and legacy network protocols have characteristics that must be dealt with-and perhaps worked around-when migrating the system to newer network standards. Legacy networks are often lower speed, with 1,200 bps being the most widely used data rate. The data is usually asynchronous and is collected by polling remote terminals. There are typically many remote terminal units polled over a single multi-point circuit.

Legacy networks’ polling protocols require all sent and received data blocks to be continuous. Therefore time gaps, such as those that could occur with newer networks, are treated as if resulting from line errors. The outcome is repetitious re-polling of the remote terminal that failed to correctly respond to the poll.

On multidrop lines using modems, the polling host computer also expects to see the data carrier detect (DCD) signal turn on as data is received and then turn off when no data is being received. A lack of DCD transitions, which can occur with newer networks, may result in an error condition on some SCADA protocols.

In networks having microwave radio links, the DCD signal (or Request to Send from the remote terminal unit) is required to key half-duplex radios. All this polling and response must happen in a very short time, often measured in fractions of a second. The question is, will the new network technology match these needs?

New Media Characteristics

The newer, faster networks have their own protocols and must transport the SCADA protocols as well. In doing so, however, new transmission factors come into play. These network protocols-frame relay, Ethernet, IP-and higher speed SCADA equipment each have characteristics that will generate delays, cause gaps in the data flow or not transmit DCD transitions. Any of these characteristics may cause SCADA protocols to “see” errors in lines. Lack of DCD transitions may also prevent keying a microwave radio link.

Solutions

To avoid transmission problems such as these, designers who are planning to migrate their legacy SCADA networks should consider the network idiosyncrasies described below, as well as some prospective hardware solutions manufacturers are offering.

Frame Relay

Frame relay is a high-speed packet switching protocol for WANs. However, the data packets of frame relay networks may not always coincide with the size of the SCADA poll/response packets. Therefore, a SCADA packet will often be broken up into several frame relay packets by the network, with delays between them. Such time gaps within a broken SCADA packet will result in the SCADA polling computer seeing transmission errors when there are in fact no real errors.

This challenge can be overcome using new hardware-based technology such as Data Comm for Business’ (DCB’s) Frame Relay Broadcast Polling FRAD (BPF). A FRAD is a frame relay assembler/disassembler for asynchronous networks that will accommodate almost any byte-oriented async polling protocol. The BPF “encapsulates” async polling protocols into frame relay format for private or frame relay networks. DCB’s SR-01-BPM one port FRAD and SR-04 four port FRAD allow multipoint async polling over frame relay networks without knowledge of the underlying protocols.

Ethernet

Ethernet, like Frame Relay, is a packet transmission protocol. Ethernet packets are generated without regard to incoming data protocols. Ethernet devices have protocol rules to obey, which are related to the needs of Ethernet, not the infinite variety of possible devices that may be connected on an Ethernet network. Ethernet also possesses an electrical interface that is different from the RS232 asynchronous interface common in many SCADA systems.

However, by using asynchronous RS232 entry onto Ethernet, delays are avoided. Because devices that use IP protocol to encapsulate SCADA and other asynchronous data are now available, delays within SCADA data packets can be eliminated.

IP Networks

IP networks have the same packet characteristics as frame relay and Ethernet networks. There is no relationship between the IP packets and incoming SCADA poll/response data packets. Therefore, timing gaps will occur and SCADA systems may see them as error conditions.

Yet, several products are now available that can handle that problem and provide point-to-point or multipoint communications over private wires via RS232 and V.35 interface, or single-channel voice-and-data over microwave or other links. Channels can be synchronous or asynchronous at speeds up to 128 Kbps.

Higher Speed SCADA Equipment

In the past, most SCADA systems used 1,200 bps modems, which were sufficient to interrogate remote units to determine if they were operating, and also allowed for the delivery and collection of small amounts of data. Today, SCADA equipment is increasingly supported by more powerful computers, so data handling requirements are escalating.

Standard phone lines, private wires and microwaves operating at voice grade frequencies (bandwidth of about 3,000 Hz) are sufficient to pass 9,600 bps using fast poll modems. However, at higher data rates, the host modem needs extra time, generally known as RTS/CTS (Request To Send/Clear To Send) delay, to properly acquire and handle the data signal, so some polling protocols must be modified. Modems with short RTS/CTS delays that include multiple diagnostics features are now available.

SCADA systems can also operate over DDS (Dataphone Digital Service) networks provided privately or by telephone companies. These networks can provide speeds from 1,200 to 57,600 bps over multidrop networks with RTS/CTS delays of less than a millisecond, which won’t cause an error condition. DDS can be an ideal solution, providing it is available and cost effective. DCB provides a model, the DL-56, which can provide error-free support of DDS at 56 Kbps with a synchronous interface, or 1,200 to 9,600 bps async data with no modifications. The DL-56A will provide data rates up to 57.6 kbps over 56 Kbps DDS lines.

Also, some manufacturers supply a number of multiplexers that can handle synchronous or asynchronous data operating over multipoint microwave or radio systems. Spread spectrum, frequency-hopping wireless radio modems, which can accommodate multiple remote SCADA terminals from a single phone line and also provide great savings over satellite- or cellular-based communications are currently available.

Russell Straayer is president of Data Comm for Business Inc. in Champaign, Ill. He can be reached at (217) 352-3207 (inside Illinois) or 800-4DBCNET (outside Illinois). More information about Data Comm for Business is available at http://www.dcbnet.com or can be obtained by e-mailing: info@dcbnet.com.

Previous articleELP Volume 78 Issue 5
Next articleELP Volume 78 Issue 6

No posts to display