During my professional career, it happened several times to be dealing with Industrial Protocols and in particular to have to develop or test some client that uses Modbus TCP. In particular, the difficulty in the development of the Client was not related to the development itself but to the need of being able to test new software without having to be in the lab (industrial equipment is not really handy to carry around).

The aim of the project is therefore to:

  1. Develop a Modbus TCP server able to respond to requests based on its map;
  2. Simulate real curves in order to allow the client to understand if the server is actually working or not;
  3. Allow a easy programming of the Modbus map without having to touch the code or local files.

High-Level Architecture

The overall system is composed by:

  1. Kubernetes-based containerised software that serves the Modbus TCP server and the configuration tool;
  2. Client which uses a standard browser to command and configure the Modbus TCP server;
  3. Modbus client (e.g. Gateway) that polls for collecting data.
Figure 1) Graphical representation of the system.

Here below some detail regarding the design choices that were taken for designing and implementing said systems.

Figure 2) Design choices taken for Modbus Simulator.

Low-Level Architecture

Modbus Simulator

Here below there is the graphical representation of the containerised software that implements the Modbus Simulator:

  • The system is fully based on kubernetes for container orchestration;
  • All resources are hosted in a single namespace;
  • The configuration is based on a single service and single Pod for a lean and simplified deployment;
  • The service exposes two ports, one for Modbus (502) and one for REST endpoints (5000);
  • Frontend is a Docker container that uses jQuery/HTML/CSS for building a static web-page and Flask for providing access to the page and offer some REST API endpoint;
  • Modbus Simulator is a Docker container that uses PyModbus and Flask to offer respectively the Modbus TCP server and the REST API endpoints for controlling the simulator;
  • Persistent Storage is used by the Modbus Simulator for storing and keeping permanently the configurations (e.g. server status or data points to simulate and offer on Modbus Map).
  • ConfigMaps is used by the Modbus Simulator to get static configs;
  • A load balancer is used for balancing load and routing traffic.
Figure 3) Graphical representation of the Modbus Simulator software.

Frontend

The frontend has been designed with simple HTML, CSS (Bootstrap5) and Javascript/jQuery. Here below the image that shows the various stacks of the code.

Figure 4) Graphical representation of the frontend software layers.

Solution & Architectural Flow

In this section there are the graphical representation and the steps description of the main architectural flows.

Figure 5) Graphical representation of “Web-App” flow.
Figure 6) Graphical representation of “Set Registers” flow.
Figure 7) Graphical representation of “Command” flow.
Figure 8) Graphical representation of “Poll Data” flow.

Results

Here below there are the images and video that show the final result obtained with this project.

Figure 9) Screenshot of the main page after the addition of 4 Modbus Registers.
Figure 10) Screenshot of the modal window that appears when adding a new Register.
Figure 11) Screenshot of the modal window for adding a new Modbus Register, with particular focus on the Modbus Function options.
Figure 12) Screenshot of the main page with particular focus on the bottom part where the server status is visible (Not running).
Figure 13) Screenshot of the main page with particular focus on the bottom part where the server status is visible (Running).
Figure 14) Screenshot of the Kubernetes dashboard where it’s possible to see the logs of the Modbus Simulator container. In particular, it’s possible to see the logs that show the changing Modbus values.

Video 1) Video that shows how the Modbus Simulator works.