These devices are the key to SCADA systems. A SCADA system consists of a number of components.

The central SCADA master system.

• A communications network.

• The RTU's. Remote Telemetry (or Terminal) Units.

• Field instrumentation.

The SCADA RTU is a (hopefully) small ruggedised computer which provides intelligence in the field, and allows the central SCADA master to communicate with the field instruments. It is a stand alone data acquisition and control unit. Its function is to control process equipment at the remote site, acquire data from the equipment, and transfer the data back to the central SCADA system.

There are two basic types of RTU - the "single board RTU" which is compact, and contains all I/O on a single board, and the "modular RTU" which has a separate CPU module, and can have other modules added, normally by plugging into a common "backplane" (a bit like a PC motherboard and plug in peripheral cards). The single board RTU normally has fixed I/O eg 16 digital inputs, 8 digital outputs, 8 analogue inputs, and say 4 analogue outputs. It is normally not possible to expand its capability.

The modular RTU is designed to be expanded by adding additional modules. Typical modules may be a 8 analog in module, a 8 digital out module. Some specialised modules such as a GPS time stamp module may be available.

Hardware functionality in an RTU
The SCADA RTU is a small ruggedised computer. It has the following hardware features:
 

• CPU and volatile memory.

• Non volatile memory for storing programs and data.

• Communications capability either through serial port(s) or sometimes with an on board modem.

• Secure Power supply (with battery backup).

• Watchdog timer (to ensure the RTU restarts if something fails).

• Electrical protection against "spikes".

• I/O interfaces to DI/DO/AI/AO's.

• Real time clock.

Software functionality in an RTU.
All RTU's require the following functionality. In many RTU's these may be intermingled and not necessarily identifiable as separate modules.

• Real time operating system. This may be a specific RTOS, or it may be code that started out life as one big loop scanning the inputs, and monitoring the communications ports. Driver for the communications system ie the link to the SCADA Master.

• Device drivers for the I/O system ie to the field devices.

• SCADA application eg scanning of inputs, processing and storing of data, responding to requests from the SCADA master over the communications network.

• Some method to allow the user applications to be configured in the RTU. This may be simple parameter setting, enabling or disabling specific I/O's or it may represent a complete user programming environment. See here for a sophisticated example of a user programming environment.

• Diagnostics.

• Some RTU's may have a file system with support for file downloads. This supports user programs, and configuration files.

Basic operation

The RTU will operate scanning its inputs, normally at a fairly fast rate. It may do some processing such as change of state processing, timestamping of changes, and storage of the data awaiting polling from the SCADA master. Some RTU's have the ability to initiate reporting to the SCADA master, although more common is the situation where the SCADA master polls the RTU's asking for changes. The RTU may do some alarm processing. When polled by the SCADA master, the RTU must respond to the request, which may be as simple as "give me all your data", to a complex control function to be executed.

Small vs Large
RTU's are specialty devices manufactured often by small suppliers in batches of as little as one hundred. They are made for niche markets, and at the smaller end can be subject to intense cost pressures. Therefore not all RTU's support all functionality. Larger RTU's may be capable of processing hundreds of inputs, and even controlling smaller "sub RTU's". These are obviously more expensive. The processing power of an RTU ranges from small 8 bit processors with minimal memory to larger sophisticated RTU's capable of time stamping data to millisecond accuracy.

Some types (sizes ) of RTU's are as follows:
 

• Tiny stand-alone systems that run off batteries for an entire year or more. These systems log data into EPROM or FLASH ROM and download data when physically accessed by an operator. Often these systems use single chip processors with minimal memory and might not be able to handle a sophisticated communications protocol.

• Small stand-alone systems that can power up periodically and apply power to sensors (or radios) to measure and/or report. Usually run off batteries that are maintained by solar energy. The batteries are large enough to maintain operation for at least 4 months during the darkness of the winter in the far northern hemisphere. These systems generally have enough capability for a much more complex communications scheme.

• Medium systems. Dedicated single board industrial computers, including IBM-PC or compatible computers either in desk-top enclosures or industrial configurations such as VME, MultiBus, STD bus, PC104 etc.

• Large systems. Complete Plant control with all the bells and whistles. These are usually in Distributed Control systems in Plants, etc and often communicate over high speed LANS. Timing may be very critical.

Standards
As indicated RTU's are specialty devices. There has been a lack of standards, especially in the communications area, and generally RTU's from one supplier cannot be mixed with RTU's from another supplier. An industry has grown up developing protocol converters and emulators. Recently some standards have begun to emerge for RTU's. Some standards are

• DNPs and IEC870 for communications

• IEC1131-3 for programming RTU's.

PLC's vs RTU's

A PLC (programmable logic controller) is a small industrial computer which originally replaced relay logic. It had inputs and outputs similar to those an RTU has. It contained a program which executed a loop, scanning the inputs and taking actions based on these inputs. Originally the PLC had no communications capability, but they began to be used in situations where communications was a desirable feature. So communications modules were developed for PLC's, supporting ethernet (for use in distributed control systems) and the Modbus communications protocol for use over dedicated (wire) links. As time goes on we will see PLC's support more sophisticated communications protocols.

RTU's have always been used in situations where the communications are more difficult, and the RTU's strength was its ability to handle difficult communications. RTU's originally had poor programmability in comparison to PLC's. As time has gone on, the programmability of the RTU has increased.

We are seeing the merging of RTU's and PLC's, but it will be a long time (if ever) before the distinction disappears.

Specification for RTU's

• Temperature ratings for your application eg -10 to 65 deg cent.

• Relative humidity 0 to 95% noncondensing.

• Dust, vibration, rain, salt and fog protection.

• Electrical noise immunity.

• Physical size - make sure it will fit in your site.

• Power consumption.

• I/O capability and capacity. Always allow some spare (say 10-20%). Don't ask for AO if you don't need it. Look at the accuracy of analogs, and the type of signal digitals are expecting. eg 0-5v, etc.

• Programmability and configurability (Look at IEC1131-3 for programmability.

• Diagnostics - local and remote.

• Communications capability including support for radio, PSTN, landline, microwave, satellite, X.25. Remember use of PSTN implies the RTU will timestamp and store the data while it is not connected, and that the SCADA master can dial up, accept this backlog of data, and backfill its database with this historical data (including trend files). Also consider how alarms are to be handled with PSTN.

• Communications protocols. Consider standard protocols such as DNP3, IEC870, MMS instead of proprietary protocols.

• Supported functionality - eg timestamping, memory capacity to store data in the event of loss of communications, ability to do calculations.

• Look at support for peer to peer communications including store and forward capability if communications are difficult (esp radio).

• Look at data rates supported (1200 baud FSK, or 9600 baud data radio). You may require additional serial ports especially to interface with PLC's. Your SCADA master must support all of the RTU functionality especially time stamping of analog data, and the communications protocols.

• Ensure if you want timestamped data, the RTU can time stamp to the required accuracy. The standard in the electricity industry appears to be 1 millisecond accuracy and this is not achievable without fast processors and an accurate time signal eg from GPS.
  Maximum addressability (eg max of 255 RTU's).

• Clear local indication of diagnostics.

• Compatibility checks of software configuration vs actual hardware

• Log kept of all errors. Remote access to these logs.

• Software filtering of analog input channels.

Links