M-Bus via TCP and UDP

M-Bus is a standard most commonly associated with serial communication, but in today’s connected world, M-Bus is increasingly used over Ethernet via TCP and UDP. However, it is surprising that the standard lacks guidelines on how these messages should be handled in network environments, particularly in critical systems such as SCADA and billing systems. This can lead to communication problems, especially when TCP’s built-in retransmission mechanisms clash with the timeout settings of SCADA systems. How can we avoid these pitfalls and ensure stable and secure data transmission?

Despite M-Bus being an established standard within serial communication, it is puzzling that it offers no guidance on how M-Bus messages should be handled over Ethernet, specifically via TCP or UDP. This is particularly relevant because many modern systems, such as SCADA systems and other critical infrastructures, for example, billing, now often communicate via Ethernet networks.

In these systems, meters and other sensors are often connected through some form of concentrator or gateway that acts as an intermediary. These gateways collect data not only from wired M-Bus devices but, in some cases, also from wireless M-Bus meters. This raises an important question: How secure and stable is the information that is collected and transmitted?

One reason to discuss this is that when communication occurs over a network with varying stability, TCP appears to be a reliable solution. TCP ensures that messages are delivered by automatically retransmitting them if necessary. This sounds good on paper, but in practice, it can lead to unexpected issues.

SCADA systems often have a timeout setting of a few seconds to ensure that a response is returned within a reasonable time. If the response does not arrive on time, the system will attempt one or more retries. Meanwhile, TCP might also retransmit messages that have not been delivered. However, these parallel retransmission processes can fall out of sync, as the SCADA system may not always correctly match requests and responses. This creates a risk where the SCADA system might receive an outdated or delayed response from TCP that it no longer expects, potentially leading to incorrect decisions or actions.

To avoid these problems, a robust solution is to introduce a transaction ID into the communication. This allows the SCADA system to match each response with the correct request, eliminating the risk of interpreting an old response as a new one. This type of identification is what differentiates, for example, Modbus TCP from Modbus RTU.

Without a transaction ID or some other form of identification, the SCADA system cannot determine whether a response belongs to the current request or a previous request that has already timed out. This could lead to the system mistakenly treating old responses as new ones, which could have serious consequences in critical systems.

An alternative to TCP, when a transaction ID is missing, as in standard M-Bus, is to use UDP. Unlike TCP, UDP is a connectionless protocol, which means it does not reorder or retransmit packets. When using UDP, one can essentially revert to the serial mechanisms since both serial communication and UDP are connectionless.

A few years ago, I began to examine these issues more closely. I have seen the problems these issues can cause, such as false alarms and more. During that time, I also developed the specification and table shown above.

Please feel free to send an email if you have any comments, requests, etc.