Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.


Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

DPS Factory Training

Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.

Reserve Your Seat Today

Top 3 Open Standard RTU Protocols

By Morgana Siggins

December 3, 2019


In a Supervisory Control and Data Acquisition (SCADA) system, there is a lot of communication between devices. These devices are mainly a master station and a Remote Terminal Unit (RTU). An RTU accepts commands from master stations to operate control points, set analog output levels, and provide responses.

In turn, master stations receive status updates, analog readings, and general data from RTU boxes.

Imagine trying to have a conversation with a person that doesn't speak the same language as you. If you both don't speak the same language, then there's no effective exchange of information.

The same thing happens to your equipment. A significant part of any SCADA network involves matching the protocol and communication parameters between connected devices so they can talk to each other.

If your devices are not able to communicate with one another correctly, then your monitoring system is useless. The real end-goal is preventing network failure and maintaining optimal up-time, however, not just for SCADA sites alone.

Key Concept: Polled vs Asynchronous

The process for transmission of information between an RTU and a master station can be either polled or asynchronous.

With polled transmission the master station controls communication with an RTU, or multiple RTUs, over a shared line. The term "polling" refers to the way the master station will continuously check RTUs to see if they are still connected and if they have anything to report. Basically, the master will send a message to the RTUs, one at a time, asking each whether it wants to use the line.

On the other hand, asynchronous transmission, also known as start/stop transmission, is when the data is being transported is sent from RTUs at irregular intervals instead of at a steady stream. This means that the messages are sent only when something must be reported (with no way of knowing if silence means "all good" or network outage entirely).

Key Concept: Open Standards vs Proprietary Protocols

Communication protocols allow devices to talk to each other. However, each device must support the same protocol in the same version. Any differences might result in communication errors.

There are 2 types of protocols:

  1. Proprietary protocols

    Normally, devices can communicate with each other without a problem when they are from the same vendor because they'll probably support the same protocol.

    However, this also means that if your equipment runs on a unique protocol - used only by a specific vendor - it will be difficult to add devices from other vendors to your system and you'll likely be restricted to this one supplier for support and purchase of future products.

  2. Open standard protocol

    This kind of protocol allows devices from different vendors to communicate with one another. This means these manufacturers want to achieve superior compatibility when they design their equipment's functionality and capabilities.

    Using an open standard protocol is a very important decision that leads to cost reduction and maximized flexibility. The open standard has many benefits over the proprietary protocol, such as:

    • Vendor independence
    • Availability of open system connectivity
    • Reliable products at optimized costs
    • Easy available knowledge and specification

Now that you know the key concepts about RTU communication, let's dive into a list of open protocols:

1. Let's Start with Simple Network Management Protocol

The Simple Network Management Protocol, also known as SNMP, consists of a standard protocol that collects and organizes information from devices on IP networks. It'll also modify that information in order to get the device to do some particular action.

SNMP Manager Agent Relationship Diagram
SNMP is based on the manager/agent model (or master and slave devices) consisting of a manager, an agent, a database of management information, managed objects, and the network protocol. The manager provides the interface between the human network manager and the management system. The agent provides the interface between the manager and the physical device(s) being managed.

SNMP traps are alert messages sent from a remote that supports this protocol to a master station, the SNMP manager. If an important event happens, the agent is able to immediately communicate with the manager via trap message, instead of waiting for a status request from the manager. This means that this protocol is asynchronous.

SNMPv1 is the first version of this protocol. It's an open standard protocol that is particularly easy to set up, but its big downside is that it has no security from someone with access to the network. Smaller RTUs commonly support this version.

SNMPv2C is the most common sub-version of the SNMPv2 - the second version of this protocol. The principal advantage over the SNMPv1 is the Inform command. This command allows the SNMP manager to positively acknowledge trap messages sent by the agent.

If the manager doesn't reply to an Inform, the trap message will be resent. Some additional benefits are: improved error handling and improved SET commands.

SNMPv3, the newest version of this protocol, enhances the security (64 bits). This version features both privacy and authentication:

Privacy adds encryption for the secure transmission of data. If any traps happen to be intercepted, they'll contain nothing but unintelligible characters. Privacy is especially useful in applications where SNMP messages must be routed over the internet.

The authentication will make sure that only the intended receivers can read the traps. When messages are created, they are given a special key that is based on the Engine ID of the device.

Engine ID uniquely identifies each SNMP device. The Engine ID is used to generate a key that will validate the messages. The key is shared with the right recipients and used to unencrypt received messages.

If you can't afford to compromise the security of your network, SNMPv3 is the way to go about it. One example of an RTU that supports this third version of SNMP is the NetGuardian 832A.

Best RTU for remote monitoring
The NetGuardian 832A G5 monitors 32 discrete alarms and 8 analog alarms. It pings 32 network elements, controls 8 relays, and provides LAN reach through access to 8 serial ports. It reports via SNMP v2c or DCPx, e-mail (including SMS text via email) - a complete remote site monitoring solution.

You if have SNMP v1 or v2 devices at your remotes sites, a good option would be using SNMPv3 converters. Some converters can handle just about any number of SNMPv1 or v2 equipment, so it's very budget-friendly. It's important to always make sure to choose a manufacturer that helps you build an effective system that will tackle most of your requirements at once.

Mediate different SNMP Versions
The NetGuardian V16 is a compact RTU capable of mediating v1 and v2c traps to SNMPv3. Your older SNMP equipment will send unencrypted traps only as far as the local NetGuardian (not across the wider network). This NetGuardian will convert the trap to SNMPv3 and send it back to your central SNMP manager.

2. The DNP3 Protocol and its Usage in SCADA Systems

DNP stands for Distributed Network Protocol, and the DNP3 is the version 3.0 of this protocol. DNP3 has been designed primarily for the communication between a master station and remotes in SCADA and remote monitoring systems. This type of protocol is used extensively within the electrical and water utility industries.

In a DNP3 network, after an initial poll from the master station all information and alarms will be gathered and sent to the master from the RTU. Although the master is usually the one asking for information from your remote, when there's an alarm, the remote will report it to the master, instead of waiting for a request. The master converts the alarm into a human-readable alert and sends it to you as some sort of notification, such as an email or SMS.

DNP3 protocol
In a typical DNP3 network, information is passed from the Remote up to the Master. Usually, the Master requests the information from the remote, but in the case of alarms, the remote will initiate an exchange rather than wait for a request from the Master. This assures that alarms are attended to in a timely manner.

The main reasons that make the DNP3 one of the most popular SCADA protocols in use today for remote monitor and control are:

  • It's an open protocol

  • It's optimized for SCADA communication

  • It provides compliance between different vendor's equipment

  • It's supported by a large number of SCADA equipment manufacturers

3. Finally, Let's Take a Look at Modbus Protocol

Modbus is an open standard protocol, mostly used for communication in industrial applications. A benefit of this protocol is that it uses a simple message structure, making it easy to set up.

Modbus devices will consist of one or more RTUs connected to the same master station. Each of these connected RTUs have an assigned Modbus address so data and commands can be transmitted correctly over the network.

The standard Modbus communication flow is controlled by the master station, as it requests information from or writes information to the RTUs. The remotes are only able to respond after receiving requests and/or commands from the master station.

The Modbus protocol has many different forms. They are the Modbus RS-232, Modbus RS-485, Modbus TCP/IP, Modbus ASCII, and Modbus RTU protocol.

  • RS-232 and RS-485

    The Modbus protocol can be used with two types of serial connections, the RS-232 and the RS-485. If you are transmitting data over short-distance and at low-speed RS-232 is the best option because of its low cost and simplicity. However if you require higher speed transmission over longer ranges or duplex networking capability then it might be better to go with RS-485.

  • Modbus TCP/IP

    Modbus TCP/IP was created due to the expanding usage of Ethernet. This version is nothing but a Modbus dressed up in TCP/IP, which means that it's used to communicate over a network structured with an IP connection. This version of the Modbus protocol has many capabilities. For instance, you can use the internet to access a device located across the world if this device supports Modbus TCP/IP.

    Usually, a Modbus network can support up to 247 RTUs connected at one time. However, the Modbus/TCP, taking advantage of the LAN infrastructure, is able to support many more units on the same network.

  • Modbus RTU

    This Modbus version uses binary communication and is more compact. In this variant, the data transmission is always followed by a cyclic redundancy check checksum, which identifies issues in the transmission.

  • Modbus ASCII

    This version uses ASCII encoded data that which means that the information sent between devices is human readable. The longitudinal checksum follows the Modbus ASCII data transmissions.

    Modbus ASCII is less efficient and secure than Modbus RTU. You should only use Modbus ASCII if your devices don't support the Modbus RTU variant. Modbus ASCII is also useful when RTU messaging can't be applied.

Do you Have Multiple Equipment Supporting Different Protocols? Here's How They Can Talk to Each Other

Not all monitoring gear will be compatible with the type of protocol the equipment at your remote site supports. The solution for this issue is protocol mediation.

RTU protocol mediation
A protocol mediation device rewrites your alarms to a format that is compatible with your alarm manager.

If you choose to get an RTU that has multi-protocol capabilities, it can function as a translator between two units that use different communication protocols. Another option for mediation is to choose a master station that supports many different protocols, this way it can work with whatever existing data transport you have.

Since a protocol is just a format for encoding info, it's usually in the form of a data packet. This packet contains the payload data (the actual message) and a header (extra bits with the address and routing info specific to the protocol).

What protocol mediation does is put a new header on the payload data. The device gets the alarm input, takes out the payload data, re-encodes the payload data in the format of another protocol, and sends the re-encoded alarm to the alarm master.

All of your data will remain the same, but it's now formatted in a way that your upstream equipment can understand.

Protocol mediation will allow your company to replace gear a few pieces at a time, instead of having to replace your entire network at once, reducing the cost of making changes to your monitoring system.

Independently if you have a small, medium or large remote site, DPS has many options of multi-protocol RTUs and master stations that will help you achieve protocol mediation, such as the NetGuardian 832A RTU and the T/Mon master station. Any of our units can be customized in order to meet your protocol translation needs. Consequently, you won't have to go through the trouble and expense of trying to redesign your network around one system.

T/Mon LNX: This hardware platform monitors, mediates, and forwards alarm data in over 25 standard and proprietary protocols, including legacy equipment no one else can support when running T/MonXM software.

Know More about Remote Monitoring

Network alarm data has to be transmitted to your masters in a protocol it can understand. Unfortunately, not all equipment operates on the same protocol. Alarm mediation devices have to be in place to translate and transmit that alarm info to your upper-level masters.

We specialize in mediation solutions. Our RTUs can receive information in a variety of protocols and output directly to the protocol of your choice.

All of our products are developed through partnerships with our customers. It's by listening to the issues our clients face building and maintaining their network, that we are able to develop products that will perfectly meet their needs.

We make sure you get the solution you need. So, if you want to know more about protocols, protocol mediation, or simply remote monitoring, just give me a call.

Morgana Siggins

Morgana Siggins

Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.