Industrial communication protocol adaptation method and system based on OpenHarmony

Abstract

The invention 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; carrying out multi-protocol adapter loading on the industrial automation runtime service of the distributed equipment connection architecture to obtain a multi-protocol runtime service instance; performing communication protocol identification and configuration on the plurality of industrial devices according to the multi-protocol runtime service instance to obtain standardized device data; and establishing a data transmission channel according to the standardized device data, and performing global state synchronization and cooperative control instruction distribution on the plurality of industrial devices to generate a distributed cooperative control network. The deployment and maintenance work of the industrial control system is simplified, the accuracy and consistency of system configuration are improved, the risk of manual configuration errors is reduced, and the development cost and maintenance complexity of industrial application are reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial control, in particular to an industrial communication protocol adaptation method and system based on OpenHarmony. BACKGROUND

[0002] In modern industrial control systems, a large number of industrial devices of different manufacturers and models are usually deployed in industrial sites, including PLC controllers, SCADA systems, robotic devices, sensors, etc. These devices use independent industrial communication protocols such as OPC-UA, Modbus, Profinet, CAN bus, and serial communication, forming a serious "data island" problem. Due to the lack of a unified communication standard, heterogeneous devices cannot directly exchange data and cooperatively control each other, severely restricting the intelligent level of the entire industrial control system.

[0003] Traditional industrial control systems generally use point-to-point communication, and each device needs to be individually configured with communication modules and conversion interfaces for different protocols. This architecture not only increases the complexity and maintenance cost of the system, but more importantly, it cannot support real-time collaborative control between devices. When multiple devices need to coordinate to complete complex tasks in an industrial site, existing technologies often rely on manual configuration or centralized control by a host computer, which has problems such as large response delay, poor scalability, and low reliability, making it difficult to meet the strict requirements of modern intelligent manufacturing for device collaboration and real-time performance. SUMMARY

[0004] The main purpose of the present application is to provide an industrial communication protocol adaptation method and system based on OpenHarmony, which simplifies the deployment and maintenance of industrial control systems, improves the accuracy and consistency of system configuration, reduces the risk of human configuration errors, and reduces the development cost and maintenance complexity of industrial applications.

[0005] To achieve the above purpose, the present application provides an industrial communication protocol adaptation method based on OpenHarmony, comprising the following steps: Distributed soft bus deployment is performed on multiple industrial devices in an industrial control network to obtain a distributed device connection architecture; A multi-protocol adapter is loaded to the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; According to the multi-protocol runtime service instance, the communication protocol of the multiple industrial devices is identified and configured to obtain standardized device data; According to the standardized device data, a data transmission channel is established, and the global state of the multiple industrial devices is synchronized and the collaborative control instruction is distributed to generate a distributed collaborative control network.

[0006] Optionally, in the first implementation manner of the first aspect, the distributed soft bus deployment on the plurality of industrial devices in the industrial control network to obtain the distributed device connection architecture comprises: deploying a libjicruntime_server.z.so service library at a central node of the industrial control network and generating a distributed soft bus; deploying a libjicruntime_client.z.so client library to each of the plurality of industrial devices in the industrial control network based on the distributed soft bus to form a set of device nodes; performing device type identification and communication capability detection on each device node in the set of device nodes to generate a device capability descriptor; calculating network distance and communication delay parameters between the plurality of industrial devices according to the device capability descriptor, and generating a distributed device connection architecture based on the network distance and the communication delay parameters.

[0007] Optionally, in the second implementation manner of the first aspect, the multi-protocol adapter loading on the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance comprises: extracting protocol type identifiers and communication interface parameters of each device node from the distributed device connection architecture, and determining protocol parsing quantity and version information based on the protocol type identifiers and the communication interface parameters; parsing a jicruntime.cfg system configuration file and a jicruntime.json protocol configuration file based on the protocol parsing quantity and the version information, and extracting a drive library path and initialization parameters corresponding to each protocol; loading a libjicruntime_server.z.so service library, a libjicruntime_client.z.so client library and a libjicruntime.z.so SDK library in sequence according to the drive library path and the initialization parameters, and performing a service registration process after the loading is completed to obtain a registered service component; recombining the registered service component to generate a multi-protocol runtime service instance.

[0008] Optionally, in the third implementation manner of the first aspect, the parsing of the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file based on the quantity and the version information to extract a drive library path and initialization parameters corresponding to each protocol comprises: File stream reading and character encoding analysis are performed on a jicruntime.cfg system configuration file and a jicruntime.json protocol configuration file to obtain an original configuration data set; Regular expression matching and version number comparison operations are performed on a protocol identifier field in the original configuration data set according to the number and the version information, to screen a target configuration data segment; Path string extraction and path validity verification are performed based on a library_path field and a module_path field in the target configuration data segment, to obtain a drive library path corresponding to each protocol; Parameter value analysis and data type conversion are performed on an init_params field, a connection_timeout field and a buffer_size field in the target configuration data segment, to obtain initialization parameters corresponding to each protocol.

[0009] Optionally, in a fourth implementation manner of the first aspect, the communication protocol identification and configuration of the multiple industrial devices based on the multi-protocol runtime service instance to obtain standardized device data comprises: The multi-protocol runtime service instance sends a standard protocol detection sequence to the multiple industrial devices respectively, and acquires protocol response frame characteristic codes and version identifiers returned by the industrial devices; Pattern matching operations are performed on the protocol response frame characteristic codes and the version identifiers to obtain a device protocol mapping table; Protocol parser components are constructed for each protocol based on protocol type information in the device protocol mapping table, and byte analysis is performed on original protocol data frames sent by the industrial devices based on the protocol parser components to obtain a parsed data packet set; Field rearrangement and type annotation are performed on data field structures of different protocols in the parsed data packet set to obtain a standard data structure; The standard data structure is converted and a protocol uniform converter is established; Device connection parameters and data acquisition rules of the multiple industrial devices are configured based on the protocol uniform converter to obtain standardized device data.

[0010] Optionally, in a fifth implementation manner of the first aspect, the conversion of the standard data structure and the establishment of the protocol uniform converter comprise: Byte position inversion operations are performed on integer and floating point numerical values in the standard data structure to obtain numerical data; The 32-bit single-precision floating point number of the numerical data is expanded into a 64-bit double-precision format to obtain floating point number data, and automatic identification of the encoding type of the string content contained in the floating point number data is performed to obtain character data; A mapping index from a source address to a target address is constructed according to the character data, and a bidirectional lookup table containing a protocol type, a data address and a conversion function pointer is established according to 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 protocol uniform converter.

[0011] Optionally, in a sixth implementation manner of the first aspect of the present application, the configuration and configuration of the device connection parameters and the data acquisition rules of the plurality of industrial devices based on the protocol uniform converter to obtain standardized device data, comprising: The device connection parameters of each industrial device are connected and configured through the configuration interface opened by the protocol uniform converter to obtain a connection configuration parameter set; Based on the device protocol information in the connection configuration parameter set, data point scanning and attribute analysis are performed on each industrial device to obtain a model configuration parameter set; According to the data change characteristics in the model configuration parameter set, the acquisition frequency is calculated to obtain the data acquisition rule, and the configuration parameters in the data acquisition rule are field-mapped and format-converted according to the industrial data uniform model to obtain the standardized device data.

[0012] Optionally, in a seventh implementation manner of the first aspect of the present application, the data transmission channel is established according to the standardized device data, and the global state synchronization and collaborative control instruction distribution of the plurality of industrial devices are performed to generate a distributed collaborative control network, comprising: The data volume statistics of the data identifier, data type, timestamp, quality identifier, security level and device source identifier in the standardized device data are performed to obtain the data transmission memory requirement; Based on the data transmission memory requirement, the getShmem() interface is called to send a memory application request to the industrial automation runtime service, and after the industrial automation runtime service receives the memory application request, the corresponding size of anonymous shared memory is allocated and a GetShmemResponse object is returned to obtain a shared memory resource; According to the memory address and size parameters of the shared memory resource, the memory region is divided to obtain a hierarchical memory data structure, and the hierarchical memory data structure is mapped to the virtual address space of each industrial device process to obtain a data transmission channel; The multiple industrial devices are globally state-synchronized and control instruction distributed based on the data transmission channel, and a distributed collaborative control network is generated.

[0013] Optionally, in the eighth implementation form of the first aspect of the present application, the globally state-synchronized and control instruction distributed based on the data transmission channel, and the distributed collaborative control network generated, include: Global device state data of the multiple industrial devices is read through the data transmission channel; Device evaluation of an industrial control task is performed based on the global device state data, and a control task allocation scheme is obtained; A call() interface is called according to the control task allocation scheme to send control instructions in the format of UInt8Array to each industrial device, the control instructions are communicated to each industrial device through a distributed soft bus, and a CallResponse format execution confirmation is obtained, and a control instruction transmission link is obtained; 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 state data is updated and synchronized to other industrial devices, and a distributed collaborative control network is obtained.

[0014] The present application also provides an industrial communication protocol adaptation system based on OpenHarmony, which includes: A deployment unit is configured to deploy a distributed soft bus for multiple industrial devices in an industrial control network, and obtain a distributed device connection architecture; A loading unit is configured to load a multi-protocol adapter for an industrial automation runtime service of the distributed device connection architecture, and obtain a multi-protocol runtime service instance; A configuration unit is configured to identify and configure the communication protocol of the multiple industrial devices according to the multi-protocol runtime service instance, and obtain standardized device data; A generation unit is configured to establish a data transmission channel according to the standardized device data, and globally state-synchronize and distribute collaborative control instructions for the multiple industrial devices, and generate a distributed collaborative control network.

[0015] In summary, the application breaks the physical boundaries and system barriers between traditional industrial devices by establishing a distributed soft bus architecture, realizing deep interconnection and intercommunication of heterogeneous devices such as PLC controllers, SCADA systems, and mechanical arm devices. By dynamically loading more than 100 industrial protocol adapters, supporting mainstream industrial communication protocols such as OPC-UA, Modbus, and CAN bus, and establishing a bidirectional conversion mapping table between protocols, the long-standing "data island" problem in the industrial control field is completely eliminated. The data transmission channel constructed by shared memory and zero-copy technology reduces the data exchange delay to the microsecond level, significantly improving the real-time performance of the system. Through the global state synchronization and collaborative control mechanism, intelligent collaborative control is realized, such as task execution on the most suitable device and real-time data flow in the required place, which is like connecting the factory neural network. Based on the "one development, multiple deployment" feature of the unified development tool chain, the development cost and maintenance complexity of industrial applications are greatly reduced. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is an industrial communication protocol adaptation method based on OpenHarmony in an embodiment of the application; Figure 2 is an industrial communication protocol adaptation system structure block diagram based on OpenHarmony in an embodiment of the application.

[0017] The implementation of the object, functional characteristics and advantages of the application will be further described with reference to the accompanying drawings. DETAILED DESCRIPTION

[0018] In order to make the object, technical scheme and advantages of the application more clear and explicit, the application 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 only used to explain the application and do not limit the application.

[0019] Referring to Figure 1 , the embodiment provides an industrial communication protocol adaptation method based on OpenHarmony, including the following steps: S1, a plurality of industrial devices in an industrial control network are distributedly deployed with a soft bus to obtain a distributed device connection architecture; Among them, the libjicruntime_server.z.so service library is deployed at the center node of the industrial control network, and the libjicruntime_server.z.so service library is used as the core running module of the distributed soft bus, and undertakes the basic communication management functions such as device registration, connection scheduling, data forwarding and state coordination. Its deployment process is based on the center node operating system platform running HualongOS, loaded and registered to the system service manager by the system service framework, and a unified service port for all network devices is established, thereby constructing the main control structure of the distributed soft bus in the logical layer. Based on the distributed soft bus, the libjicruntime_client.z.so client library is deployed in the multiple industrial devices that have been accessed in the industrial control network one by one, and the libjicruntime_client.z.so client library is embedded in various industrial device operating systems, including PLC controllers, edge computing gateways, intelligent sensors, industrial touch terminals, etc. Through the system configuration path, the registration and loading of the dynamic link library are completed, thereby constructing the terminal access channel facing the distributed bus on the physical network, and forming a device node set containing multiple industrial device nodes, and the device node set constitutes a collaborative execution unit in the distributed communication system. Through the soft bus interface, type recognition and communication capability detection operations are actively performed on each node in the device node set, including architecture recognition of the device running platform, memory and processor capability evaluation, support protocol stack type recognition, interface rate detection, whether to support WiFi or Ethernet dual-channel communication and other indicators, and then a device capability descriptor is automatically generated according to the detection result. The device capability descriptor records the communication properties, processing capability and adaptation capability of each device in a structured format. According to the device capability descriptor, network topology analysis is performed between devices, including calculating the physical network distance parameters between devices and the communication delay parameters obtained based on the data packet return delay test, and on this basis, a distributed device topology graph with node weight and connection cost is established, and connection relationship optimization is performed according to the principle of minimum network load and maximum communication efficiency, thereby generating a distributed device connection architecture most suitable for current industrial task scheduling and data flow conversion requirements.

[0020] S2, load the multi-protocol adapter of the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; Specifically, the protocol type identifier and communication interface parameters of each device node are extracted from the distributed device connection architecture by running the node descriptor query mechanism of the distributed soft bus. Each device node reports its supported communication protocol type (such as OPC UA, Modbus, CAN, serial port, Ethernet, WiFi, etc.), open interface port information, baud rate, communication frame structure characteristics, and version number, etc. basic communication capability parameters when initializing the connection, and generates a protocol analysis requirement table according to these information, which reflects the number of protocol types required to be supported in the current system and the corresponding version information. According to the protocol analysis quantity and version information, the jicruntime.cfg system configuration file and jicruntime.json protocol configuration file are loaded in turn and the semantic level analysis operation is performed. In this process, the runtime service identifies the drive library path, dynamic link library name, initialization function entry, default initialization parameter, error code table path, and log level configuration corresponding to each protocol through the configuration analysis module, thereby constructing the mapping index relationship of the driver loading. According to the analysis result, the libjicruntime_server.z.so server library, libjicruntime_client.z.so client library and libjicruntime.z.so SDK library are loaded in order according to the dependency order, wherein the server library is deployed on the center node and is responsible for registration and scheduling management, the client library is deployed on each edge device to establish a data bridge between the protocol communication stack and the soft bus interface, and the SDK library is called by the upper layer business logic to complete the cross-device data reading and writing operation. After all the dynamic libraries are loaded, the service registration process is started, and the capability services, data services, event services and management interface services provided by each drive are registered through the system service manager to ensure that the upper layer application can discover and bind them on demand. After registration, according to the device role classification, protocol stack function characteristics and running efficiency requirements, the registered service components are logically reorganized, the device services are divided into data acquisition layer, protocol conversion layer, service intermediary layer and upper layer business calling layer, and the multi-protocol runtime service instance is generated through logical path optimization and interface standardization.

[0021] S3, according to the multi-protocol runtime service instance, performing communication protocol identification and configuration on the plurality of industrial devices, to obtain standardized device data; It should be noted that the multi-protocol communication capability integrated by the multi-protocol runtime service instance sends a standard protocol detection sequence of a preset format to each industrial device node in the distributed device connection architecture, respectively. The standard detection sequence is encapsulated according to the start specification of different communication protocols, and its role is to actively stimulate device response, detect the protocol type and version information supported by the device. After each device receives the detection sequence, it returns feedback data containing protocol response frame characteristic code and version identifier. The feedback response data frame contains fields such as protocol flag bit, start byte structure, function code, check mechanism and version information. All returned response frame contents are uniformly accessed to the protocol identification module, and byte-by-byte pattern matching operation is performed thereon. The byte-by-byte pattern matching process is based on the system built-in protocol fingerprint library, and by comparing the key byte bits of the response frame characteristic code and the encoding rules of the version identifier, a device protocol mapping table is generated, recording the protocol name, master-slave mode, version number and applicable driver path of 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 checking and content extraction operations on the original protocol data frame from the device to obtain a set of parsed data packets. The fields of each protocol in the parsed data packet set are subjected to structure alignment operations, including reconstruction of field arrangement order, standardized annotation of data type, injection of unit conversion rules, etc., to generate a standard data structure with uniform semantic labels. A protocol unified converter is established based on the standard data structure. The protocol unified converter serves as a bridge between the protocol layer and the application layer, and internally stores multi-protocol field mapping rules and field recoding rules. It dynamically converts data parsing results of any source into a unified data model recognized by the system, and controls the field exposure order and structure nesting level through a configuration template. Based on the protocol unified converter, configuration and configuration operations of device connection parameters and data acquisition rules of all industrial devices are completed, including device address, communication channel, acquisition period, alarm threshold, data filter setting, etc. After configuration is completed, the real-time running data of all industrial devices is uniformly output in a standardized format.

[0022] S4, establishing a data transmission channel according to the standardized device data, and performing global state synchronization and cooperative control instruction distribution on the plurality of industrial devices to generate a distributed cooperative control network.

[0023] Specifically, statistical analysis operations are performed on data identifiers, data types, timestamps, quality identifiers, security levels, and device source identifiers in the standardized device data, the update frequency of each data field in a unit of time, data size, and requirements for real-time performance and security are analyzed, and the total data output size is calculated based on this to obtain the memory capacity size required for data transmission under the shared memory mechanism, that is, the data transmission memory requirement. Based on the data transmission memory requirement, the getShmem() interface is called to send a memory application request to the industrial automation runtime service. The getShmem() interface serves as an entry function for high-frequency real-time data communication, and its role is to initiate an anonymous shared memory allocation operation request to the runtime service. After receiving the request, the runtime service executes the resource allocation logic of the memory management module according to the application parameters and returns a GetShmemResponse object. The GetShmemResponse object contains the physical address handle of the shared memory, the total number of allocated memory bytes, the memory access status code, and the error reporting mechanism, and obtains the shared memory resource. According to the memory address and size parameters of the shared memory resource, spatial segmentation and structured division are performed to generate a data cache model with a logical hierarchy. The hierarchical memory data structure is organized in multiple layers according to the device dimension, data type dimension, and control priority dimension. Each layer structure independently corresponds to a data segment and instruction cache area of a type of device, and concurrent control mechanisms such as synchronization markers, write protection locks, and timing labels are established in the logical layer to ensure the integrity and consistency of the data reading and writing process. Through the kernel interface mechanism, the hierarchical memory data structure is mapped to the virtual address space of each industrial device process to obtain a data transmission channel. Based on the data transmission channel, global state synchronization operations are performed on each industrial device, dynamic indicators such as the running state, load condition, and communication health degree of each node are periodically read and updated to the shared memory, and control instructions issued by the centralized scheduling control module are read from the shared memory and executed according to priority, including logical start-stop, parameter modification, alarm linkage, and other control behaviors, to realize end-to-end multi-device collaboration without the participation of a central controller, and generate a distributed collaborative control network.

[0024] In one example, a plurality of industrial devices in an industrial control network are deployed in a distributed soft bus to obtain a distributed device connection architecture, including: A libjicruntime_server.z.so service library is deployed at a central node of the industrial control network to generate a distributed soft bus; Based on the distributed soft bus, a libjicruntime_client.z.so client library is deployed to each of the plurality of industrial devices in the industrial control network to form a set of device nodes; Each device node in the set of device nodes is identified by device type and detected for communication capability to generate a device capability descriptor; The network distance and communication delay parameters between the plurality of industrial devices are calculated based on the device capability descriptors, and a distributed device connection architecture is generated based on the network distance and communication delay parameters.

[0025] In this example, in the industrial control network, a node with strong processing capability, high memory capacity, sufficient network bandwidth, and relatively stable physical location is selected as the system center node, and the libjicruntime_server.z.so service library is deployed in the system center node operating system environment in the form of a system service. The libjicruntime_server.z.so dynamic link library is the core component of the industrial automation runtime service. Based on the distributed soft bus architecture running mechanism of the OpenHarmony operating system, the service registry is filled in the system initialization stage through the startup subsystem hatching and completion, a logical soft bus communication channel is generated, the soft bus communication channel supports the node management strategy based on service discovery and device identification binding, allows multiple industrial devices to be connected to the unified bus domain as a client, and accepts unified scheduling management, thereby constructing a virtual interconnection backbone structure at the system level. In the industrial control network, multiple industrial device 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 system configuration file (such as jicruntime.cfg) is used to perform initial handshake authentication with the runtime, complete the node registration process, and obtain the device unique identification code, access channel key, and synchronization strategy parameters issued by the server. From this, the target device is formally included in the soft bus communication domain, thereby forming a device node set with network controllability and state discoverability in a logical sense. Each node in the device node set has runtime service discovery capability, protocol adaptation capability, and data communication capability.An automatic device identification process is started, and a node query and capability detection API interface provided by a runtime is called to identify the device type and detect the communication capability of each device node in the device node set. The device type identification part determines the control level, data processing capability, and communication role classification of the device by reading device hardware structure information, device model number, device manufacturer identification, firmware version number, system running platform, etc. meta information, and codes it according to the general classification specification of industrial devices. The communication capability detection process extracts the protocol stack type (such as OPC UA, Modbus, CAN, serial port, WebService, etc.), interface bandwidth specification, maximum number of concurrent connections, whether it has redundant links, multi-protocol concurrency capability, and fault automatic switching capability, etc. supported by the current node through active return or runtime active detection, and records the current physical connection mode (Ethernet, WiFi or RS485, etc.), whether to enable QoS strategy and the supported security mechanism level. After the above process is completed, a structured device capability descriptor is generated for each device. The device capability descriptor records the type attribute, communication capability, protocol adaptation range, and system resource upper limit of the device in the form of key-value pairs. Based on the device capability descriptor, the network distance and communication delay are calculated and analyzed. The physical hop count, link medium type, network topology position, and bandwidth bottleneck point between any two devices are calculated based on the current network physical structure information of the nodes. The actual communication delay value between the node pairs is obtained based on the ICMP and TCP RoundTrip time sampling mechanism. The calculation results include network propagation delay, protocol stack response delay, data frame queuing time, shared link blocking time, etc. dynamic factors. A network delay matrix table is generated based on the network bandwidth, current device processing load, and connection saturation, and a weighted graph structure is constructed based on the network delay matrix table to model the communication cost between devices. A distributed device connection architecture automatic generation module is started. The device physical location distribution, communication load dispersion, real-time demand between key control nodes, and fault recovery strategy are considered to minimize the total delay and maximize the system throughput. The optimal connection path construction algorithm is executed to automatically select the network logical topology according to the star, tree, ring, or hybrid structure. In the actual connection architecture, a hierarchical control strategy is used to place the control center node, edge execution node, and auxiliary data node in different control domains, and to configure dual-channel redundant connection paths for key devices to ensure system communication integrity and operation stability in single-link abnormal conditions. A distributed device connection architecture is generated.

[0026] In one example, a multi-protocol adapter is loaded for the industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance, including: Extract the protocol type identifier and communication interface parameter 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 parameter; Based on the protocol parsing quantity and version information, the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are parsed to extract the corresponding drive library path and initialization parameter of each protocol; According to the drive library path and the initialization parameter, the libjicruntime_server.z.so server library, the libjicruntime_client.z.so client library and the libjicruntime.z.so SDK library are loaded in turn, and after the loading is completed, the service registration process is executed to obtain the registered service components; The logical architecture of the registered service components is reorganized to generate a multi-protocol runtime service instance.

[0027] In this example, based on the established node set in the distributed device connection architecture, the interface function or listening mechanism provided by the industrial automation runtime service is called to read and cache the protocol type identifier and communication interface parameter information of all device nodes in turn, including the device declared support protocol stack type (such as OPCUA, Modbus TCP, CANopen, RS485, serial frame structure, etc.), while recording the manufacturer-specific extension, version field and compatible parameters of each protocol, and the communication interface parameters cover physical port type (such as Ethernet port number, serial port channel, CAN bus address), baud rate setting, byte order, check mode, data packet boundary agreement, etc. According to the protocol identifier and interface parameter type clustering and version number extraction, and according to the statistical protocol type total number actually required to load and support in the current system, that is, the protocol analysis quantity, and the specific version number corresponding to each protocol is sorted out to generate the protocol support demand list. Taking the protocol support demand list as the input condition, the configuration parsing module is called to execute structured parsing on the jicruntime.cfg system configuration file and jicruntime.json protocol configuration file under the deployment path, where the jicruntime.cfg file is the overall architecture and service management configuration entry of the system runtime service, providing system-level parameters including library loading order, device registration rule, running mode selection, debugging level, log output level, error handling strategy, etc. While the jicruntime.json file is a protocol-level configuration container for multi-protocol driver loading, recording the driver library file path, initialization parameter list, version compatibility strategy, field resolution mapping relationship, protocol status code definition, data channel template, handshake behavior configuration and other key information of each supported protocol. Through the dual-channel reading mode based on JSON parsing engine and INI configuration reader, the driver library path and initialization parameters matching the protocol list are extracted and stored in the unified protocol component loading index table. According to the driver loading order defined in the configuration, the libjicruntime_server.z.so server library, libjicruntime_client.z.so client library and libjicruntime.z.so SDK library are loaded in turn. The server library is loaded and run in the center node of the distributed architecture, and the scheduling and coordination of the general function modules such as authentication management, service discovery, protocol scheduling and exception handling of the client connection. The client library is deployed in all industrial devices participating in communication, which plays a role in local protocol analysis and data packaging execution, while the SDK library serves as an intermediate bridge between the upper application and the runtime service, providing API encapsulation, object access, command forwarding and data channel construction function interfaces.In the library loading process, dynamic link call operations are performed, and symbol matching and initialization parameter injection are performed to ensure that each drive component can construct a correct state machine, verification mechanism and data transmission path according to the communication requirements of the target protocol, and various libraries complete the reference call of interdependent modules through pre-defined interface function pointers. After all the drive libraries are loaded and initialized successfully, the service registration process is started. The service registration process is initiated by the system service manager, and the function identifier, call path, protocol adaptation capability and data interface definition of the exported service structure in each drive library are registered and bound to the runtime service table, and a service directory tree structure is established. In the registration process, service visibility filtering, repeated service conflict detection, and abnormal service elimination strategies are performed to ensure that the registered service component set has functional completeness, uniqueness and schedulability, and meets the protocol analysis depth and response speed requirements required by the current industrial control task. The registered service components are logically restructured, that is, the service components are re-divided into basic data acquisition modules, protocol translation modules, device state synchronization modules, control instruction distribution modules, shared memory management modules and error recovery modules according to the protocol type, service function, call frequency, device distribution, communication direction and call path, etc. Dimensions, and with service interfaces as boundaries, an object-oriented module access path is constructed to form a runtime service instance with layered control, parallel analysis and asynchronous response capabilities.

[0028] In one example, the jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are parsed based on the quantity and version information, and the drive library path and initialization parameters corresponding to each protocol are extracted, including: The jicruntime.cfg system configuration file and the jicruntime.json protocol configuration file are read and character encoding parsed to obtain an original configuration data set; The protocol identifier field in the original configuration data set is matched by regular expression and compared by version number according to the quantity and version information to filter the target configuration data segment; The library_path field and the module_path field in the target configuration data segment are used to extract path strings and verify path validity to obtain the drive library path corresponding to each protocol; The init_params field, the connection_timeout field and the buffer_size field in the target configuration data segment are parsed and data type 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 called to read the jicruntime.cfg system-level configuration file and the jicruntime.json protocol-level configuration file located in the system configuration path through standard file stream reading. The character set decoding method is specified during the process to ensure that the configuration file content is correctly interpreted as a standard character sequence in UTF-8 encoding format, thereby ensuring that Chinese annotations, extended symbols, and multilingual fields remain consistent in different operating system language environments. During the file stream reading process, the content is read line by line and character cleaning operations are performed, including removing illegal line breaks, removing comment paragraphs, repairing common quote mismatch errors in JSON format, and structuring the cleaned content in the original configuration data set to form a structured tree data body containing protocol name, version information, driver path, initialization parameters, connection timeout settings, buffer size, support features, status flags, log level, and exception handling strategies. According to the protocol parsing quantity and version information list, regular expression matching operations are performed on the protocol identifier field in the original configuration data set. Regular expression matching operations use pre-defined regular expression templates to perform pattern matching on the protocol name field, supporting fuzzy matching, prefix matching, wildcard expansion, and multi-level namespace extraction functions, such as matching "modbus.*", "modbus-tcp", "MODBUS", "modbus_v1_2" and other different writing methods for "Modbus-TCP v1.2", and using a unified protocol specification mapping table to normalize the fuzzy results to the standard protocol naming system. After completing the regular matching, version number comparison operations are performed on the version field in the configuration field using a three-level version number comparison mechanism of major version number, minor version number, and patch number. Through string splitting and numerical conversion, it is compared whether the protocol version number in the configuration is consistent with the target version in the current system support list or higher than the minimum compatible version, ensuring that only the target configuration data segment with complete semantic and functional matching is retained. After version comparison, all protocol configuration fragments that pass the screening are extracted and assembled into a target configuration data segment set. Path string extraction and path validity verification operations are performed on the library_path field and module_path field in each target configuration data segment. Path string extraction is based on the absolute path, relative path, or environment variable expression format of the field content, automatically identifies system variables, current working directory identifiers, and special symbols in the path, and corrects non-standard path structures (such as spaces, illegal characters, and un-enclosed quotes in the path).After the extraction is completed, the file system interface is called to perform a validity verification operation on the extraction path, including checking whether the path exists, whether the path points to a valid.so dynamic library file, whether the library file can be read and written by the current user, whether the file has execution permission, and the like. Only the paths that pass the verification are included in the final driver loading list. For the fields that fail the path verification, an exception report is generated and recorded to the log system. After the extraction of the driver library path is completed, the init_params field, the connection_timeout field, and the buffer_size field in the target configuration data segment are parsed, and parameter value parsing and data type conversion are performed thereon. The init_params field is a JSON object or a separated string structure. The init_params field is parsed into an initialization parameter list in the form of a key-value pair, and each parameter key name is mapped to an internal variable required by the drive module according to a predefined data dictionary, for example, the init_params includes entries such as "baud_rate=9600", "parity=none", and "slave_id=1". These values are converted into integer, enumeration, or Boolean internal representations, and are encapsulated into a structure for calling by a drive initialization function. The connection_timeout field and the buffer_size field are represented in the form of a string in the configuration file, and are parsed into unsigned integer values or time unit conversion values. At the same time, values that are out of a reasonable range are subjected to limiting processing or a configuration warning is thrown. After the parameter value extraction and type conversion of all fields are completed, a standardized protocol driver loading parameter structure is generated, including the driver library file path, the loading entry name, the initialization function call parameter, the communication timeout setting, and the buffer allocation parameter, and the protocol driver loading parameter structure is stored in the protocol adapter registry.

[0030] In one example, a plurality of industrial devices are identified and configured according to a multi-protocol runtime service instance, and standardized device data is obtained, including: A standard protocol probe sequence is sent to each of the plurality of industrial devices through the multi-protocol runtime service instance, and protocol response frame characteristic codes and version identifiers returned by the industrial devices are obtained; Pattern matching operations are performed on the protocol response frame characteristic codes and the version identifiers, and a device protocol mapping table is obtained; Protocol parser components are constructed for each protocol based on protocol type information in the device protocol mapping table, and raw protocol data frames sent by the industrial devices are byte-parsed based on the protocol parser components, and a parsed data packet set is obtained; Field rearrangement and type annotation are performed on data field structures of different protocols in the parsed data packet set, and a standard data structure is obtained; The standard data structure is converted and a protocol unified converter is established; The device connection parameters and data collection rules of the plurality of industrial devices are configured based on a protocol uniform converter to obtain standardized device data.

[0031] In this example, based on the 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, including device addresses, communication ports, protocol stack assignment structures, instruction cache areas, and response monitors, to each device node. The protocol identification engine sends a predefined standard protocol probe sequence to each device node in turn, which is constructed according to the connection rules, initialization process, and handshake mode of commonly used industrial field protocols, such as the function code 0x11 used by the Modbus protocol, the Hello / ACK negotiation segment of the OPC UA protocol, and the NMT master broadcast frame of the CANopen protocol. The probe sequence is attached with a unique identification code and a timestamp during transmission to ensure that the returned result has the correct device binding attribute. After receiving the probe sequence, the device returns a structured protocol response frame containing protocol response feature codes, protocol version identifiers, function segment status codes, and protocol extension attribute bits. The frame structure parser extracts the key byte bits and binds them to the device node and stores them in the initial response cache pool. The protocol response frame feature codes and version identifiers in the initial response cache pool are subjected to pattern matching operations. The pattern matching engine uses a multi-layer matching mechanism composed of regular expression trees, feature template dictionaries, and device identification hash values to perform byte-by-byte comparison operations on the feature codes and execute version level comparison logic based on the version identifiers, ensuring that the returned result covers both the protocol type currently used by the device and the specific version of the protocol used. After matching is complete, the matching 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 in the device protocol mapping table, the corresponding protocol parser components are constructed for each protocol. Each parser component defines its own state machine model, frame boundary identification rules, verification mechanism, and field extraction template according to the target protocol specification, loads the corresponding driver library's parsing function entry, and registers the frame length, starting byte, stop bit, byte alignment mode, and verification bit calculation rules during initialization through configuration parameters. After construction, the parser is hung to the downlink data listener of the device channel. During device data collection, all original protocol data frames sent from industrial devices to the system will undergo byte stream processing by the parser component. Using the sliding window mechanism and frame header verification, the frame boundary of continuous data segments is identified, and data segment cutting, function code extraction, field pointer mapping, and value conversion operations are performed according to the protocol frame format to obtain a structured analysis data packet set.Due to the differences in the protocol data structures adopted by various industrial equipment, the original fields in the parsed packet set, which have different field orders, inconsistent data units, and non-uniform data types, are reconstructed and annotated in types by a standardized structure processing module. The standardized structure processing module standardizes the field labels in the parsed data according to the built-in data field mapping rules and semantic coding system, and rearranges the arrangement order of the fields. Important fields such as device state quantities, analog input, alarm codes, and sensor readings are placed in a unified field position. The data types from different sources are uniformly converted, such as converting a hexadecimal temperature value into a floating-point Celsius temperature, converting a Boolean state code into 01 identification, and converting the timestamp fields of different protocols into UTC millisecond standard timestamps in the system unified format. A standard data structure is obtained. The standard data structure is converted and a protocol unified converter is established. The protocol unified converter serves as an abstract adaptation layer between the upper business system and the bottom multi-protocol data. Its core functions include field mapping, data format coding conversion, abnormal field filling, redundant field filtering, and cross-protocol field alignment. The converter maps the structured data output by any protocol parser into a unified format through a mapping table and a field adaptation template, and supports fault-tolerant replacement or default value injection for abnormal fields in the original data stream, ensuring that the upper business reading process will not be affected by protocol source differences, such as field missing or format errors. Taking the protocol unified converter as the data processing core, the connection parameters and data acquisition rules of each industrial equipment node are configured through the configuration interface provided by the runtime service. The connection parameters include device address, communication channel identifier, interface port number, protocol type, session retention time, and connection priority. The data acquisition rules include sampling period, filter rule, data precision, alarm trigger threshold, data caching strategy, and data flow path. All configuration parameters are registered in the system configuration database and delivered to the device service process. The service process calls the acquisition interface in real time in combination with the protocol converter and generates device data output in a standard format, thereby obtaining standardized device data.

[0032] In one example, converting the standard data structure and establishing the protocol unified converter includes: Performing a byte position inversion operation on the integer and floating-point numerical values in the standard data structure to obtain numerical data; Extending the 32-bit single-precision floating-point number of the numerical data to a 64-bit double-precision format to obtain floating-point number data, and performing automatic identification of the encoding type of the string content contained in the floating-point number data to obtain character data; Constructing a mapping index from a source address to a target address according to the character data, and establishing a bidirectional lookup table containing protocol type, data address, and conversion function pointer according to the mapping index; When receiving data of any protocol in the bidirectional lookup table, the corresponding conversion rule is located and data format conversion is performed to obtain the protocol uniform converter.

[0033] In this example, the fields in the standard data structure are classified and processed according to the field type. For integer and floating point type fields, byte position reversal operations are performed according to the byte order convention of the protocol to which they belong. This step is used to solve the compatibility problem between different industrial equipment that follows different byte alignment specifications, such as big-endian (MSB first) and little-endian (LSB first). During runtime, the original byte arrangement of each field is automatically extracted by the protocol metadata parser, and a byte reversal function is called to reorder the original byte sequence of each integer or floating point field. 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 a unified data bus. The reversed value is considered as a valid numerical data. After completing the byte reversal operation, all 32-bit single-precision floating point fields in the numerical data are expanded to support high-precision control and long-period accumulation calculation tasks. The expansion method uses the format conversion mechanism defined in the IEEE 754 standard to split the original 32-bit floating point number into sign bit, exponent bit, and mantissa bit, and constructs a corresponding 64-bit double-precision floating point representation through mantissa padding and exponent expansion, ensuring that the data has sufficient resolution and expression range in high-precision calculation scenarios. For rounding errors and infinity representations that occur during the expansion process, an error masking strategy and overflow detection mechanism are introduced to modify the data boundary and generate a conversion status code. Further detection is performed to determine whether any character content is embedded in the floating point value, such as ASCII code strings or hexadecimal encoded text encapsulated using floating point encoding in some industrial communication protocols. A character pattern recognition function is used to perform semantic detection on each byte segment in the floating point value, including character frequency statistics, printability judgment, start and end control symbol recognition, and encoding interval positioning. Based on this, the encoding type is determined, such as UTF-8, GB2312, ASCII, ISO8859-1, etc. The character information encapsulated in the floating point number is extracted and converted into recognizable character data. Based on the parsed character data, a mapping index from the source address to the target address is constructed. The mapping index represents the mapping relationship between the physical address of a certain field in the source device and the standard field address in the target system in different protocol devices. The mapping relationship involves device logical address, register offset, memory segment number, buffer start position, etc. 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 the protocol characteristics, which contains source device ID, source protocol type, source data offset, target field identifier, target register mapping number, etc. Based on the mapping index, a bidirectional lookup table is constructed, and 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 is used to identify the protocol adapter component corresponding to the mapping table entry, the data address field contains the original data source address and the standard address format, and the conversion function pointer field points to the pre-registered field processing function, including byte reversal function, encoding conversion function, numerical reduction function and exception handling callback function, etc. The bidirectional lookup table supports two modes of forward lookup and reverse tracking. When the system is running, the protocol distribution module extracts the protocol type identifier and field address information in the data through the soft bus interface or shared memory mechanism when receiving a new data packet from any protocol device. The bidirectional lookup table is executed to locate the corresponding conversion function. Hash index, protocol priority sorting and invalid pointer filtering strategies are used in the lookup process to improve the matching efficiency. After successful matching, the data format conversion operation is performed through the bound conversion function pointer, including byte sequence rearrangement, unit conversion, encoding reconstruction, floating point number splitting, timestamp synchronization, symbol verification, illegal value replacement and field normalization processing, etc. The standard field data object is output, and the standard field data object is submitted to the standard data buffer of the protocol unified converter.

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

[0035] In this example, the connection configuration task is started 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 recognition mechanism. It allows the system to configure multiple key parameters of the connected device, such as communication protocol type, physical connection method, device logical number, port resource allocation, baud rate, check method, heartbeat period, connection maintenance strategy, link redundancy strategy, etc. The configuration results are packaged into a structured connection configuration parameter set, where each record identifies the protocol identification code of an industrial device, the connection parameter group, and the state detection item. After receiving the configuration request, the verification module performs parameter consistency check, range legality detection, and protocol adaptation verification to ensure that all configuration fields meet the corresponding protocol constraints and runtime requirements. The connection configuration parameters that pass the verification are written to the runtime device registry as the basic information structure for communication scheduling and data access. According to the device protocol information recorded in the connection configuration parameter set, the data point scanning task is started. The data point scanning task is executed by the model parser module inside the protocol unification converter. The model parser loads the corresponding data structure description template for each protocol type and guides the runtime to access the register space, variable mapping table, or object dictionary in the industrial device through the data structure description template. It performs data point traversal, variable label extraction, and attribute block reading operations at the field level. The scanning process not only identifies variable names, addresses, data types, but also includes variable scope, unit identification, upper and lower limits, read and write permissions, whether to participate in alarm triggering, whether to participate in event logs, function block ownership, and other meta-information dimensions. After the scanning process is completed, all field information is aggregated to generate a model configuration parameter set. According to the data change characteristics in the model configuration parameter set, the acquisition frequency is calculated. Based on indicators such as historical change rate, stability level, sensor type, signal change frequency, control response time limit, business importance level, etc., the optimal sampling period is calculated for each field using the change frequency algorithm, sliding window oscillation judgment method, or hierarchical decision-making mechanism. For fast-changing analog fields, higher sampling frequency and short-period caching strategies are set, while for state variables or periodic refresh fields, lower frequency, edge trigger, and value change responsive trigger strategies are used. At the same time, data filter settings (such as average value filtering, median value filtering), alarm judgment conditions (such as upper and lower limits, rate jump), data validity detection rules (such as dead zone judgment, packet repair), channel priority, etc. are defined in the acquisition rules.The field mapping and format conversion operation is performed on all configuration parameters in the collection rule, and the field alignment processing is performed based on the industrial data unified model. The industrial data unified model is a semantic abstraction framework for multi-protocol industrial equipment. The goal is to abstractly map the variable fields under various protocols to a unified namespace and structure format. During the mapping process, auxiliary information such as field semantic labels, device context, hierarchical structure information, and field ownership relationship is introduced to ensure that the field name, physical source, and logical meaning are consistent, and the mapped fields are uniformly represented using a structured path. At the format conversion level, according to the data type field in the collection rule and the model type definition, the data length, coding method, precision level, and unit standard of the field are unified, such as converting a 16-bit integer value to a 32-bit standard integer, converting a hexadecimal coded BCD code to a decimal value, appending a unit to a Celsius value and outputting it as a floating point number, converting a Boolean quantity to a state enumeration value, etc. All conversions are performed according to the unified type conversion table and coding rule template to form a standardized device data structure.

[0036] In one example, a data transmission channel is established according to the standardized device data, and global state synchronization and collaborative control instruction distribution are performed on multiple industrial devices to generate a distributed collaborative control network, including: The data volume statistics are performed on the data identifier, data type, timestamp, quality identifier, security level, and device source identifier in the standardized device data to obtain the data transmission memory requirement; Based on the data transmission memory requirement, the getShmem() interface is called to send a memory application request to the industrial automation runtime service. After the industrial automation runtime service receives the memory application request, it allocates an anonymous shared memory of corresponding size and returns a GetShmemResponse object to obtain the shared memory resource; According to the memory address and size parameters of the shared memory resource, the memory region is divided to obtain a hierarchical memory data structure, and the hierarchical memory data structure is mapped to the virtual address space of each industrial device process to obtain a data transmission channel; Based on the data transmission channel, global state synchronization and control instruction distribution are performed on multiple industrial devices to generate a distributed collaborative control network.

[0037] In this example, the data identifier, data type, timestamp, quality identification, security level and device source identification in the standardized device data are extracted, each field directly affects the spatial layout and field length configuration of the shared memory data model, so the field-level data volume statistics are performed, the occupied space, change frequency and update density of each type of field in the data structure are calculated, and the memory requirement estimation model is constructed based on this, considering the number of data points per second for each device, the field length of each data point, the alignment byte compensation, the retention proportion of redundant area and the maximum number of concurrent devices, etc., so as to estimate the minimum requirement space and recommended configuration space of the complete distributed system for shared memory in a single control cycle, and output the data transmission memory requirement. According to the data transmission memory requirement, the getShmem() interface provided by the industrial automation runtime service is called to initiate a memory application request, the getShmem() interface allows the caller to apply for an anonymous shared memory space of a specified size as needed, which is used for high-speed data interaction and low-latency communication. In the interface calling process, the calling parameters will carry the applicant identifier, the application memory length, the read-write permission mark and the pre-allocation strategy identifier. After receiving the application request, the industrial automation runtime service searches, allocates and binds handles to the current system free memory segment through the memory resource manager, and encapsulates the allocation result as a standard response object GetShmemResponse, which contains return status code, shared memory handle, allocation length, memory start address and binding token, etc. If the return status code is zero, it means that the allocation is successful, then the memory mapping and data structure initialization process is continued, otherwise the failure reason is recorded according to the error code and a second downgrade application is attempted. After obtaining the shared memory resource, the memory region is divided according to the returned memory address and memory total size parameters, and a multi-layer partitioned data cache structure, i.e. 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, including control state segment, real-time data segment, device identification segment, event buffer segment and instruction mapping segment. Each segment is further divided into field alignment units and write-protected areas to meet the requirements of industrial data in high-speed writing, high-frequency reading, multi-thread access and atomicity guarantee. The starting offset address, read-write permission and thread lock control structure are allocated for each logical segment, and registered in the system shared memory structure registration table.After completing the memory region division, the hierarchical memory data structure is mapped to the virtual address space of all industrial device processes involved in control and data interaction through a kernel-level interface mechanism. During the mapping process, the mmap mechanism or memory handle redirection method is used to map the allocated physical memory segment to a dedicated access path in the device-side business process space, and the write protection bit and access identification bit are set according to the process permission model to ensure that different devices do not interfere with each other and the access path is unique. After successful mapping, each industrial device process has the ability to access the 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 performed by the system master service periodically traversing the device state segments in the shared memory, comparing the historical state value and the current state value change, generating a synchronization flag bit through the event trigger mechanism, and summarizing all current running states of the devices into the main scheduler to form a system-level device state view. At the same time, the control instruction distribution is dynamically generated by the strategy scheduling engine based on real-time data collection and upper-level business policies, and is written into the target device channel through the control instruction segment in the shared memory according to the address mapping. The device locally scans the local shared memory channel address periodically and executes the valid instructions when received, including logical start-stop, parameter adjustment, action triggering, and process change operations. All devices complete state synchronization and instruction response through the same shared memory channel, and a real-time, efficient, low-latency, and strongly consistent distributed collaborative control network is constructed in structure. Based on the distributed collaborative control network, complex industrial application control objectives such as multi-device linkage control, production line centralized scheduling, device load balancing, and abnormal automatic switching are achieved.

[0038] In one example, global state synchronization and control instruction distribution are performed on multiple industrial devices based on a data transmission channel to generate a distributed collaborative control network, including: reading global device state data of the multiple industrial devices through the data transmission channel; performing device evaluation of an industrial control task based on the global device state data to obtain a control task allocation scheme; calling a call() interface to send control instructions in UInt8Array format to each industrial device according to the control task allocation scheme, transmitting the control instructions to each industrial device through a distributed soft bus and obtaining an execution confirmation in CallResponse format to obtain a control instruction transmission link; summarizing and analyzing the execution results of the devices in the control instruction transmission link, updating the global device state data and synchronizing to other industrial devices when any industrial device completes a control action to obtain a distributed collaborative control network.

[0039] In this example, based on the data transmission channel, the global state information of multiple industrial devices is continuously read from the pre-constructed hierarchical memory data structure through the high-speed shared memory communication mechanism or the message buffer mechanism of the industrial automation runtime service, including the current running mode, task state bit, execution load, resource occupancy rate, health status code, alarm flag, input and output signal state, sensor feedback and actuator feedback of each device. The global device state data is input into the distributed task evaluation module for real-time analysis. In the task evaluation module, for the current industrial control task waiting to be executed, combined with the device capability parameters, resource idle degree, communication delay, historical completion efficiency, control accuracy level and device location topology in the global device state data, multi-objective weighted scoring is performed on all candidate devices, and distributed evaluation model is used for sorting and optimization. State weight matrix and scheduling strategy function are applied in the evaluation process, and device priority is dynamically adjusted according to the control characteristics required by different tasks, such as real-time priority, minimum energy consumption, fast response, strong interconnection, etc. When a task can be completed by multiple devices, a sub-task division scheme is automatically constructed and a device load balancing algorithm is used to allocate sub-tasks to form a device-task mapping relationship. After the evaluation is completed, a structured control task allocation scheme is output, which records which industrial device node each task is allocated to, the expected start time, the expected completion time, the execution parameters and the response verification strategy. According to the control task allocation scheme, call() interface is called, control instruction data frame is constructed according to the device identifier and protocol stack type bound in each allocation item, and control logic parameters are packaged as UInt8Array format byte array. The byte array encapsulates device action type, command code, execution parameter, timestamp, check bit, etc. according to the protocol field structure, to ensure that devices under various protocols can correctly parse the control instruction. The call() interface provided by the runtime service is called to transmit the control request in UInt8Array format into the device execution channel. The call() interface calling process is based on the distributed soft bus architecture to realize end-to-end instruction routing and load scheduling. The instruction is transmitted from the main scheduling node to the target industrial device through the soft bus logical link, and the target device runtime receives, parses and prepares to execute. The system simultaneously starts the response monitoring thread to receive the CallResponse structure returned by the device as the execution confirmation. The confirmation object includes response status code, execution status bit, device echo information, error code and debug log summary. According to the response state, it is judged whether the control instruction is successfully issued and accepted by the target device, and the control instruction transmission link is obtained. During the process of distributing and executing all control instructions, the instruction 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 judges whether it is completed or aborted in association with the allocated task state. The devices that successfully return the control result are evaluated and the response time is recorded. The devices that fail or abnormally stop are executed with compensation strategy and re-allocated task.Whenever any industrial device completes a certain control task and returns a success signal, the state value of the device in the global device state data is updated immediately, and the device task is marked as completed, while the new state is pushed to all other device nodes through the shared memory broadcast mechanism or the soft bus broadcast link synchronization, so that the whole system maintains consistent state awareness. The timestamp and state version number in the state synchronization mechanism ensure that the device can perform state alignment or conflict resolution according to the latest version when different synchronization triggers.

[0040] Referring to Figure 2 The embodiment provides an industrial communication protocol adaptation system based on OpenHarmony, comprising: A deployment unit 01 is configured to perform distributed soft bus deployment on a plurality of industrial devices in an industrial control network to obtain a distributed device connection architecture; A loading unit 02 is configured to load a multi-protocol adapter on an industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; A configuration unit 03 is configured to identify and configure the communication protocol of the plurality of industrial devices according to the multi-protocol runtime service instance to obtain standardized device data; A generation unit 04 is configured to establish a data transmission channel according to the standardized device data, and perform global state synchronization and collaborative control instruction distribution on the plurality of industrial devices to generate a distributed collaborative control network.

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

[0042] The application establishes a unified distributed device connection architecture by deploying libjicruntime_server.z.so server library and libjicruntime_client.z.so client library, breaks the physical boundaries and system barriers between traditional industrial devices, and enables different types and functions of industrial intelligent devices to realize deep interconnection, thereby fundamentally solving the technical problem of isolated device operation. Through protocol matching algorithm and configuration file analysis, industrial protocol adapters such as OPC-UA parser, serial communication parser and CAN bus parser can be dynamically loaded, thereby realizing comprehensive support for heterogeneous industrial devices, significantly improving the compatibility and scalability of the system, and providing flexible technical support for device upgrade and expansion in industrial field. By establishing a bidirectional conversion mapping table and a standard data structure between protocols, seamless conversion of heterogeneous protocol data such as OPC-UA node value, Modbus register value and CAN message data is realized, thereby completely eliminating the long-standing "data island" problem in industrial control field, and enabling devices of different protocols to directly exchange and communicate data. Through the three-layer configuration mechanism of connection configuration, model configuration and data configuration, the automatic configuration of device connection parameters and data acquisition rules is realized, thereby greatly simplifying the deployment and maintenance of industrial control system, improving the accuracy and consistency of system configuration, and reducing the risk of manual configuration errors. Through the getShmem() interface and zero-copy technology, a high-speed data transmission channel is established, avoiding the data copying overhead of traditional network transmission, reducing the data exchange delay to the microsecond level, and significantly improving the real-time performance of the industrial control system, meeting the strict requirements of industrial control on data transmission speed. Through the call() interface and global state synchronization mechanism, the cooperative control of multiple industrial devices is realized, so that tasks can be executed on the most suitable device, and data can flow in real time where it is needed, like a neural network in the factory, enabling instructions and information to reach each execution node instantly, realizing true intelligent manufacturing cooperative control. Based on the unified development tool chain and standardized data model, developers only need to write core business logic code once, which can be efficiently adapted to run on devices with different hardware resources and different screen sizes, greatly reducing the development cost and maintenance complexity of industrial applications, and improving the efficiency and reusability of software development.

[0043] It should be noted that in this document, the terms "comprise", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, system, article or method that includes a series of elements not only includes those elements, but also includes other elements not explicitly listed, or inherent to such a process, system, article or method. Without more limitations, the element defined by the statement "comprises a" does not exclude the presence of another identical element in the process, system, article or method that includes the element.

[0044] The above merely provides the preferred embodiments of the present application, and is not intended to limit the patent scope of the present application. Any equivalent structure or equivalent flowchart transformation, or direct or indirect application in other related technical fields, which is made according to the contents of the present application specification and drawings, shall be included in the patent protection scope of the present application.

Claims

1. An OpenHarmony-based industrial communication protocol adaptation method, characterized in that, The method comprises the following steps: Distributed soft bus deployment is performed on a plurality of industrial devices in an industrial control network to obtain a distributed device connection architecture; A multi-protocol adapter is loaded on an industrial automation runtime service of the distributed device connection architecture to obtain a multi-protocol runtime service instance; Communication protocol identification and configuration are performed on the plurality of industrial devices according to the multi-protocol runtime service instance to obtain standardized device data; A data transmission channel is established according to the standardized device data, and global state synchronization and collaborative control instruction distribution are performed on the plurality of industrial devices to generate a distributed collaborative control network.

2. The OpenHarmony-based industrial communication protocol adaptation method according to claim 1, characterized in that, The distributed soft bus deployment on the plurality of industrial devices in the industrial control network to obtain the distributed device connection architecture comprises the following steps: A libjicruntime_server.z.so service library is deployed on a central node of the industrial control network to generate a distributed soft bus; A libjicruntime_client.z.so client library is deployed on the plurality of industrial devices in the industrial control network based on the distributed soft bus to form a set of device nodes; Device type identification and communication capability detection are performed on each device node in the set of device nodes to generate a device capability descriptor; Network distance and communication delay parameters between the plurality of industrial devices are calculated according to the device capability descriptor, and a distributed device connection architecture is generated based on the network distance and the communication delay parameters.

3. The OpenHarmony-based industrial communication protocol adaptation method according to claim 1, characterized in that, The multi-protocol adapter loading on the industrial automation runtime service of the distributed device connection architecture to obtain the multi-protocol runtime service instance comprises the following steps: Protocol type identifiers and communication interface parameters of each device node are extracted from the distributed device connection architecture, and protocol parsing quantity and version information are determined based on the protocol type identifiers and the communication interface parameters; jicruntime.cfg system configuration files and jicruntime.json protocol configuration files are parsed based on the protocol parsing quantity and the version information to extract a drive library path and initialization parameters corresponding to each protocol; libjicruntime_server.z.so service libraries, libjicruntime_client.z.so client libraries and libjicruntime.z.so SDK libraries are loaded in sequence according to the drive library path and the initialization parameters, and a service registration process is performed after the loading is completed to obtain registered service components; Logical architecture reorganization is performed on the registered service components to generate a multi-protocol runtime service instance.

4. The OpenHarmony-based industrial communication protocol adaptation method according to claim 3, characterized in that, The parsing of the jicruntime.cfg system configuration files and the jicruntime.json protocol configuration files based on the quantity and the version information to extract the drive library path and the initialization parameters corresponding to each protocol comprises the following steps: File stream reading and character encoding parsing are performed on the jicruntime.cfg system configuration files and the jicruntime.json protocol configuration files to obtain an original configuration data set; According to the number and the version information, a regular expression matching and a version number comparison operation are performed on a protocol identifier field in the original configuration data set to screen a target configuration data segment; Based on a library_path field and a module_path field in the target configuration data segment, a path string extraction and a path validity verification are performed to obtain a drive library path corresponding to each protocol; A parameter value analysis and a data type conversion are performed on an init_params field, a connection_timeout field and a buffer_size field in the target configuration data segment to obtain an initialization parameter corresponding to each protocol.

5. The OpenHarmony-based industrial communication protocol adaptation method according to claim 1, characterized in that, The communication protocol identification and the configuration for the multiple industrial devices by the multi-protocol runtime service instance to obtain the standardized device data, comprising: A standard protocol detection sequence is sent to the multiple industrial devices by the multi-protocol runtime service instance, and a protocol response frame characteristic code and a version identifier returned by each industrial device are obtained; A mode matching operation is performed on the protocol response frame characteristic 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 an original protocol data frame sent by each industrial device is byte-parsed based on the protocol parser component to obtain a parsed data packet set; Field rearrangement and type annotation are performed on the data field structure of different protocols in the parsed data packet set to obtain a standard data structure; The standard data structure is converted and a protocol unified converter is established; Based on the protocol unified converter, device connection parameters and data acquisition rules of the multiple industrial devices are configured to obtain the standardized device data.

6. The OpenHarmony-based industrial communication protocol adaptation method according to claim 5, characterized in that, The standard data structure is converted and a protocol unified converter is established, comprising: A byte position inversion operation is performed on integer and floating point numerical values in the standard data structure to obtain numerical data; A 32-bit single-precision floating point number of the numerical data is expanded to a 64-bit double-precision format to obtain floating point number data, and string content contained in the floating point number data is automatically identified to obtain character data; A mapping index from a source address to a target address is constructed according to the character data, and a bidirectional lookup table containing a protocol type, a data address and a conversion function pointer is established according to the mapping index; When data of any protocol is received in the bidirectional lookup table, a corresponding conversion rule is located and a data format conversion is performed to obtain the protocol unified converter.

7. The OpenHarmony-based industrial communication protocol adaptation method according to claim 6, characterized in that, Based on the protocol unified converter, device connection parameters and data acquisition rules of the multiple industrial devices are configured to obtain the standardized device data, comprising: Device connection parameters of each industrial device are connected and configured through a configuration interface opened by the protocol unified converter to obtain a connection configuration parameter set; Based on device protocol information in the connection configuration parameter set, data point scanning and attribute analysis are performed on each industrial device to obtain a model configuration parameter set; According to the data variation characteristics in the model configuration parameter set, the data acquisition frequency is calculated to obtain a data acquisition rule, and the configuration parameters in the data acquisition rule are field-mapped and format-converted according to the industrial data unified model to obtain standardized equipment data.

8. The OpenHarmony-based industrial communication protocol adaptation method according to claim 1, characterized in that, The standardized equipment data is used to establish a data transmission channel, and global state synchronization and collaborative control instruction distribution are performed on the plurality of industrial equipment to generate a distributed collaborative control network, including: The data identifiers, data types, timestamps, quality identifiers, security levels, and equipment source identifiers in the standardized equipment data are subjected to data volume statistics to obtain data transmission memory requirement; Based on the data transmission memory requirement, a getShmem() interface is called to send a memory application request to an industrial automation runtime service, and after the industrial automation runtime service receives the memory application request, an anonymous shared memory of a corresponding size is allocated and a GetShmemResponse object is returned to obtain a shared memory resource; According to the memory address and size parameters of the shared memory resource, a memory region is divided 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 state synchronization and control instruction distribution are performed on the plurality of industrial equipment to generate a distributed collaborative control network.

9. The OpenHarmony-based industrial communication protocol adaptation method according to claim 8, characterized in that, The data transmission channel is used to read the global equipment state data of the plurality of industrial equipment; Based on the global equipment state data, equipment evaluation of an industrial control task is performed to obtain a control task allocation scheme; According to the control task allocation scheme, a call() interface is called to send a control instruction in UInt8Array format to each industrial equipment, the control instruction is transmitted to each industrial equipment through a distributed soft bus, and a CallResponse format execution confirmation is obtained to obtain a control instruction transmission link; The device execution results in the control instruction transmission link are summarized and analyzed, when any industrial equipment completes a control action, the global equipment state data is updated and synchronized to other industrial equipment to obtain a distributed collaborative control network. The steps for implementing the OpenHarmony-based industrial communication protocol adaptation method of any one of claims 1 to 9 are as follows, and the OpenHarmony-based industrial communication protocol adaptation system comprises:

10. An OpenHarmony-based industrial communication protocol adaptation system, characterized in that, A deployment unit is configured to deploy a distributed soft bus for the plurality of industrial equipment in an industrial control network to obtain a distributed equipment connection architecture; A loading unit is configured to load a multi-protocol adapter for an industrial automation runtime service of the distributed equipment connection architecture to obtain a multi-protocol runtime service instance; A configuration unit is configured to identify and configure the communication protocol of the plurality of industrial equipment according to the multi-protocol runtime service instance to obtain standardized equipment data; ​ The generating unit is configured to establish a data transmission channel according to the standardized device data, and perform global state synchronization and collaborative control instruction distribution on the plurality of industrial devices to generate a distributed collaborative control network.

Images