GMGbox: A Graphical Modeling-Based Protocol Adaptation Engine for Industrial Control Systems

Abstract

The agility and scalability of modern industrial control systems critically depend on seamlessly integrating of heterogeneous field devices. However, this integration is fundamentally hindered at the communication level by the diversity of proprietary industrial protocols, which creates data silos and impedes the implementation of advanced control strategies. To overcome this communication barrier, this paper presents GMGbox, a graphical modeling-based protocol adaptation engine. GMGbox encapsulates protocol parsing and data conversion logic into reusable graphical components, effectively bridging the communication gap between diverse industrial devices and control applications. These components are orchestrated by a graphical modeling program engine that enables codeless protocol configuration and supports dynamic loading of protocol dictionary templates to integrate protocol variants, thereby ensuring high extensibility. Experimental results demonstrate that GMGbox can concurrently and reliably parse multiple heterogeneous industrial communication protocols, such as Mitsubishi MELSEC-QNA, Siemens S7-TCP, and Modbus-TCP. Furthermore, it allows engineers to visually adjust protocol algorithms and parameters online, significantly reducing development complexity and iteration time. The proposed engine provides a flexible and efficient data communication backbone for building reconfigurable industrial control systems.

1. Introduction

The interoperability of heterogeneous industrial devices, constrained by a multitude of proprietary communication protocols, remains a fundamental challenge in realizing the vision of Industry 4.0. Existing research indicates that protocol fragmentation leads to data silos and significantly increases industrial system integration costs. Wang et al. [1] showed that heterogeneous protocol stacks in manufacturing systems impede the integration of large-scale industrial cyber-physical systems. Afrin et al. [2] highlighted that insufficient device compatibility exacerbates system integration complexity, particularly in multi-protocol IIoT environments. This lack of compatibility imposes additional burdens on practical deployment. Hazra et al. [3] further emphasized that the widespread use of proprietary protocols and interfaces by heterogeneous devices in industrial settings results in inconsistent communication semantics, thereby complicating interoperability. For system integrators and plant engineers, configuring and maintaining communication networks and device drivers for numerous Programmable Logic Controllers (PLCs), sensors, and actuators requires substantial engineering effort. Dürkop et al. [4] analyzed the engineering efforts involved in commissioning industrial automation systems. They noted that software-related engineering activities account for 50–60% of the total engineering time, with communication network configuration and process data assignment alone constituting approximately 25% of the total workload. These tasks involve significant complexity, such as the need to use multiple vendor-specific tools and ensure precise matching between device description files and physical components. This “integration tax” directly impedes the agile deployment of advanced applications, from cloud-based control strategies to large-scale sensing networks. While our prior work established a software-defined gateway paradigm [5] that decouples protocol logic from hardware through graphical modeling, the practical realization of this paradigm hinges on a robust and universal core engine. This engine must efficiently translate high-level graphical configurations into reliable, real-time protocol communication capabilities.

Current industrial protocol adaptation methods primarily follow two technical pathways: text-based configuration approaches and modeling approaches based on graphical tools. Text-based methods, represented by structured descriptions, such as eXtensible Markup Language (XML) [6] and JavaScript Object Notation (JSON) [7], have been widely adopted in industrial platforms like PI System [8] and KEPServerEX [9]. Although offering a degree of flexibility, these methods generally lack deep abstraction of protocol semantics and effective validation mechanisms during the design phase. Issues such as offset deviations and field inconsistencies that arise during configuration often only manifest at runtime, significantly increasing debugging and maintenance costs. Graphical tool-based methods encompass general-purpose visual environments like Node-RED [10], as well as some modeling techniques inspired by Model-Driven Engineering (MDE) [11]. While these methods have reduced the usage barrier, their original design focus is primarily on data-flow processing or task logic orchestration. As a result, they struggle to accurately express domain-specific concepts inherent to industrial protocols, such as protocol frame structures, register semantics, and state behaviors. The relevant parsing logic still has to be implemented programmatically via independent nodes, which makes it difficult to meet stringent industrial requirements for determinism, maintainability, and extensibility. Furthermore, the logic constructed by existing tools is mostly static and generally lacks support for runtime modification, flexible adaptation to protocol variants, and online debugging. These limitations become critical in industrial environments characterized by heterogeneous devices and parallel multi-protocol operations.

The above analysis reveals a critical gap in current research; there is an urgent need for an industrial protocol adaptation mechanism that provides unified semantic abstraction, supports intuitive graphical representation, and enables runtime dynamic reconfiguration and debugging. Neither text-based configuration methods nor general-purpose graphical tools can satisfactorily balance the dimensions of protocol semantic modeling, debugging support, runtime reconfigurability, and industrial-grade reliability. To bridge this gap, this paper proposes GMGbox, a graphical modeling-based industrial protocol adaptation engine. By integrating a protocol dictionary, a domain-specific graphical component library, and a cyclically scheduled executor, this engine establishes a unified protocol adaptation mechanism. It thereby achieves protocol semantic abstraction, visual modeling, online debugging, and cycle-driven scan-based execution.

As the core runtime component of the previously proposed gateway architecture, GMGbox is specifically designed to operationalize the software-defined paradigm for industrial communication systems. The main contributions of this work are as follows:

Firstly, a unified protocol dictionary is proposed to provide semantic abstraction and consistent modeling for heterogeneous industrial protocols.

Secondly, a domain-oriented graphical modeling component library is designed, enabling the expression of communication tasks and parsing logic through codeless programming.

Thirdly, a runtime engine is implemented, which maps graphical models into memory, cyclically executes them, and supports online modification and debugging.

Finally, comprehensive experiments validate that the proposed solution achieves improvements in configurability, maintainability, and extensibility.

Collectively, the GMGbox engine presented in this work addresses these challenges. It fills the critical gap left by existing methods by providing a novel technical pathway that integrates protocol semantic modeling, visual construction, and runtime dynamic extension.

Table 1. Comparison of limitations in existing approaches and contributions of this work.

Type	Text-Based Configuration Methods	Graphical Modeling Methods	Contributions of This Work
Protocol Semantic Modeling	Text templates lack semantic abstraction; XML/JSON only describe structure and cannot express field semantics, constraints, or checksum rules	General-purpose graphical tools provide only network or data-flow abstractions (e.g., Node-RED) and cannot represent frame structures, state behaviors, or parsing algorithms	Unified protocol dictionary enabling semantic abstraction and structured representation; Domain-specific semantic components supporting communication tasks, frame parsing, and data processing
Runtime Execution and Debugging	Templates are error-prone and difficult to debug; most issues appear at runtime and require expert analysis	Most tools do not support runtime modification, online debugging, or dynamic variant adaptation	Cycle-driven runtime engine supporting online modification, predictable cyclic execution, and variant adaptation; Graphical modeling enabling visual inspection, debugging, and model reuse

summarizes the limitations of existing methods and the corresponding contributions of this work.

The remainder of this paper is organized as follows. Section 2 introduces the overall architecture of the GMGbox protocol adaptation engine. Section 3 provides an in-depth analysis of the engine’s key technologies, including the protocol dictionary model, the graphical component system, and the program execution engine, and demonstrates the complete protocol adaptation process through a concrete configuration example. Section 4 validates the engine’s multi-protocol processing capability and scalability through experiments. Section 5 evaluates and discusses the proposed method. Finally, Section 6 concludes the paper.

2. Related Work

This work focuses on realizing the core engine for the software-defined gateway paradigm outlined in [5] and systematically reviews the evolution of protocol adaptation implementation techniques. This review spans from text-based configuration methods to graphical and model-driven approaches and aims to analyze their development paths and technical limitations.

2.1. Text-Based Protocol Configuration Methods

To mitigate the rigidity of hard-coded driver architectures, text-based configuration methods enhance system flexibility to some extent by decoupling configuration information from code. Among these methods, XML and JSON, as mainstream data description languages, are widely used to define protocol structures and data-point mappings. For instance, Jiang et al. [6] implemented multi-protocol driver management by defining protocol structures and data mappings entirely in XML. Similarly, Liu et al. [7] employed XML and JSON to define data structures for a service-oriented IIoT gateway, achieving decoupling between configuration and code. The PI System [8], KEPServerEX [9] and Insights Hub [12] similarly rely on text-based templates to specify channels, devices, and tag structures. Although widely used, these text-driven approaches still require manual maintenance of protocol details and provide limited semantic abstraction or runtime debugging support.

However, these methods suffer from inherent limitations, such as complex configuration process, limited semantic expressiveness and poor visibility and debuggability. Text-based methods, while configurable, often translate into a fragile and inefficient development process. The absence of syntactic validation and semantic checking at design time means that errors in XML or JSON files, such as a misplaced tag or an incorrect address offset, are often only discovered at runtime. These errors can lead to communication failures. Furthermore, the static nature of these files makes it impossible to monitor the state of a communication task in real-time or to perform online tuning. This disconnect between the configuration and the operational reality of the control system introduces significant risks and delays during both commissioning and troubleshooting.

2.2. Graphical and Model-Driven Approaches

Graphical and model-driven methods are widely used across industrial automation to simplify system development and introduce higher-level abstractions. However, they provide limited support for protocol parsing and conversion, leaving protocol adaptation without a dedicated graphical solution.

In the Internet of Things (IoT) domain, flow-based programming tools have lowered the development barrier through visual wiring. Node-RED [10] enables device and service integration via node dragging, IFTTT [13] supports conditional trigger–action flows, and Pentaho Data Integration [14] focuses on data-flow processing. In industrial automation, Business Process Model and Notation (BPMN) offers standardized notation for business-process modeling [15]; Scientific Apparatus Makers Association (SAMA) diagrams [16] and International Electrotechnical Commission (IEC) 61131-3 graphical languages such as Function Block Diagram (FBD) and Ladder Diagram (LD) provide established visual representations for control logic [17], and platforms like OpenPLC [18] further extend its application in the IoT domain. Model-Driven Engineering (MDE) enhances system development through formal modeling. Domain-specific modeling languages (DSML) have been proposed for data acquisition architectures and configuration workflows [19]. SimulateIoT-Mobile [20] uses DSML metamodeling to define data acquisition components and their configuration logic of IoT devices. Systems Modeling Language (SysML) [21] support high-level structural and behavioral modeling of manufacturing systems. Recent studies on automated code generation and model transformation [22] bridge platform-independent models and executable logic.

Despite these advances, existing graphical or model-driven tools are not designed for industrial protocol adaptation. Flow-based platforms such as Node-RED [10] expose only generic network and data-flow abstractions and lack unified models for frame structures, parsing rules, or session management for industrial protocols, requiring engineers to manually implement state machines and frame parsers in function nodes or external libraries. IFTTT [13] and PDI [14] target high-level integration rather than field-level communication and do not expose specific parameters of fieldbus or other industrial protocols. Likewise, SAMA diagrams [16] and IEC 61131-3 languages [17] were not designed to describe protocol semantics. Pure MDE approaches offer strong formalism but involve high learning costs, and their generated code often lacks the runtime flexibility required for online debugging and dynamic reconfiguration [23]. These limitations collectively highlight the need for a dedicated graphical modeling framework that balances usability with industrial-grade robustness for protocol adaptation.

Based on the foregoing analysis, this paper designs a protocol adaptation engine based on graphical modeling. This engine draws on the engineering-friendliness of SAMA-style graphic components and is specifically optimized for the flexible parsing and conversion needs of diverse industrial protocols. It addresses a critical gap in the field of industrial protocol adaptation between general-purpose graphical tools and complex model-driven engineering frameworks.

3. Materials and Methods

3.1. Protocol Adaptation Engine Architecture

The GMGbox protocol adaptation engine serves as the core component for implementing the software-defined interoperability paradigm described in our previous research [5]. Residing within the programmable application software layer of the overall gateway architecture, this engine is designed to replace traditional hard-coded protocol drivers with a flexible, configurable, and visually programmable approach.

As shown in Figure 1 (adapted from [5]), the protocol adaptation engine consists of three foundational modules. These modules collaborate with the communication management framework and the embedded database and cache to support the complete protocol-processing workflow. The protocol adaptation engine is responsible for the visual configuration and execution of protocol logic. In contrast, the communication management framework handles connection management, message transmission and reception, and resource scheduling. The functions of the three foundational modules of the protocol adaptation engine are as follows:

• Protocol dictionary library: This module acts as the engine’s knowledge base. It stores standardized JSON-based templates used to abstractly describe the complex details of various industrial protocols, such as instruction structures, packet formats, and semantic rules. By using a unified protocol description model, the library cleanly separates parsing logic from protocol-specific implementations, and it provides structured support for protocol extension. During runtime, communication task components can dynamically query the dictionary library to construct application-layer messages that comply with specifications.
• Graphical modeling component library: This library provides basic graphical units that allow engineers to build protocol-adaptation logic without code programming. It contains standardized, reusable components, each encapsulating a specific function in the communication process. Key components include the device connection component (manages the physical link), communication task component (generates read/write commands), and data parsing & conversion component (extracts and converts values from data frames). The symbols and functions of these components enable engineers to construct complex protocol algorithms via drag-and-drop and connection methods, aligning with the visual programming concept of the SAMA-style function block language.
• Graphical modeling program engine: Acting as the runtime core of the architecture, this module is responsible for dynamically loading the user-constructed graphical protocol algorithm model. The engine parses the dependencies and execution sequence among components within the model and, with precise periodicity, invokes the underlying dynamic library functions bound to each component. This mechanism drives the end-to-end execution of communication tasks, including generating output request commands, parsing input response frames, and updating the results in the shared memory database.

The aforementioned three modules achieve protocol adaptation functionality through close collaboration. Figure 2 illustrates the interrelations among the three core modules of GMGbox. The graphical modeling program engine loads protocol algorithm models generated by the graphical configuration tool, maps them into memory-resident structures, and executes them in fixed cycles. During execution, the engine dynamically invokes domain-specific components such as device connection, communication tasks, and data parsing via the component library interface, enabling on-demand data processing. In parallel, the engine queries the protocol dictionary library for protocol templates and semantic rules based on component parameters, ensuring that generated request frames comply with device specifications and that response data are correctly parsed. Execution results and runtime status are delivered to the embedded database and communication management module for caching, monitoring, and online reconfiguration. Through this layered organization of engine, component library, and protocol dictionary, GMGbox cleanly decouples protocol semantics, component logic, and runtime scheduling while supporting industrial-grade cyclic execution and visual, extensible configuration for automation engineers. As for the automation engineers, they can first select the target protocol components from the graphical component library and configures parameters such as Internet Protocol (IP) addresses, protocol dictionary Identifiers (IDs), memory addresses, and data types to complete their instantiation. These components are then interconnected via logical wiring, ultimately being assembled visually into a complete communication algorithm. Once the generated graphical model is deployed to the program engine, the engine executes according to the model’s scheduling; it queries the dictionary for protocol details, constructs valid request frames, and coordinates the data parsing components to perform data extraction and conversion after receiving responses. Through this modular collaborative mechanism, the engine can enable flexible adaptation to various industrial protocols through configuration, eliminating the need for repetitive coding and thereby achieving the goal of highly scalable industrial interoperability.

The following sections will delve into the technical implementation details of these three core components in sequence.

3.2. Key Technologies of the Protocol Adaptation Engine

The capabilities of the GMGbox engine are driven by the close collaboration of three key technologies: the protocol dictionary model, the graphical component library, and the graphical modeling program engine. This section describes the design and operational mechanisms of each.

3.2.1. Unified Protocol Dictionary Model

When communicating with heterogeneous industrial devices, the data representation format handled by the gateway varies depending on the protocol. Therefore, defining a standard protocol dictionary model is necessary to simplify interoperability between heterogeneous devices and reduce the time investment in developing protocol communication for various devices. For this purpose, the interoperability gateway presented in this paper employs a unified protocol dictionary model, which is invoked and queried by the graphical protocol algorithm programs. Essentially, the protocol dictionary is a type of mapping table describing the contents of a communication protocol. As shown in

Table 2. Unified protocol dictionary model.

Field Name	Description
id	Integer, describes the unique identifier of the protocol dictionary in the system
version	String, describes the version of the protocol dictionary
granularity	Integer, describes the minimum unit of data reading or writing
date	String, describes the update date of the protocol dictionary
protocol	String, describes the name of the protocol used in the system
type	String, describes the physical interface driver type for protocol calls, where 0, 1, and 2 represent serial port User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), respectively
connect	Integer, where 0 indicates an unconnected packet and 1 indicates a connected packet
ascii	Integer, where 1 indicates American Standard Code for Information Interchange (ASCII) type and 0 indicates non-ASCII type
endian	Integer, describes the byte order and identifies the endian type
timeout	Integer, describes the wait time in milliseconds
devDict	JSON object, describes the configuration information for device connections, such as device number, baud rate, data bits, parity bits, stop bits, etc.
connFmt	String, describes the string format of device connection commands
otherFmt	String, describes the string format of other device information
tskDict	JSON object, describes the variables and formats used for task communication when reading or writing data from the device
areaFmt	String, describes the string format for different memory areas of the device
addrFmt	String, describes the string format of the device memory address information
areacode	JSON object, defines arrays to describe the starting addresses and quantities of different memory areas of the device, as well as address increments
packets	JSON object, describes the format of communication protocol data packets, such as defining the structure of read requests, read responses, write requests, and write responses

, it describes the basic characteristics and parameter details of a protocol. It defines the protocol’s ID and allows for the declaration of variable information such as the protocol name, data frame structure, and device memory read/write commands. Some parameters can be custom-configured within the graphical modeling software. Since this mapping table uses a unified set of characteristic fields to describe different protocols, it significantly reduces the difficulty of protocol extension. Furthermore, because the protocol communication bit sequence may contain variable parts or data that require real-time calculation, the protocol mapping table also supports variables, functions, and program flow control logic.

In contrast to the graphical elements introduced earlier, the protocol mapping table itself has no graphical representation. Instead, it is structurally expressed using text-based description languages such as JSON and is used within the gateway as a dictionary for collecting and constructing protocol information. A collection of mapping tables for different protocols forms the collaborative dictionary library.

In the provided structure (Table 2), the packets field is a JSON object whose keys are operation types (e.g., read_req, read_resp) and whose values are template descriptions for the corresponding packet structure. Figure 3 shows an example of the JSON description for the read request and read response packets of the Modbus Communication Protocol Remote Terminal Unit (Modbus RTU). As illustrated in Figure 3, the template includes both fixed byte sequences (e.g., slave address, function code, and Cyclic Redundancy Check (CRC) checksum) and defines the position, length, and data source of variable fields. For instance, the starting address field occupies 2 bytes, and its value originates from the start_address parameter in the communication task component. The data length field occupies 2 bytes, and its value comes from the length parameter. For a complete JSON template example and field-level annotations of the protocol dictionary, please refer to Supplementary Material S1.

3.2.2. Standard Graphical Modeling Components

This study also defines a graphical modeling symbol system (as shown in

Table 3. Symbolic examples of graph modeling components for protocol parsing and data conversion.

Symbol	Description
	A symbol of a device connection component, describing the target communication device information and controlling the device connection status. This component has Digital Input (DI) and Analog Output (AO).
	A symbol of a communication task component, describing communication task information, and creating and managing multiple communication tasks. This component has no input and outputs an analog signal.
	A symbol of a data parsing & conversion component, used to process the data bytes fed back from the device. It converts data bytes into decimal data according to user-input parameters and stores them in a preset data area. This component has both Analog Input (AI) and AO.
	A symbol of a data stream component that is located at a data stream branch and used to elicit a data stream branch.
	A symbol of a data flow component that is located at the end of the data flow and points to the target graph component.
	A symbol of a data flow component that transmits a digital quantity signal and is used to connect two graph components.
	A symbol of a data flow component that transmits an analog signal and is used to connect two graph components.
	A common algorithm component symbol used to generate a numeric signal 0.
	A normal algorithm component symbol. The AI is located on the input side and is used to input the analog signal associated with the engineering data point module. The AO, if located at the output, outputs the analog signal to the associated engineering data point module.
	A normal algorithm component symbol. As an intermediate process component, it is used to transmit analog data. If located at the input end, it is used as AI; if located at the output end, it can assign the result of analog calculations to this component.

). Derived from industrial monitoring and configuration systems, this symbol system plays a central role in the data acquisition process of the interoperability gateway. It provides a configurable and interactive symbolic language for device protocol parsing, data conversion, and analysis. Compatible with modeling language systems used in industrial control configuration systems, it helps establish a unified understanding among participants with different expertise, such as industrial internet development engineers and automation system engineers. This symbolic system comprises five core component types.

(1) Device connection component. In industrial field environments, communication parameters such as device IP addresses are typically preconfigured and remain relatively stable, although they may be adjusted according to production requirements. This component is responsible for defining such information and establishing communication connections with target devices. Configurable parameters include the unique identifier of the engineering device, the unique identifier of the protocol mapping table, the communication cycle determining the gateway’s communication frequency with the device, and the communication IP for device addressing, among others. The input for this component is a Boolean value (1 or 0), representing initiating or terminating a connection to the device. Its output is the number of communication attempts with the device, which increases periodically upon successful connection and remains fixed when the connection is interrupted.

(2) Communication task component. A subset of variable information exists during device data acquisition, such as the data objects, locations, and lengths to be collected. This component is responsible for creating and managing these communication tasks. Its configuration parameters primarily include the unique identifiers for the engineering device and the communication task, data read/write flags, data type, length, and starting address, which serve as input dependencies for the component. Here, the device identifier and task identifier are used to match the device requiring command transmission and to distinguish between multiple concurrent communication task commands, respectively. The read/write flag, length, and data type are used to generate the request command message for the task (key configurations enabling batch reads). After execution, this component outputs the raw message, containing only the data payload after decapsulation.

(3) Data parsing & conversion component. The raw device data message processed by the communication task component requires further processing by data parsing and conversion algorithms to obtain valid data. This component converts specified bytes of the raw data message into decimal data to meet the data display requirements of the recipient. Configurable parameters include the data starting address and bit offset identifying the data’s position within the message, the data type, and the byte order determining the arrangement of data bytes in memory, etc. This component takes the raw data message as input and, after processing by algorithms such as byte format conversion, outputs meaningful natural numbers. Reusing this component enables batch parsing and conversion of multiple data points.

(4) Data flow component. The data flow component describes the data flow between graphical components. It consists of elements such as different types of arrows and connection symbols, used to link two or more graphical components, introduce data flow branches, and transmit digital and analog signals.

(5) Other algorithm components. The graphical modeling component symbol system defined in this study supports the extension of other algorithm components used for data conversion and edge computing processing. These include input/output components, analog setpoint components, integral regulation components, and other mathematical function components, utilized for further processing after data acquisition.

3.2.3. Graph Modeling Program Engine

The graphical modeling program engine serves as the core software module driving the execution of industrial protocol algorithms. Its fundamental operating principle is depicted in Figure 4. The engine employs a fixed memory-mapped data structure to represent the graphical algorithm model, where each configuration element is mapped to a dedicated memory-resident table [24]. Based on this structure, the graphical configuration model can be loaded into the memory table to support both model execution and online modification [25]. Subsequently, a cyclic execution mechanism traverses the records in this memory table according to a configurable period, enabling execution of the graphical logic on resource-constrained industrial controllers. It treats the configuration assembled by the user not as a set of passive parameters but as an active, executable data model. This model, stored in a fixed memory structure, defines the components, their parameters, and the data flow between them. The engine’s scheduler interprets this model cyclically, invoking the corresponding dynamic library functions for each component. When an update request for the algorithm data model is triggered, the engine automatically retrieves the corresponding model data from memory. Following a predefined computation sequence, it sequentially invokes algorithm functions encapsulated within a unified dynamic library, thereby completing the required memory data updates. This mechanism not only fulfills the real-time requirements of periodic data acquisition but also enables flexible adaptation to evolving needs for protocol parsing and conversion in industrial field environments through the dynamic loading of updated algorithm models.

Within the GMGbox system, the core of this engine is a fixed-cycle task loop executor (refer to Figure 4). It first loads the graphical protocol algorithm model deployed by the visual configuration tool. Based on the component dependencies and execution sequence, the executor then activates component instances such as device connections, communication tasks, and data-parsing components. The specific execution flow is as follows. The engine first reads the configuration parameters of the current component (including target IP/port, read/write type, memory area, start address, data length, etc.). It then calls the dynamic library function bound to that component type. Taking the communication task component as an example, its associated dynamic library function is responsible for constructing the protocol instruction data. Using the configuration parameters and the current device connection status, this function queries the protocol dictionary to obtain the required instruction-frame structure. It then dynamically generates a request frame that complies with the target device protocol. Finally, it places the generated data into a designated buffer for processing by the communication management module. Similarly, the engine extracts device response data from the buffer. It performs decoding and conversion according to the graphical protocol model and writes the results to predefined memory addresses. A key aspect of this design lies in encapsulating the algorithmic logic for protocol request construction, data parsing, and conversion within replaceable dynamic libraries. Their execution is driven by the parameter configuration of the graphical components, achieving flexible decoupling between protocol command generation and the underlying engine.

This plugin mechanism based on dynamic libraries enables each graphical component to register its function identifier and configuration parameters in a memory-resident data table. During runtime, the engine scheduler follows a predefined sequence to resolve the corresponding dynamic library function pointers through these function identifiers. The resolved functions can then directly read their required parameters (such as address mappings, data types, and byte-order flags) from designated memory regions for computation. This interface-oriented design effectively decouples the core engine from specific functional algorithms. Consequently, algorithm upgrades and component extensions can be accomplished without recompiling the core engine. Only the corresponding protocol-configuration models (function identifiers, configuration parameters, execution sequence, etc.) and the relevant dynamic-library files need to be replaced or added.

Furthermore, monitoring the real-time values of protocol parsing and conversion within the gateway system is achieved through interaction between the graphical modeling software interface and the memory database. Modifications to communication parameters, protocol-format parsing, and conversion algorithms of the graphical protocol model can be carried out through an online reconfiguration loop program. This loop program is predefined within the graphical modeling engine. This loop program manages the transmission of online modifications to the graphical protocol algorithm data model. It ensures state consistency when updating graphical component parameters during the operation of the control station logic. Specifically, upon detecting an online modification request for the protocol algorithm logic, the engine iterates through the online modification data table. Based on the graphical component’s serial number and address information, it writes the modified data values into memory. The entire process is implemented through address mapping and data transfer, completes within a single logic scan cycle. This ensures that industrial communication remains continuous. This online modification mechanism, based on direct memory operations, allows engineers to dynamically optimize protocol logic without system downtime, significantly enhancing the flexibility and availability of system debugging and maintenance [25].

3.3. Protocol Adaptation Process and Configuration Example

To concretely demonstrate the codeless configuration capability and workflow of the GMGbox engine, this section provides a detailed example of parsing the Modbus-RTU protocol. This example elucidates how the graphical components, protocol dictionary, and execution engine collaborate to accomplish a complete data acquisition task.

3.3.1. Configuration and Execution of Protocol Algorithms

Figure 5 shows an example of a graphical protocol configuration algorithm. The purpose of this protocol algorithm is to collect 10 data points from the holdregs area of a Modbus RTU slave device with node number 1. The device uses serial port/dev/ttyS0, baud rate 9600, 8 data bits, even parity, and 1 stop bit, and the algorithm then parses three specified data values from the result. As shown in Figure 5a, the graphical protocol configuration program uses the standard components introduced in Section 3.2, including digital signal generation, device connection, communication tasks, data parsing, analog output, and data flow, to build a no-code configuration program. During configuration, the engineer specifies the parameters of each component and connects them into a complete protocol algorithm. The configuration files compiled by the graphical configuration algorithm are loaded into the GMGbox protocol adaptation engine. When the engine detects updated configuration data, it triggers the execution of the component algorithms and the operation of other auxiliary gateway modules. In this way, it completes the entire protocol communication and data-parsing process.

Figure 5b illustrates the execution process of this graphical protocol algorithm instance. In this instance, the parameters of the device connection component are configured as follows: device number = 1; dictionary number = 85; communication cycle = 100 ms; serial port number = 0; baud rate = 9600; data bits = 8; parity = 2; stop bits = 1. Based on these parameters, the engine establishes and maintains the serial connection to the target Modbus-RTU device and provides the connection status for subsequent components. Once the device connection component reports a successful connection, the communication task component is activated. Using its configured parameters (e.g., device number = 1, length = 10, slave address = 1, data area = 3 [holding registers], start register address = 1), it queries the protocol dictionary corresponding to this device and constructs the complete Modbus-RTU request data frame: [01 03 00 01 00 0A 94 0D]. This command frame is passed to the communication management module and ultimately transmitted to the target device via serial port/dev/ttyS0. The response frame from the device, containing the values of 10 registers (each 2 bytes), is received by the same communication task component. The component strips the protocol headers and trailers, outputting only the raw data portion (20 bytes) to the subsequent data parsing & conversion component for processing. In this example, three data parsing & conversion components are reused to extract three floating-point values from the 10-register data block. For each component, the start address (e.g., dstart = 3), data type (e.g., type = 7, single-precision floating-point), and byte order are configured. The component then locates the corresponding bytes in the message (e.g., [00 00 80 3F]), performs the necessary format and base conversion (e.g., according to the IEEE 754 standard [26]), and writes the result into the specified memory address. In this way, the real-time values of the selected data elements can be visualized within the graphical modeling environment and are available for online modification and dynamic debugging.

3.3.2. Extension of Protocol Algorithms

Industrial protocols often exist in numerous vendor-specific variants, and extending traditional drivers typically requires modifying low-level parsing code for each new device. To address this challenge, GMGbox introduces a unified extension mechanism in which protocol semantics are externalized through JSON-based dictionary templates and protocol behaviors are constructed using reusable graphical components. When a new protocol variant needs to be integrated, engineers can add or modify dictionary entries and assemble the required parsing logic graphically; the runtime engine then executes the updated model. This design enables hot deployment, reduces code dependency, and ensures consistent execution behavior across heterogeneous devices. Further discussion on the protocol algorithm extension mechanism and its step-by-step configuration guide can be found in the Section 5 and Supplementary Material S1.

4. Results

4.1. Experimental Validation and Case Studies

The primary advantage of the GMGbox engine lies in its ability to seamlessly handle multiple heterogeneous protocols while supporting flexible online expansion and debugging. This section presents experimental results validating these claims, demonstrating the engine’s superiority over traditional driver-based approaches.

4.1.1. Experimental Environment

To validate the performance of the GMGbox core modules, this study established a graphical protocol parsing test platform, as illustrated in Figure 6. The hardware system integrates sensors and controllers from multiple manufacturers, including Omron (Kyoto, Japan), Mitsubishi Electric (Tokyo, Japan), Siemens (Munich, Germany), Schneider Electric (Rueil-Malmaison, France), and WUHAN NENGHUI (Wuhan, China). It also incorporates an industrial gateway, a cloud server, an Industrial PC (IPC) for monitoring, and network communication equipment, collectively forming a comprehensive test environment. The industrial gateway hardware was equipped with Celeron(R) CPU J1900 (x86) and sun8i Cortex-A7 (ARM) chips, with the GMGbox engine integrated. The selected sensors and controllers cover communication protocols commonly found in industrial settings, including Allen-Bradley Common Industrial Protocol (AB CIP), FATEKS Protocol (FATEKS), MELSEC Communication Protocol (MELSEC) series, Modbus series, Omron series, Siemens S7 Communication Protocol (S7) series, Recommended Standard (RS485)/Recommended Standard (RS232), etc. Within this system, the industrial devices are connected to the gateway via Ethernet. The data communication between the gateway, the IPC, and the cloud server is facilitated over the Internet. The IPC runs the graphical modeling and configuration software and is responsible for the system’s graphical configuration and operational monitoring.

4.1.2. Functional Unit Testing for Graphical Protocol Parsing

To systematically evaluate the core functional characteristics of the GMGbox gateway, comprehensive functional unit testing was conducted based on the test platform. The testing scope covered key dimensions including heterogeneous protocol communication interfaces, graphical configuration management, component parameter configuration, real-time protocol data monitoring, and online debugging. During the testing process, the accompanying graphical modeling and configuration software was used to deploy protocol algorithms and configure parameters. The core test modules and representative cases are shown in

Table 4. Test function modules and content.

ID	Function Module	Test Content
1	Heterogeneous protocol compatibility	Support for industrial protocols including AB CIP, FATEKS, MELSEC series, Modbus series, Omron series, Siemens S7 series, RS485/RS232, etc.
2	Graphical configuration management	Configuration template loading, parameter initialization, custom configuration of protocol parsing components (device connection parameters, communication task parameters, data parsing parameters), algorithm editing, and visual debugging.
3	Protocol data monitoring	Dynamic monitoring of communication link parameters, real-time data value refresh, memory mapping status monitoring.

and

Table 5. Example of the test cases for graphical component parameter configuration.

ID	Test Item	Test Method and Content	Expected Result
1	Data start address configuration	Modify the data start address parameter of the parsing component and verify parsing accuracy	Data parsed correctly
2	Data transfer length configuration	Adjust the data transfer length parameter and verify data integrity	Data parsed correctly
3	Data type configuration	Change the data type parameter and verify data conversion accuracy	Data parsed correctly

, respectively.

The test results indicate that the GMGbox protocol adaptation engine possesses robust heterogeneous protocol compatibility and reliable data processing capabilities. It supports mainstream industrial protocols such as AB CIP, Modbus, Siemens S7, and RS485/RS232, enabling accurate parsing of multi-source heterogeneous device data and ensuring transmission stability. Regarding configuration flexibility, the system supports the visual configuration of protocol parsing algorithms and communication parameters, and offers capabilities for real-time data monitoring, online configuration updates, and visual debugging. In terms of system performance, the gateway was tested at a 20 Hz sampling frequency and executed 1000 consecutive acquisition tasks. It achieved a data-acquisition success rate of 99.9%, demonstrating excellent real-time performance and operational reliability in typical industrial scenarios. Detailed test results are summarized in

Table 6. Functional unit test results.

ID	Function Module	Test Result
1	Heterogeneous protocol communication interface	Successfully loaded multiple protocol communication programs (AB CIP, FATEKS, Hostlink Communication Protocol (Hostlink), MELSEC-QNA/FX2N/FX3U/FX422, Mewtocol Protocol (Mewtocol), Modbus-ASCII/RTU/TCP, OMRON HostLink/Factory Interface Network Service (Fins) UDP, Siemens S7/S7x series, RS485/RS232, etc.), established communication with heterogeneous devices, and correctly parsed various heterogeneous industrial protocol data.
2	Protocol algorithm graphical configuration management and communication parameter configuration	Supports custom configuration or modification of protocol parsing component parameters, completing the entire process from graphical configuration editing and compilation of protocol algorithms to downloading and execution by the gateway’s protocol adaptation engine.
3	Real-time monitoring of parsed protocol data	Supports monitoring real-time values of graphical protocol parsing components, online modification, transfer, and visual debugging of algorithm configuration logic, and enables reading and monitoring of real-time parsed data.

. Through systematic functional unit testing, this study validates the comprehensive advantages of the GMGbox protocol adaptation engine in terms of protocol compatibility, configuration flexibility, and system reliability, providing a technical basis for its practical deployment in the industrial control field.

4.1.3. Performance Evaluation of the Protocol Adaptation Engine

To evaluate the operational efficiency and resource overhead of the proposed protocol adaptation engine in real industrial scenarios, this study conducted performance tests on an ARM architecture-based gateway. The tests involved acquisition tasks for 100 data points from both a Modbus TCP slave device and a MELSEC-QNA protocol PLC. The average communication cycle and the average CPU and memory idle rates were recorded (Figure 7).

As shown in Figure 7a, the GMGbox maintained a stable average communication cycle of approximately 300 ms in the Modbus TCP scenario. Although this design introduces some scheduling and parsing overhead compared with XML-based configuration or manual coding, the overall response latency remains within the acceptable range for industrial monitoring systems such as SCADA. When executing the 100-point acquisition tasks for both Modbus TCP and MELSEC-QNA protocols under the same hardware conditions, the communication cycles and resource usage for both protocols were similar, demonstrating no significant runtime performance fluctuations due to protocol differences (Figure 7b). Overall, the protocol adaptation engine exhibits stable periodic behavior and controllable resource consumption on resource-constrained embedded industrial gateways, meeting the requirements for communication timeliness and reliability in industrial field environments.

4.1.4. Multi-Protocol Parsing Capability

To evaluate the concurrent parsing capability of the GMGbox protocol adaptation engine in a heterogeneous environment, this study constructed a test system (as shown in Figure 8, integrating more types of devices compared with [5]). The system integrates a NENGHUI NH206WS-type temperature and humidity sensor (Modbus-RTU/RS485, WUHAN NENGHUI, Wuhan, China), a Mitsubishi Q03UDE (MELSEC-QNA protocol, Mitsubishi Electric, Tokyo, Japan), a Siemens S7-1200 (S7-TCP, Siemens, Munich, Germany), and a Schneider BME PLC (Modbus-TCP, Schneider Electric, Rueil-Malmaison, France) simultaneously. The objective was to validate its ability to synchronously parse and convert multiple heterogeneous protocols under the established graphical configuration. During testing, device connection, communication task, and data parsing components were instantiated for the four types of devices, respectively, using the graphical modeling software. This model was compiled and deployed for execution on the GMGbox engine. The experimental results demonstrate that the engine has successfully achieved parallel parsing of multiple protocols. By executing algorithm programs for the Modbus-RTU/RS485, MELSEC-QNA, S7-TCP, and Modbus-TCPs, it correctly parsed real-time data of different types, including Boolean, Integer and Float values. The parsed results were then displayed and monitored in an integrated manner on a unified interface (Figure 8). These results validate the effectiveness and flexibility of the described protocol adaptation engine in heterogeneous protocol integration and data normalization. They also confirm its key capability as a core component of the software-defined gateway.

4.1.5. Protocol Extension and Online Debugging

To validate the dynamic extension capability and online debugging functionality of the protocol adaptation engine, this study designed an online protocol algorithm reconfiguration experiment. The experimental platform consisted of a Schneider BME PLC (Modbus-TCP), a Mitsubishi Q03UDE PLC (MELSEC-QNA protocol), and an Omron NJ301 PLC (Fins-UDP protocol). To facilitate observation of data state changes, each PLC was preloaded with data simulation programs generating periodic waveforms. In the initial stage, the gateway loaded the graphical protocol algorithms for the Schneider and Mitsubishi PLCs, with the data acquisition cycle set to 500 ms. Figure 9 shows that the gateway accurately acquired the sine wave and trapezoidal wave data, verifying the correctness of the initial parsing logic.

Subsequently, the protocol algorithm model for the Omron PLC was added online via the graphical modeling software. Parameters such as the device address, dictionary identifier, read/write length, memory area, and start address were configured dynamically. After passing syntax verification, the updated algorithm model was hot-deployed into the running gateway engine. Figure 9 presents the data monitoring results after the protocol extension. Compared with the state before reconfiguration, the visual monitoring interface has successfully displayed a new square wave data stream from the Omron PLC. All three data streams were parsed accurately by the engine and demonstrated excellent stability throughout the transmission process.

It is noteworthy that, thanks to the software-defined modular architecture, this entire protocol extension was achieved without modifying core source code or restarting the system. The dynamic algorithm reconfiguration was accomplished solely through graphical configuration and parameter adjustments, fully demonstrating the engine’s flexibility and engineering practicality in protocol adaptation.

In practice, the GMGbox protocol adaptation engine developed in this study has been successfully deployed in the Supervisory Control and Data Acquisition (SCADA) monitoring system of a large-scale underground wastewater treatment plant [5]. Practical evidence demonstrates that the engine significantly enhances data-integration efficiency and maintenance agility when adapting to process adjustments and equipment upgrades. It also provides foundational technical support for the continuous evolution of control systems in complex industrial environments.

5. Discussion

5.1. Comparative Analysis with General-Purpose Graphical Tools

The architectural advantages of the proposed GMGbox engine can be more clearly understood by contrasting it with the general-purpose graphical tool Node-RED (

Table 7. Technical comparison between the GMGbox engine and Node-RED for industrial protocol adaptation.

Comparison Item	Node-RED	Proposed GMGbox
Protocol abstraction model	Lacks a native unified model. Protocol details (e.g., frame structure, checksum) are hardcoded within community-provided nodes or custom Function nodes.	Provides a unified protocol dictionary model based on JSON templates. Structures the description of instruction formats, packet layouts, and semantic rules, decoupling them from the parsing algorithm execution logic.
Component semantic granularity	Provides general-purpose functional nodes (e.g., tcp in/out, function, switch). Their abstraction level remains at data flow and generic functions.	Provides domain-specific components (e.g., Device Connection, Communication Task, Data Parsing & Conversion). Components directly correspond to semantic units of industrial communication.
Execution engine kernel	Employs an event-driven paradigm. Periodic tasks are simulated intervals or polling settings of specific protocol nodes, triggered by timer events.	Employs a cycle-driven paradigm, executing based on in-memory scheduling. The engine kernel actively scans and executes the graphical algorithm model at fixed intervals.
Debugging & update granularity	Provides flow-level online debugging and hot-reloading, allowing inspection of messages passed between generic nodes. Internal logic of industrial protocol nodes is encapsulated, limiting dynamic adjustment.	Possesses component-level online visual debugging and hot-updating capabilities for algorithm models. Enables real-time monitoring of inputs/outputs for each component (e.g., Data Parsing component) and modification of its parameters or logic.

). While Node-RED excels in IoT-oriented integration tasks, its flow-based programming paradigm is not inherently designed for industrial protocol semantics. Protocol details are typically embedded in JavaScript-based function nodes or community-developed custom nodes, making protocol extension dependent on code-level modification.

GMGbox adopts a fundamentally different approach. A unified JSON-based protocol dictionary externalizes protocol semantics, while a domain-specific component library encapsulates key industrial concepts such as device connection, communication tasks, and data parsing. Engineers therefore configure behavior through industrial abstractions (e.g., register access) rather than constructing state machines or byte-level parsing logic inside generic nodes. This reduces configuration complexity and lowers the likelihood of errors.

The execution mechanisms of the two systems also differ. Node-RED relies on an event-driven kernel, with periodic tasks simulated by timer events. GMGbox employs a cycle-driven kernel that performs a scan-based cyclic, execution of graphical models. This aligns is well-suited for implementing periodic device polling and data acquisition.

Dynamic debugging and updating further highlight the contrast. Although Node-RED supports flow-level debugging and hot reloading, the internal logic of protocol-processing nodes cannot be modified at runtime. GMGbox, in contrast, provides component-level monitoring and online parameter adjustment. Updates are written to an in-memory data model, enabling new protocol logic to take effect within a single scan cycle. This capability is essential for industrial environments where interruptions are not acceptable.

Overall, GMGbox shifts protocol adaptation from code-based implementation to a model-driven workflow. As reported in [5], the unified dictionary, reusable component library, and online-debugging support significantly reduce development and maintenance effort for Modbus RTU/TCP variants. The results demonstrate why domain-specific architectures fundamentally outperform general-purpose graphical tools for industrial protocol/data integration.

5.2. Robustness Comparison with Traditional Extension Methods

GMGbox’s unified extension mechanism can overcome the robustness issues inherent in traditional driver-extension workflows. As summarized in

Table 8. Comparison of protocol extension methods in terms of extensibility and robustness.

Method	Extension Process	Runtime Update	Robustness Issues
XML/JSON configuration	Edit schema and update driver logic	None	Fragile configs, runtime-only error detection
Node-RED custom nodes	Develop new JS node; embed protocol logic	Limited	No unified abstraction; lacks scan-based cyclic execution
GMGbox (proposed)	Add dictionary and graphical model	Hot deployment	High robustness, unified abstraction

, methods based on XML/JSON configuration or schema files still depend on manually written parsing code, making them relatively sensitive to offset errors, boundary mismatches, and incomplete field definitions. Because such tools lack semantic validation and runtime feedback, configuration problems often remain invisible until execution, leading to unreliable behavior. In addition, their extension paths are inconsistent; introducing a new protocol variant typically requires modifying multiple code and schema components, increasing both maintenance effort and the probability of inconsistent behavior across devices.

Flow-based tools also face robustness challenges. Their extensibility relies on custom nodes whose internal parsing logic and timing behavior are not standardized. Under mixed-protocol workloads, this event-driven execution model makes it difficult to guarantee strict fixed intervals or end-to-end latencies, which can increase the risk of timing deviations and inconsistent parsing outcomes. Because node-level behavior is typically implemented as JavaScript functions and depends on the specific runtime environment, debugging and verifying that behavior remains consistent across different deployment environments becomes more challenging.

GMGbox narrows these robustness gaps through a unified and controlled extension workflow. Protocol semantics are externalized into a structured dictionary with consistent field definitions, reducing misalignment errors. Parsing behavior is composed from domain-specific components whose execution semantics are governed by the cycle-driven runtime engine, ensuring timing regardless of protocol variation. Finally, extensions are applied via hot deployment, with updated dictionary entries and component parameters taking effect within one scan cycle. This provides predictable runtime evolution without system interruption.

Collectively, these architectural properties deliver a more reliable, repeatable and extension process compared with traditional configuration-driven or code-based approaches.

5.3. Cross-Industry Transferability Analysis

Although the experimental evaluation in this study focuses on representative industrial communication scenarios, the architectural properties of GMGbox exhibit strong cross-industry transferability. Industrial protocols in sectors such as process control, discrete manufacturing, energy systems, and building automation commonly have similar structural features including register addressing, data frames, cyclic acquisition patterns, and vendor-specific semantic constraints.

GMGbox abstracts these features through its protocol dictionary and encapsulates communication behavior into reusable graphical components. New protocols or device variants can therefore be integrated by updating dictionary templates and component parameters, without modifying the engine kernel. The cycle-driven runtime and memory-resident execution model ensure stable behavior under varying loads, while the separation of semantics, component logic, and scheduling minimizes system dependencies. These characteristics provide effective evidence of the system’s robustness and scalability across heterogeneous industrial environments.

5.4. Limitations and Future Directions

Despite its flexibility and practicality, GMGbox still has several limitations. First, the protocol dictionary requires engineers to manually construct JSON templates based on vendor documentation, and proprietary or insufficiently documented protocols may need additional verification. Second, although GMGbox is compatible with mainstream PLC, DCS, and SCADA architectures, systems with closed communication stacks or vendor-specific transmission mechanisms may require additional adaptation modules. Third, GMGbox does not provide automatic handling of entirely unknown protocols.

Future work will focus on three directions: (1) using machine learning and large language models to automatically extract protocol semantics from vendor documents; (2) further optimizing the transmission-adaptation layer to accommodate specific proprietary communication stacks; and (3) exploring pattern-based semi-automatic modeling techniques to infer field boundaries, length patterns, and encoding rules from sample messages, enhancing adaptability to undocumented or newly introduced protocols.

6. Conclusions

This paper presents a systematic description of the design and implementation of the GMGbox protocol adaptation engine based on graphical modeling. As the core implementation of the software-defined interoperability gateway paradigm [5], GMGbox successfully translates the theoretical advantages of graphical modeling into a practical industrial tool for protocol parsing and conversion.

The main technical innovations of this research include three aspects. Firstly, we propose a unified protocol dictionary model based on JSON templates, which provides structured abstraction of heterogeneous protocol details and significantly reduces the complexity of protocol extension. Secondly, we develop a SAMA-style graphical component system that covers core functions such as device connection, communication tasks, and data parsing, thereby enabling a complete codeless development mechanism for protocol algorithms. Thirdly, we design a universal graphical program-execution engine that supports dynamic loading, real-time processing, and online debugging of protocol algorithms, while maintaining industrial-grade operational reliability.

Experimental evaluations demonstrated that GMGbox can concurrently parse diverse protocols such as MELSEC-QNA, S7-TCP, Modbus TCP/RTU, and FINS/UDP while supporting hot deployment, online debugging, and real-time reconfiguration. These capabilities substantially improve the flexibility and maintainability of industrial data-integration workflows. Overall, GMGbox provides a practical and reusable model-driven solution for industrial interoperability, reducing engineering effort and enabling rapid adaptation to evolving field communication requirements. The architecture demonstrates vast application potential in industrial control scenarios that demand scalable and maintainable protocol integration.