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?
Best Answer
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.