An industrial communication protocol adaptation method and system based on OpenHarmony

Abstract

The application relates to the technical field of industrial control and discloses an industrial communication protocol adaptation method and system based on OpenHarmony. The method comprises the following steps: performing distributed soft bus deployment on a plurality of industrial devices in an industrial control network to obtain a distributed device connection architecture; loading a multi-protocol adapter on an industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; identifying and configuring the communication protocols of the plurality of industrial devices according to the multi-protocol runtime service instance to obtain standardized device data; establishing a data transmission channel according to the standardized device data, and performing global state synchronization and collaborative control instruction distribution on the plurality of industrial devices to generate a distributed collaborative control network. The application simplifies the deployment and maintenance work of the industrial control system, improves the accuracy and consistency of system configuration, reduces the risk of manual configuration errors, and reduces the development cost and maintenance complexity of industrial applications.

Description

Technical Field

[0001] This invention relates to the field of industrial control technology, and in particular to an industrial communication protocol adaptation method and system based on OpenHarmony. Background Technology

[0002] In modern industrial control systems, industrial sites typically deploy a large number of industrial devices from different manufacturers and of different models, including PLC controllers, SCADA systems, robotic arms, and sensors. These devices use their own independent industrial communication protocols, such as OPC-UA, Modbus, Profinet, CAN bus, and serial communication, creating a serious "data silo" problem. Due to the lack of a unified communication standard, heterogeneous devices cannot directly exchange data and coordinate control, which severely restricts the intelligence level of the entire industrial control system.

[0003] Traditional industrial control systems generally employ point-to-point communication, requiring each device to be configured with a separate communication module and conversion interface for different protocols. This architecture not only increases system complexity and maintenance costs but, more importantly, fails to support real-time collaborative control between devices. When multiple devices in an industrial setting need to coordinate to complete complex tasks, existing technologies often rely on manual configuration or centralized control by a host computer, resulting in problems such as large response delays, poor scalability, and low reliability. These limitations make it difficult to meet the stringent requirements of modern intelligent manufacturing for equipment collaboration and real-time performance. Summary of the Invention

[0004] The main objective of this invention is to provide an industrial communication protocol adaptation method and system based on OpenHarmony. This invention simplifies the deployment and maintenance of industrial control systems, improves the accuracy and consistency of system configuration, reduces the risk of manual configuration errors, and reduces the development cost and maintenance complexity of industrial applications.

[0005] To achieve the above objectives, this invention provides an industrial communication protocol adaptation method based on OpenHarmony, comprising the following steps: A distributed soft bus is deployed for multiple industrial devices in an industrial control network to obtain a distributed device connection architecture. A multi-protocol adapter is loaded into the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; Based on the multi-protocol runtime service instance, the communication protocol of the multiple industrial devices is identified and configured to obtain standardized device data. A data transmission channel is established based on the standardized equipment data, and global status synchronization and collaborative control command distribution are performed on the multiple industrial devices to generate a distributed collaborative control network.

[0006] Optionally, in a first implementation of the first aspect of the present invention, the step of deploying a distributed soft bus on multiple industrial devices in an industrial control network to obtain a distributed device connection architecture includes: Deploy the libjicruntime_server.z.so server library at the central node of the industrial control network and generate a distributed soft bus; Based on the distributed soft bus, the libjicruntime_client.z.so client library is deployed to multiple industrial devices in the industrial control network to form a set of device nodes; For each device node in the device node set, perform device type identification and communication capability detection to generate a device capability descriptor; The network distance and communication delay parameters between the multiple industrial devices are calculated based on the device capability descriptor, and a distributed device connection architecture is generated based on the network distance and the communication delay parameters.

[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of loading a multi-protocol adapter for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance includes: Extract the protocol type identifier and communication interface parameters of each device node from the distributed device connection architecture, and determine the protocol parsing quantity and version information based on the protocol type identifier and the communication interface parameters; Based on the number of protocols parsed and the version information, the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are parsed to extract the driver library path and initialization parameters corresponding to each protocol; According to the driver library path and the initialization parameters, the libjicruntime_server.z.so server library, libjicruntime_client.z.so client library and libjicruntime.z.so SDK library are loaded sequentially. After loading is completed, the service registration process is executed to obtain the registered service components. The registered service components are logically restructured to generate multi-protocol runtime service instances.

[0008] Optionally, in a third implementation of the first aspect of the present invention, the step of parsing the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file based on the quantity and the version information, and extracting the driver library path and initialization parameters corresponding to each protocol, includes: The jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are read from file streams and parsed using character encoding to obtain the original configuration data set. Based on the quantity and the version information, perform regular expression matching and version number comparison operations on the protocol identifier field in the original configuration data set to filter the target configuration data segment; Based on the library_path and module_path fields in the target configuration data segment, path strings are extracted and path validity is verified to obtain the driver library path corresponding to each protocol. The parameter values ​​of the init_params, connection_timeout, and buffer_size fields in the target configuration data segment are parsed and their data types are converted to obtain the initialization parameters corresponding to each protocol.

[0009] Optionally, in a fourth implementation of the first aspect of the present invention, the step of identifying and configuring the communication protocols of the plurality of industrial devices according to the multi-protocol runtime service instance to obtain standardized device data includes: The multi-protocol runtime service instance sends standard protocol probe sequences to the multiple industrial devices respectively, and obtains the protocol response frame feature code and version identifier returned by each industrial device; Perform pattern matching operations on the protocol response frame feature code and the version identifier to obtain a device protocol mapping table; Based on the protocol type information in the device protocol mapping table, a protocol parser component is constructed for each protocol, and the original protocol data frames sent by each industrial device are parsed byte by byte based on the protocol parser component to obtain a set of parsed data packets; The data field structures of different protocols in the parsed data packet set are rearranged and type-labeled to obtain a standard data structure; The standard data structure is converted and a protocol-unified converter is established; Based on the unified protocol converter, the device connection parameters and data acquisition rules of the multiple industrial devices are configured to obtain standardized device data.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, the step of converting the standard data structure and establishing a protocol unified converter includes: Perform a byte position reversal operation on the integer and floating-point values ​​in the standard data structure to obtain the numerical data; The 32-bit single-precision floating-point number of the numerical data is expanded to a 64-bit double-precision format to obtain floating-point data, and the string content contained in the floating-point data is automatically identified by encoding type to obtain character data; Construct a mapping index from source address to target address based on the character data, and establish a bidirectional lookup table containing protocol type, data address, and conversion function pointer based on the mapping index; When data of any protocol is received in the bidirectional lookup table, the corresponding conversion rule is located and the data format conversion is performed to obtain a unified protocol converter.

[0011] Optionally, in a sixth implementation of the first aspect of the present invention, the configuration of the device connection parameters and data acquisition rules of the plurality of industrial devices based on the protocol unified converter to obtain standardized device data includes: The connection parameters of each industrial device are configured through the configuration interface opened by the unified protocol converter to obtain a set of connection configuration parameters. Based on the device protocol information in the connection configuration parameter set, data point scanning and attribute parsing are performed on each industrial device to obtain the model configuration parameter set; The acquisition frequency is calculated based on the data change characteristics in the model configuration parameter set to obtain data acquisition rules. The configuration parameters in the data acquisition rules are then mapped and formatted according to the unified industrial data model to obtain standardized equipment data.

[0012] Optionally, in the seventh implementation of the first aspect of the present invention, the step of establishing a data transmission channel based on the standardized equipment data and performing global state synchronization and collaborative control command distribution to the multiple industrial devices to generate a distributed collaborative control network includes: The data volume of data identifiers, data types, timestamps, quality identifiers, security levels, and device source identifiers in the standardized equipment data is statistically analyzed to obtain the data transmission memory requirements. Based on the data transmission memory requirement, the getShmem() interface is called to send a memory request to the industrial automation runtime service. After receiving the memory request, the industrial automation runtime service allocates the corresponding size of anonymous shared memory and returns a GetShmemResponse object to obtain the shared memory resource. The memory region is divided according to the memory address and size parameters of the shared memory resources to obtain a hierarchical memory data structure, and the hierarchical memory data structure is mapped to the virtual address space of each industrial equipment process to obtain a data transmission channel; Based on the data transmission channel, global status synchronization and control command distribution are performed on the multiple industrial devices to generate a distributed collaborative control network.

[0013] Optionally, in an eighth implementation of the first aspect of the present invention, the step of performing global state synchronization and control command distribution on the plurality of industrial devices based on the data transmission channel to generate a distributed collaborative control network includes: The global device status data of the multiple industrial devices is read through the data transmission channel. Based on the global device status data, an equipment evaluation is performed to carry out industrial control tasks, resulting in a control task allocation scheme. According to the control task allocation scheme, the call() interface is called to send control instructions in UInt8Array format to each industrial device. The control instructions are transmitted to each industrial device through a distributed soft bus and execution confirmation in CallResponse format is obtained, thus obtaining the control instruction transmission link. The execution results of devices in the control command transmission link are summarized and analyzed. When any industrial device completes a control action, the global device status data is updated and synchronized to other industrial devices to obtain a distributed collaborative control network.

[0014] This invention also provides an industrial communication protocol adaptation system based on OpenHarmony, comprising: The deployment unit is used to deploy multiple industrial devices in the industrial control network in a distributed soft bus configuration, resulting in a distributed device connection architecture. The loading unit is used to load the multi-protocol adapter for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; The configuration unit is used to identify and configure the communication protocols of the multiple industrial devices according to the multi-protocol runtime service instance to obtain standardized device data. The generation unit is used to establish a data transmission channel based on the standardized equipment data, and to perform global state synchronization and collaborative control command distribution to the multiple industrial devices to generate a distributed collaborative control network.

[0015] In summary, this invention breaks down the physical boundaries and system barriers between traditional industrial equipment by establishing a distributed soft bus architecture, achieving deep interconnection and interoperability among heterogeneous devices such as PLC controllers, SCADA systems, and robotic arms. By dynamically loading over 100 industrial protocol adapters, it supports mainstream industrial communication protocols such as OPC-UA, Modbus, and CAN bus, and establishes a bidirectional conversion mapping table between protocols, completely eliminating the long-standing "data silo" problem in industrial control. The data transmission channel built using shared memory and zero-copy technology reduces data exchange latency to the microsecond level, significantly improving system real-time performance. Through global state synchronization and collaborative control mechanisms, it achieves intelligent collaborative control where tasks are executed on the most suitable equipment and data flows in real time where needed, much like connecting the factory's neural network. Based on the "develop once, deploy across multiple platforms" characteristic of a unified development toolchain, it significantly reduces the development cost and maintenance complexity of industrial applications. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the steps of an industrial communication protocol adaptation method based on OpenHarmony in one embodiment of the present invention; Figure 2 This is a block diagram of an industrial communication protocol adaptation system based on OpenHarmony in one embodiment of the present invention.

[0017] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0019] Reference Figure 1 This embodiment provides an industrial communication protocol adaptation method based on OpenHarmony, including the following steps: S1, deploy a distributed soft bus for multiple industrial devices in the industrial control network to obtain a distributed device connection architecture; The libjicruntime_server.z.so server library is deployed at the central node of the industrial control network. As the core operating module of the distributed soft bus, libjicruntime_server.z.so undertakes basic communication management functions such as device registration, connection scheduling, data forwarding, and status coordination. Its deployment process is based on the central node operating system platform running HualongOS. It is loaded and run by the system service framework and registered to the system service manager, establishing a unified service port for all network devices. This constructs the main control structure of the distributed soft bus at the logical layer. Based on the distributed soft bus, the libjicruntime_client.z.so client library is deployed to each of the multiple industrial devices already connected to the industrial control network. The libjicruntime_client.z.so client library is embedded into the operating systems of various industrial devices, including PLC controllers, edge computing gateways, smart sensors, and industrial touch terminals. The registration and loading of the dynamic link library are completed through the system configuration path. This builds a terminal access channel for the distributed bus on the physical network and forms a device node set containing multiple industrial device nodes. This device node set constitutes the collaborative execution unit in the distributed communication system. The system proactively performs type identification and communication capability detection operations on each node in the device node set via a soft bus interface. This includes identifying the architecture of the device's operating platform, assessing memory and processor capabilities, identifying supported protocol stack types, detecting interface speeds, and acquiring indicators such as whether it supports dual-channel WiFi or Ethernet communication. Based on the detection results, a device capability descriptor is automatically generated. This descriptor records the communication attributes, processing capabilities, and adaptability of each device in a structured format. Network topology analysis is then performed on the devices based on the capability descriptors. This includes calculating physical network distance parameters between devices and communication latency parameters obtained from packet return latency tests. Based on this, a distributed device topology graph with node weights and connectivity costs is established. Connection optimization is then performed according to the principles of minimum network load and maximum communication efficiency, thereby generating a distributed device connection architecture best suited to the current industrial task scheduling and data flow requirements.

[0020] S2, load the multi-protocol adapter for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; Specifically, the runtime service invokes the node descriptor query mechanism of the distributed soft bus to extract the protocol type identifier and communication interface parameters of each device node from the distributed device connection architecture. Each device node reports its supported communication protocol types (e.g., OPC UA, Modbus, CAN, serial port, Ethernet, WiFi, etc.), open interface port information, baud rate, communication frame structure characteristics, and version number, etc., during connection initialization. Based on this information, a protocol parsing requirement table is generated, reflecting the number of protocol types and their corresponding version information required by the current system. According to the number and version information of protocols to be parsed, the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are loaded sequentially and semantic-level parsing operations are performed. During this process, the runtime service identifies key information such as the driver library path, dynamic link library name, initialization function entry point, default initialization parameters, error code table path, and log level configuration for each protocol through the configuration parsing module, thereby constructing a mapping index relationship for driver loading. Based on the parsing results, the libjicruntime_server.z.so server library, libjicruntime_client.z.so client library, and libjicruntime.z.so SDK library are loaded in dependency order. The server library is deployed at the central node and is responsible for registration and scheduling management. The client library is deployed on each edge device to establish data bridging between the protocol communication stack and the soft bus interface. The SDK library is used by upper-layer business logic to complete cross-device data read and write operations. After all dynamic libraries are loaded, the service registration process is initiated. The system service manager registers the capability services, data services, event services, and management interface services provided by each driver, ensuring that upper-layer applications can discover and bind them on demand. After registration, based on device role classification, protocol stack functional characteristics, and operational efficiency requirements, the registered service components are logically restructured, dividing device services into a data acquisition layer, protocol conversion layer, service mediation layer, and upper-layer business call layer. Through logical path optimization and interface standardization, multi-protocol runtime service instances are generated.

[0021] S3 identifies and configures the communication protocols of multiple industrial devices based on multi-protocol runtime service instances to obtain standardized device data. It should be noted that, through the multi-protocol communication capabilities integrated by the multi-protocol runtime service instance, a pre-formatted standard protocol probe sequence is sent to each industrial device node in the distributed device connection architecture. This standard probe sequence is encapsulated according to the startup specifications of different communication protocols. Its function is to actively stimulate device responses and probe the types and versions of protocols supported internally. Upon receiving the probe sequence, each device returns feedback data containing protocol response frame signatures and version identifiers. The feedback response data frame contains fields such as protocol flags, start byte structure, function code, verification mechanism, and version information. All returned response frame contents are uniformly accessed by the protocol identification module, and a byte-by-byte pattern matching operation is performed. The byte-by-byte pattern matching process is based on the system's built-in protocol fingerprint library. By comparing the key byte bits of the response frame signature and the encoding rules of the version identifier, a device protocol mapping table is generated, recording key information such as the protocol name, master-slave mode, version number, and applicable driver path supported by each device. Based on the protocol type information recorded in the device protocol mapping table, a corresponding protocol parser component is constructed for each protocol. Each parser loads the corresponding state machine model and byte stream parsing template according to the target protocol specification, and performs segmented reading, field verification, and content extraction operations on the raw protocol data frames from the device to obtain a set of parsed data packets. Structural alignment operations are performed on the fields of each protocol in the parsed data packet set, including reconstructing the field arrangement order, standardizing data type annotations, and injecting unit conversion rules, generating a standard data structure with unified semantic tags. A unified protocol converter is built on the standard data structure. Acting as a bridge between the protocol layer and the application layer, the unified protocol converter incorporates multi-protocol field mapping rules and field recoding rules, dynamically converting data parsing results from any source into a unified data model recognized by the system, and controlling the field exposure order and structural nesting level through configuration templates. Based on the unified protocol converter, the configuration operations for the device connection parameters and data acquisition rules of all industrial devices are completed. Configuration operations include device address, communication channel, acquisition cycle, alarm threshold, data filter settings, etc. After configuration, the real-time operating data of all industrial devices is output in a standardized format.

[0022] S4 establishes a data transmission channel based on standardized equipment data, and performs global status synchronization and collaborative control command distribution for multiple industrial devices, generating a distributed collaborative control network.

[0023] Specifically, statistical analysis is performed on data identifiers, data types, timestamps, quality indicators, security levels, and equipment source identifiers in standardized equipment data. This analysis examines the update frequency, data size, and real-time and security requirements of each data field per unit time. Based on this analysis, the total data output scale is calculated to determine the memory capacity required for data transmission under the shared memory mechanism—the data transmission memory requirement. Based on this data transmission memory requirement, the `getShmem()` interface is called to send a memory request to the industrial automation runtime service. The `getShmem()` interface, as the entry function for high-frequency real-time data communication, initiates an anonymous shared memory allocation request to the runtime service. Upon receiving the request, the runtime service executes the resource allocation logic of the memory management module according to the request parameters and returns a `GetShmemResponse` object. The `GetShmemResponse` object contains the physical address handle of the shared memory, the total number of bytes of allocated memory, the memory access status code, and an error reporting mechanism, thus obtaining the shared memory resource. Based on the memory address and size parameters of shared memory resources, spatial segmentation and structural partitioning are performed to generate a logically layered data cache model. The layered memory data structure is organized in multiple levels according to device, data type, and control priority dimensions. Each layer independently corresponds to a data segment and instruction cache area for a type of device. Concurrency control mechanisms such as synchronization markers, write protection locks, and timing tags are established at the logical layer to ensure the integrity and consistency of data read and write processes. The layered memory data structure is mapped to the virtual address space of each industrial device process through a kernel-mode interface mechanism, obtaining a data transmission channel. Based on the data transmission channel, global status synchronization operations are performed on each industrial device. Dynamic indicators such as the running status, load, and communication health of each node are periodically read and updated in shared memory. Simultaneously, control instructions issued by the centralized scheduling and control module are read from shared memory and executed according to priority, including logical start / stop, parameter modification, and alarm linkage control behaviors. This enables end-to-end multi-device collaboration without the participation of a central controller, generating a distributed collaborative control network.

[0024] In one example, a distributed soft bus deployment is implemented for multiple industrial devices in an industrial control network, resulting in a distributed device connection architecture, including: Deploy the libjicruntime_server.z.so server library at the central node of the industrial control network and generate a distributed soft bus; Based on a distributed soft bus, the libjicruntime_client.z.so client library is deployed to multiple industrial devices in the industrial control network to form a set of device nodes; For each device node in the device node set, perform device type identification and communication capability detection, and generate a device capability descriptor; Calculate the network distance and communication latency parameters between multiple industrial devices based on the device capability descriptor, and generate a distributed device connection architecture based on the network distance and communication latency parameters.

[0025] In this example, a node with strong processing power, high memory capacity, sufficient network bandwidth, and relatively stable physical location is selected as the system's central node in the industrial control network. The libjicruntime_server.z.so server library is deployed as a system service in the operating system environment of the central node. As a core component of the industrial automation runtime service, the libjicruntime_server.z.so dynamic link library operates based on the distributed soft bus architecture mechanism of the OpenHarmony operating system. During the system initialization phase, it is incubated through the startup subsystem and completes the population of the service registry, generating a logical soft bus communication channel. The soft bus communication channel supports node management strategies based on service discovery and device identifier binding, allowing multiple industrial devices to connect to a unified bus domain as clients and accept unified scheduling and management, thereby constructing a system-level virtual interconnected backbone structure. In the industrial control network, multiple industrial equipment nodes that need to be included in unified control are selected, including PLC controllers, DCS execution units, intelligent sensor modules, industrial robot terminals, embedded edge computing modules, and industrial mobile terminals. The libjicruntime_client.z.so client library is deployed in each target device according to its local system architecture. The deployment path of the libjicruntime_client.z.so client library follows the standard dynamic link library management specification of HualongOS. After loading, the node performs an initial handshake authentication with the runtime through the system configuration file (such as jicruntime.cfg), completes the node registration process, and obtains the device's unique identifier, access channel key, and synchronization policy parameters issued by the server. This marks the target device as officially included in the soft bus communication domain, thus logically forming a set of device nodes with network controllability and state discoverability. Each node in the set of device nodes has runtime service discovery capabilities, protocol adaptation capabilities, and data communication capabilities.The automatic device identification process is initiated by calling the node query and capability detection API provided at runtime. For each device node in the device node set, device type identification and communication capability detection are performed. The device type identification stage determines the device's control level, data processing capabilities, and communication role by reading metadata such as device hardware structure information, device model number, device manufacturer identifier, firmware version number, and system operating platform. This information is then structured and encoded according to the general classification standards for industrial equipment. The communication capability detection process extracts information such as the protocol stack type (e.g., OPC UA, Modbus, CAN, serial port, WebService), interface bandwidth specifications, maximum concurrent connections, redundant links, multi-protocol concurrency capabilities, and automatic fault switching capabilities supported by the current node, either through proactive data transmission or runtime probing. It also records the node's current physical connection method (Ethernet, WiFi, or RS485), whether QoS policies are enabled, and the supported security mechanism levels. After completing the above process, a structured device capability descriptor is generated for each device. This descriptor records the device's type attributes, communication capabilities, protocol adaptation range, and system resource limits in key-value pairs. Based on the device capability descriptor, a comprehensive calculation and analysis of network distance and communication latency is performed. Based on the current network physical structure information of each node, the physical hop count, link medium type, network topology location, and bandwidth bottleneck point between any two devices are calculated. An ICMP and TCP RoundTrip time sampling mechanism is introduced to obtain the actual communication latency value between node pairs. The calculation results cover network propagation latency, as well as dynamic factors such as protocol stack response latency, data frame queuing time, and shared link blocking time. A full network latency matrix table is generated by combining network bandwidth, current device processing load, and connection saturation. A weighted graph structure is constructed based on the full network latency matrix table to model the communication cost between devices. The distributed device connection architecture automatic generation module is launched. Taking into account the physical location distribution of devices, the dispersion of communication load, the real-time requirements between key control nodes, and fault recovery strategies, the optimal connection path construction algorithm is executed with the goal of minimizing total latency and maximizing system throughput. The optimal connection path construction algorithm supports automatic selection of network logical topology according to star, tree, ring, or hybrid structures. In the actual connection architecture, a hierarchical control strategy is adopted, placing the control center node, edge execution node, and auxiliary data node in different control domains. Dual-channel redundant connection paths are configured for key devices to ensure that the system communication integrity and operational stability can still be maintained in the event of a single link failure, thus generating a distributed device connection architecture.

[0026] In one example, a multi-protocol adapter is loaded for the industrial automation runtime service of the distributed device connectivity architecture to obtain a multi-protocol runtime service instance, including: Extract the protocol type identifier and communication interface parameters of each device node from the distributed device connection architecture, and determine the number of protocol parsings and version information based on the protocol type identifier and communication interface parameters; Based on the number and version information of the protocols parsed, the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are parsed to extract the driver library path and initialization parameters corresponding to each protocol; Based on the driver library path and initialization parameters, the libjicruntime_server.z.so server library, libjicruntime_client.z.so client library, and libjicruntime.z.so SDK library are loaded sequentially. After loading is complete, the service registration process is executed to obtain the registered service components. The registered service components are logically restructured to generate multi-protocol runtime service instances.

[0027] In this example, based on the established set of nodes in the distributed device connection architecture, the interface functions or listening mechanisms provided by the industrial automation runtime service are invoked to sequentially read and cache the protocol type identifiers and communication interface parameter information of all device nodes. The protocol type identifiers include the primary protocol stack types supported by the device (such as OPCUA, Modbus TCP, CANopen, RS485, serial frame structure, etc.), and also record the vendor-specific extensions, version fields, and compatibility parameters for each protocol type. The communication interface parameters cover physical port types (such as Ethernet port number, serial channel, CAN bus address), baud rate settings, byte order, verification methods, and data packet boundary conventions. Based on the protocol identifiers and interface parameters, type clustering and version number extraction are performed. This is used to calculate the total number of protocol types that actually need to be loaded and supported in the current system, i.e., the number of protocol parsing requirements. Simultaneously, the specific version numbers corresponding to each protocol are compiled to generate a protocol support requirement list. Using the protocol support requirements list as input, the configuration parsing module performs structured parsing on the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file located in the deployment path. The jicruntime.cfg file serves as the overall architecture and service management configuration entry point for the system runtime service, providing system-level parameters including library loading order, device registration rules, running mode selection, debug level, log output level, and error handling strategies. The jicruntime.json file acts as a protocol-level configuration container for multi-protocol driver loading, recording key information such as the driver library file path, initialization parameter list, version compatibility strategy, field parsing mapping relationship, protocol status code definition, data channel template, and handshake behavior configuration for each supported protocol. Using a dual-channel reading method based on a JSON parsing engine and an INI configuration reader, the driver library path and initialization parameters matching the protocol list are extracted and stored in a unified protocol component loading index table. Following the driver loading order defined in the configuration, the libjicruntime_server.z.so server library, the libjicruntime_client.z.so client library, and the libjicruntime.z.so SDK library are loaded sequentially. The server-side library is loaded and runs on the central node in the distributed architecture, coordinating and scheduling common functional modules such as authentication management, service discovery, protocol scheduling, and exception handling for client connections. The client-side library is deployed in all industrial devices participating in the communication, playing the role of local protocol parsing and data packaging and execution. The SDK library, as an intermediary bridge between the upper-layer application and runtime services, provides functional interfaces such as API encapsulation, object access, command forwarding, and data channel construction.During library loading, dynamic linking calls are performed, along with symbol matching and initialization parameter injection. This ensures that each driver component can construct the correct state machine, verification mechanism, and data transmission path according to the communication requirements of the target protocol. Furthermore, various libraries use predefined interface function pointers to reference and call interdependent modules. Once all driver libraries are loaded and successfully initialized, the service registration process is initiated by the system service manager. This process registers and binds the service structures exported from each driver library, recording their function identifiers, call paths, protocol adaptation capabilities, and data interface definitions in the runtime service master table and establishing a service directory tree structure. During registration, strategies such as service visibility filtering, duplicate service conflict detection, and abnormal service removal are implemented to ensure that the registered service component set possesses functional completeness, uniqueness, and schedulability, and meets the protocol parsing depth and response speed requirements of the current industrial control task. The registered service components undergo logical architecture reorganization. This involves reclassifying the service components according to dimensions such as protocol type, service function, call frequency, device distribution, communication direction, and call path. These components are then divided into multiple logical substructures, including a basic data acquisition module, a protocol translation module, a device status synchronization module, a control command distribution module, a shared memory management module, and an error recovery module. Furthermore, object-oriented module access paths are constructed using service interfaces as boundaries, resulting in runtime service instances with layered control, parallel parsing, and asynchronous response capabilities.

[0028] In one example, the jicruntime.cfg system configuration file and jicruntime.json protocol configuration file are parsed based on quantity and version information to extract the driver library path and initialization parameters corresponding to each protocol, including: The jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are read from file streams and parsed using character encoding to obtain the original configuration data set. Based on the quantity and version information, perform regular expression matching and version number comparison operations on the protocol identifier field in the original configuration data set to filter the target configuration data segment; Based on the library_path and module_path fields in the target configuration data segment, path strings are extracted and path validity is verified to obtain the driver library path corresponding to each protocol. The parameter values ​​of the init_params, connection_timeout, and buffer_size fields in the target configuration data segment are parsed and their data types are converted to obtain the initialization parameters corresponding to each protocol.

[0029] In this example, the configuration loading submodule in the industrial automation runtime service is invoked. It reads the jicruntime.cfg system-level configuration file and the jicruntime.json protocol-level configuration file located in the system configuration path using a standard file stream. During this process, the character set decoding method is specified to ensure that the configuration file content is correctly interpreted as a standard UTF-8 encoded character sequence, thus guaranteeing consistency of Chinese comments, extended symbols, and multilingual fields across different operating system language environments. During file stream reading, the content is read line by line, and character cleaning operations are performed, including removing illegal newline characters, eliminating comment paragraphs, and correcting common quotation mark mismatch errors in JSON format. The cleaned content is then structured and cached in the original configuration data set, forming a tree-structured data body containing several fields such as protocol name, version information, driver path, initialization parameters, connection timeout settings, buffer size, supported features, status flags, log level, and exception handling strategy. Based on the protocol parsing quantity and version information list, a regular expression matching operation is performed on the protocol identifier field in the original configuration data set. Regular expression matching performs pattern matching on the protocol name field using predefined regular expression templates. It supports fuzzy matching, prefix matching, wildcard expansion, and multi-level namespace extraction. For example, it matches "Modbus-TCP v1.2" with different spellings such as "modbus.*", "modbus-tcp", "MODBUS", and "modbus_v1_2", and uses a unified protocol specification mapping table to standardize the fuzzy results to the standard protocol naming system. After regular expression matching, a version number comparison operation is performed on the `version` field in the configuration field. A three-level comparison mechanism—major version number, minor version number, and patch number—is used. Through string splitting and numerical conversion, the protocol version number in the configuration is compared to see if it matches or exceeds the minimum compatible version in the current system's supported list, ensuring that only target configuration data segments that semantically and functionally match are retained. After version comparison, all filtered protocol configuration fragments are extracted and assembled into a target configuration data segment set. Path string extraction and path validity verification are performed on the `library_path` and `module_path` fields of each target configuration data segment. The path string extraction is based on the absolute path, relative path, or environment variable expression format of the field content. It automatically identifies system variables, current working directory identifiers, and special symbols contained in the path, and corrects non-standard path structures (such as spaces, illegal characters, and unclosed quotation marks in the path).After extraction, the file system interface is called to perform validity verification on the extracted path. This includes checking if the path exists, if it points to a valid .so dynamic library file, if the library file can be read and written by the current user, and if the file has execute permissions. Only paths that pass verification are included in the final driver loading list. For fields where path verification fails, an exception report is generated and logged to the log system. After the driver library path extraction is complete, the init_params, connection_timeout, and buffer_size fields in the target configuration data segment are parsed, and their parameter values ​​are parsed and their data types are converted. The init_params field is a JSON object or a delimited string structure. The init_params field is parsed into a list of initialization parameters in key-value pair form, and each parameter key is mapped to the internal variables required by the driver module according to a predefined data dictionary. For example, if init_params contains entries such as "baud_rate=9600", "parity=none", and "slave_id=1", these values ​​are converted into integer, enumeration, or boolean internal representations and encapsulated into a structure for the driver initialization function to call. The `connection_timeout` and `buffer_size` fields are represented as strings in the configuration file. These are parsed into unsigned integer values ​​or time unit conversion values. Values ​​exceeding a reasonable range are either throttled or flagged with a configuration warning. After extracting and converting the parameter values ​​of all fields, a standardized protocol driver loading parameter structure is generated. This structure includes the driver library file path, loading entry point name, initialization function call parameters, communication timeout settings, and buffer allocation parameters. This protocol driver loading parameter structure is then stored in the protocol adapter registry.

[0030] In one example, communication protocol identification and configuration are performed on multiple industrial devices based on a multi-protocol runtime service instance to obtain standardized device data, including: The multi-protocol runtime service instance sends standard protocol probe sequences to multiple industrial devices and obtains the protocol response frame signature and version identifier returned by each industrial device. Perform pattern matching operations on the protocol response frame signature and version identifier to obtain the device protocol mapping table; Based on the protocol type information in the device protocol mapping table, a protocol parser component is constructed for each protocol, and the original protocol data frames sent by each industrial device are parsed byte by byte based on the protocol parser component to obtain a set of parsed data packets; The data field structures of different protocols in the parsed data packet set are rearranged and type-labeled to obtain a standard data structure; Convert standard data structures and establish a unified protocol converter; Based on a unified protocol converter, the device connection parameters and data acquisition rules of multiple industrial devices are configured to obtain standardized device data.

[0031] In this example, based on a multi-protocol runtime service instance, the internal driver scheduler automatically traverses the set of registered device nodes in the system and dynamically allocates communication session resources to each device node. These resources include device address, communication port, protocol stack dispatch structure, instruction buffer, and response monitor. The protocol identification engine sequentially sends predefined standard protocol probe sequences to each device node. These sequences are constructed based on the connection rules, initialization processes, and handshake modes of commonly used industrial protocols, such as the Modbus protocol's function code 0x11, the Hello / ACK negotiation segment of the OPC UA protocol, and the NMT master broadcast frame of the CANopen protocol. The probe sequences are accompanied by a unique identifier and timestamp during transmission to ensure the returned results have the correct device binding attributes. Upon receiving the probe sequence, the device returns a structured protocol response frame. This frame contains a protocol response signature, protocol version identifier, function segment status code, and protocol extension attribute bits. The frame structure parser extracts the key bytes, binds these key bytes to the device node, and stores them in the initial response buffer pool. The protocol response frame signatures and version identifiers in the initial response cache pool are subjected to pattern matching. The pattern matching engine employs a multi-layered matching mechanism consisting of a regular expression tree, a feature template dictionary, and a device identifier hash value. It performs byte-by-byte comparison of the signatures and combines this with version identifiers to execute version level comparison logic, ensuring that the returned results not only cover the protocol type currently used by the device but also clearly identify the specific version of the protocol. After matching, the results are written to the device protocol mapping table, which records the protocol name, version number, driver library path, required parser type, and response rate parameters for each device. Based on the protocol type information marked in the device protocol mapping table, a corresponding protocol parser component is constructed for each protocol. Each parser component defines its own state machine model, frame boundary recognition rules, verification mechanism, and field extraction template according to the target protocol specification, and loads the parsing function entry point of the corresponding driver library. It registers the frame length, start byte, stop bit, byte alignment, and checksum calculation rules during initialization through configuration parameters. After construction, the parser is attached to the downlink data listener of the device channel. During the equipment data acquisition process, all raw protocol data frames sent from industrial equipment to the system will undergo byte stream processing by the parser component. The sliding window mechanism and frame header verification are used to identify the frame boundaries of continuous data segments. Data segmentation, function code extraction, field pointer mapping and numerical conversion operations are performed according to the protocol frame format to obtain a set of structured parsed data packets.Due to the differences in protocol data structures used by various industrial devices, the parsed data packet set contains original fields with different field orders, inconsistent data units, and inconsistent data types. The standardized structure processing module reconstructs the fields and labels the types of the parsed results. Based on the system's built-in data field mapping rules and semantic coding system, the standardized structure processing module renames the field labels in the parsed data and performs structural rearrangement on the arrangement order of each field. Important fields (such as equipment status quantities, analog inputs, alarm codes, sensor readings, etc.) are placed in unified field positions. At the same time, unified conversion is performed on data types from different sources. For example, hexadecimal temperature values ​​are converted to floating-point Celsius temperatures, Boolean status codes are unified to 01 identifiers, and timestamp fields from different protocols are converted to UTC millisecond standard timestamps in the system's unified format to obtain a standard data structure. The standard data structure is transformed and a unified protocol converter is established. As an abstract adaptation layer between the upper-layer business system and the lower-layer multi-protocol data, the unified protocol converter has core functions including field mapping, data format encoding conversion, abnormal field filling, redundant field filtering and cross-protocol field alignment. The converter maps the structured data output by any protocol parser to a unified format through mapping tables and field adaptation templates, and supports fault-tolerant replacement or default value injection for abnormal fields in the original data stream, ensuring that the upper-layer business will not have missing fields or format errors due to differences in protocol sources during the reading process. Using a unified protocol converter as the core of data processing, the configuration process of connection parameters and data acquisition rules is executed for each industrial equipment node through the configuration interface provided by the runtime service. Connection parameters include device address, communication channel identifier, interface port number, protocol type, session hold time and connection priority, etc. Data acquisition rules include sampling period, filter rules, data accuracy, alarm trigger threshold, data caching strategy and data flow path, etc. All configurations are registered in the system configuration database and sent to the device service process. The service process, in conjunction with the protocol converter, calls the acquisition interface in real time and generates device data output that conforms to the standard format, thereby obtaining standardized device data.

[0032] In one example, the standard data structure is transformed and a protocol-unified converter is built, including: Perform byte position reversal operations on integer and floating-point numbers in standard data structures to obtain numerical data; The 32-bit single-precision floating-point data is extended to a 64-bit double-precision format to obtain floating-point data. The string content contained in the floating-point data is automatically identified by encoding type to obtain character data. Construct a mapping index from source address to target address based on character data, and build a bidirectional lookup table containing protocol type, data address, and conversion function pointer based on the mapping index; When data for any protocol is received in the bidirectional lookup table, the corresponding conversion rule is located and the data format conversion is performed to obtain a unified protocol converter.

[0033] In this example, various fields in the standard data structure are categorized and processed according to their field types. For integer and floating-point fields, a byte reversal operation is performed according to the byte order convention of the respective protocol. This step is used to resolve the differences in byte alignment specifications followed by different industrial devices, such as the compatibility issues between big-endian (MSB-first) and little-endian (LSB-first) order. At runtime, the protocol metadata parser automatically extracts the original byte arrangement corresponding to each field and calls the byte reversal function to reorder the original byte sequence of each integer or floating-point number segment. For example, for a 32-bit integer value 0x12345678, it is converted to 0x78563412 in little-endian mode, ensuring that the value can still be correctly parsed after transmission on the unified data bus. The reversed value is considered as real and valid numerical data. After completing the byte reversal operation, the 32-bit single-precision floating-point number segment in all numerical data is expanded to support the needs of high-precision control and long-cycle cumulative calculation tasks. The expansion method adopts the format transformation mechanism defined in the IEEE 754 standard, splitting the original 32-bit floating-point number into sign, exponent, and mantissa bits, and constructing a corresponding 64-bit double-precision floating-point representation through mantissa padding and exponent expansion, ensuring that the data has sufficient resolution and representation range in high-precision computing scenarios. For rounding errors and infinite value representations that occur during the expansion process, error masking strategies and overflow detection mechanisms are introduced to correct data boundaries and generate conversion status codes. Further detection is performed to determine if any floating-point values ​​contain embedded character content. For example, some industrial communication protocols use floating-point encoding to encapsulate ASCII strings or hexadecimal encoded text. A character pattern recognition function is used to perform semantic probing on each byte segment of the floating-point values. Probing methods include character frequency statistics, printability assessment, start / end control character recognition, and encoding range location. Based on this, the encoding type is determined, such as UTF-8, GB2312, ASCII, or ISO8859-1. The character information encapsulated in the floating-point values ​​is extracted and converted into recognizable character data. A mapping index from source address to target address is constructed based on the parsed character data. This mapping index represents the mapping relationship between the physical address of a field in the source device and the standard field address in the target system across different protocol devices. The mapping relationship involves information such as device logical address, register offset, memory segment number, and buffer start position. During the mapping process, the address differences of the same logical variable in different protocol representations are automatically identified, and a one-to-one mapping table entry is generated based on protocol characteristics. This entry includes the source device ID, source protocol type, source data offset, target field identifier, and target register mapping number. Based on the mapping index, a bidirectional lookup table is constructed. Each item in the lookup table contains three core fields: protocol type field, data address field, and conversion function pointer field.The protocol type field identifies the protocol adapter component corresponding to the mapping table entry. The data address field contains the original data source address and standard address format. The conversion function pointer field points to pre-registered field processing functions, including byte reversal functions, encoding conversion functions, numerical reduction functions, and exception handling callback functions. The bidirectional lookup table supports both forward lookup and reverse tracing modes. When the system receives a new data packet from any protocol device via the soft bus interface or shared memory mechanism, the protocol distribution module extracts the protocol type identifier and field address information from the data and performs a lookup operation in the bidirectional lookup table to locate the corresponding conversion function. During the lookup process, strategies such as hash indexing, protocol priority sorting, and invalid pointer filtering are used to improve matching efficiency. After a successful match, the data format conversion operation is performed through the bound conversion function pointer. The conversion includes byte order reordering, unit conversion, encoding reconstruction, floating-point number splitting, timestamp synchronization, symbol verification, illegal value replacement, and field normalization processing. The output is a standard field data object, which is then submitted to the standard data buffer of the protocol unified converter.

[0034] In one example, a unified protocol converter is used to configure the device connection parameters and data acquisition rules of multiple industrial devices to obtain standardized device data, including: The connection parameters of each industrial device are configured through the configuration interface opened by the unified protocol converter to obtain a set of connection configuration parameters. Based on the device protocol information in the connection configuration parameter set, data point scanning and attribute parsing are performed on each industrial device to obtain the model configuration parameter set; The acquisition frequency is calculated based on the data change characteristics in the model configuration parameter set to obtain data acquisition rules. Then, the configuration parameters in the data acquisition rules are mapped and format converted according to the unified industrial data model to obtain standardized equipment data.

[0035] In this example, the connection configuration task is initiated through the configuration interface exposed by the protocol unification converter. The configuration interface supports three access methods: user interface operation, configuration file import, and automatic identification mechanism. It allows system configuration of multiple key parameters such as communication protocol type, physical connection method, device logical number, port resource allocation, baud rate, verification method, heartbeat cycle, connection persistence strategy, and link redundancy strategy of the access device. The configuration results are uniformly encapsulated into a structured connection configuration parameter set. Each record identifies the protocol identification code, connection parameter group, and status detection item of a certain industrial device. After receiving the configuration request, the verification module performs parameter consistency verification, range legality detection, and protocol adaptation verification to ensure that all configuration fields comply with the corresponding protocol constraints and runtime requirements. The verified connection configuration parameters are written to the runtime device registry as the basic information structure for communication scheduling and data access. The data point scanning task is initiated based on the device protocol information recorded in the connection configuration parameter set. This task is executed by the model parser module within the protocol unification converter. The model parser loads the corresponding data structure description template for each protocol type and guides runtime access to the register space, variable mapping table, or object dictionary in the industrial equipment. Data point traversal, variable tag extraction, and attribute block reading are performed at the field level. The scanning process not only identifies variable names, addresses, and data types but also includes multiple metadata dimensions such as variable scope, unit identifier, upper and lower limits, read / write permissions, whether it participates in alarm triggering, whether it participates in event logs, and its associated function block. After scanning, all field information is summarized to generate the model configuration parameter set. The sampling frequency is calculated based on the data change characteristics in the model configuration parameter set. Combining indicators such as the field's historical change rate, stability level, sensor type, signal change frequency, control response time, and business importance level, the optimal sampling period is calculated for each field using a change frequency algorithm, sliding window oscillation judgment method, or hierarchical decision-making mechanism. For analog fields with rapid changes, a higher sampling frequency and a short-cycle buffering strategy are set, while for status variables or periodically refreshed fields, a lower frequency, edge triggering, and value change-responsive triggering strategy are used. Simultaneously, the acquisition rules define parameters such as data filter settings (e.g., average value filtering, median filtering), alarm judgment conditions (e.g., upper and lower limits, rate value jumps), data validity detection rules (e.g., dead zone judgment, packet loss repair), and channel priority.All configuration parameters in the acquisition rules undergo field mapping and format conversion. Field alignment is performed based on the unified industrial data model, a semantic abstraction framework for multi-protocol industrial equipment. Its goal is to abstract and map variable fields from various protocols to a unified namespace and structural format. During the mapping process, auxiliary information such as field semantic tags, device context, hierarchical structure information, and field affiliation is introduced to ensure consistency in field name, physical origin, and logical meaning. Mapped fields are uniformly represented using structured paths. At the format conversion level, based on the data type fields and model type definitions in the acquisition rules, the data length, encoding method, precision level, and unit standard of the fields are unified. For example, 16-bit integer values ​​are converted to 32-bit standard integers, hexadecimal BCD codes are converted to decimal values, Celsius values ​​are appended with units and output as floating-point numbers, and Boolean values ​​are converted to status enumeration values. All conversions are performed according to a unified type conversion table and encoding rule template, forming a standardized equipment data structure.

[0036] In one example, a data transmission channel is established based on standardized equipment data, and global status synchronization and collaborative control command distribution are performed on multiple industrial devices to generate a distributed collaborative control network, including: The data volume is statistically analyzed for data identifiers, data types, timestamps, quality identifiers, security levels, and equipment source identifiers in standardized equipment data to obtain the data transmission memory requirements. Based on the memory requirements for data transmission, the getShmem() interface is called to send a memory request to the industrial automation runtime service. After receiving the memory request, the industrial automation runtime service allocates the corresponding size of anonymous shared memory and returns a GetShmemResponse object, thus obtaining the shared memory resource. The memory region is divided according to the memory address and size parameters of the shared memory resources to obtain a hierarchical memory data structure. The hierarchical memory data structure is then mapped to the virtual address space of each industrial device process to obtain a data transmission channel. A distributed collaborative control network is generated by synchronizing the global status of multiple industrial devices and distributing control commands based on the data transmission channel.

[0037] In this example, data identifiers, data types, timestamps, quality identifiers, security levels, and device source identifiers are extracted from standardized device data. Each field directly affects the spatial layout and field length configuration of the shared memory data model. Therefore, field-level data volume statistics are performed to calculate the space occupied, change frequency, and update density of each type of field in the data structure. Based on this, a memory requirement estimation model is constructed. The model considers factors such as the number of data points per second per device, the field length of each data point, alignment byte compensation, redundancy area retention ratio, and the maximum number of concurrent devices. This allows for the estimation of the minimum and recommended shared memory space requirements of the complete distributed system within a single control cycle, and the output of the data transmission memory requirement. The industrial automation runtime service initiates a memory allocation request by calling the getShmem() interface provided by the industrial automation runtime service based on the memory requirements for data transmission. The getShmem() interface allows the caller to request an anonymous shared memory space of a specified size as needed for high-speed data interaction and low-latency communication. During the interface call, the call parameters will carry the requester identifier, the requested memory length, the read / write permission flag, and the pre-allocation policy flag. After receiving the request, the industrial automation runtime service searches for, allocates, and binds handles to the currently available memory segments through the memory resource manager, and encapsulates the allocation result into a standard response object GetShmemResponse, which includes the return status code, the shared memory handle, the allocation length, the memory starting address, and the binding token. If the return status code is zero, it indicates that the allocation was successful, and the memory mapping and data structure initialization process continues; otherwise, the reason for failure is recorded according to the error code, and a second downgrade request is attempted. After acquiring shared memory resources, the memory region is divided according to the returned memory address and total memory size parameters, and a multi-level partitioned data cache structure, namely a hierarchical memory data structure, is constructed. The same shared memory space is divided into multiple logical segments according to access granularity, data type, device grouping, and protocol priority. These segments include control status segment, real-time data segment, device identifier segment, event buffer segment, and instruction mapping segment. Each segment is further subdivided into field alignment units and write protection zones to meet the needs of industrial data in terms of high-speed writing, high-frequency reading, multi-threaded access, and atomicity guarantee. Each logical segment is assigned a starting offset address, read / write permissions, and thread lock control structure, and registered in the system shared memory structure registry.After memory region partitioning is completed, the hierarchical memory data structure is mapped to the virtual address space of all industrial device processes involved in control and data interaction through the kernel-mode interface mechanism. During the mapping process, the allocated physical memory segments are mapped to dedicated access paths within the device-side business process space using the mmap mechanism or memory handle redirection. Write protection bits and access flag bits are set according to the process permission model to ensure that different devices do not interfere with each other and that access paths are unique. After successful mapping, each industrial device process has the ability to access shared memory locally and can directly read and write data and instructions issued by the control center, forming a bidirectional data access channel, i.e., a data transmission channel. Based on the data transmission channel, the distributed collaborative control module is started to perform global state synchronization and control instruction distribution operations on all connected industrial devices. State synchronization is achieved by the system master control service periodically traversing the state segments of each device in shared memory and comparing historical and current state values. A synchronization flag bit is generated through an event-triggered mechanism, and the current operating status of all devices is summarized in the master scheduler to form a system-level device state view. Meanwhile, the control command distribution is dynamically generated by the strategy scheduling engine based on real-time collected data and upper-layer business strategies. The control command segments in the shared memory are written to the target device channel by address mapping. The device periodically scans the local shared memory channel address and parses and executes the received valid command, including operations such as logical start / stop, parameter adjustment, action triggering, and process change. All devices complete status synchronization and command response through the same shared memory channel. Structurally, a real-time, efficient, low-latency, and highly consistent distributed collaborative control network is constructed. On the basis of the distributed collaborative control network, complex industrial application control objectives such as multi-device linkage control, centralized production line scheduling, equipment load balancing, and automatic switching in case of anomalies are realized.

[0038] In one example, a distributed collaborative control network is generated by globally synchronizing the status of multiple industrial devices and distributing control commands based on a data transmission channel, including: Read global device status data of multiple industrial devices through data transmission channels; Based on global device status data, an equipment assessment is performed to execute industrial control tasks, resulting in a control task allocation scheme. According to the control task allocation scheme, the call() interface is called to send control instructions in UInt8Array format to each industrial device. The control instructions are transmitted to each industrial device through the distributed soft bus and the execution confirmation in CallResponse format is obtained, thus obtaining the control instruction transmission link. The execution results of devices in the control command transmission link are summarized and analyzed. When any industrial device completes a control action, the global device status data is updated and synchronized to other industrial devices to obtain a distributed collaborative control network.

[0039] In this example, based on a data transmission channel, global status information of multiple industrial devices is continuously read from a pre-built hierarchical memory data structure via a high-speed shared memory communication mechanism or a message buffer mechanism of industrial automation runtime services. This includes each device's current operating mode, task status bits, execution load, resource utilization, health status code, alarm flags, input / output signal status, sensor feedback, and actuator feedback. The global device status data is then input into a distributed task evaluation module for real-time analysis. In the task evaluation module, for the currently pending industrial control tasks, multi-objective weighted scoring is performed on all candidate devices based on factors such as device capability parameters, resource idleness, communication latency, historical completion efficiency, control accuracy level, and device location topology from the global device status data. A distributed evaluation model is then used to rank and select the best device. During the evaluation process, a state weight matrix and scheduling strategy function are applied to dynamically adjust device priorities based on the control characteristics required for different tasks, such as real-time priority, minimum energy consumption, fast response, and strong interconnectivity. When a task can be completed by multiple devices, a sub-task partitioning scheme is automatically constructed, and a device load balancing algorithm is used to allocate sub-tasks, forming a device-task mapping relationship. After evaluation, a structured control task allocation scheme is output. The scheme records which industrial equipment node each task is assigned to, its estimated start time, expected completion time, execution parameters, and response verification strategy. Based on the control task allocation scheme, the `call()` interface is called. A control instruction data frame is constructed based on the device identifier and protocol stack type bound to each allocation item. The control logic parameters are encapsulated as a byte array in UInt8Array format. This byte array encapsulates the device action type, command code, execution parameters, timestamp, checksum, etc., according to the protocol field structure, ensuring that devices under various protocols can correctly parse the control instructions. The `call()` interface provided by the runtime service is called to pass the control request in UInt8Array format to the device execution channel. The `call()` interface call process implements end-to-end instruction routing and load balancing based on a distributed soft bus architecture. Instructions are transmitted from the main scheduling node to the target industrial equipment via the soft bus logical link. The target equipment receives, parses, and prepares for execution at runtime. Simultaneously, the system starts a response listening thread to receive the `CallResponse` structure returned by the device as execution confirmation. The verification object includes the response status code, execution status bit, device echo information, error code, and debug log summary. Based on the response status, it is determined whether the instruction was successfully issued and received by the target device, thus establishing the control instruction transmission link. During the distribution and execution of all control instructions, the execution results of each industrial device are monitored and analyzed in real time. The analysis module extracts the device control result segment from the data transmission channel and correlates it with the assigned task status to determine whether it has been completed or aborted. For devices that successfully return control results, status evaluation and response time recording are performed. For devices that fail or abnormally abort, compensation strategies are implemented and tasks are reassigned.Whenever any industrial device completes a control task and returns a success signal, its status value in the global device status data is immediately updated, marking the task as completed. Simultaneously, the new status is synchronously pushed to all other device nodes via a shared memory broadcast mechanism or a soft bus broadcast link, ensuring consistent system-wide status awareness. The status synchronization mechanism includes a timestamp and status version number, ensuring that devices can perform status alignment or conflict resolution based on the latest version even when triggered at different times.

[0040] Reference Figure 2 This embodiment provides an industrial communication protocol adaptation system based on OpenHarmony, including: Deployment unit 01 is used to deploy multiple industrial devices in the industrial control network in a distributed soft bus to obtain a distributed device connection architecture. Loading unit 02 is used to load the multi-protocol adapter for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; Configuration unit 03 is used to identify and configure the communication protocols of multiple industrial devices based on multi-protocol runtime service instances to obtain standardized device data; Generation unit 04 is used to establish a data transmission channel based on standardized equipment data, and to perform global status synchronization and collaborative control command distribution for multiple industrial devices, thereby generating a distributed collaborative control network.

[0041] In this embodiment, the specific implementation of each unit in the above system embodiment is described in the above method embodiment, and will not be repeated here.

[0042] This invention establishes a unified distributed device connection architecture by deploying the libjicruntime_server.z.so server library and the libjicruntime_client.z.so client library. This breaks down the physical boundaries and system barriers between traditional industrial devices, enabling deep interoperability between different types and functions of industrial intelligent devices, fundamentally solving the technical challenge of isolated device operation. Through protocol matching algorithms and configuration file parsing, it can dynamically load industrial protocol adapters such as OPC-UA parsers, serial communication parsers, and CAN bus parsers, achieving comprehensive support for heterogeneous industrial devices. This significantly improves system compatibility and scalability, providing flexible technical support for equipment upgrades and expansions in industrial settings. By establishing a bidirectional conversion mapping table and standard data structure between protocols, it achieves seamless conversion between heterogeneous protocol data such as OPC-UA node values, Modbus register values, and CAN message data, completely eliminating the long-standing "data silo" problem in industrial control and enabling devices with different protocols to directly exchange and communicate data. Through a three-layer configuration mechanism encompassing connection configuration, model configuration, and data configuration, automated configuration of device connection parameters and data acquisition rules is achieved, significantly simplifying the deployment and maintenance of industrial control systems, improving the accuracy and consistency of system configuration, and reducing the risk of human configuration errors. A high-speed data transmission channel is established using the getShmem() interface and zero-copy technology, avoiding the data copying overhead of traditional network transmission and reducing data exchange latency to the microsecond level. This significantly improves the real-time performance of industrial control systems and meets the stringent requirements of industrial control for data transmission speed. Through the call() interface and global state synchronization mechanism, collaborative control of multiple industrial devices is realized, enabling tasks to be executed on the most suitable devices and data to flow in real time where needed. This is akin to connecting the factory's neural network, allowing instructions and information to instantly reach each execution node, achieving true intelligent manufacturing collaborative control. Based on a unified development toolchain and standardized data model, developers only need to write the core business logic code once to efficiently adapt and run on devices with different hardware resources and screen sizes, significantly reducing the development cost and maintenance complexity of industrial applications and improving software development efficiency and reusability.

[0043] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, system, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, system, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0044] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An industrial communication protocol adaptation method based on OpenHarmony, characterized in that, include: A distributed soft bus is deployed for multiple industrial devices in an industrial control network to obtain a distributed device connection architecture. Specifically, this includes: deploying the libjicruntime_server.z.so server library at the central node of the industrial control network and generating a distributed soft bus; deploying the libjicruntime_client.z.so client library to each of the multiple industrial devices in the industrial control network based on the distributed soft bus, forming a device node set; performing device type identification and communication capability detection on each device node in the device node set to generate a device capability descriptor; calculating the network distance and communication delay parameters between the multiple industrial devices based on the device capability descriptors, and generating a distributed device connection architecture based on the network distance and communication delay parameters. The industrial automation runtime service of the distributed device connection architecture is loaded with a multi-protocol adapter to obtain a multi-protocol runtime service instance. Specifically, this includes: extracting the protocol type identifier and communication interface parameters of each device node from the distributed device connection architecture, and determining the protocol parsing quantity and version information based on the protocol type identifier and communication interface parameters; performing file stream reading and character encoding parsing on the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file to obtain the original configuration data set; performing regular expression matching and version number comparison operations on the protocol identifier field in the original configuration data set according to the quantity and version information to filter target configuration data segments; and based on the target... The `library_path` and `module_path` fields in the configuration data segment are used to extract path strings and verify path validity to obtain the driver library path corresponding to each protocol. The `init_params`, `connection_timeout`, and `buffer_size` fields in the target configuration data segment are parsed and their data types converted to obtain the initialization parameters corresponding to each protocol. Based on the driver library path and the initialization parameters, the `libjicruntime_server.z.so` server library, `libjicruntime_client.z.so` client library, and `libjicruntime.z.so` SDK library are loaded sequentially. After loading, a service registration process is executed to obtain the registered service components. The registered service components are then logically restructured to generate multi-protocol runtime service instances. Based on the multi-protocol runtime service instance, communication protocol identification and configuration are performed on the multiple industrial devices to obtain standardized device data. Specifically, this includes: sending standard protocol probe sequences to each of the multiple industrial devices through the multi-protocol runtime service instance, and obtaining the protocol response frame feature code and version identifier returned by each industrial device; performing pattern matching operations on the protocol response frame feature code and the version identifier to obtain a device protocol mapping table; constructing a protocol parser component for each protocol based on the protocol type information in the device protocol mapping table, and performing byte parsing on the original protocol data frames sent by each industrial device based on the protocol parser component to obtain a parsed data packet set; rearranging and labeling the data field structures of different protocols in the parsed data packet set to obtain a standard data structure; performing byte position reversal operations on the integer and floating-point values ​​in the standard data structure to obtain numerical data; and expanding the 32-bit single-precision floating-point numbers of the numerical data to 64-bit double-precision numbers. The process involves obtaining floating-point data and automatically identifying the encoding type of the string content contained in the floating-point data to obtain character data. A mapping index from source address to target address is constructed based on the character data, and a bidirectional lookup table containing protocol type, data address, and conversion function pointers is established based on the mapping index. When data of any protocol is received in the bidirectional lookup table, the corresponding conversion rule is located and data format conversion is performed to obtain a unified protocol converter. The connection parameters of each industrial device are configured through the configuration interface opened by the unified protocol converter to obtain a set of connection configuration parameters. Based on the device protocol information in the set of connection configuration parameters, data point scanning and attribute parsing are performed on each industrial device to obtain a set of model configuration parameters. The acquisition frequency is calculated based on the data change characteristics in the set of model configuration parameters to obtain data acquisition rules. The configuration parameters in the data acquisition rules are then mapped and format converted according to the unified industrial data model to obtain standardized device data. A data transmission channel is established based on the standardized equipment data, and global status synchronization and collaborative control command distribution are performed on the multiple industrial devices to generate a distributed collaborative control network. Specifically, this includes: performing data volume statistics on data identifiers, data types, timestamps, quality identifiers, security levels, and device source identifiers in the standardized equipment data to obtain the data transmission memory requirement; based on the data transmission memory requirement, calling the getShmem() interface to send a memory request to the industrial automation runtime service; after receiving the memory request, the industrial automation runtime service allocates an anonymous shared memory of the corresponding size and returns a GetShmemResponse object to obtain the shared memory resource; the memory region is divided according to the memory address and size parameters of the shared memory resource to obtain a hierarchical memory data structure, and the data is then... The hierarchical memory data structure is mapped to the virtual address space of each industrial device process to obtain a data transmission channel. Global device status data of the multiple industrial devices is read through the data transmission channel. Based on the global device status data, an industrial control task is evaluated to obtain a control task allocation scheme. According to the control task allocation scheme, the `call()` interface is called to send control instructions in UInt8Array format to each industrial device. The control instructions are transmitted to each industrial device via a distributed soft bus, and execution confirmation in CallResponse format is obtained, thus obtaining a control instruction transmission link. The execution results of the devices in the control instruction transmission link are summarized and analyzed. When any industrial device completes a control action, the global device status data is updated and synchronized to other industrial devices, resulting in a distributed collaborative control network.

2. An industrial communication protocol adaptation system based on OpenHarmony, characterized in that, The steps for implementing the OpenHarmony-based industrial communication protocol adaptation method of claim 1, wherein the OpenHarmony-based industrial communication protocol adaptation system comprises: The deployment unit is used to deploy multiple industrial devices in the industrial control network in a distributed soft bus configuration, resulting in a distributed device connection architecture. The loading unit is used to load the multi-protocol adapter for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; The configuration unit is used to identify and configure the communication protocols of the multiple industrial devices according to the multi-protocol runtime service instance to obtain standardized device data. The generation unit is used to establish a data transmission channel based on the standardized equipment data, and to perform global state synchronization and collaborative control command distribution to the multiple industrial devices to generate a distributed collaborative control network.

Images