Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next 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 TodayIn 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.
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).
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:
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.
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:
Now that you know the key concepts about RTU communication, let's dive into a list of open protocols:
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 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.
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.
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.
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
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.
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.
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.
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 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.
