Add new IP to BACRouter

We are often faced with third-party devices in the field whose IP cannot be modified and whose IP is not in the same subnet as the BACRouter or other BIP devices.
The solution already in place is to add an IP router, which will result in increased cost and complexity.
Usually we only need the BACRouter to communicate with this third party device using Modbus TCP or BACnet IP protocol, so the easiest way is to add an IP to the BACRouter dedicated to communicate with this device

For example, local IP subnet is 192.168.100.0/24,  BACRouter’s IP is 192.168.100.1;  Third-party device has a IP of 172.16.1.20, its netmask is 255.255.255.0

We will add IP of 172.16.1.1 to BACRouter
Original /etc/rc.local:

root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

cd /root
./webui&
exit 0

Modify /etc/rc.local: (vi is available too)

root@OpenWrt:~# cat>/etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

ifconfig br-lan:1 172.16.1.1 netmask 255.255.255.0
cd /root
./webui&
exit 0
CTRL+D

The ifconfig command will create a br-lan:1 interface with IP 172.16.1.1; if we connect to the third-party device by BIP protocol, we have to add new interface to BACRouter configuration.

Original /root/resource.conf:

~#cat /root/resource.conf
{ “eth0”: { “type”: “ETH”, “ifname”: “br-lan” }, “RS485-1”: { “type”: “USB”, “ifname”: “0:0” }, “RS485-2”: { “type”: “USB”, “ifname”: “0:1” } }

Modify /root/resource.conf: (vi is available too)

~#cat >/root/resource.conf
{ “eth0”: { “type”: “ETH”, “ifname”: “br-lan” }, “eth1”:{“type”:”ETH”, “ifname”:”br-lan:1″}, “RS485-1”: { “type”: “USB”, “ifname”: “0:0” }, “RS485-2”: { “type”: “USB”, “ifname”: “0:1” } }
CTRL+D

now restart BACRouter!

Upgrade underlayer firmware of BACRouter

BACRouter’s software is based on OpenWRT. The version of OpenWRT we used has never been upgraded since 2016. Security auditors complain the dropbear server’s vulnerabilities, though those vulnerabilities can not be utilized based on our evaluation.

However, we decided to switch to OpenWRT v19.07.10, which released on Apr 20, 2022. For existing users who want to upgrade, please follow those steps:

1.  Download OpenWRT upgrade file

2.  Upgrade BACRouter from WebUI’s “Upgrade Firmware”.  It will take 2~3 minutes. Be careful, all settings will be lost, including IP

3.  Open “http://192.168.100.1” by Web browser, the page will likes:

4. Select whatever version BACRouter firmware file, then click “upgrade”, the page will show:

5. Refresh page after one minute, the WebUI will come back, then restore settings from backup.

 

Convert BASgatewayLX CSV Configuration To BACRouter JSON

BASgatewayLX (Hereinafter referred to as LX) supports CSV configuration file. There are decent documents about the format and dozens of configuration samples for vary devices on their website. The convert tool we provided could convert the CSV file to JSON file which could be imported in BACRounter’s WebUI to create a Modbus slave station.

Convert on our website

Download and extract it to disk, open index.html by your web browser

Matters need attention:

Though LX claims the object name should be unique, but the accessory “Profile Checker” does not check duplicated object name. We found a lots duplicated object names in the samples. So we decided to disable object with duplicated name in converting.

Some CSV files have characters out of UTF8 code page, we guess they are ISO-8859-1 encoding. So if we fail to decode CSV by UTF8, we fall back to ISO-8859-1.

LX supports maximum 64 bytes of object name and description (With ISO-8859-1 encoding?). BACRouter supports 64 bytes too, but with UTF8 encoding. There has possibility that 64 bytes in ISO-8859-1 is larger than 64 bytes when encoding as UTF8. We will tail-cut too long name and description and promote to user.

BACRouter doesn’t allow 2 output objects mapped to overlapped Modbus address, but LX seems to allow it. We will disable the conflicted object in converting.

LX defines register order for every 32 bits data, but BACRouter has to set unitary byte order for all objects. If the consistent byte order definitions are found when converting, the previous definition will be accepted, the conflict will be promoted to user.

BACRouter has object instance range of 0~999 for every slave, but LX seems no limitation. If instance larger than 999 is found, the object will be auto assigned a new instance.

Max_info_frames by token occupy time

From firmware ver2.0, BACRouter introduced new “Max_info_frames by token occupy time” feature.

In BACnet standard of MSTP, a master device could hold token until it has sent frames up to Max_info_frames. The default value of Max_info_frames is 1. But for router, this value may be increased to improve bandwidth between networks. Mostly the suggested value for router is between 5 to 20.

MSTP works as a field bus for controllers; sensors and actuators. The data exchanging latency between devices usually should be guaranteed.  We recommend devices get token at least every 1 second.

The APDUs passing router usually have size between 10~50 bytes, but could be up to 480 or 1476 (Extended frame). Larger APDU need more time to send or receive.

For APDU which need a reply from targeted device, router has to wait for reply. Usually the targeted device need more time to handle or generate larger APDU, router has to wait longer.

So the time router holding token could be varied much, which impacts latency guaranty of MSTP bus. To avoid this problem, “Max_info_frames by token occupy time” feature limits router’s token holding time.

The limitation is calculated by:

byte_time * 32 * Max_info_frames

For example, Max_info_frames is set to 10. The baud rate is 76800bps, so the byte_time is 0.13 milliseconds:

0.13 * 32 * 10 = 41.6 milliseconds.

When router founds it have held token for 41.6 milliseconds, it passes token to next station, though the frames it sent may be less than 10.

This feature could be enabled/disabled by user from WebUI.

BACRouter benchmark for routing between BIP and Ethernet

The intent of this benchmark is to investigate the capability of BACRouter. Because of low baudrate of MSTP, there is not a bottleneck on routing packet to/from MSTP network.

BACRouter support 10/100M Ethernet interface, so there will be a challenge to flood it. The testing machine is a Notebook with i7 2.8G 4 cores CPU and 1000M Ethernet card, directly connected to BACRouter with CAT5+ cable. The result is:

PathAPDU size in byteMax routing rate without packet drop
(per second)
Routing rate in packet flooding
(per second)
Packet flood rate
(per second)
BIP->Ethernet41320035479087
7508980611113500
1476552038006832
Ethernet->BIP4101001138113000
7508090603011895
1476611055426526

When BACRouter is flooded by small packets, the handling capability dramatically decreased, especially in BIP port.

On 2019-04-16, We made new benchmark on firmware version 2.18, with a new testing machine( i5 4 core CPU and 1000M Ethernet card). the result is:

PathAPDU size in byteMax routing rate without packet drop
(per second)
Routing rate in packet flooding
(per second)
Packet flood rate
(per second)
BIP->Ethernet415300188768705
75010300864513005
1476630054247179
Ethernet->BIP4127501937111358
75010300864012281
1476730073107453

The performance is improved much with new firmware.