SCADA RTU's 

These devices are the key to SCADA systems. This page provides a more detailed 
explanation of a SCADA RTU. It assumes you have a general understanding of SCADA. If 
not please go to this SCADA primer. 
Basics
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). 
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. 
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. 

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. 
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 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 a date. 
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 a computer. 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. 

SCADA stands for supervisory control and data acquisition. It generally refers to industrial control
systems: computer systems that monitor and control industrial, infrastructure, or facility-based
processes, as described below:

• Industrial processes include those of manufacturing, production, power generation,

fabrication, and refining, and may run in continuous, batch, repetitive, or discrete modes.
• Infrastructure processes may be public or private, and include water treatment and
distribution, wastewater collection and treatment, oil and gas pipelines, electrical power
transmission and distribution, Wind Farms, railway electrification, and large communication
systems.

Facility processes occur both in public facilities and private ones, including buildings, airports,
ships, and space stations. They monitor and control HVAC, access, and energy consumption.

SCADA (supervisory control and data acquisition) is a category of software application program
for process control, the gathering of data in real time from remote locations in order to control
equipment and conditions. SCADA is used in power plants as well as in oil and gas refining,
telecommunications, transportation, and water and waste control.

SCADA systems include hardware and software components. The hardware gathers and feeds data
into a computer that has SCADA software installed. The computer then processes this data and
presents it in a timely manner. SCADA also records and logs all events into a file stored on a hard
disk or sends them to a printer. SCADA warns when conditions become hazardous by sounding
alarms.

Remote Terminal Unit (RTU)

An RTU, or Remote Terminal Unit is a microprocessor controlled electronic device which

interfaces objects in the physical world to a distributed control system or SCADA(supervisory
control and data acquisition system) by transmitting telemetry data to the system and/or altering the
state of connected objects based on control messages received from the system.

An RTU monitors the field digital and analog parameters and transmits all the data to the Central
Monitoring Station. An RTU can be interfaced with the Central Station with different
communication media (usually serial (RS232, RS485, RS422) or Ethernet). RTU can support
standard protocols (Modbus, IEC 60870-5-101/103/104, DNP3, ICCP, etc.) to interface any third
party software. In some control applications, RTUs drive high current capacity relays to a digital
output (or "DO") board to switch power on and off to devices in the field. The DO board switches
voltage to the coil in the relay, which closes the high current contacts, which completes the power
circuit to the device. An RTU can monitor analog inputs of different types including 4 to 20
milliamperes (4-20 mA), 0 to 10 V., -2.5V to 2.5V, 1 to 5V etc.; the RTU or host system then
translates this raw data into the appropriate units such as gallons of water left or temperature before
presenting the data to the user via the HMI or MMI.

RTUs differ from Programmable Logic Controllers (PLCs) in that RTUs are more suitable for wide
geographical telemetry, often using wireless communications, while PLCs are more suitable for
local area control (plants, production lines, etc.) where the system utilizes physical media for
control. The IEC 61131 programming tool is more popular for use with PLCs, while RTUs often
use proprietary.

ASE2000 Test Set Overview

ASE's protocol and communication test products, first introduced in 1989, are currently in use
worldwide by RTU and IED equipment manufactures, electric power utilities, and SCADA system
vendors. The earliest versions of the ASE RTU Test Set (Comm/32 and Comm/64) were DOS
based applications that were adapted for operation under Windows 3.x and Windows 95/98. While
these models have served the SCADA and RTU community extremely well for over 10 years, 1999
brought the introduction of a new model to the well established ASE RTU Test Set family, the
ASE2000 Communication Test Set. The latest in the ASE family of SCADA Test Set products, the
ASE2000 is a true 32-bit Windows application that retains all the functionality of the earlier model
ASE RTU Test Sets and includes many new features which enhance the data viewing, test setup,
and test function capabilities of the unit. The ASE2000 RTU Test set can be a DNP 3 Test set, it
can be a Modbus Test set or it can be an IEC 870-5-101 Test set. Protocols are licensed to run on
the same ASE2000 RTU test set platform.

ASE provides a total solution approach to the area of protocol test equipment with its' family of PC
based protocol test products that includes both laptop and desktop hardware configurations and
operating environments for DOS and Windows based units. With the largest base of supported
protocols in the industry (100+), most orders can be filled immediately. For example a ASE2000
RTU test set can be ordered with Tejas protocol, DNP 3 protocol and Conitel 2020. All protocols
will operate on the same platform. Adding support for previously unsupported protocols
(continuously ongoing activity) typically adds only one to two weeks to delivery time. One protocol
(customer choice) is included in the price of each unit. Additional protocols can be purchased at any
time for $250.

Functional Capabilities of the ASE2000

The ASE2000 RTU Test Set is a full-featured protocol test unit that provides the user with a
powerful and flexible tool for testing and maintaining SCADA RTU and SCADA IED equipment
and diagnosing communication problems.

User Interface
The user interface for SCADA test set operation is a menu driven, screen window oriented interface
with directional key or pointer device navigation. Set-up screens allow the user to define test
session specific information and user preference information. For quick-start operation, the supplied
default values for most test operations are sufficient and preclude the need for lengthy and
complicated pre-test set-up. For tests that do require special conditions, a set of intuitive and easy to
use set-up screens is provided. Special set-up conditions can be saved to uniquely named files and
easily retrieved for use in future sessions. Many users develop a library of frequently used test
scenarios with this feature thereby eliminating repetitive set-up for future test sessions.

Display Options
Display screens provide dynamic data display during monitoring and simulation mode test sessions.
Users are not limited to a single display format for message data. A number of data display options
are available such as "update in place" or message scrolling. In addition, message data can be
displayed in Interpretive Mode which identifies, in English, the various message elements and their
values, Raw Data Mode which displays only the numeric message data, or both which is a
combination to the two. Many other display options such as displaying analog data scaled in a ±
5Volt range, percentage of full scale, and selection of numbering base (decimal, hexadecimal, octal,
and binary) are also available.

Modes of Operation
The ASE2000 test set has three modes of operation, Master Simulation (talking to a downstream
device or RTU), RTU Simulation ( talking up to a master station), and Line Monitor (watch the
communications between Master and RTU or Slave).

Master Simulation Mode provides the capability to issue data scan requests and supervisory
control commands to one or more RTU's on a communication line. The set-up screens for this mode
allow the user to define a test scenario that identifies which device(s) to communicate with, which
commands to issue for each device, frequency of commands, screen format and display format of
message data.

RTU Simulation Mode allows the user to configure the ASE2000 RTU test set as one or more
RTU's that will respond to data scan requests and supervisory control commands with the proper
response for the particular protocol. Convenient set-up menus allow the user to specify point types,
number of points, and point ordering that will result in the proper data message structure. Point
modeling can also be enabled to provide data value changes on successive data scans.

Line Monitoring Mode is used to monitor the communication between a master station and end
SCADA terminal devices (RTU / IED) on a communication line. Message data for both directions
is shown.
Advanced Features
A number of advanced features are available for specialized test requirements. The user
configurable event log feature can be set up to capture specific events such as analog limit
exceptions, digital point changes, selected message types (such as Trip/Close requests), and more.
Trigger conditions can be tied to specific events.

Hardware Configuration Options

The ASE2000 RTU Test Set is available in multiple models as described below. The models differ
only by the communication hardware they utilize; the software is identical. Only Byte protocols
(6, 7, 8 data bits) are supported on the ASE2000-COM . Standard PC COM ports cannot support
bit-oriented protocols. All protocols are supported on BCOM-USB model. Otherwise, operation of
the models is virtually identical.

ASE ASE BCOM-USB

The ASE BCOM-USB is a USB Bus powered, two-channel serial RS-232 communication device
that is being offered as a direct replacement for the ASE two-channel BCOM PCMCIA
communication card. The PCMCIA slot has been discontinued on most new laptops and ASE is no
longer activley selling the PCMCIA cards..

The two RS-232 ports support both Synchronous (bit protocol) and Asynchronous (byte protocol)
communication. A set of RS-232 LED’s for each channel show TX, RX, RTS, CTS, and CD status.
Connection to the PC is via a standard USB device cable. Both USB 2.0 and USB 1.1 standards are
supported. A +5 VDC connector is included for powering the external ASE dual channel, Bell 202
modem.

Communication operates from 50 up to 56K baud for byte-oriented protocols and from 50 upto
2400 baud for bit-oriented protocols. The BCOM-USB is available with new ASE2000 Test Set
purchases or as an upgrade option from existing ASE PCMCIA or dongle (USB or Parallel port)
Test Sets.

Upgrade from an existing PCMCIA or dongle Test Set requires return of the current hardware
(PCMCIA card or dongle). For upgrades, the BCOM USB device will be delivered with a license
supporting operation for six-weeks from the date of shipment. This provides an overlap period
where the BCOM-USB device can be installed and tested prior to return of the PCMCIA card or
dongle. When the PCMCIA card or dongle is returned, an updated license will be provided to
remove the time limitation and allow unlimited usage. BCOM-USB devices included with new
ASE2000 orders will be configured with the unlimited use license.

The BCOM-USB device requires ASE2000 release 1.47, available for download from our web site.
Support is not included in prior releases. The BCOM-USB hardware package includes a BCOM-
USB device, a 3’ USB Type A to USB Type B device cable, two 6’ DB9F to DB25M RS232
Cables, and a power connector for the ASE Dual Channel Bell 202/V.23 modem.

BCOM-USB Data Sheet download in PDF version.

ASE2000-COM
Designed for both laptop and desktop computers, the ASE2000-COM utilizes standard PC COM
ports and is suitable for users that require support for byte oriented protocols only. For applications
requiring bit oriented protocol support, or bit and byte oriented protocol support, the ASE2000-
PCM is required.

There are four points to note with this option:

 Only byte protocols are supported. PC COM ports support a maximum of 8 data bits and
will not accommodate bit oriented protocols. (for example, DNP 3 testing, IEC 870-5-101
testing and modbus testing can operate using the standard PC com ports as they are byte
oriented)
 ASE's Bell-202 modem is not available with the COM model since the modem derives its
power through reserved conductors in ASE supplied cables. The COM model will operate
with an external modem.
 Test Set Monitor Mode operation requires two communication channels, as provided by the
ASE I/O cards. One channel is used to monitor master station transmissions and the other
monitors RTU transmissions. If the PC has two COM ports available, Monitor Mode can be
used, however, most laptop computers come equipped with only one external COM port.
 The Line Analyzer function requires ASE I/O hardware and is not supported on the COM
version
 Modem timing properties (pre-transmission mark, post-transmission mark, and receiver
squelch times) require ASE hardware and are not supported on the COM model.

In addition, when the COM version is used with Windows 95 or 98, the ASE2000 will only operate
in constant carrier mode. This is due to a known problem in the Microsoft Windows 95 and 98
standard COM port I/O driver. This is not a problem with Windows NT. It is not known when or if
Microsoft will correct this problem. For users that require switched carrier operation, it is
recommended that you purchase a version of the test set (USB-M or USB-RS) that uses ASE I/O
hardware and I/O drivers or run the Test Set under Windows NT. If you would like more
information on this problem, please feel free to contact us at 408-364-0500.

Bell 202T Compatible Dual Channel Modem

The optional dual channel modem provides two Bell 202T compatible modem channels and can be
used in conjunction the ASE2000-USB I/O device. The modem is powered through the supplied
cable.

Packaged System or Kit Form

ASE offers the test set in kit form or as a packaged system. The test set kit consists of the
appropriate I/O board, cables, adapters, software, and user's guide. The packaged system consists of
the test set kit integrated into a PC of the user's choice.

ASE2000 Summary of Features & Specifications

General
 Graphics window / menu screen presentation with keyboard or pointer navigation
 Common user interface set-up displays, independent of protocol
 Custom display of data with protocol specific formatting
 User preference set-up and save
 Extensive On-Line help facility
 Supports Windows 2000/XP/Vista operating environments

Line Monitoring
 Real-time display of message data (bi-directional)
 Time stamped messages
 Interpreted and raw data display options
 Filtering options for selected data display
 Trigger options for identification of specific events
 Data display number base preference (decimal, hex, octal, binary)
 Disk storage / retrieval of message data from test sessions
 Communication statistics (message count, parity errors, security errors, etc.)

Master Simulation
 Data and control requests to one or more devices
 User defined test scenarios
 Continual "in place" update of received data or message scrolling

RTU Simulation
 User configurable to respond to master requests for multiple devices (party line)
 Point value modeling for data change activity (analog, digital, accumulator)
Advanced Features
 User configurable event log can capture, for later review, communication errors, analog
limit exceptions, digital point changes, selected message types (supervisory control),
and more
 Event triggering
 RTU response time measurement (1 msec. resolution BCOM-USB)
 Low level control over message structure, security error, message timing, and other
fields to allow customization for advanced testing requirements
 Communication error generator for error detection testing
 Time synchronization for protocols that support Master/RTU time synchronization

SCADA or RTU : Test Set vs. Protocol Analyzer vs. Protocol

Translator

Over the years various names have been given to a box which essentially performs the following
functions: Test the Remote Terminal Unit (RTU) communication and point I/O; Test the Master
station communication and point I/O; Test the communications circuits between the Master and
RTU units; advanced testers capable of analyzing the communications data stream from Master to
RTU; capable of converting raw hexadecimal values into Readable characters for human users;
even more advanced features for data acquisition and control capabilities and automated testing.
The ASE2000 can perform all of these functions.

SCADA Test Set: Most original RTU manufacturers who developed proprietary protocols to speak
from their master station to their RTU, also created a testing box. This Box became known as a
RTU Tester, RTU Test Set, and sometimes I/O Test set. These large heavy duty test sets could
withstand a lot of abuse. Conitel 2020, Harris 5000/6000, CDC Type 1, Tejas 3 and Tejas 5,
BBCSI, are a few of the manufacturers' boxed test set we have worked with in the past. They are
still in the field and are very reliable, however they weighed 50 pounds and could only emulate one
protocol.

Protocol Analyzer: With the advent of Personal computers, and a few clever software developers,
a second generation of 'Test sets' arose. They first appeared on "Lunch box" or "luggable" portable
computers (Although movable, they were not particularly light, and were definitely not for your
lap!). This generation of protocol analyzer was based on DOS operating system, and had no mouse
support. Function keys ran everything. (only F1 through F8). However the bits and bytes could now
be analyzed and displayed in ASCII or Text for a human to read. This version of the Protocol
Analyzer grew in functionality as did the personal computer. Today we have the full featured
Windows XP Pro/Vista version, which has all of the capabilities listed above.

Protocol Translator: Although North Americans have called capabilities listed above, one of the
following: RTU Test Set, IED Test Set, SCADA Test Set, RTU Protocol Analyzer, IED Protocol
Analyzer, or SCADA Protocol Analyzer; the international community has requested a 'Protocol
Translator' (translate a protocol to english) test set. In North America we normally consider a
protocol translator to be a device (like the SPT4-NET) which converts one protocol to another
protocol (DNP 3 to IEC 870-5-101) .

If you have some fond memories of systems from the past, please use our contact us form, and we
will try to post relevant informative information in regards to legacy test test units.
For more information about the products and services Applied Systems Engineering provides, select
from the main menu on the top or please feel free to contact us directly if you have any questions
or would like to discuss your requirements with an application engineer.