A heterogeneous protocol access system and method

Abstract

The embodiment of the application provides a heterogeneous protocol access system and method, the heterogeneous protocol access system comprises: a basic universal layer, which is used for providing universal basic service capabilities required by heterogeneous protocol collection, the universal basic service capabilities comprise: identity authentication and connection management of an access device, and generation of a standardized collection task; a protocol adaptation layer, which is used for loading and unloading a coding and decoding plug-in, and performing coding conversion and decoding restoration of protocol data through the loaded coding and decoding plug-in; and a cloud native access layer, which is used for encapsulating the heterogeneous protocol access system as a container instance and reporting the decoded and restored data to the cloud. The technical solution of the application can effectively solve the problems of low development efficiency, poor reusability and complicated protocol expansion of heterogeneous protocol adaptation in the prior art.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a heterogeneous protocol access system and method. Background Technology

[0002] Against the backdrop of the rapid development of the Industrial Internet, the manufacturing sector has an increasingly urgent need for data acquisition from industrial equipment such as machine tools and sensors. Data acquisition is the core foundation for achieving production monitoring, fault early warning, and efficiency optimization. Currently, the technical approaches to industrial equipment data acquisition mainly fall into two categories: one is customized acquisition solutions, which involve developing dedicated acquisition programs for specific equipment protocols; the other is general-purpose acquisition solutions, which attempt to achieve multi-device adaptation by integrating multiple protocols. With the popularization of cloud-native technologies, industrial IoT platforms are gradually migrating to cloud-native architectures, placing higher demands on the elasticity, dynamic deployment, and high compatibility of data acquisition devices.

[0003] In existing technologies, customized data acquisition solutions require the redevelopment of an entire acquisition program for devices using different protocols. Because the common capabilities of each protocol are not abstracted and extracted, the architecture is highly coupled, resulting in extremely low development efficiency and poor reusability. In general-purpose data acquisition devices, the protocol parsing module is tightly coupled with the core framework; adding a new protocol requires modifying the core code and recompiling and redeploying, making protocol expansion cumbersome. Furthermore, most acquisition solutions require on-site deployment of hardware terminals, making it impossible to directly connect to data center cloud-controlled IoT systems as a software gateway. They also lack flexibility in resource adjustment when device access fluctuates, failing to meet the needs of rapid adaptation, efficient reuse, and flexible expansion of heterogeneous protocols in manufacturing scenarios. Summary of the Invention

[0004] This application provides a heterogeneous protocol access system and method to at least solve the problems of low development efficiency, poor reusability, and cumbersome protocol extension in the prior art.

[0005] According to one embodiment of this application, a heterogeneous protocol access system is provided, comprising:

[0006] The basic general layer is used to provide general basic service capabilities required for heterogeneous protocol collection. These general basic service capabilities include: identity authentication and connection management of access devices, and generation of standardized collection tasks.

[0007] The protocol adaptation layer is used to load and unload codec plugins, and to perform encoding conversion and decoding restoration of protocol data through the loaded codec plugins;

[0008] The cloud-native access layer is used to encapsulate the heterogeneous protocol access system into container instances and to report the decoded and restored data to the cloud.

[0009] In one embodiment of this application, the basic general layer further includes:

[0010] The data caching and retransmission module is used to cache collected data when the network is abnormal and trigger a retransmission mechanism after the network is restored to ensure data integrity.

[0011] The log monitoring module is used to collect the system's operating status and generate alarm information when an anomaly is detected. The system operating status includes the plugin loading status, connection status, and data transmission status.

[0012] In one embodiment of this application, the basic general layer is further used for:

[0013] The national cryptographic algorithm SM2 is used to perform two-way authentication between access devices and the system, and a unique digital certificate is assigned to each access device.

[0014] When a disconnection is detected, a reconnection mechanism with an increasing interval is triggered until the maximum number of reconnections is reached or the connection is successfully established.

[0015] In one embodiment of this application, the protocol adaptation layer is further configured to:

[0016] Based on the service discovery mechanism, scan plugin implementation classes that conform to the predefined standardized interfaces;

[0017] Verify the completeness of the codec plugin interface implementation and its compatibility with the system;

[0018] Plugins that pass verification are loaded into the plugin pool. During uninstallation, the thread pool corresponding to the codec plugin is closed and resources are released through the class loader isolation mechanism.

[0019] In one embodiment of this application, the predetermined standardized interface includes the following core abstract methods:

[0020] The encoding method receives standardized data acquisition task instructions and encodes them into binary format data corresponding to the industrial protocol.

[0021] The decoding method receives binary response data returned by the device and decodes it into a standardized acquisition response object.

[0022] The initialization method receives protocol parameter configuration and completes plugin initialization.

[0023] The compatibility verification method is used to perform version and interface adaptation verification when the plugin is loaded.

[0024] In one embodiment of this application, the cloud-native access layer is further configured to:

[0025] The system is encapsulated into an independent operating unit using containerization technology;

[0026] Register service information through the service registry and perform a health check mechanism to remove unhealthy instances from the service list.

[0027] In one embodiment of this application, the cloud-native access layer is further configured to:

[0028] The decoded and restored data is sent to the specified cloud topic via a message queue;

[0029] When a message fails to be sent, it will be resent according to the preset retry interval and maximum number of retries until it is successfully sent or the retry limit is reached.

[0030] In one embodiment of this application, the system further includes an elastic telescopic unit;

[0031] The elastic scaling unit is used to adjust the number of container instances according to preset scaling indicators; the scaling indicators include a device access number threshold and a system resource utilization threshold; when the scaling indicator exceeds the set threshold, a new container instance is added; when the scaling indicator is less than the set threshold, the number of container instances is reduced.

[0032] According to one embodiment of this application, a heterogeneous protocol access method is provided, including:

[0033] The device is authenticated using a preset algorithm. Once authentication is successful, a persistent network connection is established, the device protocol type is recorded, and a standardized collection task is generated based on the configured collection strategy.

[0034] The corresponding codec plugin is invoked to encode the standardized task into a device-recognizable protocol format and send it to the device;

[0035] The system receives response data from the receiving device, decodes it into standardized collection response objects using an encoding / decoding plugin, caches or processes the data, and then reports the processed data to the cloud via a message queue.

[0036] In one embodiment of this application, the invocation of the corresponding codec plugin includes:

[0037] Based on the protocol type, retrieve matching codec plugins from the plugin pool;

[0038] The plugin is loaded using the class loader isolation mechanism, and encoding conversion is performed.

[0039] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0040] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0041] By applying the technical solution of this application, the system performs identity authentication and connection management for access devices and generates standardized collection tasks through a basic general layer, establishing a data flow starting point from device access to task generation. Then, through a protocol adaptation layer, codec plugins are loaded and unloaded. The loaded codec plugins are used to perform encoding conversion and decoding restoration of protocol data, encapsulating the differentiated data processing logic of different protocols in independent plugins. This decouples the protocol adaptation logic from the core framework, allowing for adjustments to plugins without modifying the core code when adding or changing protocols. Finally, a cloud-native access layer encapsulates the heterogeneous protocol access system as container instances and reports the decoded data to the cloud, achieving containerized deployment of the system to adapt to the cloud-native environment. This layered architecture combined with a plug-in mechanism enables the system to quickly extend to new protocols in a plug-in manner when dealing with heterogeneous protocols, avoiding frequent modifications to the core code. This effectively solves the problems of low development efficiency, poor reusability, and cumbersome protocol extension in existing technologies, improving protocol adaptation efficiency and system reusability, and ensuring the orderly collection of heterogeneous protocol data. Attached Figure Description

[0042] Figure 1 This is a structural block diagram of a heterogeneous protocol access system according to an embodiment of this application;

[0043] Figure 2 This is a schematic diagram of the structure of a heterogeneous protocol access system according to an embodiment of this application;

[0044] Figure 3 This is a flowchart of a heterogeneous protocol access method according to an embodiment of this application;

[0045] Figure 4 This is a structural diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0046] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0047] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0048] To facilitate understanding of the technical solutions in this application, a brief introduction to the technologies involved in this solution is provided.

[0049] This embodiment provides a heterogeneous protocol access system. Figure 1 This is a structural block diagram of a heterogeneous protocol access system according to an embodiment of this application, such as... Figure 1 As shown, the heterogeneous protocol access system includes:

[0050] The basic general layer is used to provide the general basic service capabilities required for heterogeneous protocol collection. These general basic service capabilities include: identity authentication and connection management of access devices, and generation of standardized collection tasks.

[0051] The protocol adaptation layer is used to load and unload codec plugins, and to perform encoding conversion and decoding restoration of protocol data through the loaded codec plugins;

[0052] The cloud-native access layer is used to encapsulate heterogeneous protocol access systems into container instances and to report decoded and restored data to the cloud.

[0053] In this embodiment, the focus is first on building the general basic service capabilities required for heterogeneous protocol acquisition, aiming to provide unified underlying support for upper-layer services. These service capabilities mainly cover two core functionalities: first, authentication and connection management of access devices; and second, generation of standardized acquisition tasks. By implementing authentication and connection management, the system can establish a reliable and stable communication link with access devices, ensuring that only legitimately authenticated devices can establish connections, thereby guaranteeing access security. Based on this, by generating standardized acquisition tasks, the system abstracts the differentiated acquisition requirements for different heterogeneous protocols into a unified format of task instructions, shielding the specific differences in the underlying protocols and laying the data structure foundation for subsequent unified scheduling and processing.

[0054] In this embodiment, by performing the loading and unloading operations of the codec plugin, dynamic management and resource scheduling of protocol adaptation capabilities are realized. At the same time, the loaded codec plugin is used to encode and decode the protocol data, completing the format exchange between heterogeneous protocol data and standardized data. Thus, flexible expansion of protocol functions and efficient data processing are supported without restarting the core process.

[0055] In this embodiment, the heterogeneous protocol access system is first encapsulated as a container instance. This operation aims to leverage the lightweight and isolation characteristics of container technology to package the software system, including the basic general layer, protocol adaptation layer, and cloud-native access layer, and its dependent environment, into an independent deployment unit. This enables standardized deployment of the soft gateway in a cloud-native data center environment, eliminating the need for on-site hardware deployment and supporting Kubernetes-based automated operation and maintenance and elastic scaling. Subsequently, the decoded and restored data is reported to the cloud. This involves connecting to the cloud-controlled IoT system through the cloud-native access layer. Using the internal network and message queues (such as Kafka), the data, processed and standardized by the protocol adaptation layer's encoding and decoding plugin, is transmitted to the cloud platform in real time, completing the closed-loop data flow from industrial field equipment to the cloud-controlled IoT system and ensuring the integrity and real-time nature of the data required for production monitoring.

[0056] By applying the technical solution of this application, the system performs identity authentication and connection management for access devices and generates standardized collection tasks through a basic general layer, establishing a data flow starting point from device access to task generation. Then, through a protocol adaptation layer, codec plugins are loaded and unloaded. The loaded codec plugins are used to perform encoding conversion and decoding restoration of protocol data, encapsulating the differentiated data processing logic of different protocols in independent plugins. This decouples the protocol adaptation logic from the core framework, allowing for adjustments to plugins without modifying the core code when adding or changing protocols. Finally, a cloud-native access layer encapsulates the heterogeneous protocol access system as container instances and reports the decoded data to the cloud, achieving containerized deployment of the system to adapt to the cloud-native environment. This layered architecture combined with a plug-in mechanism enables the system to quickly extend to new protocols in a plug-in manner when dealing with heterogeneous protocols, avoiding frequent modifications to the core code. This effectively solves the problems of low development efficiency, poor reusability, and cumbersome protocol extension in existing technologies, improving protocol adaptation efficiency and system reusability, and ensuring the orderly collection of heterogeneous protocol data.

[0057] Optionally, the basic general layer also includes: a data caching and retransmission module, which is used to cache collected data when the network is abnormal and trigger a retransmission mechanism after the network is restored to ensure data integrity;

[0058] The log monitoring module is used to collect system operating status and generate alarm information when an anomaly is detected. The system operating status includes plug-in loading status, connection status, and data transmission status.

[0059] In this embodiment, the data caching and retransmission module monitors the network link status in real time. When network signal interruption or fluctuations prevent data transmission, it temporarily stores the collected raw data in local storage. Once the network link is restored, it automatically reads the cached data and re-initiates transmission requests in sequence, thus ensuring that data is not lost in unreliable network environments. The log monitoring module continuously collects key operating indicators within the system through a hook interface, including the loading and unloading progress of codec plugins, the heartbeat maintenance status of device connections, and the real-time throughput of data stream transmission. When abnormal situations such as plugin loading failure, connection timeout, or data stream stagnation are detected, an alarm log containing the type of abnormality and the time of occurrence is immediately generated, so that maintenance personnel can quickly locate the source of the fault. The basic general layer integrates the above two functions. On the one hand, it uses the caching and retransmission mechanism to make up for the shortcomings of traditional solutions that directly discard data when the network jitter occurs, ensuring the integrity and continuity of the collected data. On the other hand, it realizes the visualization of the system's operating status through multi-dimensional status monitoring, so that plugin abnormalities or connection failures can be detected and warned in time, significantly improving the stability and maintainability of the heterogeneous protocol access system.

[0060] Optionally, the basic general layer is also used for: performing two-way authentication between access devices and the system using the national cryptographic SM2 algorithm, assigning a unique digital certificate to each access device; and triggering a reconnection mechanism with an incrementing interval when a disconnection is detected, until the maximum number of reconnections is reached or the connection is successfully established.

[0061] In this embodiment, the national cryptographic algorithm SM2 is used for two-way authentication between the access device and the system. This means that before the device establishes a connection, the system and the device use asymmetric encryption technology to verify each other's identity, ensuring that both communicating parties are legitimate entities, rather than a one-way server verifying the client. A unique digital certificate is assigned to each access device. This means that when the system initializes or connects for the first time, it generates and binds an encrypted credential containing its unique identity information for each physical device. This credential serves as the device's "digital ID card" in the system, preventing unauthorized devices from impersonating and accessing the system. When a disconnection is detected, an incremental reconnection mechanism is triggered. This means that after the connection monitoring unit detects a link interruption, it does not immediately and frequently retry, but gradually increases the time interval of reconnection attempts according to a preset exponential backoff strategy (such as 1 second, 2 seconds, 4 seconds, 8 seconds, etc.) until the connection is restored or the set maximum retry limit is reached. Through the above steps, a highly secure access threshold is constructed using the national cryptographic SM2 algorithm and a unique digital certificate, effectively resisting the risks of identity forgery and unauthorized access, and ensuring the legitimacy of the data source. At the same time, the incremental reconnection strategy avoids the impact of frequent invalid requests caused by instantaneous network fluctuations on system resources, and achieves automatic connection recovery while ensuring network stability. This significantly improves the continuity of data collection and the robustness of the heterogeneous protocol access system in complex network environments.

[0062] Optionally, the protocol adaptation layer is also used for: scanning plugin implementation classes that conform to the predetermined standardized interface based on the service discovery mechanism; verifying the integrity of the codec plugin interface implementation and its compatibility with the system; loading plugins that pass the verification into the plugin pool, and closing the thread pool corresponding to the codec plugin and releasing resources during uninstallation through the class loader isolation mechanism.

[0063] In this embodiment, scanning plugin implementation classes that conform to a predetermined standardized interface based on the service discovery mechanism means that the system automatically retrieves and locates plugin code that conforms to specific specifications during startup or runtime. For example, it searches for Java class files that implement the unified encoding / decoding interface in a specified directory, thus identifying available plugins without manual configuration. Verifying the completeness of the encoding / decoding plugin interface implementation and its compatibility with the system means performing static or dynamic verification on the plugin code before loading to ensure that it contains all necessary method definitions and has no version conflicts. For example, it checks whether the plugin fully implements the "decoding" core method. If a key interface is missing or a dependency library is incompatible, loading is intercepted and an exception is thrown to prevent the main program from crashing due to plugin defects. Plugins that pass verification are loaded into the plugin manager. The pool signifies that verified plugins are instantiated and stored in a dedicated collection for memory management, enabling rapid subsequent invocation. When a plugin needs to be uninstalled, the thread pool corresponding to the encoding / decoding plugin is shut down and resources are released through a class loader isolation mechanism. This means that an independent class loader is used to create an isolated namespace for each plugin. During uninstallation, only the thread execution flow specific to that plugin is cut off and its occupied memory space is reclaimed, without affecting the main program or the runtime environment of other plugins. Compared to existing technologies where plugin uninstallation may lead to global resource leaks or require a system restart, this solution achieves fine-grained management of the plugin lifecycle, ensuring that the heterogeneous protocol access system can maintain uninterrupted service and no resource leaks when dynamically adding or deleting encoding / decoding capabilities, significantly improving system stability and operational efficiency.

[0064] Optionally, the predefined standardized interface includes the following core abstract methods:

[0065] The encoding method receives standardized data acquisition task instructions and encodes them into binary format data corresponding to the industrial protocol.

[0066] The decoding method receives binary response data returned by the device and decodes it into a standardized acquisition response object.

[0067] The initialization method receives protocol parameter configuration and completes plugin initialization.

[0068] The compatibility verification method is used to perform version and interface adaptation verification when the plugin is loaded.

[0069] In this embodiment, the predefined standardized interface provides a unified development specification and behavioral constraints for codec plugins by defining four core abstract methods: encoding method, decoding method, initialization method, and compatibility verification method. Specifically, the encoding method converts standardized acquisition task instructions from the upper layer into the binary data format required by specific industrial protocols, ensuring the compliance of data transmission; the decoding method performs the reverse operation, restoring the binary response data returned by the device into a standardized acquisition response object recognizable by the system, ensuring the accuracy of data parsing; the initialization method receives and applies protocol parameter configurations, completing the environment preparation before plugin operation; and the compatibility verification method intervenes during the plugin loading stage, automatically performing adaptation checks by comparing the plugin version and interface implementation. By adopting the above interface definition, the plugin development process is standardized, shielding the differences in underlying details of different industrial protocols. This not only reduces the complexity of plugin development but also effectively avoids system compatibility issues caused by inconsistent interfaces or version conflicts through a unified compatibility verification mechanism, improving the scalability and maintenance efficiency of the heterogeneous protocol access system.

[0070] Optionally, the cloud-native access layer can also be used to: encapsulate the system as an independent running unit using containerization technology; register service information through a service registry and perform a health check mechanism to remove unhealthy instances from the service list.

[0071] In this embodiment, "using containerization technology to encapsulate the system as an independent running unit" refers to packaging software with heterogeneous protocols accessing the system and its dependent environments into standardized container images, so that each instance has an isolated file system, network stack, and process space, thereby avoiding resource conflicts between different instances; "registering service information through the service registry" means that after the container starts, it actively reports its own metadata such as IP address, port number, and version information to the service registry of the cloud-native platform, so that the cluster can be aware of the existence of available service nodes; "performing a health check mechanism" means that the monitoring component periodically sends probe requests (such as HTTP heartbeats or TCP connection tests) to each container instance to confirm whether the instance is in a normal operating state; "removing unhealthy instances from the service list" means that when the health check fails continuously or the response times out, and the instance is determined to be faulty, the routing information of the instance is automatically removed from the service registry to prevent traffic from being distributed to the node. The above steps work together to ensure a clean operating environment through instance isolation, achieve dynamic discovery through service registration, monitor status in real time through health checks, and automatically remove faulty nodes. This achieves fault isolation without interrupting the overall service, ensuring that only instances in good condition participate in business processing, and significantly improving the service continuity and stability of the system in a cloud-native environment.

[0072] Optionally, the cloud-native access layer is also used for:

[0073] The decoded and restored data is sent to the specified cloud topic via a message queue;

[0074] When a message fails to be sent, it will be resent according to the preset retry interval and maximum number of retries until it is successfully sent or the retry limit is reached.

[0075] In this embodiment, when the cloud-native access layer reports the decoded and restored data to the cloud, it introduces a message queue mechanism as an intermediate transmission channel. That is, instead of directly pushing the data point-to-point, the data is delivered to a designated cloud topic for caching. When the first message transmission fails due to network fluctuations or momentary unavailability of cloud services, the retransmission control unit intervenes and automatically triggers retransmission logic according to the preset retry interval and maximum number of retries. For example, after the first failure, it waits 5 seconds to try again. If it still fails, it gradually extends the interval according to the exponential backoff strategy and continues to retry until the transmission is successful or the set retry limit is reached. This process ensures the persistent storage and eventual consistency of the data, thereby effectively solving the problem of data loss caused by a single network transmission failure in the prior art, and greatly improving the reliability and stability of the heterogeneous protocol access system reporting data to the cloud.

[0076] Optionally, the system also includes a flexible telescopic unit;

[0077] The elastic scaling unit is used to adjust the number of container instances according to preset scaling indicators; the scaling indicators include the device access number threshold and the system resource utilization threshold; when the scaling indicator exceeds the set threshold, a new container instance is added; when the scaling indicator is less than the set threshold, the container instance is reduced.

[0078] In this embodiment, the system introduces an elastic scaling unit as the core of dynamic resource scheduling. This unit determines whether it is necessary to adjust the scale of container instances in the cloud-native access layer by real-time monitoring two key scaling indicators: the current number of connected devices threshold and the system resource utilization threshold. Specifically, when a surge in the number of connected devices or the utilization of resources such as CPU and memory exceeds a preset limit is detected, the elastic scaling unit automatically triggers a scaling mechanism to dynamically create and deploy new container instances to join the cloud-native access layer. These newly added instances then undertake some of the encoding / decoding conversion and data reporting tasks for heterogeneous protocols, thereby distributing the connection management pressure of the basic general layer. The system reduces the computational load on the power and protocol adaptation layers, preventing processing delays or data loss due to sudden load increases. Conversely, when the number of offline devices increases or resource utilization falls below a preset lower limit, the elastic scaling unit performs a scaling-down operation, orderly terminating and removing redundant container instances, and releasing occupied cloud-native environment resources. Through this automated scaling-down mechanism based on actual load indicators, the system can match the drastic traffic fluctuations caused by the start-up or shutdown of production lines or the addition or reduction of production lines in industrial manufacturing scenarios in real time. This eliminates the idle waste caused by fixed resource allocation and prevents system overload during peak periods, achieving both efficient utilization of computing resources and continuous data acquisition.

[0079] This embodiment provides a heterogeneous protocol access method, which is executed by the aforementioned heterogeneous protocol access system. Figure 3 This is a flowchart of a heterogeneous protocol access method according to an embodiment of this application, such as... Figure 3 As shown, the method includes:

[0080] S302. Use a preset algorithm to authenticate the device. After successful authentication, establish a persistent network connection, record the device protocol type, and generate a standardized collection task according to the configured collection strategy.

[0081] S304. Call the corresponding codec plugin to encode the standardized task into a device-recognizable protocol format and send it to the device.

[0082] S306: Receive the response data returned by the receiving device, decode it into a standardized collection response object through the codec plugin, cache or process the response data, and report the processed response data to the cloud through the message queue.

[0083] This application also provides a heterogeneous protocol access method. By employing a preset algorithm to authenticate devices, a persistent network connection is established and the device protocol type is recorded upon successful authentication. Combined with a configured collection strategy, standardized collection tasks are generated, achieving standardization and automation of the access process and effectively avoiding security risks from unauthorized device access. Subsequently, the corresponding encoding / decoding plugin is invoked to encode the standardized tasks into a device-recognizable protocol format and send it to the device. Upon receiving response data, it is decoded into a standardized collection response object using the same plugin. This plugin-based dynamic encoding / decoding mechanism allows the system to adapt to different protocols without modifying the core code, significantly improving the flexibility and development efficiency of heterogeneous protocol access. Finally, the data is cached or processed and reported to the cloud via a message queue. The caching mechanism ensures data integrity during network fluctuations, and the message queue enables asynchronous reporting, reducing the impact of data transmission on front-end collection. This achieves highly reliable, low-latency cloud data synchronization, solving the problems of difficult protocol adaptation, easy data loss during reporting, and poor real-time performance in traditional solutions.

[0084] Optionally, invoking the corresponding codec plugin includes: retrieving a matching codec plugin from the plugin pool based on the protocol type; loading the plugin using the class loader isolation mechanism; and performing encoding conversion.

[0085] In this embodiment, "retrieving matching codec plugins from the plugin pool" means that the system uses the pre-recorded device protocol type as an index key to accurately locate and obtain the corresponding codec processing module in a pre-built plugin repository. For example, when the protocol type is identified as "Modbus," the plugin file encapsulating Modbus data parsing logic is directly retrieved, rather than blindly traversing all available plugins. "Loading plugins using a class loader isolation mechanism" means that the system does not share the same global class loading context for each plugin, but instead instantiates an independent class loader instance for the specific plugin retrieved. The plugin code is loaded, the class is defined, and initialized in this independent environment, ensuring that the third-party libraries or internal classes that the plugin depends on are completely isolated from the main application and other plugins, without interference. By combining this precise retrieval based on protocol type with isolated loading based on independent class loaders, not only are the risks of resource conflicts or memory leaks caused by shared class paths in traditional dynamic loading methods avoided, but the independence and stability of different protocol plugins during encoding conversion are also ensured, improving the operational security and maintenance efficiency of the heterogeneous protocol access system during dynamic expansion.

[0086] Figure 2 This is a schematic diagram of a heterogeneous protocol access system according to an embodiment of this application, such as... Figure 2As shown, the core architecture of the heterogeneous protocol access system of this invention is a "three-layer modular layered decoupled architecture." The core design goal is to achieve "general capability reuse, flexible protocol adaptation, cloud-native elastic deployment, and seamless integration with cloud-controlled IoT." Each layer achieves data interaction and command transmission through standardized interfaces, with low coupling between layers and high cohesion within layers, facilitating independent iteration and maintenance. The soft gateway is deployed entirely within the FAW data center's cloud-native environment, without any on-site hardware deployment. Industrial equipment directly connects to the soft gateway in the data center via the factory's industrial network using various industrial protocols. After protocol conversion and data processing by the soft gateway, the data is reported to the cloud-controlled IoT system through the internal network, forming an end-to-end access link of "device-soft gateway-cloud-controlled IoT." See the attached diagram for a detailed architecture diagram. Figure 2 The core roles of each layer are as follows: ① Basic General Layer: Encapsulates the core capabilities shared by all protocols, providing standardized basic services for upper layers; ② Protocol Adaptation Layer: Enables rapid adaptation of heterogeneous protocols based on a plug-in mechanism, shielding the differences in details between different protocols; ③ Cloud-Native Access Layer: Enables deep adaptation of software gateways with data center cloud-native environments and cloud-controlled IoT systems, ensuring elastic scaling and stable connection.

[0087] This layer is the foundational support layer of the entire software gateway architecture. Its core objective is to abstract and encapsulate the common core capabilities used in all industrial protocol acquisition processes, avoiding redundant development and reducing the coupling between upper-layer modules. This layer is developed using Java (relying on Java's mature ecosystem, robust multi-threading mechanism, and rich industrial-grade component support to ensure service stability). It contains four core modules, the functions, internal components, and interactions with other layers of each module are as follows:

[0088] The device authentication and connection management module consists of a key authentication unit, a digital certificate unit, and a connection status monitoring unit. It employs the national cryptographic algorithm SM2 to achieve two-way authentication between the device and the data collector, assigning a unique digital certificate to each access device (stored in a cloud-native configuration center). The connection status monitoring unit checks the connection link every 100ms, triggering a reconnection mechanism when a disconnection occurs (reconnection intervals are 1s, 3s, and 5s, with a maximum of 5 reconnections). This module communicates with the protocol adaptation layer through an "authentication result feedback interface," allowing only authenticated devices to enter the protocol parsing process.

[0089] Data caching and retransmission module: Utilizing a domestically developed Redis Cluster (adapted for domestic IT environments) as the caching component, the cache capacity can be dynamically adjusted through cloud-native configuration. When network fluctuations occur, collected data is first cached in a local queue (maximum cache size 100,000 records). After network recovery, it is synchronized to the platform via the "cached data retransmission interface." Simultaneously, a cache eviction policy (LRU algorithm) is configured to prevent cache overflow. This module interfaces with the message queue of the cloud-native access layer to ensure data transmission integrity.

[0090] The data acquisition task scheduling module supports two strategies: scheduled data acquisition (minimum acquisition interval of 10ms) and triggered data acquisition (triggered by platform commands). It receives scheduling parameters from the cloud-native configuration center via the "task configuration interface," generates task queues, and allocates them to the corresponding protocol plugins. The module has a built-in task priority management unit, prioritizing production monitoring tasks (priority 1) over regular data acquisition tasks (priority 2) to prevent high-priority tasks from being blocked.

[0091] The log monitoring module comprises three sub-units: operation logs, exception logs, and resource usage logs. Logs follow the JSON format and are uploaded in real-time to a cloud-native logging system (such as the ELK Stack) via a "log reporting interface." When plugin anomalies, authentication failures, or data loss occur, alerts are automatically triggered (alert levels are categorized as severe / general / notice), supporting rapid problem troubleshooting.

[0092] The protocol adaptation layer is the core extension layer of the entire architecture, enabling rapid adaptation to heterogeneous protocols. Its core design principle is "standardized interface definition + replaceable plugin implementation." By encapsulating the differentiated encoding and decoding logic of protocols into independent plugins, it achieves the goal of "unchanged core framework, plugins extended as needed," solving the problem of cumbersome protocol extensions in traditional architectures. This layer uses the Java SPI mechanism to dynamically load and manage plugins. It interfaces with the basic general layer through standardized interfaces to obtain data such as device authentication results and collection task commands, and then sends the decoded standardized data back to the basic general layer. The specific design is as follows:

[0093] Standardized Encoding / Decoding Interface Definition: To achieve compatibility between plugins and the core framework, a unified interface specification (fully qualified name: com.faw.iot.protocol.ProtocolCodecInterface) is designed, containing four core abstract methods covering the entire protocol adaptation process: ①encode(CollectRequest req): Receives the standardized acquisition task instruction (CollectRequest object) passed from the basic general layer, encodes it into binary format data of the corresponding industrial protocol for device recognition; ②decode(byte[] resp): Receives the binary response data returned by the device, decodes it into a standardized CollectionResponse object, and sends it back to the basic general layer; ③init(Map<String, String> params): During plugin initialization, it receives protocol parameters (such as baud rate and timeout) from the cloud-native configuration center to complete the plugin configuration; ④ checkCompatibility(): When the plugin is loaded, it performs a compatibility check to verify the integrity of the plugin interface implementation, version compatibility, and adaptability to the current core framework. All codec plugins must strictly implement this interface to ensure that they can be recognized and called by the core framework.

[0094] Encoding / Decoding Plugin Design: The plugin is developed in Java and encapsulated as a JAR file based on the Java SPI (Service Provider Interface) mechanism. It includes an encoding module, a decoding module, and a parameter configuration module. Taking the Modbus protocol plugin as an example: the encoding module converts platform acquisition commands (such as reading machine tool speed) into Modbus RTU format (including fields such as slave address, function code, register address, and data length); the decoding module converts the hexadecimal data returned by the device into a JSON format recognizable by the platform; and the parameter configuration module supports dynamic adjustment of protocol parameters such as baud rate, data bits, and parity bits through the configuration center.

[0095] Dynamic plugin loading / unloading mechanism: Plugin loading is implemented based on the Java SPI mechanism. When the collector starts, it scans the classpath for implementations of the ProtocolCodecInterface interface (JAR package plugins need to have their fully qualified interface names configured in the META-INF / services directory) using ServiceLoader. It then calls the plugin's checkCompatibility() method for compatibility verification. If the verification passes, the plugin is loaded into the plugin pool. During unloading, the corresponding thread pool is shut down using the class loader isolation mechanism to release resources without restarting the collector's core process. The plugin pool supports concurrent access and is thread-safe using ReentrantLock.

[0096] The cloud-native access layer is a crucial adaptation layer for the soft gateway architecture to adapt to the cloud-native environment and interface with the cloud-controlled IoT system. Its core objective is to achieve containerized deployment, elastic scaling, service registration and discovery, and data interoperability with the cloud-controlled IoT system, ensuring the stable operation and efficient integration of the soft gateway within the FAW data center's cloud-native environment. This layer is built upon existing domestically developed cloud-native components in the data center (Kubernetes, Nacos, Kafka, etc.) and interacts with the basic general layer through "data reporting interfaces" and "configuration synchronization interfaces." The specific design is as follows:

[0097] Containerized deployment adaptation: The software gateway (collector) is encapsulated in Docker containers. The base image is a domestic Tongxin UOS operating system image. Resource limits are configured in the Dockerfile. The entire deployment is carried out in the cloud-native environment of FAW's data center. It supports two modes of Kubernetes: Deployment (stateless deployment) and StatefulSet (stateful deployment). The StatefulSet mode is used for scenarios that require persistent plugin configuration. The plugin storage directory is mounted through PVC, without any on-site hardware deployment.

[0098] Service Registration and Discovery: Integrating the domestic service registry Nacos, the collector automatically registers its service information (including service name, IP address, port, and health status) with Nacos upon startup. The platform discovers collector instances through Nacos, enabling load balancing of collection tasks. A health check mechanism is executed every 30 seconds, automatically removing unhealthy instances from the service list.

[0099] Elastic scaling and adaptation: Dynamic scaling of instances is achieved through Kubernetes HPA (Horizontal Pod Autoscaler), with two scaling metrics set: ① Number of connected devices (threshold: a maximum of 500 devices per instance; if this is exceeded, a new instance is added); ② CPU utilization (threshold: 70%; if this threshold is exceeded for 2 consecutive minutes, a new instance is added; if it is below 30%, an instance is reduced). During scaling, Nacos is used to smoothly migrate tasks, avoiding data loss.

[0100] Data reporting adaptation: The software gateway connects to the cloud-controlled IoT platform via the data center's internal network, supporting integration with the cloud-native message queue Kafka (domestic version) that accompanies the cloud-controlled IoT. Collected data is sent to the designated topic via Kafka's Producer, using Avro serialization (to improve transmission efficiency). A built-in message sending retry mechanism is included, with 3 retries at 2-second intervals to ensure reliable data reporting to the cloud-controlled IoT system.

[0101] Based on the above three-layer architecture, the heterogeneous protocol access method of this invention forms an implementation path of "layered architecture implementation + closed-loop process control". The core process is divided into four steps, each of which strictly corresponds to the functional division of each layer of the architecture, and the process is seamlessly connected:

[0102] Architecture initialization phase: After the soft gateway container instance starts, the cloud-native access layer first registers service information (service name, IP, port) with Nacos to complete the connection with the cloud-native environment; then, it pulls global configuration parameters from the cloud-native configuration center through the configuration synchronization interface and synchronizes them to the basic general layer to complete the loading of common parameters such as authentication policies and log levels; finally, the protocol adaptation layer scans and loads the codec plugins specified by the configuration center through the Java SPI mechanism, performs compatibility verification, generates a plugin pool, and completes the initialization and readiness of the entire architecture.

[0103] Device access authentication phase: Industrial equipment sends an access request to the soft gateway through the factory production network. The request data first enters the identity authentication module of the basic general layer. The module uses the SM2 national cryptographic algorithm to verify the device's digital certificate and key. After successful authentication, the connection management module establishes a persistent network connection, records the device protocol type, and requests the corresponding codec plugin to be allocated to the protocol adaptation layer. If authentication fails, the connection is rejected, and the log monitoring module reports an alarm.

[0104] Protocol encoding / decoding and data acquisition phase: The task scheduling module of the basic general layer generates standardized acquisition tasks according to the configured acquisition strategy (timed / trigger-based) and passes them to the corresponding plugins in the protocol adaptation layer through the interface; the plugin encoding module encodes the standardized tasks into a device-recognizable protocol format and sends them to the device through the network; after the device responds with data, the plugin decoding module converts it into a standardized CollectResponse object and sends it back to the data caching and retransmission module of the basic general layer.

[0105] In the data reporting and status monitoring phase: the cache module of the basic general layer transmits the decoded data to the cloud-native access layer through the interface, and the access layer reports the data to the cloud control IoT system through Kafka; at the same time, the log monitoring module of the basic general layer collects the running status of each layer in real time (plugin loading status, connection status, data transmission status), generates log data and reports it to the cloud-native log system through the access layer; if network fluctuations or plugin anomalies occur, the cache module triggers the retransmission mechanism, and the protocol adaptation layer triggers the plugin switching strategy to ensure the continuity of data collection.

[0106] The beneficial effects of this invention stem directly from the core design of the three-layer architecture and the synergistic effect of the technical solutions at each layer. The architecture design and technical effects are strongly correlated, and the specific correspondence is as follows:

[0107] Three-layer decoupled architecture + standardized interface design: General capabilities and differentiated protocol logic are encapsulated in layers, and with the help of a unified encoding and decoding interface, new protocol adaptation only requires the development of plugins without modifying the core architecture, reducing the development workload by more than 60% and directly achieving a significant improvement in development efficiency.

[0108] Cloud-native access layer architecture adaptation solution: Through containerized deployment, HPA elastic scaling, Nacos service registration and discovery, the soft gateway can dynamically adapt to fluctuations in device access volume, ensuring latency ≤100ms even when the concurrent access volume of devices increases by 5 times, while realizing automated operation and maintenance, directly supporting cloud-native adaptability and elastic scaling requirements.

[0109] The Java SPI plugin mechanism in the protocol adaptation layer supports dynamic loading / unloading of plugins and remote configuration updates. Combined with the log monitoring module in the basic general layer, it enables remote troubleshooting and repair of plugin anomalies without on-site intervention, reducing maintenance workload by more than 80% and lowering maintenance costs.

[0110] The multi-dimensional guarantee mechanism of the basic general layer: combined with the compatibility verification of the protocol adaptation layer, a full-link stability guarantee system of "interface verification - thread isolation - cache retransmission" is formed to avoid the impact of a single plug-in failure on the overall architecture operation, reduce the failure rate by 90%, and the data loss rate ≤0.01%, thereby improving the operational stability.

[0111] The architecture is designed for domestic IT innovation adaptation: the basic general layer and cloud-native access layer are both compatible with domestic software and hardware. With plug-in protocol adaptation capabilities, it can quickly adapt to various industrial protocols, increasing the device access coverage to 3 times that of traditional solutions, and achieving architecture-level extended compatibility and domestic IT innovation adaptation.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0113] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps in any of the above method embodiments.

[0114] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0115] Embodiments of this application also provide an electronic device 400, such as... Figure 4 As shown, it includes a processor 401 and a memory 402, in which a computer program is stored, and the processor 401 is configured to run the computer program to perform the steps in any of the above method embodiments.

[0116] In one exemplary embodiment, the electronic device 400 may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor 401 and the input / output device is connected to the processor 401.

[0117] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0118] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0119] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0120] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A heterogeneous protocol access system, characterized in that, The system includes: The basic general layer is used to provide general basic service capabilities required for heterogeneous protocol collection. These general basic service capabilities include: identity authentication and connection management of access devices, and generation of standardized collection tasks. The protocol adaptation layer is used to load and unload codec plugins, and to perform encoding conversion and decoding restoration of protocol data through the loaded codec plugins; The cloud-native access layer is used to encapsulate the heterogeneous protocol access system into container instances and to report the decoded and restored data to the cloud.

2. The system according to claim 1, characterized in that, The basic general layer also includes: The data caching and retransmission module is used to cache collected data when the network is abnormal and trigger a retransmission mechanism after the network is restored to ensure data integrity. The log monitoring module is used to collect the system's operating status and generate alarm information when an anomaly is detected. The system operating status includes the plugin loading status, connection status, and data transmission status.

3. The system according to claim 1, characterized in that, The basic general layer is also used for: The national cryptographic algorithm SM2 is used to perform two-way authentication between access devices and the system, and a unique digital certificate is assigned to each access device. When a disconnection is detected, a reconnection mechanism with an increasing interval is triggered until the maximum number of reconnections is reached or the connection is successfully established.

4. The system according to claim 1, characterized in that, The protocol adaptation layer is also used for: Based on the service discovery mechanism, scan plugin implementation classes that conform to the predefined standardized interfaces; Verify the completeness of the codec plugin interface implementation and its compatibility with the system; Plugins that pass verification are loaded into the plugin pool. During uninstallation, the thread pool corresponding to the codec plugin is closed and resources are released through the class loader isolation mechanism.

5. The system according to claim 4, characterized in that, The predefined standardized interface includes the following core abstract methods: The encoding method receives standardized data acquisition task instructions and encodes them into binary format data corresponding to the industrial protocol. The decoding method receives binary response data returned by the device and decodes it into a standardized acquisition response object. The initialization method receives protocol parameter configuration and completes plugin initialization. The compatibility verification method is used to perform version and interface adaptation verification when the plugin is loaded.

6. The system according to claim 1, characterized in that, The cloud-native access layer is also used for: The system is encapsulated into an independent operating unit using containerization technology; Register service information through the service registry and perform a health check mechanism to remove unhealthy instances from the service list.

7. The system according to claim 1, characterized in that, The cloud-native access layer is also used for: The decoded and restored data is sent to the specified cloud topic via a message queue; When a message fails to be sent, it will be resent according to the preset retry interval and maximum number of retries until it is successfully sent or the retry limit is reached.

8. The system according to claim 1, characterized in that, The system also includes a flexible telescopic unit; The elastic scaling unit is used to adjust the number of container instances according to preset scaling indicators; the scaling indicators include a device access number threshold and a system resource utilization threshold; when the scaling indicator exceeds the set threshold, a new container instance is added; when the scaling indicator is less than the set threshold, the number of container instances is reduced.

9. A heterogeneous protocol access method, characterized in that, Applied to the heterogeneous protocol access system as described in any one of claims 1-8, the method includes: The device is authenticated using a preset algorithm. Once authentication is successful, a persistent network connection is established, the device protocol type is recorded, and a standardized collection task is generated based on the configured collection strategy. The corresponding codec plugin is invoked to encode the standardized task into a device-recognizable protocol format and send it to the device; The receiving device returns response data, which is then decoded into a standardized collection response object through an encoding / decoding plugin. The response data is then cached or processed, and the processed response data is reported to the cloud through a message queue.

10. The method according to claim 9, characterized in that, The invocation of the corresponding codec plugin includes: Based on the protocol type, retrieve matching codec plugins from the plugin pool; The plugin is loaded using the class loader isolation mechanism, and encoding conversion is performed.

Images