Arrow Modbus protocol handling

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.