Communication terminal decoupling architecture based on message bus and dynamic library loading

Abstract

The invention provides a communication terminal decoupling architecture based on message bus and dynamic library loading. The architecture comprises a module message theme, bus message theme management and module dynamic loading. According to the module message theme, a message theme system is constructed based on a Pub / Sub mode, and all module data sets are abstractly packaged into a structured theme; the bus message theme management is that a bus dynamically creates a routing table of a double linked list structure in priority ranking based on a message theme submitted by a module when the module is loaded, the bus inserts subscriber information into the routing table and adjusts the ranking, and the bus traverses the routing table when the theme information is published to sequentially complete data synchronization with a subscriber; the module dynamic loading refers to loading the module into a system bus in a mode of abstracting the module as an independent functional unit into a so library, and realizing decoupling cooperation with the bus through a standardized interface; according to the architecture, an application program bus is responsible for managing and routing theme information, data synchronization is achieved between modules through a message bus to achieve decoupling, and decoupling is achieved between the modules and the bus through a standardized interface.

Description

Technical Field

[0001] This invention relates to the field of Linux embedded communication terminal equipment technology in the power industry, specifically a decoupled architecture for communication terminals based on message bus and dynamic library loading. Background Technology

[0002] With the rapid development of the power industry and the acceleration of its digital transformation, the number of peripherals and protocols that need to be integrated into communication terminals has surged, such as sensors, 4G / 5G communication modules, edge controller devices, relay protection devices, and protocols such as IEC61850 and DL / T. Traditional embedded architectures, such as 860, Modbus, and MQTT, face four major problems: 1) Strong coupling: Peripheral drivers are deeply bound to business logic, and adding new peripherals requires modifying core code, resulting in long iteration cycles; 2) Difficult testing: Modules cannot be tested independently and require building a complete system environment; 3) Poor dynamism: Modules are statically compiled, and adding new functions requires complete recompilation, which does not support hot updates; 4) Insufficient real-time performance: Polling / interrupt mechanisms are prone to resource contention in multi-protocol concurrent scenarios, and high-priority task response delays are difficult to meet hard real-time requirements. To address these issues, the applicant proposes a decoupled communication terminal architecture based on message bus and dynamic library loading. Each module is connected to the system as a SO dynamic library, and data synchronization between modules is achieved through a message topic publish-subscribe model. This effectively decouples modules, improves dynamism, enables hot-plugging, and meets real-time requirements, providing a highly reliable and easily maintainable embedded software architecture for the construction of new power system communication terminals. Summary of the Invention

[0003] To address the aforementioned technical issues, this invention proposes a decoupled communication terminal architecture based on a message bus and dynamic library loading. Through module message topics, module loading and subscription management, and sub-module dynamic libraries, each module accesses the system as an SO dynamic library. Data synchronization between modules is achieved through a message topic publish-subscribe model. This effectively decouples modules, improves dynamism, enables hot-swapping, and meets real-time requirements, providing a highly reliable and easily maintainable embedded software architecture for the construction of new power system communication terminals.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A decoupled communication terminal architecture based on message bus and dynamic library loading is characterized by the following: The architecture includes module message topics, bus message topic management, and module dynamic loading; the module message topics are constructed based on the Pub / Sub model, abstracting and encapsulating all module datasets into structured topics; the bus message topic management involves the bus dynamically creating a priority-ordered doubly linked list routing table based on the message topics submitted by the module during module loading, and the bus inserts subscriber information into the routing table and adjusts the order; when publishing topic information, the bus traverses the routing table to sequentially complete data synchronization with subscribers; the module dynamic loading refers to the module being loaded into the system bus as an independent functional unit abstracted as an SO library, achieving decoupled collaboration with the bus through standardized interfaces; each submodule in the architecture is abstracted and encapsulated as an SO library. When the SO library is loaded, it declares its own topic information and the topic information to be subscribed to. The application bus is responsible for managing and routing the topic information. In this way, modules achieve data synchronization and decoupling through the message bus. In addition, because the SO library can abstract standardized interfaces and can be dynamically loaded / unloaded, it does not depend on the implementation of the message bus, thus achieving decoupling between modules and the bus.

[0005] Furthermore, the module message topics in the decoupled communication terminal architecture based on message bus and dynamic library loading are equipped with hierarchical naming, access control, and message topic formatting structure. The hierarchical naming and access control module topic information adopts a three-level naming structure, divided into: publisher, operation type, and receiver. The first field identifies the publisher of the message topic and controls the information flow; the second field identifies the action name and defines the communication behavior; and the third field identifies the message receiver or data type. This three-level naming method controls the information flow through the publisher information in the first field, allowing the direction to be from the bus to the module or vice versa. Other modules use single-level or multi-level wildcards for management. The system has a theme, enabling communication between the bus and modules, as well as between modules. The theme information of the message theme format structure adopts a structured data format, specifically JSON data format, and includes the following core points: metadata and payload levels. The payload node transmits both raw data and operation logic function pointers, achieving integrated encapsulation of data and processing logic. When the 4G submodule is loaded into the system, it registers the message theme MODULE_4G / DATA with the bus. The bus creates a subscription list for this theme information. Other submodules can obtain the 4G module's business data and function operation set by subscribing to this theme information, thereby achieving data synchronization.

[0006] Furthermore, the module loading and subscription management of the communication terminal decoupled architecture based on message bus and dynamic library loading includes creating a subscriber management table and a routing subscriber management table. The creation of the subscriber management table occurs when the system dynamically loads a module's SO library; the module registers a message topic with the bus, and the bus dynamically creates a linked list as the subscriber management table. Then, subscriber information is added to the linked list according to the subscriber's subscription priority. The subscriber management table structure is as follows: Topic mapping; each message topic corresponds to an independent doubly linked list of subscribers; Dynamic table creation: The bus dynamically creates a subscriber management table for each topic, which is implemented as a priority-sorted doubly linked list. The linked list nodes are arranged in descending order according to the subscription priority, and the nodes are linked in a closed loop through predecessor and successor pointers. At the same time, in order to improve the real-time performance of the system, the same message topic can create subscriber management tables with three priority types: high, medium and low. Each priority management table has a built-in descending sorting. Dynamic expansion mechanism; each module's SO library declares the message topic set that the module needs to publish and the message topic set that it needs to subscribe to. When loading a module, the bus inserts the subscriber node into the corresponding position in the corresponding topic list. When unloading, the corresponding subscriber node information is deleted from the list. The routing subscriber management table is used when a module in the system publishes topic information. The bus matches the topic and obtains the corresponding subscription list, traverses the routing list, and asynchronously executes the subscriber callback function to complete data synchronization. This ensures that high-priority subscribers receive information first to guarantee real-time performance, while also ensuring zero data loss during transmission. The core mechanism of the routing management table is as follows: Topic matching; the bus parses the published topic information structure and obtains all subscription list information for that topic; Priority traversal; the bus scans the subscriber list in a chain at a fixed refresh rate. Each subscriber node is accessed sequentially along the successor pointer, and the information of the subscriber node with the highest priority is automatically obtained. Synchronizing data information: The system extracts the callback functions registered by each subscription node and executes them asynchronously through a thread pool to achieve data synchronization between modules. The refresh frequency of the bus determines the data synchronization latency and the real-time performance of the system.

[0007] Furthermore, the sub-module dynamic library in the decoupled architecture of the communication terminal based on message bus and dynamic library loading is specifically designed such that sub-modules are abstracted as independent functional units and loaded into the system bus, and then decoupled collaboration is achieved through standardized interfaces. The data types of the sub-modules mainly include three categories: data acquisition class responsible for real-time data acquisition and push, action operation class responsible for instruction reception and hardware driving, and protocol class responsible for protocol conversion and transparent transmission. Different functional modules with different roles emphasize different data types, specifically: 1) Role function encapsulation; Data Producer - Sensor Class: Only publishes messages to data acquisition topics; Instruction Executor - Execution Class: Only subscribes to action operation topic messages; Data Processor - Protocol Class: Both publishes and subscribes to data collection and protocol class topic messages; 2) Standardized library interfaces; When a dynamic library is loaded into the bus system, modules can be "hot-swapped" into / out of the system through a standardized interface. At the same time, the implementation details of the modules are independent of the bus, enabling bidirectional decoupling. The module's metadata drives the implementation from static declaration to dynamic construction. The communication metadata information of the dynamic library includes the module's unique identifier, published topic sets, and subscribed topic sets. When the system loads the so library, the core message topic is constructed through module_init().

[0008] The benefits of this application are: 1. The decoupled architecture of the communication terminal based on message bus and dynamic library loading is abstracted into a so dynamic library and loaded into the bus system through a dynamic linker to realize the "hot-swappable" function of sub-modules. Adding or deleting functional modules does not require recompiling the program or restarting the system. 2. The communication terminal decoupled architecture based on message bus and dynamic library loading allows each module to access the system as a SO dynamic library. Data synchronization between modules is achieved through a message topic publish-subscribe model, which effectively decouples modules, improves dynamism, enables hot-swapping, and meets real-time requirements. 3. The decoupled architecture of communication terminals based on message bus and dynamic library loading establishes a differentiated scheduling mechanism by configuring priority attributes for subscribers, ensuring that sub-modules with high real-time requirements receive data synchronization first. 4. The communication terminal decoupling architecture based on message bus and dynamic library loading effectively solves the pain points of poor scalability, insufficient real-time performance, and high operation and maintenance costs faced by the industry by decoupling the peripheral management and communication mechanism of power terminal equipment. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the architecture of the present invention; Figure 2 This is a schematic diagram of the data synchronization performance test results of the present invention. Detailed Implementation

[0010] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments: like Figure 1-2The diagram illustrates a decoupled communication terminal architecture based on a message bus and dynamic library loading. This architecture includes module message topics, bus message topic management, and module dynamic loading. The module message topics are constructed based on a Pub / Sub model, abstracting and encapsulating all module datasets into structured topics. The bus message topic management involves the bus dynamically creating a priority-ordered doubly linked list routing table based on the message topics submitted by the module during module loading. The bus inserts subscriber information into the routing table and adjusts the order. When publishing topic information, the bus traverses the routing table to sequentially complete data synchronization with subscribers. Module dynamic loading refers to the module loading process... Independent functional units are abstracted as SO libraries and loaded into the system bus, achieving decoupling and collaboration with the bus through standardized interfaces. In this architecture, the application bus is responsible for managing and routing topic information. Modules are decoupled from each other through data synchronization via a message bus, while modules are decoupled from the bus through standardized interfaces. The communication terminal decoupling architecture based on message bus and dynamic library loading establishes a differentiated scheduling mechanism by configuring priority attributes for subscribers, ensuring that sub-modules with high real-time requirements receive data synchronization first. Modules are abstracted as SO dynamic libraries and loaded into the bus system through a dynamic linker, realizing the "hot-swappable" function of sub-modules. Adding or deleting functional modules does not require recompiling the program or restarting the system.

[0011] The module message topics in the decoupled communication terminal architecture based on message bus and dynamic library loading, as shown, feature hierarchical naming, access control, and message topic formatting. The hierarchical naming and access control module topic information uses a three-level structured naming method, divided into: publisher, operation type, and receiver. The first field identifies the publisher of the message topic and controls the information flow; the second field identifies the action name and defines the communication behavior; the third field identifies the message receiver or data type. Example: MODULE_4G / OPS represents the data subject of the 4G module operation function set; MODULE_4G / P2P / {MODULE_ID} represents the data topic for communication between the 4G module and other modules; BUS / CMD / MODULE_4G indicates the topic of the BUS downlink to the 4G module; BUS / BROADCAST indicates the topic broadcast by the BUS bus to all sub-modules; The three-level naming scheme shown controls the information flow through the publisher information in the first field, from bus to module or from module to bus. Other modules use single or multiple layers, and wildcards manage all topics, thus enabling communication between the bus and modules, as well as between modules. The topic information in the message topic formatting structure shown adopts a structured data format, specifically JSON data format, and includes the following core points: metadata and payload levels. The metadata level sets the publisher, timestamp, and qos fields, whose functional descriptions are publisher identifier, UNIX timestamp, and service quality level, respectively. Their example values ​​are "module_4g_0001", 1720000000, and 1, respectively. The payload level shown sets the data, processes, and ops fields, whose functional descriptions are raw business data, function pointers for associated processing logic, and a set of module local operation callback functions, respectively. Their example values ​​are "[1,3,0,0,0,1,121,134]", "module_4g_handler", and "[4g_write, 4g_read, [4g_reset]”; The Payload node transmits raw data and operation logic function pointers simultaneously, realizing integrated encapsulation of data and processing logic. When the 4G submodule is loaded into the system, it registers the message topic MODULE_4G / DATA with the bus. The bus will create a subscription list for this topic information. Other submodules can obtain the 4G module's service data and function operation set by subscribing to this topic information, thereby achieving data synchronization.

[0012] The decoupled communication terminal architecture based on message bus and dynamic library loading, as shown, includes module loading and subscription management with the creation of a subscriber management table and a routing subscriber management table. The creation of the subscriber management table is as follows: when the system dynamically loads a module's SO library, the module registers a message topic with the bus, and the bus dynamically creates a linked list as the subscriber management table. Then, subscriber information is added to the linked list according to the subscriber's subscription priority. The structure of the subscriber management table is as follows: Topic mapping; each topic corresponds to an independent doubly linked list of subscribers; Dynamic table creation: The bus dynamically creates a subscriber management table for each topic, implemented as a priority-sorted doubly linked list. The linked list nodes are arranged in descending order of subscription priority, with the highest priority node at the head of the linked list. The nodes are linked in a closed loop through predecessor and successor pointers. At the same time, to improve the real-time performance of the system, the same message topic can create subscriber management tables with three priority types: high, medium, and low. Each priority management table has a built-in descending sorting. Dynamic expansion mechanism; each module's SO library contains the message topic set published by the module itself and the message topic set subscribed to. When loading a module, the bus inserts the subscriber node into the corresponding topic list according to its priority sorting position. When unloading, the corresponding subscriber node information is deleted from the list. The route subscriber management table shown is used when a module in the system publishes topic information. The bus matches the topic and obtains the corresponding subscription list, traverses the route list, and asynchronously executes the subscriber callback function to complete data synchronization. This ensures that high-priority subscribers receive information first to guarantee real-time performance, while also ensuring zero data loss during transmission. The core mechanism of the route management table is as follows: Topic matching; the bus parses the published topic information structure and expands the wildcard rules to obtain all subscription list information for that topic; Priority traversal: The bus scans the subscriber list in a chain at a fixed refresh rate, typically 1kHz. Each subscriber node in the list is accessed sequentially along the successor pointer, and the information of the subscriber node with the highest priority is automatically obtained. Taking the topic information "{MODULE_4G} / P2P" as an example, the purpose of this topic information is to forward the data received by the 4G module to other modules for parsing and processing. After the bus obtains the subscriber node information of the 4G module through chain scanning, the node information contains priority order information. Then, data synchronization between the subscribers is further completed, thereby realizing priority traversal. Synchronize data information; extract the callback functions registered by each subscription node, and execute the callback functions asynchronously through a thread pool to achieve data synchronization between the bus and modules, as well as between modules. The refresh frequency of the bus determines the data synchronization latency and the real-time performance of the system.

[0013] The decoupled architecture of the communication terminal based on message bus and dynamic library loading, as shown, involves sub-module dynamic libraries that are abstracted as independent functional units and loaded into the system bus. Decoupling and collaboration are then achieved through standardized interfaces. The data types of the sub-modules mainly include three categories: data collection classes responsible for real-time data acquisition and push; action operation classes responsible for command reception and hardware driving; and protocol classes responsible for protocol conversion and transparent transmission. Different functional modules emphasize different data types, specifically: 1) Role function encapsulation; Data Producer - Sensor Class: Only publishes messages to the Data Collection class topic; Instruction Executor - Execution Class: Only subscribes to action operation topic messages; Data Processor - Protocol Class: Both publishes and subscribes to data collection and protocol class topic messages; 2) Standardized library interfaces; When a dynamic library is loaded into the bus system, modules can be "hot-plugged" into / out of the system through a standardized interface. Simultaneously, the module's implementation details are independent of the bus, enabling bidirectional decoupling. The module's metadata drives the implementation from static declaration to dynamic construction. The dynamic library's communication metadata includes the module's unique identifier, published topic sets, and subscribed topic sets. When the system loads the .so library, the core message topic is dynamically constructed using `module_init()`. Its standard interface functions are as follows: 1) module_init(bus_handle, ModuleMetadata* meta) is used to initialize the module, register topics with the bus, and build a subscription management table. The call direction is: bus → module. 2) `publish(topic, data)` is used to publish a topic message. The call direction is: module → bus. 3) `subscribe(topic, cb)`: This function subscribes to a topic and binds a callback. The call direction is: module → bus. 4) on_message(topic, data) is used to push messages from the bus to the module. The calling direction is: bus → module.

[0014] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any modifications or equivalent changes made based on the technical essence of the present invention shall still fall within the scope of protection claimed by the present invention.

Claims

1. A decoupled communication terminal architecture based on message bus and dynamic library loading, characterized in that: The decoupled communication terminal architecture based on message bus and dynamic library loading includes module message topics, bus message topic management, and module dynamic loading. The module message topics are constructed based on a Pub / Sub model, abstracting and encapsulating all module datasets into structured topics. The bus message topic management dynamically creates a priority-ordered doubly linked list routing table based on the message topics submitted by the module during module loading. The bus inserts subscriber information into the routing table and adjusts the order. When publishing topic information, the bus traverses the routing table to sequentially complete data synchronization with subscribers. Module dynamic loading refers to modules being loaded into the system bus as independent functional units abstracted as SO libraries, achieving decoupled collaboration with the bus through standardized interfaces. In this architecture, each submodule is abstracted and encapsulated as an SO library. When an SO library is loaded, it declares its own topic information and the topics to be subscribed to. The application bus manages and routes the topic information. This decoupling between modules achieves data synchronization through the message bus. Furthermore, because SO libraries can abstract standardized interfaces and can be dynamically loaded / unloaded without depending on the message bus implementation, decoupling between modules and the bus is achieved.

2. The communication terminal decoupling architecture based on message bus and dynamic library loading according to claim 1, characterized in that: The decoupled architecture of the communication terminal based on message bus and dynamic library loading features a hierarchical naming and access control system for module message topics, along with a message topic formatting structure. The hierarchical naming and access control of module topic information employs a three-level naming scheme: publisher, operation type, and receiver. The first field identifies the publisher of the message topic and controls the information flow; the second field identifies the action name and defines the communication behavior; and the third field identifies the message receiver or data type. This three-level naming scheme controls the information flow through the publisher information in the first field, allowing the direction to be from the bus to the module or vice versa. Other modules use single-level or multi-level wildcards to manage all main... The message topic formatting structure adopts a structured data format, specifically JSON data format, and includes the following core points: metadata and payload levels. The payload node transmits both raw data and operation logic function pointers, achieving integrated encapsulation of data and processing logic. When the 4G submodule is loaded into the system, it registers the message topic MODULE_4G / DATA with the bus. The bus creates a subscription list for this topic information. Other submodules can obtain the 4G module's business data and function operation set by subscribing to this topic information, thereby achieving data synchronization.

3. The communication terminal decoupling architecture based on message bus and dynamic library loading according to claim 1, characterized in that: The module loading and subscription management of the communication terminal decoupled architecture based on message bus and dynamic library loading includes creating a subscriber management table and a routing subscriber management table. The creation of the subscriber management table occurs when the system dynamically loads a module's SO library; the module registers a message topic with the bus, and the bus dynamically creates a linked list as the subscriber management table. Subscriber information is then added to the linked list according to the subscriber's subscription priority. The structure of the subscriber management table is as follows: Topic mapping; each message topic corresponds to an independent doubly linked list of subscribers; Dynamic table creation: The bus dynamically creates a subscriber management table for each topic, which is implemented as a priority-sorted doubly linked list. The linked list nodes are arranged in descending order according to the subscription priority, and the nodes are linked in a closed loop through predecessor and successor pointers. At the same time, in order to improve the real-time performance of the system, the same message topic can create subscriber management tables with three priority types: high, medium and low. Each priority management table has a built-in descending sorting. Dynamic expansion mechanism; each module's SO library declares the message topic set that the module needs to publish and the message topic set that it needs to subscribe to. When loading a module, the bus inserts the subscriber node into the corresponding position in the corresponding topic list. When unloading, the corresponding subscriber node information is deleted from the list. The routing subscriber management table is used when a module in the system publishes topic information. The bus matches the topic and obtains the corresponding subscription list, traverses the routing list, and asynchronously executes the subscriber callback function to complete data synchronization. This ensures that high-priority subscribers receive information first to guarantee real-time performance, while also ensuring zero data loss during transmission. The core mechanism of the routing management table is as follows: Topic matching; the bus parses the published topic information structure and obtains all subscription list information for that topic; Priority traversal; the bus scans the subscriber list in a chain at a fixed refresh rate. Each subscriber node is accessed sequentially along the successor pointer, and the information of the subscriber node with the highest priority is automatically obtained. Synchronizing data information: The system extracts the callback functions registered by each subscription node and executes them asynchronously through a thread pool to achieve data synchronization between modules. The refresh frequency of the bus determines the data synchronization latency and the real-time performance of the system.

4. The communication terminal decoupling architecture based on message bus and dynamic library loading according to claim 1, characterized in that: The sub-module dynamic library in the decoupled communication terminal architecture based on message bus and dynamic library loading is specifically designed so that sub-modules are abstracted as independent functional units and loaded into the system bus, and then decoupled collaboration is achieved through standardized interfaces. The data types of the sub-modules mainly include three categories: data acquisition classes responsible for real-time data acquisition and push; action operation classes responsible for instruction reception and hardware driving; and protocol classes responsible for protocol conversion and transparent transmission. Different functional modules emphasize different data types, specifically: 1) Role function encapsulation; Data Producer - Sensor Class: Only publishes messages to data acquisition topics; Instruction Executor - Execution Class: Only subscribes to action operation topic messages; Data Processor - Protocol Class: Both publishes and subscribes to data collection and protocol class topic messages; 2) Standardized library interfaces; When a dynamic library is loaded into a bus system, modules can be "hot-plugged" into / out of the system through a standardized interface. At the same time, the implementation details of the modules are independent of the bus, enabling bidirectional decoupling. The module's metadata drives the implementation from static declaration to dynamic construction. The communication metadata information of the dynamic library includes the module's unique identifier, published topic sets, and subscribed topic sets. When the system loads the so library, the core message topic is constructed through module_init().

Images