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.
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
A typical single board RTU.
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.
Some RTU's may have a file system with support for file downloads. This supports user programs, and configuration files.
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.
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.
What should I specify for my 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.
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
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 timestamping 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.
Year 2000 issues for RTU's and PLC's
As both RTU's and PLC's are computers they have the potential to be affected by the so called millenium bug. Many RTU/PLC's do not use
dates at all and are completely unaffected. There are many that do. There have been cases of PLC's locking up due to problems with leap years, indicating the
potential for problems in the year 2000. It may happen that the RTU/PLC uses a generic Real Time Operating System which
supports dates, and the RTU/PLC does not utilise this date. It is easy to assume the RTU/PLC is not affected as there may be no external evidence that the device contains
It is important that any device which potentially has an embedded computer be checked, either with the supplier, or by testing to verify their compliance. The risk of failure must be assessed.
Systems that affect safety of life for example must be rigorously checked. In other cases the impact may be minor.
Don't just assume you can operate the plant or equipment manually in the event of problems. The manual "ON" switch may be wired to
Failure to demonstrate due diligence in checking may render individuals liable for the consequences of failure.
Remember that the instrumentation and plant the RTU/PLC is connected to may also have embedded computers.