In recent years, world of communication is ruled by the Internet Protocol stack and RS232-based interfaces are generally considered obsolete. Typical SCADA device life cycle is nevertheless long enough to guarantee demand for good old serial interfaces for several years from now. Common RS232 to TCP (UDP) converters can help in some cases by creating the required number of transparent peer-to-peer connections from all remote serial ports to the corresponding (physical or virtual) ports in the data center. However such solution requires a special routing arrangement in the center, hence it is not always feasible. A typical SCADA Front End Processor (the central interface of the application to the communication network) uses a proprietary protocol over a single RS232 interface. Each message coming out from the FEP is addressed and should be delivered to the designated remote serial port. Certainly a transparent broadcasting to all remotes could do the job, making the service provider happy (assuming the resulting bills are paid). Obviously the proper solution is to transmit the message to the destination address only.
A SCADA serial protocol typically uses simple 8 or 16 bit addressing. The mobile network address scheme is an IP network, where the range is defined by the service provider (sometimes including individual addresses, even in the case of a private APN). Consequently a mechanism of translation between the SCADA and the IP addresses is required. To make things worse, IP addresses may be assigned to GPRS (EDGE, UMTS, etc.) devices dynamically upon each connection.
This chapter describes how to efficiently solve this problem using RACOM made routers.
Two basic situations are described:
The M!DGE/MG102i IP addresses are reachable from each other in both directions. This can either mean that you have the private APN with the own IP subnet for your application. Or it can mean that all routers have static public IP addresses. The example in Section 4.1, “SCADA Protocols – private APN” shows the routers’ configuration using the private APN with static addresses.
The M!DGE/MG102i IP addresses are NOT reachable in both directions – only the center is reachable from the remote side. The center must have a static public IP address. The remote units (slaves in the Master-Slave configuration) can have private and dynamic IP addresses. Utilization of VPN tunnels is required. See the example Section 4.2, “SCADA Protocols – public APN” for more details.
In the INTERFACES – Mobile – Interfaces menu, configure the private APN as defined by your service provider.
Once established, you can check the connection status in the HOME menu.
Configure other units with the appropriate credentials. In our example the Master M!DGE obtained the IP address 10.203.3.28 and the remote M!DGE units have 10.203.3.33 and 10.203.3.34.
Our example will explain the Modbus Master-slave configuration with two slave units. On the Master station, select the INTERFACES – Serial menu and set the Protocol server option.
Configure the correct RS232 parameters such as baud rate, stop bits, …
Configuration within the Port Settings – Server configuration is only usable with Device server option, but we configure Protocol server. You can ignore the settings here.
Go to the Protocol server menu and configure the Master parameters. Focus on the correct Address translation. You can either use mask or table for this purpose. If in doubts, open the Help window via the button located on top right corner. This Help explains the whole Protocol server functionality.
In the example below, the Master translates addresses A and B (hex) into IP addresses (and vice versa) 10.203.3.33, resp. 10.203.3.34. Using the port 8882 is mandatory if the remote device is connected via M!DGE RS232 interface.
The Slave configuration is very straightforward. You just set the Modbus Mode to “slave” and the rest is solved by the Protocol server.
In case that you encounter any issue, you can read the Protocol Server Help which is reachable from the right top corner of the page. Sending the issue description to our technical support at email@example.com is possible. Please try to include the following information:
The issue description (together with topology, required technology, …)
Please increase the debug level of rrsp2 daemon first (SYSTEM – Troubleshooting – System Debugging – Debug Levels – set rrsp2 to “4”). When applied, try to run your application and then download the Tech Support package (can be downloaded from the SYSTEM – Troubleshooting – Tech Support menu).
You can also include the WWAN interface monitoring output: SYSTEM – Troubleshooting – Network debugging – tcpdump – Set interface to “wwan1” and check all the “Exclude” boxes. Click start, run your application and after a while, stop the tcpdump again and download the file.
It is not possible to monitor the serial interface in M!DGE/MG102i.
With the public APN, you need to have a public and static IP address in the center. In our example, we configure the APN to be “internet.open.s” so we obtain the required IP address.
The remote stations can be configured with the most basic APN, e.g. “internet” to obtain the private and dynamic IP address. In the next section, we will configure the VPN tunnel which is necessary for this kind of connection. Without the tunnel, the serial communication will be blocked within the mobile network.
In this example, we configure the OpenVPN tunnel in the routed mode. See Section 2.1.1, “OpenVPN – Routed mode” for configuration details. The only difference is that we do not need to configure any VPN connected networks on any M!DGE unit, we just use the fixed tunnel addresses for serial data communication.
The clients can be then configured just via the Expert files downloaded from the Master M!DGE. The first client will obtain 10.8.0.6 tunnel address and the second client 10.8.0.10.
The configuration is the same as explained with the Private APN , but replace the IP addresses.
Now we are finished, but due to Protocol server configuration, we need to disable source IP control mechanism, because IP addresses are changed due to using VPN tunnel. This needs to be done via SSH access to the M!DGE unit. Login as root using the same password as for the web administrator access and run the following command:
$ vi /etc/config/factory-config.cfg
The configuration file will be opened. Find the line with
and change the last digit to “0” (press the button “i” to enter editor)
Press “ESC” button and close the file by typing “:x”. Then run the command
$ rm /etc/rrconf/rrsp2.cfg
and reboot the unit via the command
After the unit boots up, you have finished the Master configuration.
The Slave must be connected via the OpenVPN tunnel to the Master and its Protocol server must be configured to the Modbus – Slave mode.
The troubleshooting is the same as explained in the Section 4.1.4, “Troubleshooting”.
If your server is using TCP connection, configure the Device server instead of Protocol server and set the Mode to “TCP Raw” with the appropriate TCP port.