At KMC, we think it is important to understand the underlying mechanisms behind building automation systems. One major player in the operation technology space is the Modbus protocol.

Modbus was introduced in 1979 by Modicon, now known as Schneider Electric. Modbus is one of the most widely used network protocols in industrial environments thanks to its openness and simplicity. Because thousands of vendors have adopted the protocol, Modbus is not only used in industrial and commercial buildings but can be found in many infrastructure, transportation and energy applications as well.

Modbus is a serial communications protocol – a messaging structure used to establish master-slave and client-server comm

unication between intelligent devices. It defines function codes and the encoding scheme for transferring data as either 1-bit binary points, known as coils, or as 16-bit data, known as registers. This basic data packet is then encapsulated according to the protocol specifications for each of the Modbus transmission methods. There are three transmission methods used: Modbus ASCII, Modbus RTU and Modbus TCP.

The most commonly used form of Modbus protocol is RTU, or Remote Terminal Unit. Modbus TCP uses the Modbus RTU protocol with a TCP interface, meaning it can run over Ethernet. Additionally, it can be run over IP to enable internet connectivity. So again, while Modbus RTU is used most frequently, the data can be wrapped into the TCP/IP protocol enabling common internet connectivity to these networks. Such is the case with KMC Commander, our IoT platform, which supports Modbus TCP. With KMC Commander, you can connect all these devices to the cloud and aggregate their data to track and trend equipment performance remotely and setup alarms as needed.

Modbus is a master/slave messaging system. This means that a master device talks to all the other devices on the network. It can query them for information or tell them what to do, but the slave devices themselves won’t talk until queried. Each slave has a unique 8-bit device address or unit number. Packets sent by the master include the address of the slave device, the function code – which defines what the master device is asking – and the data for the query. The slave must then respond within a certain period of time or a “no response” error will occur. In contrast to other protocols like BACnet, you can’t auto discover a network. You need to know the correct device address and points you are trying to view and control.

In Modbus, data is stored in four different tables. A vendor may decide to use only one table or a combination of tables depending on what data types the device provides. Two tables store coils and two tables store registers. The coils and registers each have a read-only table and read-write table, again depending on what the device allows.

A Modbus message typically contains five parts:

• The device address;
• The function code, or what we want the device to do;
• The coil or register address, which is the address of the data that we want to access;
• The data value at that address or the value we want to write to that address; and,
• The CRC, or cyclic redundancy check, which allows the data to be checked for any problems.

Modbus/TCP allows for peer to peer communication – essentially allowing multiple master and slave devices to live on a single network. By using TCP, we can think more in the lines of servers and clients. The slave becomes the server and the master becomes the client. There can be more than one client obtaining data from a server. Rather than defining master and slave on a physical device-by-device basis as you normally would, the system designer can create logical associations between master and slave functionality on the network. This allows the architecture to be more dynamic and simpler since the masters and slaves can all communicate more openly between more devices rather than one at a time.

This is just the surface of how Modbus works. To learn more about the protocol, visit www.modbus.org.