This document provides functional descriptions to modbus related Arrow options, as well as configuration steps, required to provision modbus service for Arrow devices.

Modbus protocol is widely used in manufacturing environment such as automative industry, energy conversion plants, machinery networks and other industrial environments. Data generated within production zones, are now becoming more and more relevant for the business process management and optimization. Although modbus protocols is relatively old, it is still the de-facto protocol to share data within production related environments, thanks to evolved structure of the protocol with TCP support. Supervisory Control and Data Acquisition, shortly SCADA systems, are using information from different data generation, to mostly control the production processes. Evolving business flows requires information from every aspect of production tools. This data then used to analyse the efficiency, quality and performance of overall processes as part of lifecycle managements. This is why it is crucially important to transfer the data from production environment for further analysis, while keeping the machinery network isolated from any incoming threats.

For more information about MODBUS protocol, please follow this wikipedia link.

How MODBUS works?

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.

Device Address

Function Code

Register Number

Register Count

Data

Checksum

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.

How Arrow MODBUS feature works ?

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.