Modbus - the middle layers

 

Introduction

This web page focuses on the middle layer or layers of Modbus - the physical layer has been dealt with in the page entitled "SCADA and Telemetry - the physical layer".

Although many protocols are not usually described in terms of layers, it is quite a good way to think about how they operate. It also makes comparisons of different protocols somewhat easier. The early versions of Modbus were not described in terms of layers, however some later ones are.

There is more general information about protocol stacks in the previous web page entitled "SCADA Protocols - the middle layers - IEC 60870 and DNP3".

 

Modbus

Modbus is one of the protocols that isn`t described in terms of layers - however some versions "fit" into the EPA 3 layer model, and some fit into the TCP/IP model.

There are several versions of Modbus, some of them are open, and some of them are proprietry. The open versions include :-

There may well be other open versions of Modbus.

Modbus was originally designed for use with the plc`s that existed at the time, so it is limited in what it can do compared to some more modern SCADA protocols. However it is still widely used in various forms in the world of industrial control.

Modbus was originally designed to be used where all communications were based on the master polling the slaves. Slaves could not initiate an exchange of data. However they can in Modbus TCP.

Modbus was restricted to addressing 247 devices, There are some modifications made in some cases so that the device addresses are 2 bytes long, so 65536 addresses can be used. Modbus TCP has a different addressing scheme, and can address a higher number of devices.

The original versions of Modbus were designed to operate over always-on dedicated serial connections such as RS232 and RS485 - they cannot cope with breaks in a transmission - the break is seen as the end of a message.

There seems to be some variation in the descriptions of the various Modbus variants, depending on which website you are looking at - I don`t know if these are inaccuracies, or further variations in Modbus.

 

Modbus RTU

Modbus RTU "fits" quite nicely into the EPA 3 layer model. Some of the essential features of Modbus RTU are :-

The frame structure for Modbus RTU produced by the "data link layer" is therefore :-

 

Modbus ASCII

Modbus ASCII also "fits" quite nicely into the EPA 3 layer model, however the "data link layer" is quite different to that in Modbus RTU.

Compared to the features shown above for Modbus RTU, the corresponding features in Modbus ASCII are :-

The use of a limited range of values in a byte is a bit of a weird concept to get to grips with - so here is my understanding of it.

In the outside world, an 8-bit byte can have any value from hex 00 to hex ff - this gives a possible 256 different values.

This also applies to Modbus RTU, which uses 8 bits in each data byte for data.

However in Modbus ASCII, each data byte is only allowed to have one of 16 values in the range from hex 30 to hex 46 - the ones that correspond to the alphanumeric characters - the numbers from 0 to 9, and the letters from A to F.

[[ so the allowed hex values are 30 up to 39, and 41 up to 46. The hex values 3a up to 41 are not allowed. ]]

Then they add a second byte, with the same rule - only 16 possible values.

Now we have the situation that for each of the 16 values that the first byte can have, the second byte has also got 16 possible values. So the total number of possible values for the two bytes is now 16 x 16, which equals 256 possible values - ie, the same as Modbus RTU.

A knock on effect is that since we are only using 16 possible values in each byte, we don`t need 8 bits in the byte - we could do it with 4 bits. However in order to have compatibility with the ASCII coding scheme, 7 bits are used. The 8th bit can be used for parity checking.

This way of coding is used in all bytes in the frame - including the address information and control information.

The frame structure for Modbus ASCII is therefore :-

Modbus ASCII is a little better in terms of its acceptance of breaks in the transmission, because each message has got an end-of-message marker - it can tolerate breaks of up to 1 second.

 

Modbus TCP

There is quite a lot of stuff on the web that suggests that Modbus TCP is quite simply Modbus frames encapsulated into TCP packets. However a bit more digging revealed that this is somewhat inaccurate - Modbus TCP has a different protocol stack from Modbus RTU or Modbus ASCII - Modbus TCP uses the TCP/IP stack. However the "application layer" is the same.

Modbus TCP does not use the CRC or LRC checksums used in Modbus RTU or Modbus ASCII - Modbus TCP relies on the error correction within TCP/IP

In Modbus TCP, the slave address byte is removed, and instead there is a Modbus TCP header added - the MBAP header. The MBAP header contains a single byte "unit id", which can be used to identify individual devices beyond the TCP/IP section of the network - ie, it can be used by RS232 or RS485 network tails.

Because Modbus TCP doesn`t use the slave address for addressing slaves, it can handle as many different devices as the IP network configuration will allow - eg, as many as the sub-net mask will allow.

This also means that whilst Modbus RTU and Modbus ASCII are exclusively master station driven - ie, only the master station can initiate a data exchange - in Modbus TCP either the master or the slaves can initiate a data exchange.

Presumably, this also means that there can be more than one master station - so two different systems can operate over the same physical network.

 

The Modbus stacks

The "application layer" in Modbus is the same for the three versions of Modbus I have listed on this page.

The "application layer" produces what Modbus calls the Protocol Data Unit - PDU - and has two parts -

In Modbus RTU and Modbus ASCII, the "data link layer" wraps the PDU in to an Application Data Unit, which consists of -

So Modbus RTU and Modbus ASCII have a protocol stack that looks like -

However Modbus TCP wraps the PDU up into an Application Data Unit which consists of -

The MBAP header is composed of 4 sections -

I`m not sure what you would call the layer that takes the PDU and wraps it up into the Application Data Unit. You could copy DNP3 and still call it a data link layer. However it might be better to steal the name from the ISO OSI 7 layer stack, and call it a session layer.

But whatever you call it, Modbus TCP would end up with a 6 layer stack -

I have seen reference to Modbus TCP being a 7 layer stack with full ISO OSI 7 layer compatibiity, but I don`t know where the 7th layer comes from. I think they are possibly dividing up what I have called the application layer into an application layer and a presentation layer, so the stack would look like -

I don`t have anything like enough knowledge of the upper layers of SCADA protocols to be more precise about this. And just as a sort of a disclaimer in case it is all wrong - trying to define Modbus in terms of layers of a protocol stack is my way of understanding Modbus. Modbus wasn`t originally defined and isn`t usually described in terms of layers in the way that I have tried to do.

One other thing that is worth noting is that TCP and IP don`t actually map to the Transport and Network layers of the ISO OSI 7 layer model, their functionality is somewhat different. So even though it is a 7 layer stack, any stack based on TCP and IP can`t be fully compatible with the ISO OSI 7 layer model.

 

 

 

 

 

website design by ron-t

 

website hosting by freevirtualservers.com

 

© 2024   Ron Turner

 

+                                   +  

 

Link to the W3C website.   Link to the W3C website.