Sometimes it happens that the M-Bus bus can only be connected to the control system via an Ethernet network. The designer – or in the worst case, the project manager – then looks for “some converter from M-Bus to Ethernet”. Let’s see how this problem could be solved with the Domat PLC and what the advantages and risks of this solution are.
The PaPouch company supplies M-Bus/Ethernet converters from the Swedish company PiiGAB to the Czech market. We can choose from PiiGAB 820 models for 5 to 250 M-Bus devices. The converters work by “unpacking” the serial M-Bus/Ethernet telegrams sent by the client from the TCP or UDP packet and sending them to the M-Bus bus. The response from the meter is then "packaged" again into a TCP or UDP packet and communicated over the Ethernet network with the counterparty – a TCP or UDP client.
Setting up the PiiGAB converter is very simple: in addition to the standard network settings (IP address, network mask, default gateway), It is only necessary to set the speed on the M-Bus interface and check which transport protocol we will use for transmission – UDP or TCP. The connectionless UDP protocol is simpler, the UDP port number can be chosen arbitrarily, but for the sake of standardization, let's leave the default, 10001:
More interesting is the setting on the client side, in the converter R035.
First of all, we need to select the UDP Sockets functional profile in the basic settings. This will open the settings in the image. We must also ensure that the data that comes over the serial line (RS485) from the PLC is sent over the network using the UDP protocol to the PiiGAB converter. This is ensured by the routing table in the UDP Client Settings section. In our case, PiiGAB has the address 192.168.1.142 and the entry in the table corresponds to this. As another parameter in the entry, the UDP port (here 10001) is also entered to which the data should be sent - and on which PiiGAB listens.
The M-Bus channel setting in the PLC is standard, the PLC does not even know that the data is not directly over the serial line, but travels part of the way over the Ethernet network. The speed and other communication parameters must correspond to the settings in R035. With regard to service, we recommend setting the serial parameters incl. parity the same as on the M-Bus side of the PiiGAB converter, although theoretically it does not matter.
As we can see in the Ethernet communication statement, the R035 converter (with address 192.168.1.99) forwards M-Bus queries to the PiiGAB IP address, port 10001. Wireshark reveals that the M-Bus query (5 bytes) is the only data content in the UDP packet, no other data is added to the telegram. The response is returned back to the R035 on UDP port 2101. We can easily test the communication without a PLC, with any M-Bus client connected from a computer via a serial port to the RS485 interface of the R035 converter. Meter detection also works – the screenshot was taken during communication with the MBCONF program (downloadable at www.relay.de).
After importing the meters into Domat IDE, we can see the values from water meters, electricity meters or calorimeters, as when directly connecting an M-Bus serial converter to a PLC serial port.
What to watch out for from a cybersecurity perspective? Neither UDP nor TCP connections are encrypted in any way, the converters do not care which device is connected to them. It is therefore necessary to operate the device in a closed network, which can only be accessed ideally via VPN. When using manageable switches, it is recommended to limit access to the device only from the necessary IP addresses (the other converter, the configuration PC) and block access to the converter configuration websites. For the PiiGAB converter, we recommend disabling the NFC interface.
Why is it necessary to use the R035 converter? Couldn't we communicate via UDP directly from the PLC - it also has a network card? Unfortunately, this is not possible today, the M-Bus protocol transmission via TCP or UDP is not yet implemented in the runtime.
Could it be possible to connect multiple M-Bus/Ethernet converters to the network and read data from their meters via one R035? Theoretically yes, you just need to expand the table in the R035 settings to include additional destinations. Queries will then be sent to multiple PiiGAB converters at the same time, but the answer will only be returned from the one to which the meter with the appropriate address is connected?
Does the transition to Ethernet allow multiple clients to read data from meters? The data is serialized on the network and this would solve the frequent problem of sharing data from meters between multiple systems! Theoretically yes, but we would have to ensure that the reading frequency was low enough to prevent the M-Bus bus from becoming overloaded, or ensure that one client reads for several minutes, for example, a whole hour and another a whole + 30 minutes. In the case of TCP, the converter is able to handle a maximum of 2 connections, with UDP this is not relevant and we only deal with time collisions or the throughput of the M-Bus bus. In any case, more clients represent a possible hazard that could lead to communication failures, and therefore each such solution needs to be well thought out from the perspective of all communication layers.
