PaperlayerView exact revision on arXiv

Source-linked AI summary

A Modular Event-Driven Software Architecture for Open-Source Industrial IoT Edge Gateways

Pei Yu Wong, Thien Tran, Hudyjaya Siswoyo Jo, Jonathan Kua

arXiv:2610.10544v1cs.ARcs.DCcs.SYeess.SY

TL;DR

Legacy industrial devices and cloud platforms use different communication protocols, while open-source SBC gateways require extensive custom configuration. The paper proposes a web-based, event-driven architecture for Modbus-to-MQTT gateway configuration, with localized edge evaluation. Preliminary tests report reduced deployment overhead and stable operation, while the system remains limited to RS-485 connectivity and Modbus-to-MQTT translation.

  • Problem

    Open-source SBC gateways offer a hardware alternative, but deploying them requires custom configuration to bridge legacy serial devices and cloud platforms.

    Source: §I · p. 1

  • Method

    The paper proposes a modular web-based gateway architecture that translates Modbus data to MQTT and evaluates threshold events locally at the edge.

    Source: §I · p. 1, C. Protocol Translation Workflow · p. 3, D. Automated Linkage Event Engine · p. 3

  • Results

    The preliminary evaluation reports reduced deployment overhead, continuous Modbus polling and AWS IoT publishing without packet loss, and low CPU load during bidirectional communication.

    Source: B. Performance and Usability Evaluation · p. 4

  • Takeaways & Limitations

    The authors conclude that localized threshold evaluation supports deterministic response times for critical operations while reducing reliance on cloud processing.

    Source: §IV · p. 4

    The current system depends on RS-485 physical connectivity and translates exclusively between Modbus and MQTT, constraining remote or highly distributed deployment and interoperability.

    Source: §IV · p. 4

Abstract

from arXiv · show

Integrating legacy industrial machinery into modern cloud infrastructures poses a significant software engineering challenge. Industrial Internet of Things (IIoT) deployments frequently rely on rigid and proprietary edge controllers that require extensive manual configuration. Open-source single-board computers (SBCs) offer a highly adaptable hardware alternative, but they still lack standardized software deployment frameworks capable of bridging localized serial protocols with global cloud environments. In this paper, we present a modular event-driven software architecture designed specifically for open-source IIoT edge gateways. We built a containerized web stack to provide a unified architecture that abstracts the complexities of Modbus-to-MQTT protocol translation, enabling rapid configuration of telemetry streams to cloud platforms such as Amazon Web Services (AWS) IoT. Furthermore, we designed a localized event engine that processes conditional logic directly at the edge layer, which significantly reducing network latency. The proposed architecture is preliminarily deployed and validated on an industrial-grade Raspberry Pi Compute Module 4 (CM4) to investigate its robustness, scalability and user-friendliness. Experimental results demonstrate a substantial reduction in system integration time and high operational stability, thus establishing a robust software foundation for real-time edge-based industrial automation. This paper contributes to extending the lifespan of legacy machinery by enabling seamless integration with modern industrial infrastructure.

I. INTRODUCTION

Open-source single-board computers offer a flexible alternative to costly, rigid proprietary controllers, but deploying them requires substantial custom configuration. The paper proposes a GUI-driven, modular gateway architecture to simplify that integration and establish a scalable foundation for edge-cloud orchestration.

I. INTRODUCTION

  • Legacy field devices use deterministic serial protocols such as Modbus RTU, whereas industrial analytics platforms require asynchronous MQTT for large-scale data ingestion.Bridging these network layers is identified as a bottleneck in the transition to smart manufacturing.Source: §I · p. 1
  • Proprietary PLCs and gateways offer high reliability but impose high costs, limited adaptability, and architectural rigidity for SMBs.SBCs offer I/O flexibility and computational power at a fraction of the cost while running full operating systems.Source: §I · p. 1
  • SBC deployment traditionally requires custom code for network setup, serial parsing, and secure cloud handshakes, increasing deployment time and configuration-error risk.These challenges constrain the use of adaptable, lower-cost hardware alternatives.Source: §I · p. 1
  • Prior SBC gateway studies demonstrated Modbus-to-MQTT cloud transmission, but often relied on static operating-system configuration scripts.The proposed architecture's diagram traces data from physical Modbus nodes through application middleware to cloud MQTT brokers.Source: §I · p. 1, Figure 1 · p. 2
  • The GUI-driven architecture abstracts low-level hardware configuration, enabling operators to reconfigure open-source IIoT gateways through a graphical interface.It is proposed as a standardized, scalable foundation for advanced edge-cloud orchestration in industrial automation.Source: §I · pp. 1–2

II. PROPOSED SYSTEM ARCHITECTURE

The proposed gateway separates edge hardware, application middleware, and cloud orchestration into three layers. Field-device data is aggregated and processed at the gateway, then transmitted to the cloud over MQTT.

II. PROPOSED SYSTEM ARCHITECTURE

  • The system architecture is presented as an IIoT edge-gateway design.The paper states that its software and tutorial videos are publicly available.Source: §II · p. 2
  • The architecture separates the gateway into Edge Hardware Interface, Application Middleware, and Cloud Orchestration Layer.The system's software and tutorial videos have been made publicly available.Source: §II · p. 2
  • Industrial field devices connect to the gateway through established fieldbus protocols, and aggregated, processed data is transmitted to the cloud using MQTT.Source: §II · p. 2

A. Hardware Infrastructure

The gateway uses an industrial-grade IRIV PiControl system built around a Raspberry Pi Compute Module 4. Its isolated RS-485 interfaces, dual Gigabit Ethernet ports, and expandable NVMe storage support industrial connectivity and localized buffering.

A. Hardware Infrastructure

B. Application Middleware and Technology Stack

The Application Middleware runs on the CM4 and handles computation, protocol translation, and state management. Its Node.js/Express backend, local MongoDB database, and React dashboard support device polling, persistent configuration, and GUI-based setup.

B. Application Middleware and Technology Stack

  • The Node.js and Express backend handles computation, protocol translation, and state management on the CM4, using an asynchronous event-driven runtime for concurrent I/O.This supports simultaneous polling of multiple RS-485 devices and a persistent WebSocket connection to the cloud.Source: B. Application Middleware and… · p. 2
  • MongoDB stores network parameters, mapped Modbus registers, and user-defined automation rules locally, preserving autonomous operation during severe network partitions.Source: B. Application Middleware and… · p. 2
  • The React web dashboard lets technicians assign I/O roles, define MQTT topics, and adjust scanning intervals without using the Linux command line.Source: B. Application Middleware and… · pp. 2–3

C. Protocol Translation Workflow

The software translates field-device readings from Modbus RTU over RS-485 into structured JSON published to an MQTT broker. In the reverse direction, it converts cloud commands received through MQTT into Modbus writes for physical actuators.

C. Protocol Translation Workflow

  • During uplink polling, the Node.js engine reads registered devices over RS-485 using Modbus RTU, decodes payloads with user-defined function codes, and publishes structured JSON to an MQTT broker.The payload is published under specified Quality of Service parameters.Source: C. Protocol Translation Workflow · p. 3
  • For downlink control, the Node.js client subscribes to MQTT command topics and translates received JSON commands into Modbus writes sent to physical actuators.The passage gives Force Single Coil as an example write command.Source: C. Protocol Translation Workflow · p. 3

D. Automated Linkage Event Engine

The localized linkage event engine evaluates sensor thresholds at the edge rather than sending raw readings to the cloud for simple evaluation. The Node.js backend checks the logic during each polling cycle and triggers a coupled digital output when a threshold is breached.

D. Automated Linkage Event Engine

  • The edge engine is intended to avoid the latency and bandwidth use associated with sending raw sensor data to the cloud for simple threshold evaluation.It supports rapid, autonomous decisions at the edge.Source: D. Automated Linkage Event Engine · p. 3
  • The engine models a sensor’s continuous state and user-defined upper and lower thresholds to determine a coupled digital output’s discrete actuation state.The paper describes this as a finite state evaluation process.Source: D. Automated Linkage Event Engine · p. 3
  • During each polling cycle, the backend evaluates the logic locally and triggers the corresponding output through CM4 GPIO pins when the sensor breaches a threshold.The passage states this is instantaneous and independent of cloud latency for meeting critical safety or operational thresholds.Source: D. Automated Linkage Event Engine · p. 3

III. IMPLEMENTATION AND RESULTS

The implementation and results section introduces structured integration tests simulating an industrial deployment and says that preliminary outcomes are verified and reflected.

III. IMPLEMENTATION AND RESULTS

  • The section frames its evaluation as structured integration tests simulating an industrial deployment, with preliminary outcomes to follow.The passage does not state any specific outcome.Source: §III · p. 3

A. Testbed Configuration

The testbed connects an analog signal simulator and an RS-485 data logger to the IRIV PiControl as a legacy Modbus field-device setup. A laptop-connected dashboard is used to configure the gateway and establish a secured AWS IoT Core connection.

A. Testbed Configuration

  • The physical testbed pairs an analog signal generator with an N4AIA04 RS-485 data logger acting as a legacy Modbus field device that broadcasts fluctuating analog variables.The logger connects to the IRIV PiControl through isolated RS-485 terminals.Source: A. Testbed Configuration · p. 3
  • The testbed integration figure depicts the IRIV PiControl connected to the RS-485 data logger and analog signal generator.This identifies the devices in the physical setup.Source: Figure 2 · p. 3
  • Using a React.js dashboard from an Ethernet-connected laptop, the configuration defines a static IP, maps holding registers, and establishes a TLS 1.2-secured AWS IoT Core connection.The web application figure identifies dashboard, I/O status monitoring, and event logs.Source: A. Testbed Configuration · p. 3, Figure 3 · p. 3

B. Performance and Usability Evaluation

The pilot reduced deployment overhead by allowing technicians to configure the data pipeline through a web GUI. Validation also reported continuous Modbus-to-AWS IoT communication without packet loss and low CPU use.

B. Performance and Usability Evaluation

IV. CONCLUSIONS AND FUTURE WORK

The paper concludes that its event-driven gateway simplifies open-source IIoT deployment and uses localized threshold evaluation for deterministic response times. Its current scope is limited by RS-485 connectivity and Modbus-to-MQTT translation; planned work expands connectivity, security, and distributed automation.

IV. CONCLUSIONS AND FUTURE WORK

  • Localized threshold evaluation provides deterministic response times for critical operations while reducing reliance on cloud processing.Source: §IV · p. 4
  • RS-485 connectivity constrains scalability in remote or highly distributed deployments, and Modbus-to-MQTT-only translation limits interoperability.Source: §IV · p. 4
  • Future work plans LoRa and 4G/5G configuration, edge-framework security, and horizontal scalability using agentic automation protocols.The authors describe dynamic task placement and collaborative decision-making across distributed edge gateways as a future capability.Source: §IV · p. 4
Loading 2610.10544v1…