FSP0014 – Modbus – Facility Science Podcast #14

By | July 30, 2019
0 Comment

 

Notes for FSP0014 – Modbus
  • Modbus is protocol for industrial automation and communication
  • defines both a communication structure and a data model.
  • is an application layer protocol. I talked more about protocol stacks and layers in #1 of this podcast (How the Internet Works) if you want more information about that.
  • was developed by Modicon corporation to allow communication between it Programmable logic controllers (PLCs), and originally published in 1979.
  • Master/slave, client/server protocol, generally this means that there is one master device that initiates communication with and controls the other devices.
  • is a defacto standard in its niche for several reasons.
    • It works for its intended purpose.
    • It is simple and easy to implement.
    • Maybe most importantly the standard, although developed by a private company, has always been open and free to use by anyone.
  • You can find the protocol specification for Modbus at the Modbus Organization web site (modbus.org).
Modbus data model
  • Data model is based on a set of tables or blocks of data points that represent the state of the device and allow an application to interact with the device. In general, there are 4 conceptual blocks that correspond to the four Modbus data types. In practice, for a particular device there might not actually be 4 blocks or the four blocks might overlap or whatever.
  • The four Modbus data types are discrete inputs, coils, input registers, holding registers. The names of the data types suggest Modbus’s origin as a protocol designed for communication between PLCs (Programmable Logic Controllers). A PLC is a (not surprisingly) a programmable device used to implement some type of automation (this is a general purpose device). Let’s go through the four data types:
    • Discrete input (sometimes called a “contact” in the PLC context). This represents a one-bit or binary value, that’s an on or off, or a true or false, or a zero or one. A person with PLC programming experience might call this a contact because in the PLC context this would often represent monitoring some type of physical switch with the on-off state of the input representing the open-close state of the switch. The term “contact” is used to describe the conducting metal parts in a switch. Since a discrete input represents something that is detected or maybe otherwise external to the control mechanism, it is a read-only value. You can’t tell the external switch whether it is open or closed, you can only look to see if it is open or closed.
    • Coils might also be called discrete outputs. This represents a controllable on-off type of value so it’s a one-bit or binary value like the discrete input. The main different between the coil and the discrete input is that the coil is writable, which means that you can tell it whether to be on or off. In the PLC context this would represent a switch that we can use to turn something outside the control mechanism on or off. It’s called a coil because it would historically represent an electro-mechanical relay. This is a device that uses a literal coil of wire to create an electromagnet to pull a physical switch closed (or open). In general, in addition to being able to send a command to change the state of the coil you would also be able to ask the coil about is current state.
    • Input register represents a 16 bit value (that’s a number between 0 and 65535. This could be the value of some type of sensor, or a counter or timer of some type. The input register, like the discrete input is meant to represent something outside the direct control of the control mechanism (so a detected or observed value), and consequently can only be read and not written to. This is called a “register” again because of the historical PLC context. “Register” is the name for a bit of memory used for holding a value in a micro-controller (which would be the brain of the PLC). If you had, for example, an analog temperature sensor connected to an analog-to-digital converter in the PLC, the ADC would convert the analog signal into a 16 bit digital value and hold the value in a register inside the PLC.
    • Holding register, like input register, represents a 16-bit value. These are values that represent some type of setting or other data internal to the device. Example of this might be a setpoint or a threshold or a mode setting. Since a holding register represents a value internal to the device, the value in the holding register can be changed by the external application via Modbus commands.
  • With all that being said about what the data types are conceptually meant to represent, the designer of a device can use the 4 basic types to represent their device data in whatever way makes sense for their application. The details if this are non-standard and specific to each individual device (though each manufacturer might adhere to an internal standard across similar devices)
Addressing
  • Each data point is identified by a numerical address. You can think of this as a numbered row in a table.
  • Each data block or data table (that’s one for each of the four data types) has its own address space.
  • There are 65536 possible addresses in each data table (that’s a 16 bit number). The addresses start at 0 (so they go up to 65535).
  • The protocol knows which table to look in for a given address by the function being used. For example if you use the read coil function to read the value of coil at address 12, the device knows to look at the address 12 in the coil table rather than address 12 in a different table.
  • While the protocol knows which table to look in based on the function code, it can be confusing to humans to have the same address refer to multiple possible data points depending on the function code. For this reason (I think just for this reason) there is a convention to prepend a number to each address where the number indicates the data block. By this convention, all coil addresses start with 0, all discrete input addresses with 1, input registers addresses start with 3, and holding register addresses start with 4. For example, instead of having a holding register at address 12, it would have an address 40012. This way each data point can be addressed completely unambiguously. This has some implications for the number of available addresses but I’ll call that outside the scope of this podcast. As far as I can tell, this convention is not part of the Modbus standard (or at leas I couldn’t find it). It is, however, widely used.
  • A quirk of the Modbus data model is that addresses start at 0 while data elements or data points are numbered starting at 1. So, if you want to read coil #1 you would ask for address #0 in the coil table. This really only matters if you are the one responsible integrating a Modbus device into a system.
  • The use of the data types and the exact addressing is entirely device specific. Each device should come with documentation which will tell you which data points are available and which
Functions
  • We interact with the data in a Modbus device using functions.
  • There is a different function for reading and writing (where applicable) each of the Modbus data types.
  • The functions are numbered with function codes.
    • Read coil function has function code 1
    • Read discrete input has function code 2
    • etc.
  • There are functions for reading or writing multiple values at once. Function code 3 (Read multiple holding register) allows the reading of a series of (consecutive) holding registers. This type of function requires a starting address and a number of registers to read.
  • There are also functions for network and device diagnostics.
Exceptions
  • The last piece of the puzzle, at least at the application layer, is exceptions. Exceptions are used to indicate error conditions.
  • Under normal conditions when a function is successfully executed, the remote device will respond with either the data you asked for or by echoing the function you asked it to perform in the case of a write.
  • When a request can’t be carried out for whatever reason, the remote device will respond with an exception. Exceptions, like everything else, are numbered. Exception #1 is returned for for an illegal function (function not recognized or not allowed). Exception #2 is returned for an illegal data address (for when the device doesn’t have anything at the address or access is not allowed). And etc…
More detail about everything covered so far (data model, addressing, functions, exceptions) can be found in the Modbus Application Protocol Specification (http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf) which can be found at modbus.org.
Network Types
  • Modbus is an application layer protocol which means that it doesn’t actually physically connect devices together. Instead it relies on other technologies to accomplish this.
  • The most common supported lower layers are EIA-485 (RS-485, that’s a 2 wire serial communication technology) and TCP/IP over Ethernet (see #1 of this podcast).
  • There are 2 common versions of the protocol used over the serial (EIA485 network). Modbus RTU and Modbus ASCII. These only differ in how they package up the data for communication.
    • Modbus RTU (Remote Terminal Unit) uses a compact binary representation of the data as defined in the spec.
    • Modbus ASCII represents the communication data using ASCII characters. ASCII stands for American Standard Code for Information Interchange. It is basically a standard way of representing letters.
    • Modbus RTU is by far the more widely used, at least as far as I know.
  • Modbus can be used over our general purpose IT networks using TCP/IP. This is called Modbus TCP/IP or sometimes just called Modbus TCP. This has the obvious advantage that we get all the benefits of using Ethernet and TCP/IP including the fact the our building already likely have this infrastructure installed, and we can use it across the Internet.
  • Modbus is used by a lot of manufacturers in a lot of devices and has been used for a long time so there are quite a few other variations and extensions of the protocol, but I don’t think think there is any reason to cover them here.
Security – Let’s talk about security
  • There is none. Any Modbus device will happily carry out any command it receives from anyone without question. Take a minute to think about what an attacker could do to your business if they had access to your Modbus network.
  • That’s not quite technically true, there is a Modbus security protocol. It doesn’t really matter though, because none of the millions of devices produced before 2018 are using it and even if we had devices that were using it (and this is my opinion) I wouldn’t count on it because it hasn’t been widely tested by exposure to hackers and I don’t necessarily trust the companies that make these devices to implement secure protocols correctly. This isn’t meant to disparage these companies in any way, it’s just that doing security correctly is hard and its not their core competency.
  • The only security you can really count on for your Modbus network is isolation. If you must connect your Modbus network across multiple sites using Modbus TCP/IP, connect the sites using a VPN and tunnel the Modbus through that rather than putting the Modbus devices directly on the Internet. If you need outside access to the data from your Modbus devices, make sure it is only accessible through some type of hardened gateway. The gateway can aggregate the data from the Modbus network and provide access to it through a more secure mechanism.
  • Physical security is also important. Anyone with physical access to the devices or even the cables connecting them could potentially access every Modbus device on the network. I’ve mentioned this before, but imagine you have a Modbus capable device (like a generator or a lift station controller) outside your building (and maybe you don’t have to imagine it. That device, or even the cable you run out to that device to connect it to the network is a potential entry point into your network. For a Modbus network “entry” is as simple as splicing a device somewhere into the cable.
Benefits (some)
  • Free to use, open standard.
  • Simple to implement and requires little resources…can be implemented in very low power devices.
  • Ubiquitous, supported by many devices and everybody knows how to use it.
  • Works well for its intended purpose. We can easily ask a device about its state or tell it to do something.
Limitations (some)
  • Old and primitive. Doesn’t provide any of the services and capabilities we expect from more modern technologies.
  • Talked a little bit about the data model, we have the limited set of data types and the numerical addressing scheme…and that’s it. The data points don’t have names, just numerical addresses and we can’t group data points together into logical structures. There is no way to ask the device about its available data points or capabilities.
  • No security to speak of.
  • No event alert mechanism. The remote devices have no mechanism to tell the master controller when something happens. We have to continuously poll if we want to know about something.