A plug-in based device interface protocol interaction method

Abstract

This invention relates to the field of computer communication and equipment monitoring technology, specifically a plug-in-based device interface protocol interaction method. It employs a three-layer architecture—interface layer, protocol adaptation layer, and core business layer—combined with a plug-in management module and a global exception handling module. This architecture defines standardized interaction interface methods, parameters, and return value formats. It encapsulates the parsing and framing logic of various protocols such as Socket, SNMP, and Modbus in plug-in form, enabling dynamic loading, multi-version coexistence, and hot deployment through a plug-in management center. A standardized frame model and universal encoding / decoding logic are designed to unify frame processing rules for different protocols. The global exception handling module implements default responses for unsupported functions and exception degradation strategies, and a configuration center enables hot updates of parameters such as protocol mapping and plug-in paths. This invention achieves complete decoupling of protocol logic from the core system, improving development efficiency and shortening the time required to adapt to complex device environments.

Description

Technical Field

[0001] This invention relates to the field of computer communication and equipment monitoring technology, specifically a plug-in-based device interface protocol interaction method. Background Technology

[0002] In the fields of computer communication and equipment monitoring, device interface protocol interaction is the core link for realizing data exchange and command issuance between devices and systems, and is the foundation for ensuring stable operation in scenarios such as industrial production, network maintenance, and aerospace telemetry and control. With the rapid development of Industry 4.0 and IoT technologies, device types are becoming increasingly diversified, covering industrial control equipment (such as PLCs and PDUs), network equipment (such as routers and switches), sensors (such as temperature and pressure sensors), and dedicated telemetry and control equipment (such as satellite ground station ACU antenna control units). The interface protocols used by different devices are diverse and complex, including multiple protocol types such as Socket, SNMP, Modbus (RTU / ASCII / TCP), OPC UA, and BLE, and there are multiple versions of the same protocol (such as SNMP v1 / v2c / v3, Modbus RTU v1.0 / v2.0). This diversity of devices and protocols places extremely high demands on the system's protocol adaptability, scalability, and stability.

[0003] Traditional device interface protocol interaction systems generally adopt a tightly coupled architecture design, deeply binding core logic such as protocol parsing, command framing, and data conversion with the core business code of the system to meet the device communication needs in specific scenarios. However, this architecture design exposes many insurmountable defects when faced with diverse devices and protocols.

[0004] First, the tightly coupled architecture results in extremely poor scalability. When a new device type is added or a new protocol version is updated, developers must directly modify the core system code, recompile, test, and deploy the entire system. This not only leads to long development cycles and low efficiency but also easily introduces new compatibility issues, making it difficult to quickly respond to market demands and device iterations. For example, if an industrial workshop adds a batch of smart PDU devices supporting the Modbus TCP protocol, while the existing system only supports the Socket protocol, technicians need to add Modbus TCP protocol parsing logic to the core business code, modifying multiple modules such as device management and data acquisition. The entire development and deployment cycle takes 7-10 days, severely impacting production efficiency.

[0005] Secondly, code redundancy is prominent, making maintenance extremely difficult. The protocol interaction logic for different devices is often developed independently, without abstracting and reusing common functions (such as interface initialization, parameter validation, and frame header validation). This results in a large amount of duplicate code, with system code redundancy exceeding 60%. Furthermore, various protocol codes are mixed within core business code. When device communication fails, troubleshooting requires checking all related modules, with an average fault location time exceeding 4 hours. Moreover, version upgrades are highly prone to causing compatibility issues with older device protocols, leading to persistently high maintenance costs.

[0006] Furthermore, the lack of a unified standard for interfaces leads to complex calls. In traditional systems, the interaction methods, parameter formats, and return value types of different protocols vary greatly. For example, the Socket protocol uses byte stream transmission, and parameters need to be manually concatenated into a specific format string. The SNMP protocol is based on PDU data packets, and parameters are associated through OID mapping. When making calls across devices and protocols, it is necessary to write dedicated adaptation code for different protocols, resulting in high system integration complexity, high learning costs for developers, and a call error rate exceeding 15%.

[0007] Furthermore, the lack of anomaly handling mechanisms leads to poor system stability. Traditional systems lack a unified handling strategy for abnormal scenarios such as undeveloped protocol interfaces or plugin loading failures, and incorrect data formats, often resulting in system crashes or interruptions. For example, when a satellite ground station added a new experimental ACU device, its v1102 protocol was not yet compatible. When the system called the device's interface, it directly threw an undefined exception, paralyzing the entire ground station monitoring system and affecting the normal operation of telemetry and control missions.

[0008] Finally, fixed configurations lead to insufficient flexibility. Configurations such as protocol versions and device-protocol mappings are mostly implemented through hard-coding or local static configuration files, making dynamic updates impossible. When switching device protocols or adding new protocol versions is needed, a system restart is required for the changes to take effect, making it difficult to handle complex scenarios with multiple protocol versions coexisting. For example, some servers in a data center needed to be upgraded from the SNMP v2c protocol to the SNMP v3 protocol to improve security. Due to the fixed configurations, the data center monitoring system needed to be stopped for configuration modifications and restarts, resulting in monitoring interruptions of over two hours and a risk of data loss.

[0009] In existing technologies, some solutions attempt to address the single-protocol adaptation problem. For example, CN202010271543.2 discloses a software and hardware interaction method for a BLE 5.0 protocol system, which implements the software and hardware interaction interface through linked lists and event definitions to support the extension of the BLE protocol. However, this solution only targets the single BLE protocol type and does not involve dynamic adaptation to multiple protocols and versions, nor does it solve problems such as inconsistent interfaces and fixed configurations. CN202410308247.3 discloses a multi-communication protocol adaptive interaction method, which adopts a separation architecture between the main running process and the communication protocol process to improve system reliability. However, it does not adopt a plug-in design, and protocol extensions still require modification of the process logic, resulting in limited scalability. CN202510854340.9 discloses a multi-protocol data interaction system, which solves the data interoperability problem by integrating multiple general protocol interfaces through an intermediate layer. However, the intermediate layer is still coupled with the core system and lacks global exception handling and dynamic configuration mechanisms, resulting in insufficient stability and flexibility. Therefore, there is an urgent need for a device interface protocol interaction method that can achieve dynamic adaptation of multiple protocols and versions, while solving problems such as tight architecture coupling, inconsistent interfaces, and lack of exception handling. Summary of the Invention

[0010] The purpose of this invention is to overcome the shortcomings of the prior art and provide a plug-in-based device interface protocol interaction method. Through a layered decoupling architecture, plug-in protocol management, standardized processing, global exception handling, and dynamic configuration collaborative design, it achieves complete decoupling of protocol logic and core system, supports dynamic adaptation and efficient management of multiple protocols and versions, and solves the technical problems of poor scalability, code redundancy, inconsistent interfaces, insufficient stability, and low flexibility of traditional systems.

[0011] The technical solution adopted by this invention to solve its technical problem is: a plug-in-based device interface protocol interaction method, comprising the following steps:

[0012] (1) Construct a three-layer architecture of interface layer - protocol adaptation layer - core business layer, configure a plugin management module and a global exception handling module to form a protocol interaction system; the interface layer defines standardized interaction interfaces, unifies the methods, parameter formats and return value formats of protocol interaction, and serves as the interaction contract between the core business layer and the protocol adaptation layer; the protocol adaptation layer encapsulates the parsing and framing logic of specific protocols in the form of plugins, decoupling it from the core system; the core business layer focuses on core business logic, calls protocol functions through the interface layer and does not depend on specific protocol implementations;

[0013] (2) Formulate protocol plugin specifications. Each protocol plugin includes a description file, protocol implementation and dependent resources. The plugin format is uniformly standardized JAR package structure. The plugin management module performs the registration, loading, version management, uninstallation and update operations of protocol plugins. It supports dynamic loading of plugins from local directories or remote repositories, maintains multiple version instances of the same protocol and calls the version matching according to the device request.

[0014] (3) Design a standardized frame model and general encoding and decoding logic. The frame model includes a frame header, data field and frame tail. The specific data unit is described by the field. The encoding and decoding logic supports a variety of data formats such as bytes, integers and floating-point numbers, as well as endianness mode and precision processing configuration.

[0015] (4) The global exception handling module presets a default adapter for unimplemented functions, as well as exclusive error codes and handling strategies for exception scenarios such as plugin loading failure, version mismatch, and data format error, so as to realize standardized exception transmission and stable system operation;

[0016] (5) By configuring the configuration center management protocol and device mapping, plugin path, frame processing parameters and other configuration contents, the system updates parameters in real time after configuration changes without restarting, thus achieving dynamic adaptation.

[0017] Specifically, the standardized interaction interface includes core methods such as dataReport (data reporting), commandQuery (command query), and controlSend (control command issuance); input parameters are encapsulated as ProtocolRequest objects, which include fields for unique device identifier, business data, and protocol version; and return values ​​are encapsulated as ProtocolResponse objects, which include fields for execution result, business data, error code, and error information.

[0018] Specifically, the protocol adaptation layer implements common functions such as protocol initialization and parameter verification in a unified manner through the abstract class AbstractProtocolAdapter; for Socket, SNMP and Modbus protocols, it implements standardized interaction interfaces and encapsulates protocol-specific encoding and decoding and frame structure processing logic, such as CRC verification for Socket protocol and OID mapping for SNMP protocol.

[0019] Specifically, the plugin description file is META-INF / protocol.yml, which records the protocol type, version, implementation class path, and compatible device type metadata. The plugin management module implements isolated loading and instantiation of plugins through a custom ProtocolClassLoader, and has a built-in conflict detection mechanism that returns an error message when the protocol version is incompatible or the dependency is missing.

[0020] Specifically, the general encoding and decoding logic includes read field parsing and write field conversion methods; the read method extracts data from the byte stream and converts it into a unified Java object format, and the write method converts the unified format data into a protocol-specific byte stream.

[0021] Specifically, the exception degradation strategy of the global exception handling module includes: when the plugin fails to load, try to load a lower version of the same protocol plugin; when the versions do not match, prompt the device to update the protocol version or the system to supplement the plugin; and all exceptions are uniformly captured and converted through ProtocolException.

[0022] Specifically, the configuration center uses Nacos or Consul, supports real-time modification of the protocol and device mapping relationship, realizes dynamic switching of device protocols, and the system takes effect within 10 seconds after the configuration is updated.

[0023] Specifically, the plugin management module supports hot deployment, and there is no need to stop the system when adding or updating protocol plugins. The plugin package will be loaded and take effect within 30 seconds after being uploaded.

[0024] Specifically, the fields of the standardized frame model can be configured with offset, length, default value, and verification rule attributes; the frame processing parameters include frame timeout and number of retries, which are dynamically adjusted through the configuration center.

[0025] Specifically, the core business layer includes device monitoring services and command scheduling services. It calls protocol functions through standardized interaction interfaces, and the business logic is isolated from the protocol implementation. When a new protocol is added, the core code does not need to be modified.

[0026] The beneficial effects of this invention are:

[0027] Highly scalable: Through layered decoupling and plug-in design, when adding a new protocol or updating a protocol version, only the corresponding plug-in needs to be developed and the mapping relationship configured, without modifying the core business code. The development cycle is shortened from the traditional 7-10 days to 1-2 days, improving development efficiency by more than 50%. It supports loading multiple protocols and multiple versions of plug-ins at the same time, which can adapt to the communication needs of various devices such as industrial control, network equipment, and sensors, increasing the number of compatible device types by more than 3 times.

[0028] High code reusability: By extracting common logic of protocols through abstract classes, general encoding and decoding tools and frame models enable frame processing reuse for different protocols, reducing code redundancy by more than 60%; independent encapsulation of plugins allows fault location to focus only on specific plugins, reducing maintenance costs by 70%, and reducing the occurrence rate of version upgrade compatibility issues from the traditional 30% to less than 1%.

[0029] Simple and efficient calls: Standardized interfaces and parameter formats eliminate differences in cross-protocol calls, developers do not need to pay attention to protocol details, cross-device call code volume is reduced by 40%, and call error rate drops from 15% to below 0.5%; unified return value format and error code system simplify exception handling logic and shorten problem troubleshooting time by 60%.

[0030] High system stability: Global exception handling and degradation strategies avoid system crashes caused by unimplemented functions, plugin anomalies, etc., reducing the system interruption rate from the traditional 15% to below 0.1%; Plugin isolation loading mechanism ensures that the failure of a single plugin does not affect the operation of other protocols and core businesses, improving system availability to 99.99%.

[0031] High flexibility and adaptability: Dynamic configuration and hot update mechanism support real-time switching of protocols and adjustment of parameters, reducing the adaptation time for complex device environments from 3 days to 2 hours; the ability to coexist with multiple versions of protocols meets the needs of mixed deployment scenarios of new and old devices, without the need for forced upgrades of devices or systems, reducing user upgrade costs. Attached Figure Description

[0032] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0033] Figure 1 The overall architecture diagram of the plug-in-based device interface protocol interaction system is as follows: The system achieves decoupling through a three-layer architecture. The plug-in management module is responsible for loading / version management of protocol plug-ins, the global exception handling module uniformly intercepts exceptions, and the configuration center realizes dynamic parameter updates, which together support flexible interaction of multiple protocols and multiple versions of devices.

[0034] Figure 2 ACU Protocol Plug-in Architecture Diagram: The core business layer (ground station monitoring system) calls the ACU protocol plug-in (v30 / v31 / v42 / v2.0 / v1102) of the protocol adaptation layer through the protocol interface layer to achieve decoupled interaction with different models of ACU devices (old models / new models / experimental models). The plug-in independently encapsulates the protocol logic of each version, and the core business layer does not need to pay attention to the protocol details.

[0035] Figure 3 ACU protocol version matching flowchart (taking v2.0 protocol as an example); The core business layer (antenna control service) obtains the device protocol version through the configuration center. The plugin management center matches plugins according to "protocol type + version" (if loaded, it is directly called; if not loaded, it is dynamically loaded). Finally, it interacts with the device through the protocol adaptation layer and returns standardized results to achieve seamless compatibility of multiple version protocols.

[0036] Figure 4A schematic diagram of the standardized frame model structure (taking the Socket protocol as an example); the general frame model defines a standardized frame header, data field, and frame trailer, and the fields support diverse types and attribute configurations to adapt to the differences in frame structure of different protocols. Encoding and decoding tools achieve unified data conversion based on this model. Detailed Implementation

[0037] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0038] like Figures 1-4 As shown, the plug-in-based device interface protocol interaction method of the present invention includes the following steps:

[0039] (1) Three-tier architecture design

[0040] A three-layer architecture of "interface layer - protocol adaptation layer - core business layer" is constructed, combined with a plugin management module and a global exception handling module, to form a protocol interaction system with clear responsibilities and loose coupling:

[0041] Interface Layer: Defines a standardized interaction interface IProtocol, including core methods dataReport (data reporting), commandQuery (command query), and controlSend (control command issuance), unifying input parameter and return value formats. Input parameters are encapsulated as ProtocolRequest objects, containing common fields such as device unique identifier (deviceId), business data (data), protocol version (version), and timeout. Return values ​​are encapsulated as ProtocolResponse objects, containing fields such as execution result (success), business data (result), error code (errorCode), error message (errorMsg), and response time (responseTime), ensuring consistency across protocol calls.

[0042] Protocol Adaptation Layer: Serving as an intermediary bridge between the core business layer and the device, this layer encapsulates the specific logic for protocol parsing, framing, encoding, and decoding, enabling dynamic loading as a plugin. The abstract class `AbstractProtocolAdapter` provides a unified implementation of common functions such as protocol initialization (init), parameter validation (validateParam), and connection management (connect / close), avoiding redundant development. For different protocols such as Socket, SNMP, Modbus, and OPC UA, the `IProtocol` interface is implemented to encapsulate protocol-specific processing logic, such as byte stream encoding / decoding, frame header verification, and CRC verification for the Socket protocol; PDU data packet construction and OID mapping for the SNMP protocol; and RTU / ASCII frame structure framing and parsing for the Modbus protocol.

[0043] Core Business Layer: Focuses on core business functions such as device monitoring, command scheduling, and data statistics. It only relies on the standardized interface call protocol functions of the interface layer and does not involve any protocol details. For example, the device monitoring service obtains the status data of various devices through IProtocol.dataReport(), aggregates it, and generates a monitoring dashboard; the command scheduling service issues control commands to different devices through IProtocol.controlSend(), without needing to know the specific protocol type and version used by the devices.

[0044] (2) Plug-in protocol management mechanism

[0045] Protocol Plugin Specification: Each protocol plugin is an independent component, adopting a standardized JAR package structure, containing three core parts: a description file (META-INF / protocol.yml), which records metadata such as protocol type, version, implementation class path, dependencies, and compatible device types; the protocol implementation body, i.e., the class file that implements the IProtocol interface, encapsulating protocol-specific parsing, framing, and encoding / decoding logic; and dependent resources, including configuration templates, third-party library JAR packages, certificate files, etc., required for protocol operation.

[0046] The plugin management module features plugin registration, loading, version management, uninstallation, updates, and conflict detection. It supports loading plugins from local plugin directories or remote repositories (such as Nexus and Maven Central), achieving isolated loading and instantiation of plugins through a custom class loader (ProtocolClassLoader) without requiring a system restart. Based on the version field of the plugin description file, it maintains multiple version instances of the same protocol, using a two-key mapping mechanism of "protocol type + version" to accurately match the corresponding plugin instance based on the version field requested by the device. It supports hot deployment of plugins; when adding or updating a protocol, simply upload the plugin package to the specified directory, and the plugin management module automatically detects and loads it, with an effective time of no more than 30 seconds. A built-in conflict detection mechanism automatically returns error codes and prompts, and records detailed logs when the protocol version requested by the same device is incompatible with the loaded plugin version or when plugin dependencies are missing.

[0047] (3) Standardized frame processing and universal encoding and decoding

[0048] Standardized Frame Model: Defines a general frame model, Frame, which includes three common parts: Header, DataField, and Tailer. Each part consists of multiple fields. Fields support diverse data types such as bytes, integers (Int8 / Int16 / Int32), floating-point numbers (Float32 / Float64), hexadecimal numbers, and strings. Each field can be configured with attributes such as offset, length, default value, and check rule. For example, a Socket protocol frame can be defined as: Frame Header (2 bytes, identifier 0x5A5A), Device Address (1 byte), Data Length (2 bytes), Data Field (N bytes), Checksum (1 byte, CRC16), and Tailer (1 byte, 0xAA), uniformly described through the Frame model.

[0049] General Encoding / Decoding Logic: A general encoding / decoding tool (FrameCodec) is designed based on the frame model, providing dedicated read (parsing) and write (framing) methods for each data type. During parsing, the corresponding data is extracted from the input byte stream according to the field offset and length, and converted into a unified Java object format (such as string or numeric types) according to the field type. During framing, the unified format business data is converted into a byte stream according to the field configuration, filled into the corresponding fields of the Frame model, and automatically completes operations such as frame header identification, length calculation, and checksum generation. The encoding / decoding tool supports extended configurations such as little-endian / big-endian mode, precision preservation, string encoding (UTF-8 / GBK / ASCII), and encryption / decryption (AES / DES). Encoding / decoding parameters can be dynamically adjusted through the configuration center.

[0050] (4) Global exception handling and degradation strategy

[0051] Error Types and Error Code System: Five major categories of error scenarios are defined, including plugin-related errors (loading failure, version mismatch, missing dependencies), protocol interaction errors (data format errors, frame verification failure, timeout), configuration errors (mapping relationship not existing, parameters invalid), unimplemented function errors, and system resource errors. Each error scenario corresponds to a unique error code (e.g., plugin loading failure is -2001, version mismatch is -2002), forming a standardized error code system.

[0052] Exception Handling Mechanism: The global exception handling module intercepts all exceptions during protocol interactions using AOP (Aspect-Oriented Programming), uniformly converting them into ProtocolException exceptions, and then executing the corresponding handling strategy based on the exception type. For unimplemented protocol interfaces, routing is performed to the default adapter (DefaultProtocolAdapter), returning error code -1001 and the message "Feature not yet supported," and recording device request details to support priority evaluation for subsequent plugin development. For plugin loading failure exceptions, it automatically attempts to load a lower version of the same protocol as a fallback solution; if a lower version does not exist, an exception message is returned. For data format errors or frame verification failure exceptions, error codes and specific reasons are returned, supporting rapid problem location on the device side. All exception information is recorded through a logging system (such as Logback), including details such as device ID, protocol type, request parameters, and exception stack trace, facilitating troubleshooting.

[0053] (5) Dynamic configuration management

[0054] Configuration Content: Four core configurations are managed through a configuration center (supporting mainstream configuration centers such as Nacos, Consul, and Apollo): Device-protocol mapping configuration, which records the mapping relationship between device type or device ID and protocol type and version, and supports batch configuration of multiple devices; Plugin management configuration, including local plugin directory path, remote repository address, plugin loading timeout, dependency library caching strategy, etc.; Frame processing configuration, including frame timeout, number of retries, encoding and decoding parameters (such as endianness, string encoding), verification rule enabling status, etc.; Anomaly handling configuration, including degradation policy switch, error log output level, alarm trigger threshold, etc.

[0055] Hot update mechanism: After the configuration center pushes configuration changes, the system listens for configuration change events and updates the local configuration cache in real time, taking effect without restarting the system. For example, if a device needs to switch from the SNMP v2c protocol to the SNMP v3 protocol, the administrator only needs to modify the device's protocol version configuration in the configuration center. The system completes the configuration update within 10 seconds, the plugin management module automatically loads the SNMP v3 plugin and completes the switch, and subsequent device requests are directly routed to the new plugin instance.

[0056] Example 1: Multi-protocol Interaction System for Industrial PDU Devices

[0057] I. Application Scenarios

[0058] A large data center has 500 industrial PDUs (Power Distribution Units) of different brands and models, including Huawei, Vertiv, and Kehua. Huawei PDUs support the SNMP v2c protocol, Vertiv PDUs support the Modbus TCP protocol, and Kehua PDUs support the Socket protocol. Some older Kehua PDUs support the Socket v1.0 protocol (basic data reporting only), while newer Kehua PDUs support the Socket v2.0 protocol (with added power threshold alarm functionality). The data center needs to build a unified PDU monitoring system to collect current, voltage, and power data from all PDUs, as well as remotely control their operation. The system must support rapid integration of new PDUs and maintain uninterrupted operation (99.99% availability throughout the year).

[0059] II. System Configuration

[0060] Hardware environment: The monitoring server uses two Intel Xeon E5-2680 v4 processors (dual-machine hot standby), each with 32GB of memory and a 1TB SSD hard drive, and the operating system is CentOS 7.9; the PDU device communicates with the monitoring server via gigabit Ethernet, with network latency ≤10ms, and redundant switches are deployed to ensure reliable communication links.

[0061] Software environment: JDK 11, Spring Boot 2.7.10, Nacos 2.3.0 (configuration center and service discovery, dual-node deployment), Logback (log system, logs stored in Elasticsearch 7.17.0), Redis 6.2.8 (caching plugin instances and device status), InfluxDB 2.7.1 (time series data storage, used for querying historical data such as current and voltage), Grafana 9.2.0 (monitoring dashboard, real-time display of PDU running status).

[0062] Protocol plugin configuration:

[0063] (1) SNMP v2c plugin: Plugin package name snmp-protocol-plugin-2.0.0.jar, configuration in description file META-INF / protocol.yml:

[0064]

[0065] The SNMPv2cProtocolAdapter implementation encapsulates the construction and parsing of SNMP PDU data packets, supporting the mapping between OID and PDU data items (current OID: 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.3;

[0066] Voltage OID: 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.4;

[0067] Power OID: 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.5).

[0068] Implement the methods dataReport (parse PDU data reporting), commandQuery (query data for a specified OID), and controlSend (issue switch control commands, corresponding to OID: 1.3.6.1.4.1.2011.6.128.1.1.1.6.1.3).

[0069] (2) Modbus TCP plugin: Plugin package name modbus-tcp-protocol-plugin-1.5.0.jar, description file configuration:

[0070]

[0071] The protocol implementation encapsulates the framing and parsing of Modbus TCP frames, supporting function codes 0x03 (read holding register) and 0x06 (write single register); current data is stored in register address 0x0001 (16-bit integer, unit A), voltage data is stored in 0x0002 (16-bit integer, unit V), power data is stored in 0x0003 (32-bit floating-point number, unit kW), and switch control corresponds to register 0x0010 (1 for on, 0 for off).

[0072] (3) Socketv1.0 plugin: Plugin package name socket-protocol-plugin-1.0.0.jar, description file configuration:

[0073]

[0074] The frame format is defined as follows: frame header 0x5A5A (2 bytes), data length (2 bytes), device address (1 byte), data field (8 bytes, current 2 bytes, voltage 2 bytes, power 2 bytes, status 2 bytes), check bit (1 byte, CRC8), frame tail 0xAA (1 byte); only dataReport (data reporting and parsing) and controlSend (switch control framing) functions are supported.

[0075] (4) Socket v2.0 plugin: The plugin package name is socket-protocol-plugin-2.0.0.jar, and the description file configuration is added based on v1.0:

[0076]

[0077] The data field has been expanded to 12 bytes, and new fields for power threshold (2 bytes, unit kW) and alarm status (2 bytes, bit 0 indicates overcurrent alarm and bit 1 indicates overvoltage alarm) have been added. Power threshold configuration (sent via controlSend) and alarm reporting (dataReport returns alarm status) functions are supported.

[0078] 4. Configuration Center Configuration:

[0079] (1) Device-protocol mapping (Nacos configuration item: protocol.device.mapping):

[0080]

[0081] (2) Frame processing configuration (Nacos configuration item: protocol.frame.config):

[0082]

[0083] (3) Plugin management configuration (Nacos configuration item: protocol.plugin.config):

[0084]

[0085] III. System Workflow

[0086] Plugin loading process:

[0087] When the monitoring system starts, the plug-in management module performs the following steps:

[0088] (1) Scan the local plugin directory / data / protocol-plugins, identify four protocol plugin packages, and load the description file protocol.yml of each plugin through ProtocolClassLoader (a custom class loader to avoid conflicts with the core class);

[0089] (2) Parse the metadata such as protocol type, version, and implementation class path in the description file, check if the dependent library exists (e.g., the SNMP plugin depends on snmp4j.jar), and if it is missing, automatically download and cache it from the remote repository;

[0090] (3) Instantiate the protocol implementation class (such as SNMPv2cProtocolAdapter) and call the init() method to complete the initialization (such as the SNMP plugin initializing the target device IP list and port);

[0091] (4) Construct a mapping table from “type+version” to the plugin instance (e.g., “SNMP_2.0.0” → SNMP v2cProtocolAdapter instance), store it in the Redis cache, and register it with the Spring container for the core business layer to call.

[0092] Data reporting process (taking Huawei PDU HW-PDU-001 as an example):

[0093] (1) Huawei PDU collects current (16A), voltage (220V), and power (3.52kW) data every 30 seconds according to the SNMP v2c protocol specification, encapsulates it into a PDU data packet (containing OID and corresponding value), and sends it to port 161 of the monitoring server via UDP protocol;

[0094] (2) The SNMP receiving service (bound to port 161) of the monitoring server interface layer receives data packets, parses the device ID as HW-PDU-001, and calls the configuration center client to obtain the protocol mapping of the device (type=SNMP, version=2.0.0).

[0095] (3) The plugin management module retrieves the plugin instance from the Redis cache based on the key “SNMP_2.0.0”. The device data acquisition service of the core business layer calls the dataReport implementation of the plugin through the IProtocol.dataReport() method, passing in the parameter ProtocolRequest(deviceId=HW-PDU-001, version=2.0.0, data=PDU data packet byte stream).

[0096] (4) The SNMPv2cProtocolAdapter plugin parses PDU data packets:

[0097] Traverse the OID list and extract the value of 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.3 (current) as 16;

[0098] 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.4 (Voltage) value is 220;

[0099] 1.3.6.1.4.1.2011.6.128.1.1.1.4.1.5 (Power) value is 3.52;

[0100] (5) The plugin encapsulates the parsed data into a ProtocolResponse object;

[0101] (success=true, result={"current":16.0,"voltage":220.0,"power":3.52}, errorCode=0, responseTime=50ms) Return to the core business layer;

[0102] (6) The core business layer stores data in InfluxDB (time series database) and pushes it to the Grafana monitoring dashboard to display the running status of HW-PDU-001 in real time and determine whether the power exceeds the threshold (e.g., 5kW). If it does not exceed the threshold, the process ends; if it does exceed the threshold, an alarm is triggered.

[0103] Remote control procedure (taking the shutdown of port 1 of the new Kehua PDUKH-PDU-New-050 as an example):

[0104] (1) The administrator finds the KH-PDU-New-050 device in the Grafana monitoring interface, clicks the "Close Port 1" button, enters the operation password (authorization verification), and submits the control request to the core business layer.

[0105] (2) After the core business layer instruction scheduling service verifies the permission, it generates a ProtocolRequest object (deviceId=KH-PDU-New-050, version=2.0.0, data={“port”:1,“status”:0,“operator”:“admin”}).

[0106] (3) Call the configuration center client to query the protocol mapping of the device (type=Socket, version=2.0.0), and the plugin management module obtains the SocketV2ProtocolAdapter instance from the Redis cache;

[0107] (4) The core business layer calls the IProtocol.controlSend() method. After receiving the request, the plugin instance assembles the frame according to the Socketv2.0 protocol frame format:

[0108] Frame header: 0x5A5A (2 bytes)

[0109] Data length: 0x000C (12 bytes, data field length)

[0110] Device address: 0x32 (50, 1 byte)

[0111] Data fields: 0x0000 (current, 2 bytes), 0x0000 (voltage, 2 bytes), 0x0000 (power, 2 bytes), 0x0000 (status, 2 bytes), 0x03E8 (power threshold, 2 bytes, 10kW), 0x0000 (alarm status, 2 bytes)

[0112] Check bit: 0x7F (CRC8 calculation result, 1 byte)

[0113] Frame end: 0xAA (1 byte)

[0114] (5) The plugin sends frame data via TCP protocol (connecting to port 8080 of PDU). After receiving the frame data, PDU parses it, verifies that the checksum (CRC8) passes, performs the operation of closing port 1, and returns a response frame (status field 0x0001 indicates successful execution).

[0115] (6) The plugin parses the response frame, encapsulates it into a ProtocolResponse object (success=true, result={"port":1, "status":0}, errorCode=0) and returns it to the core business layer;

[0116] (7) The core business layer updates the instruction execution status (stored in MySQL) and reports "Port 1 closed successfully" to the administrator interface, while recording the operation log (including device ID, operator, time and result).

[0117] Plug-in hot update process (adding Schneider OPC UAPDU devices):

[0118] (1) Developers develop OPC UA protocol plugins:

[0119] The plugin package name is opc-ua-protocol-plugin-1.0.0.jar, the description file is configured with type=OPC UA, version=1.0.0, and the implementation class... ,rely milo-sdk-client:0.6.10;

[0120] (2) Developers upload the plugin package to the remote repository Nexus:

[0121] (http: / / nexus.example.com / repository / protocol-plugins / opc-ua-protocol-plugin-1.0.0.jar);

[0122] (3) The administrator updates the device-protocol mapping in the Nacos configuration center;

[0123] Add " ":{"type":"OPC UA","version":"1.0.0"};

[0124] (4) When the configuration center pushes a configuration change event, the plugin management module of the monitoring system detects the change and automatically downloads the OPC UA plugin package from the remote repository to the local directory / data / protocol-plugins;

[0125] (5) The plugin management module loads plugins (without restarting the system): parses the description file, checks dependencies, instantiates OPCUAProtocolAdapter, and updates the Redis mapping table;

[0126] (6) After the newly added Schneider PDU device (device ID: Schneider-PDU-001) is started, it connects to port 4840 of the monitoring server according to the OPC UA protocol and reports current and voltage data;

[0127] (7) The monitoring system interface layer receives data, matches the OPC UA plugin through the configuration center, and completes data parsing and reporting. The whole process does not require modification of the core code, and the plugin takes 25 seconds to load and take effect.

[0128] Implementation results:

[0129] In this embodiment, the monitoring system successfully connected to 500 PDU devices of different brands and protocols, achieving unified management of data acquisition and remote control, and achieving the following results:

[0130] Scalability: The development cycle of the new OPC UA protocol plugin is 1 day, and the loading and activation time is 25 seconds. Compared with the traditional system's development and deployment cycle of 7-10 days, the efficiency is improved by more than 85%.

[0131] Stability: After 6 months of system operation, there was only one interruption due to protocol anomalies (lasting 10 seconds, triggered by a missing plugin dependency), with an interruption rate of 0.05%, meeting the 99.99% availability requirement.

[0132] Maintainability: Code redundancy is reduced from 60% in traditional systems to 20%, and the average fault location time is 30 minutes (e.g., if a Vertiv PDU has abnormal data, it can be quickly located as a Modbus plug-in register address configuration error).

[0133] Economic efficiency: No need to develop multiple independent systems, saving approximately RMB 800,000 in maintenance costs annually (including development personnel hours and server resources).

[0134] Example 2: Multi-version protocol adaptation system for satellite ground station ACU equipment

[0135] I. Application Scenarios

[0136] A satellite ground station has deployed 12 ACU (Antenna Control Unit) devices, covering older models (manufactured in 2015, supporting protocol versions v30 and v31, used for conventional satellite tracking), newer models (manufactured in 2020, supporting protocol versions v42 and v2.0, used for high-precision satellite telemetry and control), and experimental models (manufactured in 2023, supporting protocol version v1102, used for experimental telemetry and control of new satellites). The ACU devices need to remotely adjust the antenna azimuth and elevation angles, and report real-time data such as position (accuracy ≤0.1°), operating mode (automatic tracking / manual control), and fault information (e.g., motor failure, signal loss). The different protocol versions differ significantly.

[0137] Version 30: Frame format "frame header 0xAA + data field 10 bytes", no parity bit, azimuth angle is a 2-byte integer (unit: degree, precision 1°).

[0138] Version 2.0: Frame format "Frame header 0xAA + device address 1 byte + data field 12 bytes + check bit 1 byte (CRC16) + frame tail 0x55", azimuth angle is 4 bytes floating point number (precision 0.01°).

[0139] Version 1102: Added "Fast Tracking" command (antenna adjustment speed up to 10° / s), expanded data field to 16 bytes, and supports satellite signal strength acquisition (0-100dBm).

[0140] The ground station needs to build a unified ACU telemetry and control system, which should support centralized management of all versions of ACU, allow for rapid access to new functions of test equipment models, and not affect the normal operation of existing equipment (telemetry and control task interruption time ≤ 1 minute / year).

[0141] II. System Configuration

[0142] Hardware environment: The monitoring and control server uses two Intel Xeon Gold 6248 processors (dual-machine hot standby to avoid single point of failure), each with 64GB of memory and a 2TB SSD hard drive, and the operating system is Ubuntu 20.04 LTS; the ACU device communicates with the monitoring and control server via fiber optic Ethernet, with a network latency of ≤5ms, and supports TCP / UDP dual protocols (UDP is used for real-time data reporting, and TCP is used for control command issuance); a GPS time synchronization server is deployed to ensure that the time deviation between the ACU and the server is ≤1ms.

[0143] Software environment: JDK 17, Spring Cloud Alibaba 2022.0.0.0 (microservice architecture, separating device management, command scheduling, and data storage services), Nacos 2.3.0 (configuration center, three-node deployment to ensure high availability), Elasticsearch 7.17.0 (stores ACU status data and operation logs, with sharded backup), Prometheus 2.45.0 (performance monitoring, monitoring server CPU, memory, and plugin running status), Grafana 9.2.0 (monitoring and control interface, displaying antenna location and operating mode), Vue 3 (front-end interface development, supporting command issuance and status query).

[0144] Protocol plugin configuration:

[0145] (1) ACU v30 plugin: Plugin package name acu-protocol-plugin-v30.jar, description file configuration:

[0146]

[0147] The protocol implementation AcuV30ProtocolAdapter encapsulates the v30 protocol logic: the data field is parsed into azimuth (2 bytes, 0-360°), elevation (2 bytes, 0-90°), operating mode (1 byte, 0=manual, 1=automatic), fault code (1 byte, 0=normal, 1=motor fault), and reserved (4 bytes); it implements the dataReport (parsing ACU reported data), commandQuery (querying antenna position), and controlSend (sending angle adjustment command).

[0148] (2) ACUv31 plugin: The plugin package name is acu-protocol-plugin-v31.jar, and the description file configuration is modified based on v30:

[0149]

[0150] The reserved 4 bytes in the data field are changed to satellite number (2 bytes, such as 0x0001 representing satellite A) and signal strength (2 bytes, 0-100, unit dBm). Other logic is the same as v30, supporting the acquisition of satellite number and signal strength.

[0151] (3) ACU v42 plugin: Plugin package name acu-protocol-plugin-v42.jar, description file configuration:

[0152]

[0153] The frame format includes a frame header 0xAA (1 byte), a data field (10 bytes), and a check bit (1 byte, XOR check). The data field adds a temperature field (1 byte, unit °C, offset 8), and supports remote restart commands (control code 0x05, sent via controlSend).

[0154] (4) ACU v2.0 plugin: Plugin package name acu-protocol-plugin-v20.jar, description file configuration:

[0155]

[0156] The azimuth and elevation angles are stored using 32-bit floating-point numbers with a precision of 2 decimal places. The data field includes azimuth (4 bytes), elevation (4 bytes), operating mode (1 byte), fault code (1 byte), temperature (1 byte), and reserved (1 byte). It supports high-precision angle control (such as adjusting to 45.35°).

[0157] (5) ACU v1102 plugin: Plugin package name acu-protocol-plugin-v1102.jar, description file configuration:

[0158]

[0159] The frame format consists of a frame header of 0xABAB (2 bytes), a device address (2 bytes), a data length (2 bytes), a data field (16 bytes), a checksum (2 bytes, CRC32), and a frame tail of 0xCD (1 byte). The data field includes azimuth (4-byte floating-point number), elevation (4-byte floating-point number), operating mode (1 byte), fault code (1 byte), temperature (1 byte), satellite number (2 bytes), fast tracking parameters (2 bytes, speed), and accuracy threshold (2 bytes). It supports fast tracking commands (control code 0x08), with a speed range of 1-10° / s and an accuracy threshold range of 0.001-0.1°.

[0160] 4. Configuration Center Configuration:

[0161] (1) Device-protocol mapping (Nacos configuration item: acu.protocol.mapping):

[0162]

[0163] (2) Exception handling configuration (Nacos configuration item: protocol.exception.config):

[0164]

[0165] (3) Frame processing configuration (Nacos configuration item: acu.frame.config):

[0166]

[0167] III. System Workflow

[0168] Multi-version protocol adaptation process (old model ACU-2015-V30-003 and experimental model ACU-2023-V1102-012 are reported simultaneously):

[0169] (1) Old model ACU reports: ACU-2015-V30-003 collects azimuth angle 120°, elevation angle 60°, operating mode "automatic tracking" (0x01), and fault code 0x00 every 1 second, and frames according to v30 protocol (frame header 0xAA + data field 0x0078003C010000000000), and sends it to the 5000 port of the measurement and control server via UDP protocol;

[0170] (2) Test model ACU reporting: ACU-2023-V1102-012 collects azimuth angle 180.50° (0x43488000), elevation angle 45.20° (0x42346666), operation mode "fast tracking" (0x02), fault code 0x00, temperature 35℃ (0x23), satellite number 0x0001, fast tracking speed 5° / s (0x0005), accuracy threshold 0.005° (0x0005) according to v1102 protocol (frame header 0xABAB + device address 0x000C + data length 0x0010 + data field 0x43488000423466660200230001000005 + check bit 0x1234 + frame tail 0xCD) and sends it to the 5001 port of the telemetry and control server via TCP protocol;

[0171] (3) Data reception and protocol matching: The UDP receiving service (bound to port 5000) and TCP receiving service (bound to port 5001) of the measurement and control server interface layer receive data packets respectively, parse the device ID (ACU-2015-V30-003, ACU-2023-V1102-012), and call the Nacos configuration center to obtain the corresponding protocol version (30, 1102).

[0172] (4) Plugin invocation and data parsing:

[0173] The plugin management module obtains an AcuV30ProtocolAdapter instance based on the "ACU_30" key. The core business layer calls the dataReport method, and the plugin parses the data fields: 0x0078→120 (azimuth), 0x003C→60 (elevation), 0x01→auto-tracking, and encapsulates it into ProtocolResponse(result={"azimuth":120.00,"elevation":60.00,"mode":"auto-tracking"}).

[0174] The plugin management module obtains an AcuV1102ProtocolAdapter instance based on the key "ACU_1102". The core business layer calls the dataReport method, and the plugin parses the data fields: 0x43488000→180.50 (azimuth), 0x42346666→45.20 (elevation), 0x02→fast tracking, 0x23→35℃, 0x0001→satellite 1, 0x0005→5° / s, and encapsulates it into ProtocolResponse(result={"azimuth":180.50,"elevation":45.20,"mode":"fast tracking","temperature":35,"satelliteId":1,"fastTrackSpeed":5.0}).

[0175] (5) Data storage and display: The core business layer stores the data of the two ProtocolResponse objects in Elasticsearch (sharded by device ID and timestamp) and pushes it to the Grafana monitoring interface. The interface displays the data according to the protocol version: the v30 device displays integer angles, and the v1102 device displays floating-point angles and fast tracking parameters. Administrators can filter and view the status of different versions of the device.

[0176] Quickly track the instruction issuance process (Control ACU-2023-V1102-012):

[0177] (1) The administrator selects the ACU-2023-V1102-012 device in the Vue measurement and control interface, enters the "Quick Tracking" function page, sets the tracking speed to 6° / s and the accuracy threshold to 0.003°, and clicks the "Issue Command" button;

[0178] (2) The front-end interface submits parameters to the instruction scheduling service of the core business layer, and the service generates a ProtocolRequest (deviceId=ACU-2023-V1102-012, version=1102, data={“controlCode”:0x08,“fastTrackSpeed”:6.0,“precisionThreshold”:0.003}).

[0179] (3) The instruction scheduling service calls the configuration center to obtain the protocol mapping, the plugin management module matches the AcuV1102ProtocolAdapter instance, and calls the IProtocol.controlSend() method;

[0180] (4) Frame assembly: Frame data is constructed according to the v1102 protocol format. The fast tracking speed is 6° / s → 0x0006, the accuracy threshold is 0.003° → 0x0003, the data field is 0x00000000000000002000000010000060003, and the check bit is calculated as 0x5678 by CRC32.

[0181] (5) The plug-in sends frame data via TCP protocol (connecting to port 6000 of ACU). After receiving the data, ACU parses it: verifies the frame header, device address, and check bit, confirms that the control code is 0x08 (fast tracking), sets the speed to 6° / s and the accuracy threshold to 0.003°, starts the fast tracking mode, and adjusts the antenna pointing.

[0182] (6) The ACU returns a response frame (fault code 0x00 indicates success). After the plugin parses the frame, it encapsulates ProtocolResponse (success=true) and returns it. The core business layer updates the instruction status (stored in MySQL), and the interface displays "Quickly track instruction execution successful". At the same time, the operation log is recorded (including instruction parameters, execution time, and result).

[0183] Protocol version upgrade compatibility process (ACU-2020-V42-008 upgraded to v2.0):

[0184] (1) Ground station technicians upgraded the firmware of the ACU-2020-V42-008 device. After the upgrade, the device supports the v2.0 protocol (while retaining v42 protocol compatibility).

[0185] (2) The administrator modifies the device-protocol mapping in the Nacos configuration center, changing the version of ACU-2020-V42-008 from 42 to 2.0;

[0186] (3) When the configuration center pushes a change event, the core business layer updates the local cached protocol version;

[0187] (4) After the ACU equipment upgrade is completed, data (including floating-point angle and check bit) is reported according to the v2.0 protocol. After the measurement and control server interface layer receives the data, it matches the v2.0 plugin through the configuration center.

[0188] (5) The AcuV20ProtocolAdapter plugin parses the data (converts the 4-byte floating-point number to 180.35°), encapsulates the ProtocolResponse return, and the core business layer can receive high-precision data without modifying the code;

[0189] (6) The administrator viewed the data of the device on the monitoring and control interface and found that the azimuth accuracy improved from 1° to 0.01°. The upgrade was confirmed to be successful and the whole process was uninterrupted (ACU reporting did not stop and the system automatically switched the plug-in).

[0190] IV. Implementation Results

[0191] In this embodiment, the measurement and control system successfully adapted to 12 ACU devices with different protocol versions, achieving centralized control and status monitoring, and achieving the following effects:

[0192] New feature integration efficiency: The development cycle of the protocol plugin for the test model v1102 is 3 days, which is 80% more efficient than the 15-day cycle of refactoring the core code of the traditional system.

[0193] Stability: The system has been running for 1 year and only experienced 3 plugin loading failures (due to insufficient hard disk space). The downgrade strategy (loading lower version plugins) ensured the continuity of tasks, with a cumulative interruption time of 5 minutes, meeting the requirement of ≤1 minute / year (actually, 2 of these failures were due to human error, which were resolved after optimization).

[0194] Compatibility: The older v30 device and the experimental v1102 device can be used in parallel without any data acquisition conflicts.

[0195] Economic benefits: Avoiding the replacement of 12 ACU devices (each costing 500,000 yuan), saving approximately 6 million yuan in upgrade costs, while reducing the development costs of traditional system reconstruction by approximately 1 million yuan.

[0196] Example 3: Sensor Network Dynamic Protocol Switching System

[0197] I. Application Scenarios

[0198] A smart agriculture industrial park covers 1,000 mu (approximately 67 hectares) and deploys 1,000 environmental monitoring sensors (250 each for temperature, humidity, soil moisture, and light intensity) distributed across 50 greenhouses (20 sensors per greenhouse). Initially, the sensors use the LoRa protocol (transmission distance 1-3km, rate 1-50kbps) for periodic data reporting (every 5 minutes), suitable for low-power, wide-coverage scenarios. Some high-end greenhouses (such as strawberry greenhouses) have added video monitoring equipment to monitor crop growth in real time. This requires the use of the MQTT protocol (transmission rate 1-10Mbps) to transmit high-definition video streams (720P, 25fps) and issue real-time control commands (such as irrigation valve switching). In addition, the park deploys 10 edge computing nodes (each covering 5 greenhouses). The edge nodes and sensors communicate using the Modbus RTU protocol (RS485 bus, transmission distance 100-1200m) for local data caching and fast querying (response time ≤300ms). The system needs to support dynamic switching between three protocols: LoRa, MQTT, and Modbus RTU. It should automatically select the optimal protocol based on the business scenario (periodic reporting, real-time monitoring, local query), and ensure that data transmission is not interrupted during protocol switching. It should also support the rapid access of new protocols (such as NB-IoT).

[0199] II. System Configuration

[0200] Hardware environment:

[0201] (1) Edge computing nodes: 10 Raspberry Pi 4B (4GB memory, 64GB SD card), operating system Raspbian11, deployed RS485 module (MAX485), LoRa module (SX1278), Ethernet module (Gigabit).

[0202] (2) Sensor node: The ESP32 chip (low power consumption, supports WiFi / Bluetooth / LoRa) is used, and the LoRa module (SX1278), MQTT communication module (ESP8266, supports WiFi), and Modbus RTU module (MAX485) are integrated. The power supply is a lithium battery (6-12 months of battery life, LoRa mode).

[0203] (3) Central server: Deploy 2 Intel Xeon E3-1230 v5 processors (dual-machine hot standby), 16GB memory, 512GB SSD hard disk, operating system Ubuntu 20.04 LTS; deploy Nacos configuration center (dual nodes), EMQ X MQTTBroker (4.4.8, supporting cluster), InfluxDB (time series data storage), and Redis (caching protocol configuration and sensor status).

[0204] Software environment: JDK 17, Spring Boot 3.1.2, Spring Cloud Stream (for MQTT message reception), Modbus4j (Modbus RTU protocol library), LoRaWAN Server (LoRa protocol service), Python 3.9 (edge ​​node script development, used for protocol switching control).

[0205] Protocol plugin configuration:

[0206] (1) LoRa protocol plugin: Plugin package name lora-protocol-plugin-1.2.0.jar, description file configuration:

[0207]

[0208] The protocol implementation encapsulates the LoRaWAN protocol logic: it supports Class A mode (low power consumption, short-term windowed reception of downlink after uplink), and the frame format is preamble (8 bytes), synchronization word (2 bytes, 0x3444), physical layer header (1 byte), MAC layer header (3 bytes), data field (N bytes), CRC (2 bytes); the default data reporting period is 5 minutes (300000ms), which can be dynamically adjusted through the configuration center.

[0209] (2) MQTT protocol plugin: Plugin package name mqtt-protocol-plugin-3.0.0.jar, description file configuration:

[0210]

[0211] The protocol implementation supports the MQTT 3.1.1 protocol, with a topic format of "sensor / {deviceId} / {dataType}" (e.g., "sensor / TEMP-001 / temperature"), QoS level 1 (ensuring messages are delivered at least once); it supports real-time data reporting (period of 1 second) and control command issuance (e.g., irrigation valve control).

[0212] (3) ModbusRTU protocol plugin: Plugin package name modbus-rtu-protocol-plugin-2.1.0.jar, description file configuration:

[0213]

[0214] The protocol implementation supports the Modbus RTU protocol and uses RS485 bus communication; sensor data is stored in register addresses: temperature (0x0001, 16-bit integer, unit 0.1℃), humidity (0x0002, 16-bit integer, unit 0.1%RH), soil moisture (0x0003, 16-bit integer, unit %), and light intensity (0x0004, 32-bit integer, unit lux); it supports function codes 0x03 (read register) and 0x06 (write register).

[0215] 4. Configuration Center Configuration:

[0216] (1) Protocol switching strategy (Nacos configuration item: sensor.protocol.switch.strategy):

[0217]

[0218] (2) Device-protocol default mapping (Nacos configuration item: sensor.protocol.default.mapping):

[0219]

[0220] (3) Edge node configuration (Nacos configuration item: edge.node.config):

[0221]

[0222] III. System Workflow

[0223] Protocol dynamic switching process (temperature sensor TEMP-008):

[0224] (1) Normal periodic reporting (LoRa):

[0225] The TEMP-008 uses the LoRa protocol by default, collecting the temperature every 5 minutes (25.0℃→0x00FA), and then sending it to edge node 1 (covering greenhouses 1-5) via the LoRa module after framing.

[0226] The LoRa receiving service of edge node 1 receives data, calls the LoRa plugin to parse it, encapsulates it into ProtocolResponse (result={"temperature":25.0}), and reports it to the central server via MQTT;

[0227] The central server stores data in InfluxDB, and the Grafana interface displays the temperature trend of greenhouse 1.

[0228] (2) Triggering a switchover (data mutation):

[0229] TEMP-008 detected that the temperature rose from 25.0℃ to 32.0℃ within 1 minute (the rate of change is 7.0℃ / minute, which is greater than 5℃ / minute), triggering the protocol switching condition;

[0230] The sensor sends a handover request (including the current temperature and the request protocol type MQTT) to edge node 1 via the LoRa protocol.

[0231] Edge node 1 queries the switching policy of the configuration center, confirms that the target protocol is MQTT, and returns the MQTT configuration (Broker address, port, topic).

[0232] (3) Protocol switching and real-time reporting (MQTT):

[0233] TEMP-008 initializes the MQTT module, connects to the EMQ X Broker (tcp: / / emqx.example.com:1883), and subscribes to the control topic "sensor / TEMP-008 / control";

[0234] The sensor switches to the MQTT protocol, collects temperature data every second, and publishes it to the topic "sensor / TEMP-008 / temperature";

[0235] The central server's MQTT receiving service (Spring Cloud Stream bound to a topic) receives data, calls the MQTT plugin to parse it, and pushes it to the Grafana interface in real time. When the administrator discovers an abnormal temperature, he issues a "turn on ventilation" control command.

[0236] (4) Switch back to LoRa (to restore stability):

[0237] After ventilation, the temperature stabilizes at 30.0℃, and no control command is issued within 30 minutes, triggering the condition to switch back to LoRa;

[0238] Edge node 1 sends a switching command to TEMP-008 (LoRa protocol, reporting period 5 minutes).

[0239] The sensor disconnects from the MQTT connection, initializes the LoRa module, resumes periodic reporting, and there is no data loss during the switching process (the three data entries during the switching period are cached and retransmitted after the switch).

[0240] Local query process for edge nodes (edge ​​node 1 queries greenhouse 1 sensor):

[0241] (1) The local monitoring script (developed in Python) of edge node 1 executes a local query every 5 minutes to obtain real-time data from 20 sensors in greenhouse 1;

[0242] (2) The script calls the Modbus RTU plugin to generate a query command (function code 0x03, register address 0x0001-0x0004, slave address 1-20).

[0243] (3) The plug-in sends Modbus RTU frame data through the RS485 port ( / dev / ttyUSB0), and the sensor temporarily switches to the Modbus RTU protocol (the original LoRa protocol is suspended) and receives query commands;

[0244] (4) The sensor parses the instruction, reads the register data (such as TEMP-008 temperature 30.0℃ → 0x0138), and returns the frame response;

[0245] (5) The plugin parses the response frame, encapsulates the ProtocolResponse and returns it to the script, and the script caches the data in the local SQLite database;

[0246] (6) After the query is completed, the sensor resumes the LoRa protocol and continues to report periodically. The local query response time is 280ms≤300ms, which meets the requirements.

[0247] New NB-IoT protocol access process:

[0248] (1) Developers develop NB-IoT protocol plugins:

[0249] The plugin package name is nb-iot-protocol-plugin-1.0.0.jar, the description file is configured with type=NB-IoT, version=1.0.0, the implementation class is com.protocol.plugin.nbiot.NbIoTProtocolAdapter, and it depends on com.nbiot:nbiot-sdk:1.0.0;

[0250] (2) Developers upload the plugin package to the remote repository of the central server, and the administrator adds a protocol switching policy in the Nacos configuration center (lowPowerReport: protocol=NB-IoT, reportInterval=600000).

[0251] (3) The administrator updates the device-protocol mapping and adds " :“NB-IoT” (soil sensor for remote greenhouse);

[0252] (4) When the edge node sensing configuration changes, the NB-IoT plugin is automatically downloaded and loaded without restarting;

[0253] (5) After the soil sensor (SOIL-101-Remote) in the remote greenhouse is deployed, it automatically connects to the NB-IoT network and reports data according to the NB-IoT protocol. The central server parses the data through the NB-IoT plugin and completes the access. The whole process takes 2 days (1 day for development and 1 day for deployment).

[0254] IV. Implementation Results

[0255] In this embodiment, the sensor network dynamically switches between three protocols to adapt to different business scenarios, achieving the following effects:

[0256] Protocol switching efficiency: Switching time ≤ 500ms, data loss rate 0%, meeting real-time requirements;

[0257] Power consumption optimization: The sensor has a battery life of 12 months in LoRa mode and 2 months in MQTT mode (with external power supply), and power consumption can be reduced by switching as needed;

[0258] Query efficiency: Local query response time at edge nodes is ≤300ms, which is 80% more efficient than remote queries from the central server (average 1500ms).

[0259] Scalability: The development and deployment cycle of the new NB-IoT protocol plugin is 2 days, which supports remote greenhouse sensor access and has low expansion cost;

[0260] Economic efficiency: No need to deploy independent gateways for different protocols, each edge node costs about 500 yuan, and 10 nodes cost only 5,000 yuan, saving 90% compared to the traditional multi-gateway solution (cost of 50,000 yuan).

[0261] Comparison Example

[0262] Compare with Example 1: Device protocol interaction system with a traditional tightly coupled architecture

[0263] System architecture: It adopts a tightly coupled design, directly writing the parsing logic of SNMP, Modbus and Socket protocols into the core business code (such as the device data acquisition module containing SNMP parsing methods and Modbus parsing methods), without layering and plug-in design.

[0264] Problems exist:

[0265] Poor scalability: When adding a LoRa protocol sensor, more than 2,000 lines of core code need to be modified, the development and deployment cycle is 10 days, and the system needs to be shut down for 8 hours during this period;

[0266] Insufficient stability: When the Socket protocol parsing logic malfunctions, the entire data acquisition module crashes, causing a 2-hour system outage;

[0267] Maintenance difficulties: 60% code redundancy, 4 hours to locate faults (e.g., if SNMPOID is misconfigured, all related modules need to be checked).

[0268] Low flexibility: Switching protocols requires a system restart, resulting in a 1-hour monitoring interruption.

[0269] Compared with the present invention: The present invention, through layered decoupling and plug-in architecture, reduces the development cycle of new protocols to 1-2 days, requires no downtime, locates faults in 30 minutes, and enables real-time protocol switching, which is significantly better than the traditional system.

[0270] Compare with Example 2: Device Interaction System with a Single Protocol

[0271] System architecture: Only supports the single SNMP protocol, all devices are required to adapt to SNMP, and there is no multi-protocol adaptation capability.

[0272] Problems exist:

[0273] Poor adaptability: When adding a new Modbus TCP PDU device, an independent Modbus system needs to be developed, forming two independent architectures: "SNMP system + Modbus system", and data cannot be managed uniformly.

[0274] High cost: Two systems require independent servers (increasing cost by 50,000 yuan), and two more development and maintenance personnel are needed (increasing annual cost by 200,000 yuan).

[0275] Insufficient compatibility: Older Socket protocol devices cannot be connected and must be replaced (100 devices, cost 500,000 yuan).

[0276] Compared with this invention: This invention supports unified management of multiple protocols, eliminates the need to develop multiple systems, is compatible with both new and old equipment, and saves hardware and labor costs.

[0277] Compare with Example 3: A plug-in system without dynamic configuration

[0278] System architecture: It adopts a plug-in design, but the protocol and device mapping is managed through local static configuration files (such as protocol-mapping.properties), without a configuration center.

[0279] Problems exist:

[0280] Configuration updates are cumbersome: When adding a new protocol plugin, it is necessary to log in to all edge nodes and manually modify the configuration files, which takes 2 hours for 10 nodes;

[0281] System interruption: A system restart is required for configuration changes to take effect. Monitoring interruption occurs every 30 minutes.

[0282] Poor consistency: Manual modifications are prone to errors, leading to inconsistent configurations on some nodes and device access failures (occurrence rate 10%).

[0283] Compared with the present invention: The present invention achieves real-time configuration updates through a configuration center, without the need for a restart, takes effect within 10 seconds, has 100% configuration consistency, and avoids human error.

[0284] Compare with Example 4: A pluggable system without global exception handling

[0285] System architecture: It adopts a plug-in design, but does not have global exception handling. Exceptions are directly thrown to the core business layer.

[0286] Problems exist:

[0287] System crash risk: When calling an unimplemented protocol interface, a NullPointerException is thrown, causing the core service to crash (occurrence rate 15%).

[0288] No degradation capability: When the plugin fails to load, the device interaction is directly interrupted, affecting business operations (such as the interruption of ACU measurement and control tasks).

[0289] Troubleshooting difficulties: Abnormal information is not recorded in a standardized manner, and the problem location time is 4 hours.

[0290] Compared with the present invention: The present invention achieves a system interruption rate of 0.1% through global exception handling and degradation strategies, automatically degrades when plugin loading fails, standardizes exception logs, and reduces troubleshooting time to 30 minutes.

[0291] This invention achieves complete decoupling between protocol logic and the core system through a three-layer architecture (interface layer, protocol adaptation layer, and core business layer), pluggable protocol management, standardized frame processing and encoding / decoding, global exception handling, and dynamic configuration. This supports dynamic adaptation and efficient management of multiple protocols and versions. Three embodiments cover different application scenarios such as industrial equipment monitoring, aerospace telemetry and control, and smart agriculture, detailing system configuration, workflow, and implementation effects, thus verifying the universality and effectiveness of the invention. The comparative examples, through comparison with traditional systems, single-protocol systems, systems without dynamic configuration, and systems without global exception handling, highlight the significant advantages of this invention in terms of scalability, adaptability, stability, and ease of use.

[0292] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of protection claimed by the present invention. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A plug-in based device interface protocol interaction method, characterized in that, Includes the following steps: (1) Construct a three-layer architecture of interface layer - protocol adaptation layer - core business layer, configure a plugin management module and a global exception handling module to form a protocol interaction system; the interface layer defines standardized interaction interfaces, unifies the methods, parameter formats and return value formats of protocol interaction, and serves as the interaction contract between the core business layer and the protocol adaptation layer; the protocol adaptation layer encapsulates the parsing and framing logic of specific protocols in the form of plugins, decoupling it from the core system; the core business layer focuses on core business logic, calls protocol functions through the interface layer and does not depend on specific protocol implementations; (2) Formulate protocol plugin specifications. Each protocol plugin includes a description file, protocol implementation and dependent resources. The plugin format is uniformly standardized JAR package structure. The plugin management module performs the registration, loading, version management, uninstallation and update operations of protocol plugins. It supports dynamic loading of plugins from local directories or remote repositories, maintains multiple version instances of the same protocol and calls the version matching according to the device request. (3) Design a standardized frame model and general encoding and decoding logic. The frame model includes a frame header, data field and frame tail. The specific data unit is described by the field. The encoding and decoding logic supports a variety of data formats such as bytes, integers and floating-point numbers, as well as endianness mode and precision processing configuration. (4) The global exception handling module presets a default adapter for unimplemented functions, as well as exclusive error codes and handling strategies for exception scenarios such as plugin loading failure, version mismatch, and data format error, so as to realize standardized exception transmission and stable system operation; (5) By configuring the configuration center management protocol and device mapping, plug-in path, frame processing parameters and other configuration contents, the system updates the parameters in real time after the configuration is changed without restarting, thus achieving dynamic adaptation; The standardized interaction interface includes core methods such as dataReport (data reporting), commandQuery (command query), and controlSend (control command issuance); input parameters are encapsulated as ProtocolRequest objects, containing fields for unique device identifier, business data, and protocol version; return values ​​are encapsulated as ProtocolResponse objects, containing fields for execution result, business data, error code, and error message. The protocol adaptation layer implements common functions such as protocol initialization and parameter verification through the abstract class AbstractProtocolAdapter; it also implements standardized interaction interfaces for Socket, SNMP and Modbus protocols, and encapsulates the protocol-specific encoding / decoding and frame structure processing logic. The plugin description file is META-INF / protocol.yml, which records the protocol type, version, implementation class path, and compatible device type metadata. The plugin management module implements isolated loading and instantiation of plugins through a custom ProtocolClassLoader, and has a built-in conflict detection mechanism that returns an error message when the protocol version is incompatible or the dependency is missing. The general encoding and decoding logic includes read field parsing and write field conversion methods; the read method extracts data from the byte stream and converts it into a unified Java object format, and the write method converts the unified format data into a protocol-specific byte stream; The exception degradation strategy of the global exception handling module includes: when the plugin fails to load, try to load a lower version of the same protocol plugin; when the versions do not match, prompt the device to update the protocol version or the system to supplement the plugin; and capture and convert all exceptions uniformly through ProtocolException. The configuration center uses Nacos or Consul, supports real-time modification of the protocol and device mapping relationship, realizes dynamic switching of device protocols, and the system takes effect within 10 seconds after the configuration is updated. The plugin management module supports hot deployment. Adding or updating protocol plugins does not require stopping the system, and the plugin package is loaded and takes effect within 30 seconds after being uploaded. The standardized frame model's fields can be configured with offset, length, default value, and verification rule attributes; frame processing parameters include frame timeout and retry count, which can be dynamically adjusted through the configuration center. The core business layer includes device monitoring services and command scheduling services. It calls protocol functions through standardized interaction interfaces. Business logic and protocol implementation are isolated, and the core code does not need to be modified when a new protocol is added.

Images