1

It is often stated that Modbus/TCP isn't a real-time protocol. It is also "known" that Modbus isn't a real-time protocol. This despite the fact that the original Modbus protocol is highly deterministic.

In fact, as far as I can tell, the reason why it has historically and industrially not been considered real-time is because it is simply slow.

However, the proper Computer Science definition of real-time is that it have a deterministic bounded execution time, aka guaranteed deadlines. [1][2]

Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".

Real-time communication is a category of software protocols and communication hardware media that gives real-time guarantees, which is necessary to support real-time guarantees of real-time computing.

The field of industrial automation is long past the first days of PLCs. While robotic arms may require 10ms latency to communicate with their controller, intra-plant communications can have acceptable latencies in the hundreds of ms but still need to be real-time over distances of hundreds of meters. This is why solutions like EtherCAT, Profinet and Ethernet/IP exist.

With this preamble stated, and with the understanding that solutions exist for putting TCP on RT capable ethernet:

does anything make Modbus/TCP non-deterministic, i.e. unbounded in execution time as a protocol?

I've looked at Modbus/TCP protocol on the wire, and it consists of a single request/response exchange.

Looking closely at the protocol definition, the slave can return an exception response which includes the following:

5 Acknowledge Slave has accepted request and is processing it, but a long duration of time is required. This response is returned to prevent a timeout error from occurring in the master. Master can next issue a Poll Program Complete message to determine whether processing is completed

6 Slave Device Busy Slave is engaged in processing a long-duration command. Master should retry later

Both would fit the definition of unbounded execution time, but can be interpreted simply as a comms error since they are exception codes. Especially if the exception response is returned within a bounded amount of time. After all, real-time doesn't mean error-proof.

So then why is Modbus/TCP - as a protocol - truly not real-time?


Evidently the way I originally wrote this question solicited some trivial answers. Please understand that I'm not looking for a naive yes or no answer. I'm looking for thoughtful consideration.

Also I've searched quite a bit to determine whether TCP itself is fundamentally non-deterministic. I do not see that it is. While IP is best effort delivery, I don't see how un-routed TCP over LAN should pose a problem. But maybe there's a condition under which TCP frames can be mangled due to some esoteric circumstances?

8

Sometimes (due to noise, collisions, ...) packets get mangled and/or just plain lost (dropped due to congestion, lots due to a router going offline, etc). TCP is supposed to recover from this by retrying.

The number of retries is unbounded.

For a theoretical worst case (which is the only thing that matters for real time), an unbounded number of retries makes it impossible to guarantee a maximum time it'd take for a packet to be (successfully) delivered.

  • As stated though: Profinet solves this issue. Also, it is fundamentally not a Modbus protocol problem. – user247243 Mar 19 '18 at 6:06
  • 2
    @user247243: If you're using Profinet then you're not using TCP and not using Modbus/TCP. – Brendan Mar 19 '18 at 6:14
  • innovasic.com/news/industrial-ethernet/… "Industrial Ethernet protocols like PROFINET and EtherCAT modify standard Ethernet in a way to ensure specific manufacturing data is not only correctly sent and received, but also sent and received on-time" en.wikipedia.org/wiki/PROFINET "Three protocol levels are defined: TCP/IP for non time-critical data and the commissioning of a plant[2] with reaction times in the range of 100 ms" Long story short: Profinet is time deterministic ethernet. – user247243 Mar 19 '18 at 7:30
  • @user247243: You are completely changing the question. You say in your comments Modbus/TCP is real-time IFF we assume that all underlying protocols are real-time, deterministic, and reliable, but in your question you say that "I'm not really interested in the real-time attributes of underlying protocols". Well, which is it? Are you interested in the real-time properties of underlying protocols or not? Modbus/TCP is not real-time, because there is nothing in either the Modbus or the TCP protocols that makes it real-time. It is perfectly possible to transport Modbus/TCP over IP and WiFi. – Jörg W Mittag Mar 20 '18 at 8:22
  • 1
    You can't have it both ways. You cannot say you are not interested in the underlying protocol's real-time capabilities and then assume that you are only using protocols that have real-time capabilities. – Jörg W Mittag Mar 20 '18 at 10:45
3

Let's start again!

Under perfect conditions TCP would never need (e.g.) retries and times would be bounded. Under the exact same perfect conditions TCP would also never be needed - it'd be a silly waste of time and you'd just use UDP instead.

Under imperfect conditions TCP is unbounded. In these cases you could set a time-out and pretend that it will either succeed or fail in a bounded amount of time. In practice this is useless. You could say everything in the world is real-time just by slapping time-outs on it and the only thing you'll achieve is that you'll make the words "real time" meaningless. For an extreme example, why bother having a relatively expensive computer when you can use a "real time block of wood" that guarantees everything fails in a bounded amount of time (instantly)?

For all cases that aren't silly, TCP is unbounded.

Note that TCP is non-deterministic in BOTH directions. This means that the master sends a request and after a non-deterministic amount of time the slave eventually receives the request, then the slave can send "Slave Device Busy" back to the master, and after another non-deterministic amount of time the master will receive "Slave Device Busy". The "Slave Device Busy" reply that's built into ModBus just doubles the amount of problems you have with TCP (while solving a completely different problem that has nothing to do with the problem you have with TCP).

Also note that unreliability (including unreliability caused by RF interference, which is relatively common in industrial settings - thankfully the lowest level ethernet frames have a frame check sequence/CRC to detect when a packet was "trashed in transit" and has to be discarded and/or resent) is not the only cause of non-deterministic times. The other cause is congestion. At every point (at the sender, at each router or switch in the middle, and at the receiver) you have queues and your packet can/will sit in these queues for however long it takes for the packet to reach the head of the queue. This is why (e.g.) PROFINET has bandwidth reservation and prioritised scheduling. TCP doesn't have any of this - it just has retries. Note: for the sake of completeness; technically, there's multiple attempts at "quality of service" added to lower layers (the IP layer, the MAC layer) where its all still "best effort with no guarantees".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.