Modbus is an open serial communications protocol. It was developed in 1979 for use with Programmable Logic Controller (PLC) devices. 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 for SCADA systems. It's used extensively for a number of its key benefits, including the following:
Modbus is an open-source protocol. It can be included in a wide range of device types from any equipment vendor.
Modbus uses a simple message structure, making it less difficult to deploy. It might require just a matter of days to implement. This can save months of work. There is no need to learn and deploy other protocols.
Modbus moves raw words and bits, and it has very few restrictions.
Like any remote monitoring setup, Modbus consists of one (or a few) devices at the top of the network. These are the most powerful computers (called HMIs) in the system and are responsible for managing everything else.
The bottom of the network is small individual devices like RTUs and PLCs. These are your "front lines", collecting data and executing commands for the central HMI(s).
Modbus data can be carried on multiple channels (ethernet or older serial). It can also be in two major protocol forms ("TCP" or "RTU"). This flexibility is part of the lasting appeal of Modbus.
Even the format of Modbus data is flexible. Devices store important values in various standard data units, called "holding registers". A register could be one analog value, a collection of binary values, or something else. Manufacturers are free to use any of a number of formats ("function code fields") to suit the function of their devices.
Imagine an HMI needs information to present to the human operator. The targeted device will read holding registers to retrieve the data. It will then package and send it in one or more Modbus messages.
The Modbus protocol can be used with two types of serial connections, both RS-232 and RS-485. Some versions of Modbus can also be sent over Ethernet or TCP/IP. These Modbus communications 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. Modbus communications 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 protocol.
In this video, see a few simple steps. We'll start polling data from a backup generator (propane/diesel) using Modbus protocol. This example use the web interface of the NetGuardian DIN remote monitoring device.
There are two variants of the standard Modbus protocol: "Modbus RTU" and "Modbus TCP" formats. One of these is the Modbus RTU protocol. This variation is more compact and uses binary communication. In this format, a Modbus RTU message is always followed by a cyclic redundancy check checksum, which is used to detect transmission problems.
The second variant is Modbus ASCII. This version is more verbose, and it uses hex ASCII encoding of data that can be read by human operators. A different type of checksum, the longitudinal redundancy check checksum, takes place after ASCII data transmissions. ASCII is the less secure of the two variants.
As it is also less efficient than Modbus RTU, operators must take care. Only utilize Modbus ASCII for the transmission of data to devices that do not support the RTU format. Modbus ASCII can also be useful when RTU messaging cannot be properly applied.
The system "master" requests information from connected Modbus devices, which are referred to as "slaves". Slave devices only send information to the master in response to these requests and do not initiate messages. The master can also write information to the slave devices, but the slave devices cannot write information to the master.
When a slave address transmits a communication to the Modbus master, it begins the message with a unique address identifier. This is a number ranging from 1 to 247. This enables the master to identify which specific device is responding with the requested information.
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 external sensors. 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. 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, you must never forget certain things.
Always focus on open protocols that don't trap you. By reading this article, you've already done that.
Open standards empower you to choose a new manufacturer later. Closed protocols written by one manufacturer don't do that.
Also, look for devices that speak in multiple protocols. You should always standardize as much as possible, but something WILL come up.
You'll want a piece of equipment, but it only understands DNP3 or CANBUS. Without the right HMI, you will only have visibility over equipment that supports these two protocols. So, make sure your HMI has multiprotocol support. That box might be called a "master station" if it does more than just SCADA.
Any SCADA system you choose will have a big impact on you. Your operations are important. 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.
Proven providers who maintain a custom focus on your needs can be great. Look for a team that will provide tech support. That tech support shouldn't be massively expensive.
Also, ask any sales rep you talk to whether designs can be changed. What if you need something unexpected. Will you get a solution, or will they just shrug?
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. Good luck changing those designs when you need to.
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.
To protect yourself and your company, you need to get educated. The more you know about Modbus and SCADA generally, the better.
That's why I recommend these guides for you next. You have a full white paper on SCADA.
You can also read about the T/Mon HMI if you're evaluating solutions now. Finally, keep learning about tech with the RS485/RS232 article below.