Modbus is indeed a very old (late 1970s) protocol that was created for the communication between among programmable logic controllers, PLC. It is based on a master/slave relation. That means a device acting as master, polls slave devices to read or write information. Registers are data storage repository defined with a register reference address and are slave specific only. Old Modbus implementations are based on serial communication, but today with the spread of network based communication, Modbus also evolved to be operated on TCP/IP networks. Arrow supports TCP based modbus operations, so this document will be restricted to only network side of modbus protocol and focused on Arrow operation.

Similar to other client/server applications, modbus master sends out a request to slave address with a specific function code, register number and count. This requests inform the slave about information to be received by master. The request and response is very similar to each other and are in the following format.

There are different types of register. Function code defines what type of register information exchange will be triggered. The most common function belongs to the operation of “reading holding registers”, and it is 3 (three). This function allows the master to request one or more holding register stored values. Similarly code 16 is used to write into holding registers.

Arrow is built to relay information between two security zones with different level of criticality. MODBUS slave devices, are usually used to store and use information in an operating environmnet consisting of machinery, production tools, manufacturing and processing engines and analysis systems. Since the information is not only used to provide metrics but also to inform the tools or machines about their operation, no external manipulating device should reside in this critical production environment. So the risk with any externally connected device is not acceptable. Yet the information created in this environment can possess crucial value for business flows, and is required to be transferred out for further processing.

This is where Arrow gets into the picture. Arrow speaks with modbus slaves (PLC, machines, tools etc.), retrieve the information and sends this information to its twin sister into corporate IT network, where information is processed into more readable and valuable format.

Here is a simple illustration of how Arrow works in a modbus environment:

Figure 1 – Simple production environment, where modbus data is read from PLC and sends out analysis tools

Arrow architecture is based on separate services, and modbus is one of IOT services that turns the receiving end device (guardian) into a modbus master. Arrow Guardian polls the slave devices, receives register values, and sends to other end pair (postman) using its very own transfer technologies. On the other network Arrow Postman, receives information, and creates a virtual modbus slave to provide information for IT side modbus masters. Other infomration exchange methods can be implemented to share modbus retrieved informations, thanks to ArrowOS, flexible architecture. For each slave device to read information on Guardian side, there exists a virtual device to relay it in the Postman side.

Flow of information retrieval and sharing is visualized in the following illustration:

Figure 2 – Steps to retrieve information and share with external tools

Here are the steps for the information relay process:

1. Modbus request from Arrow Guardian to PLC sent, with proper function code to read holding register, port and address infomation of slave TCP server.
2. Modbus reply from PLC sent back to Guardian. If there are any error on slave side, this error would also sent back to Guardian.
3. Guardian holds a table of registers information. There is also a mapping for actual PLC’s in Guardian side, to virtual PLC’s in Postman side.
4. Guardian sends out all the received register and PLC informations to Postman.
5. Postman holds this information in the matching registers of virtual PLC devices, created inside its operating system. For each actual PLC in Guardian side, Postman creates a slave instance, to be accessed by external master pollers. Only the last information for a specific register is holding, and while a new infomation received, it is overwritten. Slaves remains active as long as it is defined in Guardian side as virtual devices. A master device sends request to Postman virtual device, pretty much the same way Guardian sends to actual PLC’s
6. Upon receiving the request from external master pollers, Postman replies with relevant informations.
7. To access different virtual devices, masters need to send separate requests. Different masters may request information from different virtual devices.
8. Each request is handled by Postman separately, and replied back. Any error condition, such as wrong register requests, is also handled by Postman.

For more information on how to configure Arrow devices for modbus operation, please follow this link to access modbus configuration guide.

Arrow basic modbus process creates a simulated modbus network by starting virtual devices on Postman side. Every PLC would have its shadow copy on unrestricted network, allowing data stored in the actual PLC device to be accessible by business or reporting tools while keeping it safe from tampering.

Arrow Guardian is responsible with reading data from individual modbus slaves, encapsulate into a transferrable format and send it to Postman from the fiber interconnection. Last information is stored in Postman memory for a period of refresh time interval defined in Guardian IOT settings menu. Neither Guardian nor Postman writes the retrieved information into a permanent datastore, preventing any data leak. Data requester ask register informations from Postman using standart Modbus protocol. If Guardian stops sending information for one modbus slave, Postman also stops providing this information and return relevant error codes.

In case a virtual PLC device is removed from rule sets defined in Guardian “Data Collect” menu, this virtual device will be removed from Postman and unaccessible error code would return if any receiver tries to ask information from this virtual device.

You can create up to 20 virtual devices per pair. This number will be increased in following versions.

Angora way of managing a product is to keep it simple, and request as few as possible input from users and administrator. Arrow is no exception to that mentality. There are only couple of parameters to be defined if only needed to change from default values.

IOT Settings menu includes, timer parameters that may be needed to tune based on specific deployments.

Parameter	Description
Modbus data retrieval interval	Time interval that Guardian asks slave devices about current register values. This changes the latest data information in Guardian
Modbus query timeout	Time interval that Guardian checks if there are any rule changes in data collection set
Data sending interval	Time interval for Guardian to send data to Postman. This value would be better match with modbus data retrieval to keep both sides synchronized.

Arrow modbus operation consists of couple of steps. First you must add modbus supported devices from add/remove devices menu. Then you must create virtual devices to simulate physical devices on Guardian at the Postman side. Please keep in mind that physical devices are always residing behind Guardian, and their simulated shadow, virtual devices are running on Postman.

After both side devices are ok, you should create mappings from data collect menu. Optionally you can tune transfer parameters from IOT settings. Please follow next sections to find out about details of device creation and rule sets.

There should be a shadow of physical modbus slaves to simulate the same behavior in Postman side, where open access is allowed. Virtual Devices have no register parameters and number of registers and information stored are always as the physical device that is mapped from data collect menu.

Virtual Devices menu item is used to create and configure. There is only two field to define. First is the name which is basically a description for the virtual device. Second is the port number to be used in Postman side. Requests from Postman sides should sent to Postman IP address using this port number. Port number should be between 1501 and 1520. Currently only 20 modbus is supported, while more will be available in next releases.

All existing virtual devices can be shown by clicking the blue button. You can also find out what is the physical device mapping to a virtual device by simply clicking the “👁️‍🗨️” button. You can also remove a virtual device if there is no mapping in the data sets. You will receive an error and not be allowed to remove it if there is a mapping.

Modbus slave devices can be added using IOT/Scada > Device Add/Remove menu

There you can add new devices, remove existing and check if there is any information received from this device.

There are five text fields that should be filled to add a device. Mandatory informations of device name, IP address and port must be provided. Although model and description is optional, it is recommended to have this information to distinguish devices from each other.

It is expected by nature that IP/Port pairs should be unique. If you are trying to add the same pair of IP/Port informations, you will get an error prompt.

Added devices are listed in a tabulated format within the Device List. Click the blue button to show the list.