Moxa NPort or an industrial Raspberry? You choose…

A demonstration of how you can replace the Moxa NPort for a Raspberry PI, e.g. during data acquisition from electrometers.

When we need to communicate through a serial interface (e.g. with energy meters, PLCs and so on) using various protocols (Modbus, DLMS/COSEM, IEC 60870-5-101...), we standardly use a Moxa NPort converter.

A practical example of such communication with the use of an NPort converter is shown in this diagram.

The principle of the operation is as follows:

One or more electrometers are connected to the RS-485 serial bus which is connected to the NPort converter. The converter is connected to the Ethernet switch. There is also a computer connected into this network on which the D2000 system runs.

The D2000 KOM communication process sends requests to the NPort converter (using TCP, UDP)  or else writes into the virtual COM port representing the NPort converter. NPort sends received data to a serial line to electrometers. Then, it receives an answer with data which it sends to the KOM process via the Ethernet network.

One NPort can have one to sixteen serial interfaces. So, it also works as a communication concentrator.

Since we started to support Raspberry PI devices starting with the D2000 V12.0 version, the following figure explains the possibility of its practical usage – we can replace the NPort with the Raspberry PI which will work as a remote communication server.

On or more electrometers are connected to RS485 bus  which is now, however, connected to the serial interface of Raspberry PI. In our case, we used the industrial version of Raspberry – NPE X500 from the Techbase company.

If we want to use a standard Raspberry PI, we will have to equip it with an extension using HAT that will implement the RS-485 interface. You can find various renditions on the Internet – simpler or more professional with galvanic isolation. Needless to say, you will pay more for quality J.

The KOM process is configured and running on the NPE X500 – DLMS.KOM in the figure which processes data from the RS485 bus and then sends it via the Ethernet network to the D2000 server.

Unlike the “standard” solution based on the NPort when the KOM process was running as one of the processes on the server, in the configuration with Raspberry PI the KOM process is run on the Raspberry PI which thus serves as a remote communication server.

One of the advantages of such a solution is decreasing of the CPU load of the D2000 server – operation of the KOM process is now handled by the Raspberry PI. In case of configuration with more distributed KOM processes and the use of protocols with higher data flow which are more demanding on the CPU load (e.g. Modbus TCP or Siemens SIMATIC S7 ISO on TCP) it is possible to distribute the load among more communication servers (however, every RPI 3 has a quad-core processor clocked to 1.2 GHz, RPI 3+ up to 1.4 GHz).

Another advantage is speeding communication up (network latency is omitted) and at the same time decreasing the load of a local network (all requests and responses don’t have to go via the network but the KOM process sends only changed data to the server). This might be important in geographically large installations using networks with higher latency and lower throughput. At the same time, this enables to use of a mobile network for creating a virtual network (you can buy the NPE X500 with GPRS, 3G or LTE modem).

The last advantage is that during potential connection outage between the D2000 Kernel and the KOM process, there will be no data loss since the KOM process supports also local data archiving form communication (so-called KOM archive mode). The KOM process can independently read data, store it to disc and after reconnecting, it is possible to “dragged” data on request or the KOM process will send it automatically (depends on the setting of the start parameter /KA).

In the following figure, there is a practical connection of a realized working solution – when using the industrial NPE X500 and two electrometers. Since the NPE X500 configuration, which was available to us, had two serial ports (each could be configured as RS-232 or RS-485), we connected each electrometer to one of them. We used a newer electrometer Iskra and an older Landis&Gyr.

The configuration was as follows:

The port COM1 (more precisely COM4 in the RS-485 mode) was connected to the older electrometer Landis & Gyr ZMD405C with "Short Name" addressing (objects are addressed using 16-bit addresses). The port was on the Raspberry side represented by a logical device /dev/ttyAMA0.

The port COM2 (more precisely COM3 in the RS-485 mode) was connected to the newer electrometer ISKRA MT880 with "Logical Name" addressing (using 6-byte OBIS codes). The port was on the Raspberry side represented by a logical device /dev/ttySC0.

Testing of the KOM archive functionality

We will look at behaviour after the communication loss between the D2000 KOM process and the D2000 Server.

Instead of pulling out cables, we used forbidding of the TCP communication on the Windows firewall (so that we wouldn’t have to run between a server and a workplace where electrometers are and pull out cables form the NPE X500). After forbidding we could see in the CNF tool that the KOM process – from the point of view of the D2000 server – has crashed (state CRASH):

We see the voltage development in the graph – the I/O tag M.DLMS_LG.VoltageL1. On the right side of the figure, there is a clearly visible several-minute-long straight line corresponding with time when the connection loss with the KOM process occurred.

After the KOM process was reconnected, the value in graph continued to “live”:

Understandably, the state of the DLMS.KOM process also changed:

After re-reading data into a graph, we can see the development with the “dragged” data covering the period of outage.

When looking at the data in the table, it is possible to distinguish “dragged” data from the data acquired continuously – this data has the OLDVAL flag. This flag means that these are “old” values which go only to the archive – unlike the current values which are distributed everywhere they’re needed – into diagrams, calculated tags, events, alarm subsystem and so on.

In the KOM process log on the NPE X500 (file /opt/d2000/log/KOM-DLMS.log), it is possible to find information about data sent to the D2000 Server after reconnecting:

Conclusion

In this blog, I tried to demonstrate the possibility to replace the Moxa NPort converter with a remote communication server based on the industrial Raspberry PI – the Techbase NPE X500. This solution enables to decrease the load of the application server as well as load of the network infrastructure.

Moreover, it is possible to use also networks with higher latency (mobile networks) for communication – since communication between the KOM process and the other side is not influenced by the network latency.

The third important advantage is the use of the KOM archive feature that enables to avoid data loss in the case of network problems.