You need to see DPS gear in action. Get a live demo with our engineers.
Download our free SCADA tutorial.
An introduction to SCADA from your own perspective.
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 Today
Modbus is a communications protocol for transmitting data between two or more devices. It was developed in 1979 for use with Programmable Logic Controllers (PLCs). It's now widely used for connecting many types of industrial electronic devices on different types of networks.
Modbus communication protocol is a widely used protocol in Supervisory Control and Data Acquisition (SCADA) systems. It's used extensively for a number of its key benefits, including the following:
For devices with large numbers of input registers (more than a few hundred), you'll benefit from a master device that can prioritize more important registers over less important ones.
Like most remote monitoring system protocols, Modbus follows the master/slave model, but the devices are typically referred to as interrogators/responders, respectively. A system will consist of an RTU which polls (or interrogates) a device for data and alarm information. A remote terminal unit (RTU) is also able to tell a Modbus device when and what commands to execute.
Even the format of the data is flexible. Devices store important values of different data types in various 16 bit registers. A register could contain one analog value, a collection of binary values, or something else. For simplicity's sake, imagine a database or a spreadsheet with two columns: one column contains the register name, and the other column contains the register value. That's really all holding registers are, and you'll configure an RTU to only collect data from the registers you want.
Manufacturers are free to use any number of formats (Modbus function code fields) to suit the function of their devices. If your monitoring device needs information to present to a human operator, the targeted device will read holding registers to receive the data.
Modbus data can be carried on two channels - over serial communication, or over a network connection. This flexibility is part of the lasting appeal of Modbus.
There are two types of Modbus serial protocols, RS-232 and RS-485. Modbus RS-232 allows concurrent, full-duplex flow of data. Modbus RS-485 is half-duplex, and indicates values using differences in voltage.
Modbus messages can also be sent over Ethernet or TCP/IP. These Modbus messages are packed as a single bit, or 16-bit word packets.
Modbus is not part of a physical layer on a network, as with some other protocols. Messages are transferred on top of physical layers, enabling it to be utilized on many different types of networks. This non-physical layer property makes Modbus an application layer SCADA protocol.
Modbus is used by many devices, including most modern generators. In this diagram, a mediation device is converting Modbus to another protocol, SNMP.
In this video, you'll see a few simple steps on how to monitor your generator using Modbus. We'll start polling data from a backup generator (propane/diesel). This example uses the web interface of the NetGuardian DIN remote monitoring device.
There are two variants of the standard Modbus protocol: ASCII Modbus vs Modbus RTU. The Modbus RTU protocol is more compact and uses binary communication. In this format, a message is always followed by a cyclic redundancy check checksum, which is used to detect transmission problems.
The second variant is the Modbus ASCII protocol. This version is more verbose, and it uses ASCII characters that can be read by human operators. A different type of checksum, the longitudinal redundancy check checksum, takes place after ASCII data transmission. ASCII is the less secure of the two variants.
As it is also less efficient than the RTU variant, operators shouldn't use it as their go-to variant. Only utilize Modbus ASCII for the transmission of data to devices that do not support the RTU format.
The system interrogator requests information from connected Modbus devices, which are referred to as responders. Responding devices only send information to the interrogator in response to these requests, and do not initiate messages themselves. The interrogator can also write information to the responding devices, but the responding devices cannot write information to the master.
When a responder address transmits a communication to the Modbus interrogator, it begins the message with a unique address identifier. This is a number ranging from 1 to 247. This enables the interrogator to identify which specific device is responding with the requested information.
Modbus registers are formatted according to one of several "function codes" based on the data contained. You might have an analog fuel level value stored as an 8-bit integer. Instead, a register could use those same 8 bits to store 8 different binary values (door open, power fail, etc.) in a bitmap.
Just like any SCADA devices, the official Modbus function of "data acquisition" can vary.
The most common thing you probably think of is an external sensor. You have a process that involves heat, so you put a temperature sensor near it. You have a sealed chamber, so you add a pressure sensor.
That's not the only way to acquire data, though. Many devices self-monitor and report via Modbus; and generators are a great example. They monitor their own fuel levels, temperatures, pressures, and more.
Finally, there are synthesized registers that depend on soft values like timers and calculations. "Time since last maintenance" could be tracked as an analog value, perhaps. Some generators have over 1000 registers to poll. Most of them aren't a physical sensor reading.
No matter what protocol you choose to use, keep in mind a few important points:
Always focus on open protocols that don't trap you in ridiculous licensing fees. By reading this article, you've already taken one step in the right direction.
Open standards empower you to choose a new manufacturer later. Closed protocols written by one manufacturer won't allow that.
Also, look for devices that speak in multiple protocols. You should always standardize as much as possible because something WILL come up. Don't settle for a master if it only has Modbus SCADA software if you have other devices that use different protocols like SNMP or DNP3. The T/Mon LNX is a great example of a master that speaks multiple protocols.
Any SCADA system you choose will have a big impact on your unmanned site. Your operations are important, and SCADA protects those operations. That's why you need to choose a manufacturer with a track record. Big companies can be a reasonable option, but sometimes they're too big to care about you unless you're huge also, or willing to shell out tons of cash for a solution.
Proven providers who maintain a custom focus on your needs can be great. Look for a team that will provide free tech support, and who doesn't outsource their tech support.
Ask any sales rep you talk to whether designs can be changed or new features you need can be added. What if you need something unexpected, will they develop a solution for you? A great shorthand for this is whether a company has its own engineers. Devices built overseas and merely sold in your country can be a problem.
Ideally, your SCADA manufacturer has strong control over design, manufacturing, sales, and support. That's a priceless tool for the problems you can't predict.
The more you know about Mod bus and SCADA, the more valuable you'll be to your company.
You can also read about the T/Mon Alarm Master if you're evaluating solutions now. Finally, keep learning about tech with the RS485/RS232 article below.