Multi-interface industrial control equipment based on OpenHarmony industrial operating system and control method thereof

Abstract

The invention relates to the technical field of industrial operation, and discloses a multi-interface industrial control device based on an OpenHarmony industrial operating system and a control method thereof, and the method comprises the steps: scanning an interface resource list of an industrial control computer after the OpenHarmony industrial operating system is started; industrial equipment connected to each interface is automatically found according to the interface resource list, and an equipment connection table is obtained; performing protocol conversion based on the device connection table to obtain a device communication data stream, and extracting a feature data set from the device communication data stream; and calculating an interface coordination scheme based on the feature data set, issuing a control instruction to each industrial device, and collecting execution feedback to obtain unified management and control data. Unified control and remote cooperation of the industrial control equipment are realized through the OpenHarmony distributed soft bus, the conflict problem during multi-protocol concurrent access is effectively solved, and local intelligent decision and cloud resource scheduling of the industrial operation system are realized.

Description

Technical Field

[0001] This invention relates to the field of industrial operation technology, and in particular to a multi-interface industrial control device and its control method based on the OpenHarmony industrial operating system. Background Technology

[0002] Modern industrial control equipment needs to simultaneously support multiple physical interfaces such as USB, RS232, RS485, CAN bus, and Ethernet, as well as multiple industrial protocols such as OPC-UA, Modbus, CAN protocol, and serial communication. Traditional industrial control systems suffer from technical problems such as decentralized interface management, independent protocol adaptation, and outdated device discovery mechanisms. When multiple industrial protocols compete for the same interface resource simultaneously, problems such as data conflicts, transmission delays, and communication failures are prone to occur. Summary of the Invention

[0003] This invention provides a multi-interface industrial control device and its control method based on the OpenHarmony industrial operating system. This invention realizes unified management and remote collaboration of industrial control devices through the OpenHarmony distributed soft bus, effectively solves the conflict problem when multiple protocols access concurrently, and realizes local intelligent decision-making and cloud resource scheduling of the industrial operating system.

[0004] In a first aspect, the present invention provides a control method for multi-interface industrial control equipment based on the OpenHarmony industrial operating system, the control method for multi-interface industrial control equipment based on the OpenHarmony industrial operating system comprising: After the OpenHarmony industrial operating system starts, scan the list of interface resources of the industrial control computer; The system automatically discovers industrial devices connected to each interface based on the interface resource list, and obtains the device connection table. Based on the device connection table, a protocol conversion is performed to obtain the device communication data stream, and a feature dataset is extracted from the device communication data stream. Based on the feature dataset calculation interface coordination scheme, control commands are issued to each industrial device and execution feedback is collected to obtain unified management and control data.

[0005] In conjunction with the first aspect, in a first implementation of the first aspect of the present invention, the step of scanning the interface resource list of the industrial control computer after the OpenHarmony industrial operating system starts includes: After the OpenHarmony industrial operating system starts, the distributed soft bus driver module is loaded and the device management framework is initialized to obtain the soft bus node identifier and driver handle. Based on the soft bus node identifier and the driver handle, scan the USB interface, RS232 interface, RS485 interface, CAN bus interface and Ethernet interface on the industrial control computer to obtain the interface hardware information; Based on the interface hardware information, a unique OpenHarmony device identifier is assigned to each interface, and an interface abstraction layer data structure is established to obtain the interface mapping relationship. Based on the interface mapping relationship, the interface status monitoring mechanism is activated and the interface resource list is collected.

[0006] In conjunction with the first aspect, in a second implementation of the first aspect of the present invention, the step of automatically discovering industrial devices connected to each interface based on the interface resource list to obtain a device connection table includes: Based on the aforementioned interface resource list, start the OpenHarmony distributed soft bus device discovery service and create a local soft bus node; The local soft bus node broadcasts device discovery request messages to the industrial equipment connected to each interface and receives device response information. Based on the device response information, verify the OpenHarmony device certificate of each industrial device and identify the device identity information; Based on the device identity information, each verified industrial device is assigned an OpenHarmony device node identifier and the device connection table is recorded.

[0007] In conjunction with the first aspect, in a third implementation of the first aspect of the present invention, the step of performing protocol conversion based on the device connection table to obtain a device communication data stream, and extracting a feature dataset from the device communication data stream, includes: The industrial runtime service is started based on the device connection table, and the corresponding OPC-UA protocol adapter, Modbus protocol adapter, CAN protocol adapter and serial communication protocol adapter are instantiated according to the protocol type of each industrial device. Establish a bidirectional data transmission channel between each protocol adapter and the OpenHarmony distributed soft bus; Based on the bidirectional data transmission channel, the OPC-UA data packets, Modbus data packets, CAN data packets, and serial communication data packets of each industrial device are converted into OpenHarmony message format to obtain standardized message data packets; A protocol scheduling queue is established based on the standardized message data packets, and data stream scheduling is performed based on the protocol scheduling queue to obtain the device communication data stream.

[0008] In conjunction with the first aspect, in a fourth implementation of the first aspect of the present invention, the step of establishing a protocol scheduling queue based on the standardized message data packet and performing data stream scheduling based on the protocol scheduling queue to obtain a device communication data stream includes: A protocol scheduling queue is established based on the protocol type identifier in the standardized message data packet; The protocol type identifier of each standardized message data packet is parsed according to the protocol scheduling queue, and the OPC-UA message data packet is added to the first priority queue, the Modbus message data packet is added to the second priority queue, the CAN message data packet is added to the third priority queue, and the serial communication message data packet is added to the fourth priority queue based on the protocol type identifier, thus obtaining the message queue combination; Priority scheduling is performed based on the aforementioned message queue combination to obtain a message data packet sequence; The device communication data stream is generated by merging the message data packet sequence according to timestamp order. Extract feature datasets from the device communication data stream.

[0009] In conjunction with the first aspect, in a fifth implementation of the first aspect of the present invention, the step of extracting the feature dataset from the device communication data stream includes: The source device node identifier, target device node identifier, protocol type identifier, and timestamp information of each OpenHarmony message format in the device communication data stream are parsed to obtain the message communication parameters; Based on the aforementioned message communication parameters, monitor the data transmission volume of each interface and calculate the real-time load rate and transmission delay of the USB interface, RS232 interface, RS485 interface, CAN bus interface, and Ethernet interface. Count the number of concurrent accesses to the same interface by OPC-UA protocol, Modbus protocol, CAN protocol and serial communication protocol within the same time window; Collect the node hop count, network latency, and communication success rate of the OpenHarmony distributed soft bus, and combine the real-time load rate, transmission latency, concurrency count, node hop count, network latency, and communication success rate into a feature dataset.

[0010] In conjunction with the first aspect, in the sixth implementation of the first aspect of the present invention, the step of issuing control commands to various industrial devices and collecting execution feedback based on the feature dataset calculation interface coordination scheme to obtain unified management and control data includes: Conflict detection is performed on the feature dataset to obtain conflict detection results; Based on the conflict detection results, the first deep Q-network algorithm is started. The main network in the first deep Q-network algorithm predicts the action value of the current state, and the target network calculates the target Q value to obtain the value assessment result. Based on the value assessment results, the second deep Q-network algorithm of the OpenHarmony distributed soft bus is executed in parallel to calculate the value decomposition results; Based on the value decomposition results, an interface coordination scheme is calculated, which includes the optimal interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme. According to the interface coordination scheme, control commands are issued to each industrial device and execution feedback is collected to obtain unified management and control data.

[0011] In conjunction with the first aspect, in the seventh implementation of the first aspect of the present invention, the step of parallel execution of the second deep Q-network algorithm of the OpenHarmony distributed soft bus based on the value assessment result to calculate the value decomposition result includes: Receive the value assessment results, and construct the state value function and advantage function of the second deep Q-network algorithm based on the value assessment results; The first calculation task of the state value function is assigned to the master node for processing using the OpenHarmony distributed soft bus, and the second calculation task of the advantage function is assigned to the corresponding device nodes for parallel computation. The target value score of the current multi-interface conflict state is calculated based on the master control node and the state value function, and the advantage value of each interface coordination action relative to the average action is calculated simultaneously based on the device node and the advantage function. The value decomposition results of each interface coordination action are generated based on the target value score and the advantage value.

[0012] In conjunction with the first aspect, in the eighth implementation of the first aspect of the present invention, the step of issuing control commands to various industrial devices according to the interface coordination scheme and collecting execution feedback to obtain unified management and control data includes: The interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme in the interface coordination scheme are converted into control commands corresponding to the industrial equipment connected to each USB interface, RS232 interface, RS485 interface, CAN bus interface, and Ethernet interface. The OpenHarmony distributed soft bus is used to select the optimal transmission path according to the control command, and the control command is sent to the corresponding industrial equipment based on the optimal transmission path. After the control command is issued, the system acquires the execution feedback data of each industrial device and integrates the execution feedback data to generate unified management and control data.

[0013] Secondly, the present invention provides a multi-interface industrial control device based on the OpenHarmony industrial operating system, the multi-interface industrial control device based on the OpenHarmony industrial operating system comprising: The scanning module is used to scan the list of interface resources of the industrial control computer after the OpenHarmony industrial operating system starts. The device discovery module is used to automatically discover industrial devices connected to each interface based on the interface resource list, and obtain a device connection table; The protocol conversion module is used to perform protocol conversion based on the device connection table to obtain the device communication data stream, and extract feature datasets from the device communication data stream. The interface coordination module is used to calculate the interface coordination scheme based on the feature dataset, issue control commands to various industrial devices and collect execution feedback to obtain unified management and control data.

[0014] The technical solution provided by this invention achieves unified abstraction and management of various heterogeneous interfaces through the OpenHarmony distributed soft bus architecture, breaking through the technical limitations of independent management of interfaces in traditional industrial control systems. It establishes a unified interface mapping mechanism based on device identifiers, enabling collaborative work and resource sharing of multiple interfaces such as USB, RS232, RS485, CAN bus, and Ethernet. By uniformly driving multiple protocol adapters through industrial runtime services, it achieves unified management and coordination of heterogeneous industrial protocols such as OPC-UA, Modbus, CAN, and serial communication, solving the technical problem of independent operation and lack of coordination mechanisms in traditional industrial control systems. It also establishes a standardized data encapsulation system based on the OpenHarmony message format. Through the deep Q-network algorithm, it achieves intelligent identification and automated processing of multi-interface resource conflicts, overcoming the technical problem of static rule scheduling in traditional industrial control systems. It establishes a dynamic resource allocation and protocol priority adjustment mechanism based on machine learning, effectively solving the conflict problem when multiple protocols access concurrently. Through the device discovery service of the OpenHarmony distributed soft bus, automatic identification, dynamic registration, and plug-and-play functionality for industrial equipment are achieved, overcoming the technical limitations of traditional industrial control systems that require manual configuration of device connections. A secure access mechanism based on device certificate verification and a distributed device collaborative management system are established. Real-time collection and analysis of multi-dimensional characteristics such as interface load rate, transmission latency, protocol contention, and soft bus hop count enable comprehensive perception and predictive maintenance of the industrial control system's operating status. A device health assessment model and anomaly early warning mechanism are established, improving system reliability and maintainability. The OpenHarmony distributed soft bus enables unified management and remote collaboration of industrial control equipment, supporting northbound cloud platform integration and southbound device control. A complete device lifecycle management system is established, achieving local intelligent decision-making and cloud resource scheduling.

[0015] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of an embodiment of the multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system in this invention. Figure 2This is a schematic diagram of an embodiment of a multi-interface industrial control device based on the OpenHarmony industrial operating system in this invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] To facilitate understanding of this embodiment, a detailed description of a multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system disclosed in this embodiment of the invention will be provided first. For example... Figure 1 As shown, the control method for multi-interface industrial control equipment based on the OpenHarmony industrial operating system includes the following steps: 101. After the OpenHarmony industrial operating system starts, scan the list of interface resources of the industrial control computer; Specifically, after the OpenHarmony industrial operating system starts, a kernel-level initialization process is invoked to load the distributed soft bus driver module into the runtime environment. Simultaneously, a device management framework is built, generating unique soft bus node identifiers and obtaining driver handles corresponding to each physical interface driver. This allows the operating system to access underlying hardware resources using a unified interface call format. Using the soft bus node identifiers and driver handles, various interfaces on the industrial control computer hardware platform are scanned sequentially, including four USB 3.0 interfaces, four RS232 interfaces, one RS485 interface, one CAN bus interface, and two Gigabit Ethernet interfaces. Hardware information for each interface is collected, such as interface type, physical address, speed capability, protocol compatibility, and current connection status. Based on the interface hardware information, a unique OpenHarmony device identifier is assigned to each physical interface, and an interface abstraction layer data structure is established based on this. This data structure includes interface type enumeration, physical address mapping, and driver handle pointers, as well as status flags and a configurable parameter table, thus forming an interface mapping relationship. Based on the interface mapping relationship, an interface status monitoring mechanism is initiated to periodically collect real-time operating data of each interface, including key performance indicators such as load rate, transmission latency, and error count, and then summarizes this data into an interface resource list.

[0021] 102. Automatically discover the industrial devices connected to each interface based on the interface resource list, and obtain the device connection table; Specifically, the OpenHarmony distributed soft bus device discovery service is initiated based on the interface resource list, and a local soft bus node is created. A unique node identifier is generated for each local soft bus node to identify the industrial control computer's identity in the distributed network. Using the local soft bus node, a device discovery request message is broadcast to the connected industrial devices for each activated interface listed in the interface resource list. The request message is constructed according to the standard message encapsulation format of the OpenHarmony distributed soft bus and sent through the corresponding physical interface and protocol channel. Upon receiving the device discovery request, each industrial device returns device response information including its own device type, protocol support capabilities, network address, and interface parameters. While receiving and parsing the device response information, the OpenHarmony device certificate attached to each device is verified to ensure it is a trusted device and prevent unauthorized devices from accessing the industrial control network. After certificate verification, the system extracts identity feature data from the device response information to identify the device's identity, including manufacturer, model, and functional category. Based on this, a unique OpenHarmony device node identifier is assigned to each verified industrial device. The OpenHarmony device node identifier, along with its corresponding interface information, protocol capabilities, and network parameters, is recorded in the device connection table. The device connection table is continuously updated during system operation to reflect the status and attributes of all currently connected devices in the network.

[0022] 103. Perform protocol conversion based on the device connection table to obtain the device communication data stream, and extract the feature dataset from the device communication data stream; Specifically, the industrial runtime service is started based on the device connection table. According to the protocol type recorded in the connection table for each connected industrial device, corresponding protocol adapters are instantiated, including OPC-UA, Modbus, CAN, and serial communication protocol adapters. While instantiating the adapters, the industrial runtime service allocates independent running threads and buffers to each adapter to ensure parallelism and isolation in data processing for different protocols. A bidirectional data transmission channel is established between each protocol adapter and the OpenHarmony distributed soft bus, forming a bidirectional communication link. During data exchange, based on the protocol parsing and encapsulation functions of each adapter, OPC-UA, Modbus, CAN, and serial communication data packets are uniformly converted into the OpenHarmony standardized message format. The standardized message data packets include fields such as source device identifier, target device identifier, protocol type, data length, timestamp, and verification information in the message header, thereby achieving consistent encapsulation across protocols. Based on task priority, protocol type, and real-time requirements, the standardized message data packets are sequentially added to the protocol scheduling queue. The protocol scheduling queue is dynamically maintained by the industrial runtime service, and the processing order is adjusted according to interface load status and arbitration strategy. The protocol scheduling queue is used to schedule and distribute standardized messages from different sources in an orderly manner, forming a continuous and controllable device communication data stream.

[0023] 104. Based on the feature dataset calculation interface coordination scheme, control commands are issued to various industrial equipment and execution feedback is collected to obtain unified management and control data.

[0024] Specifically, the conflict detection module built into the industrial runtime service analyzes the feature dataset to identify access conflicts and resource contention between different industrial protocols, physical interfaces, or data flows. The conflict detection process compares multiple operating parameters, such as interface load rate, transmission latency, protocol priority, and soft bus hop count, to generate conflict detection results including conflict type, conflict intensity, and conflict probability. After obtaining the conflict detection results, the first deep Q-network algorithm (DQN) is activated. The main network processes the current system state input, predicts the value of each possible action in this state, and simultaneously calculates the corresponding target Q-value using the target network. The prediction results from the main network are combined with the calculation results from the target network to obtain the value assessment result. Based on the value assessment result, the second deep Q-network algorithm, enhanced with OpenHarmony distributed soft bus, is executed in parallel. The second deep Q-network algorithm has value decomposition capabilities. By decomposing the overall Q-value into a state value function and a dominance function, it refines the key influencing factors in interface scheduling and protocol arbitration, generating value decomposition results including the priority of each interface and protocol, resource utilization contribution, etc. Based on the value decomposition results, an interface coordination scheme is calculated, which includes the optimal interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme. The industrial runtime service issues specific control commands to each industrial device according to the interface coordination scheme, including operations such as interface switching, task delay, data flow migration, or protocol degradation. During the execution of commands, the service collects the execution feedback from the devices in real time, and summarizes the feedback information with the scheduling results to form unified management and control data.

[0025] In one specific embodiment, the process of performing step 101 may specifically include the following steps: After the OpenHarmony industrial operating system starts, the distributed soft bus driver module is loaded and the device management framework is initialized to obtain the soft bus node identifier and driver handle. Based on the soft bus node identifier and driver handle, scan the USB interface, RS232 interface, RS485 interface, CAN bus interface and Ethernet interface on the industrial control computer to obtain the interface hardware information; Based on the interface hardware information, a unique OpenHarmony device identifier is assigned to each interface, and an interface abstraction layer data structure is established to obtain the interface mapping relationship. The interface status monitoring mechanism is initiated based on the interface mapping relationship, and the interface resource list is collected.

[0026] Specifically, after the OpenHarmony industrial operating system boots up, the distributed soft bus driver module is loaded into the operating system kernel's runtime environment, and parameter configuration and dependency initialization are performed. During the driver module loading process, a device management framework is simultaneously built. This framework, as the core subsystem of the industrial operating system, manages all hardware interfaces and peripheral resources, abstracting physical interfaces, establishing unified access interfaces, and maintaining interface operational status. After the device management framework initialization is complete, a soft bus node identifier is generated—the unique identifier of the current industrial control computer in the distributed soft bus network—using a composite code generated by combining the device MAC address, timestamp, and OpenHarmony internal identifiers. Simultaneously, the handle of each physical interface driver in the kernel is obtained. The driver handle is the control entry point for the operating system to access the underlying hardware, used to send commands to the hardware, read its status, and perform configuration operations. Based on the soft bus node identifier and driver handle, the interface scanning program of the device management framework is invoked to perform a comprehensive detection and information collection of all supported interface types on the current industrial control computer hardware platform. The interfaces include four USB 3.0 high-speed data interfaces, four RS232 serial communication interfaces, one RS485 industrial bus interface, one CAN bus interface, and two Gigabit Ethernet interfaces. During the scanning process, information such as the physical address, transmission rate capability, protocol support, hardware version number, connection status, and current load rate of each interface is read through the corresponding driver. The collected data constitutes the interface hardware information set. A unique OpenHarmony device identifier is assigned to each physical interface based on the interface hardware information and device identifier. An interface abstraction layer data structure is established based on the interface hardware information and device identifier. This data structure includes interface type enumeration values, a physical address mapping table, driver handle pointers, current running status flags, a configurable parameter table, and a historical performance data buffer. This abstracts physical interfaces into logical interface objects, enabling upper-layer applications and protocol adaptation layers to access and manage different types of interfaces in a unified manner. An interface status monitoring mechanism is initiated based on the interface mapping relationship. This mechanism uses a combination of periodic sampling and event triggering to monitor the operational status of all mapped interfaces in real time, collecting key performance indicators such as current interface load rate, data transmission latency, error count, link stability, instantaneous bandwidth usage, and error frame ratio. This monitoring mechanism caches this operational data in a monitoring buffer in memory and reports the data to the device management framework periodically or when status changes exceed preset thresholds. Upon receiving the monitoring data, the device management framework combines it with the static hardware information of the interfaces to generate an interface resource list.

[0027] In one specific embodiment, the process of performing step 102 may specifically include the following steps: Start the OpenHarmony distributed soft bus device discovery service based on the interface resource list and create a local soft bus node; The local soft bus node broadcasts device discovery request messages to the industrial devices connected to each interface and receives device response information. Verify the OpenHarmony device certificates of each industrial device based on device response information and identify device identity information; Each verified industrial device is assigned an OpenHarmony device node identifier based on its device identity information, and the device connection table is recorded.

[0028] Specifically, the device discovery service of the OpenHarmony distributed soft bus is started based on the interface resource list. As the core component for the automatic identification of multi-interface industrial devices, the device discovery service is initialized simultaneously in the kernel and user space. Based on the physical interface type, address information, and driver handle recorded in the interface resource list, the device discovery service establishes the corresponding communication channel configuration file and registers it in the distributed soft bus framework, enabling it to access all interfaces through a unified soft bus management layer. At this point, a local soft bus node is created as the logical identity of the current industrial control computer in the distributed network environment, represented by a unique node identifier. This node identifier combines the device's MAC address, soft bus version number, and timestamp to ensure no identifier conflicts occur in large-scale industrial networks. Based on the local soft bus node, the distributed soft bus device discovery mechanism is invoked, sending device discovery request messages to all connected industrial devices through the established interface channels. The device discovery request message is generated according to the standard encapsulation format of the OpenHarmony soft bus. The message body contains information such as the local node identifier, interface identifier, request type, and timestamp, and is sent out via physical interfaces such as USB, RS232, RS485, CAN bus, and Ethernet in broadcast or point-to-point format. Upon receiving a device discovery request message, each industrial device returns a response message based on its supported protocols and device discovery standards. This response includes the device's manufacturer information, model, interface type, supported industrial protocols, firmware version, network parameters, and its OpenHarmony device certificate. When the system receives the response, it extracts the OpenHarmony device certificate and invokes the device trust verification module to verify its validity. The verification process includes checking the certificate authority's trustworthiness, the certificate's validity period, whether the certificate signature matches the identity data in the device response, and whether the certificate contains any revocation records. If the verification is successful, the industrial device is recognized as a trusted device, allowing it to access the distributed soft bus network. Under the premise of successful verification, the device's identity information is extracted from the response, including its unique hardware identifier, functional category, protocol capabilities, geographical location identifier, and interface mapping relationships. Each verified industrial device is assigned an OpenHarmony device node identifier. This identifier is a unique logical identifier for the device in the distributed soft bus network, used for communication, resource scheduling, and status management. It is associated with both the physical interface identifier and the local node identifier to enable unified addressing and access control across nodes and protocols. The assigned node identifier, along with the device's identity information, interface type, protocol support capabilities, network parameters, and current connection status, is recorded in the device connection table.The device connection table is maintained in real time by the industrial runtime service and supports dynamic updates. When a new device is connected, a new entry is automatically added, and when a device is disconnected or its status changes, the corresponding record is modified immediately.

[0029] The process of verifying the OpenHarmony device certificates of each industrial device and identifying device identity information based on device response information includes: a device certificate verification module extracting the OpenHarmony device certificates of each industrial device from the device response information and parsing the device manufacturer identifier, device model information, supported protocol list, and digital signature in the certificate to obtain the device certificate parsing result; a distributed soft bus security authentication engine verifying the validity of the digital signature and checking the trustworthiness of the certificate authority based on the device certificate parsing result, while verifying whether the device manufacturer identifier is in the OpenHarmony industrial device whitelist to obtain the device security authentication status; and a protocol capability identification algorithm parsing the OPC-UA protocol version and Modbus protocol version in the device's supported protocol list based on the device security authentication status. The system identifies the specific protocol implementation capabilities and compatibility characteristics of each device by checking RTU / TCP support, CAN protocol baud rate configuration, and serial communication protocol parameters, thus obtaining a device protocol capability profile. Based on this profile, the device identity registration service generates a unique OpenHarmony device node identifier for each verified industrial device and establishes a device identity database, recording the device's MAC address, IP address, protocol port, and connection timestamp, thus obtaining complete device identity information. The trust relationship establishment mechanism establishes trust relationships between devices in the OpenHarmony distributed soft bus based on the device identity information and assigns corresponding access permissions, ensuring that only certified industrial devices can participate in multi-interface coordination and control, thus obtaining the device trust relationship configuration.

[0030] In one specific embodiment, the process of performing step 103 may specifically include the following steps: The industrial runtime service is started based on the device connection table, and the corresponding OPC-UA protocol adapter, Modbus protocol adapter, CAN protocol adapter and serial communication protocol adapter are instantiated according to the protocol type of each industrial device. Establish a bidirectional data transmission channel between each protocol adapter and the OpenHarmony distributed soft bus; Based on the bidirectional data transmission channel, OPC-UA data packets, Modbus data packets, CAN data packets, and serial communication data packets of various industrial devices are converted into OpenHarmony message format to obtain standardized message data packets; A protocol scheduling queue is established based on standardized message data packets, and data stream scheduling is performed based on the protocol scheduling queue to obtain the device communication data stream.

[0031] Specifically, the industrial runtime service is started based on the device connection table. This service is the core execution module of the OpenHarmony industrial operating system in multi-interface industrial control environments, responsible for coordinating key tasks such as protocol adaptation, data flow management, and cross-device communication. After starting the service, it reads the protocol type information corresponding to each industrial device in the device connection table and instantiates corresponding protocol adapters for different protocol types, including OPC-UA, Modbus, CAN, and serial communication protocol adapters. The instantiation process for each adapter includes loading the protocol stack, configuring necessary communication parameters, and allocating an independent running thread and memory buffer to ensure that different protocols do not interfere with each other during operation, while also possessing concurrent processing capabilities to meet the high real-time requirements of simultaneous communication between multiple devices in industrial environments. After each protocol adapter is instantiated, a bidirectional data transmission channel is established between each adapter and the OpenHarmony distributed soft bus. The establishment of this bidirectional data transmission channel relies on the message publishing and subscription mechanism and point-to-point transmission capabilities provided by the soft bus. The bidirectional data transmission channel's uplink direction transmits data generated by industrial equipment to the distributed soft bus after being parsed by the protocol adapter, enabling upper-layer applications or other device nodes to access this data. The downlink direction receives control commands or data from the distributed soft bus, which are then encapsulated by the protocol adapter into a data format conforming to the target industrial equipment's protocol before being sent to the device via the physical interface. Under stable operation of the bidirectional data transmission channel, based on the parsing capabilities of each protocol adapter, native data packets from industrial equipment, such as OPC-UA packets, Modbus packets, CAN packets, and serial communication packets, are uniformly converted into OpenHarmony's standardized message format. The standardized message format explicitly includes fields such as source device identifier, target device identifier, protocol type, data length, timestamp, and data integrity checksum in the message header, while the message body stores the parsed and necessary encapsulated payload data, allowing data from different protocols to be transmitted and processed in a consistent structure within the distributed soft bus. The industrial runtime service adds standardized message packets to the protocol scheduling queue sequentially based on task priority, protocol type, real-time requirements, and interface load. The protocol scheduling queue is dynamically maintained by the system and can adjust the dequeue order of data packets under different runtime states. For example, it can prioritize the processing of OPC-UA control commands with high real-time requirements, or delay the processing of low-priority data acquisition information when the network load is high. In conjunction with the system's conflict arbitration strategy, the protocol scheduling queue automatically reorders or temporarily stores data packets when different protocols are detected contending for the same interface, to prevent interface congestion or data conflicts.Based on the dequeue strategy and scheduling algorithm of the protocol scheduling queue, data packets are transmitted in a determined order and at time intervals to form a continuous and controllable device communication data stream.

[0032] The process involves starting an industrial runtime service based on the device connection table and instantiating corresponding protocol adapters according to the protocol type of each industrial device. This includes: the industrial runtime service manager parsing the protocol type identifier of each industrial device in the device connection table and loading the corresponding protocol adapter dynamic library; loading the OPC-UA server library for OPC-UA devices, the Modbus master library for Modbus devices, the CAN driver library for CAN devices, and the serial communication library for serial communication devices, thus obtaining the protocol library loading status; and the protocol adapter factory mode creating a corresponding adapter instance for each protocol type based on the protocol library loading status. The OPC-UA protocol adapter is configured with a subscription mechanism and security policy, the Modbus protocol adapter has its polling cycle and register mapping set, the CAN protocol adapter has its message filter and baud rate configured, and the serial communication protocol adapter has its baud rate and data format set, thus obtaining the protocol library loading status. The protocol adapter instance set is used for the unified interface encapsulation layer. Based on this set, a standardized data read / write interface is provided for each protocol adapter, encapsulating the native APIs of different protocols into unified read, write, subscribe, and notify methods, thus shielding the underlying protocol differences and resulting in a unified protocol interface encapsulation. The protocol adapter lifecycle manager monitors the running status of each protocol adapter based on this unified protocol interface encapsulation and provides start, stop, restart, and exception recovery functions. When an adapter exception is detected, it automatically restarts or switches to a backup adapter, thus obtaining the protocol adapter management status. The industrial runtime service bus integrates the protocol adapter management status with the OpenHarmony distributed soft bus, establishing a message routing mechanism between the protocol adapter and the distributed soft bus to achieve transparent cross-device protocol data transmission, thus obtaining the industrial runtime service integration status.

[0033] In one specific embodiment, the process of establishing a protocol scheduling queue based on standardized message data packets and performing data stream scheduling based on the protocol scheduling queue to obtain the device communication data stream can specifically include the following steps: Establish a protocol scheduling queue based on the protocol type identifier in the standardized message data packet; The protocol type identifier of each standardized message data packet is parsed according to the protocol scheduling queue, and the OPC-UA message data packet is added to the first priority queue, the Modbus message data packet is added to the second priority queue, the CAN message data packet is added to the third priority queue, and the serial communication message data packet is added to the fourth priority queue based on the protocol type identifier, thus obtaining the message queue combination; Priority scheduling is performed based on message queue combinations to obtain message data packet sequences; The device communication data stream is generated by merging message data packets according to their timestamp order. Extract feature datasets from device communication data streams.

[0034] Specifically, the scheduling management module within the industrial runtime service establishes a protocol scheduling queue based on the protocol type identifier in the standardized message data packets. The scheduling management module iterates through all standardized message data packets in the current buffer, reads the protocol type identifier field from their message headers, and uses this field as a classification criterion to establish corresponding priority queue structures for different protocol types. Based on the protocol scheduling queue, the module parses the protocol type identifier of each standardized message data packet, adding packets conforming to the OPC-UA protocol type identifier to the first priority queue, packets conforming to the Modbus protocol type identifier to the second priority queue, packets conforming to the CAN protocol type identifier to the third priority queue, and packets conforming to the serial communication protocol type identifier (such as RS232 or RS485) to the fourth priority queue. Based on the matching of the protocol identifier field, and combined with real-time load and latency information provided by the interface status monitoring module, the priority distinction between different queues is maintained even under high load conditions, forming a message queue combination consisting of four priority queues. Based on this message queue combination, the industrial runtime service initiates a priority scheduling algorithm, using the message queue priority as the core scheduling criterion, while also considering real-time requirements, task urgency, and interface conflict detection results for comprehensive sorting. During scheduling, OPC-UA packets in the first priority queue are extracted first and sent to the transmission buffer to meet the high requirements for real-time performance and reliability in industrial control scenarios. Modbus packets in the second priority queue are scheduled for processing when OPC-UA packet transmission is completed or the transmission window is idle. CAN packets in the third priority queue are scheduled after the first two types of packets have been processed. Serial communication packets in the fourth priority queue are transmitted only after other queue tasks have been completed or the scheduling cycle is about to end. A message packet sequence is generated based on the dequeue order determined during scheduling. The message packet sequence is then reordered chronologically based on the timestamp field in the standardized message format for each packet, and merged according to timestamp order. During merging, a unified time slice identifier is established for multi-protocol packets within the same time window, enabling cross-protocol synchronous playback and collaborative control during data stream transmission, generating a device communication data stream. Feature datasets are extracted from the device communication data stream, including protocol type distribution ratios, packet length statistics, time interval distribution, latency trends, error rates, packet loss rates, load fluctuations, and the frequency of data interaction between different protocols.

[0035] In one specific embodiment, the process of extracting a feature dataset from the device communication data stream may specifically include the following steps: The source device node identifier, target device node identifier, protocol type identifier, and timestamp information of each OpenHarmony message format in the device communication data stream are parsed to obtain the message communication parameters; Based on message communication parameters, monitor the data transmission volume of each interface and calculate the real-time load rate and transmission delay of the USB interface, RS232 interface, RS485 interface, CAN bus interface and Ethernet interface. Count the number of concurrent accesses to the same interface by OPC-UA protocol, Modbus protocol, CAN protocol and serial communication protocol within the same time window; The number of node hops, network latency, and communication success rate of the OpenHarmony distributed soft bus are collected, and the real-time load rate, transmission latency, concurrency, number of node hops, network latency, and communication success rate are combined into a feature dataset.

[0036] Specifically, the communication parsing module built into the industrial runtime service parses each record in the device communication data stream that conforms to the OpenHarmony standardized message format. During parsing, the source device node identifier, target device node identifier, protocol type identifier, and timestamp information are extracted from the message header fields, uniformly organized into a message communication parameter set, and indexed and associated with the corresponding payload data in the data stream. The source and target device node identifiers together define the directionality of communication, the protocol type identifier clarifies the type of transmission protocol for the data packet, and the timestamp records the precise time point when the data packet was generated or entered the network. The data transmission volume of each interface is monitored in real time based on the message communication parameters. During monitoring, according to the interface mapping relationship, each message communication parameter is mapped to a specific physical interface type (such as USB, RS232, RS485, CAN bus, or Ethernet), and the data transmission volume of the specific physical interface within the current statistical period is accumulated. Simultaneously, the time difference from message generation to receipt confirmation is recorded, and the transmission delay of the corresponding interface is calculated. The real-time load rate is calculated based on the ratio of the interface bandwidth limit to the current data transmission volume, obtaining the real-time load rate of the USB, RS232, RS485, CAN bus, and Ethernet interfaces at any given time. This, combined with transmission latency, constitutes a key performance indicator for the interface. To analyze resource contention among different protocols on the interface, the concurrent access counts of OPC-UA, Modbus, CAN, and serial communication protocols to the same physical interface are counted within the same time window. The statistical process relies on timestamp comparison, dividing the time window into millisecond-level or finer-grained segments. Within each window, the number of different protocol requests accessing the same interface is calculated, identifying high-frequency concurrent access hotspot interfaces and analyzing multi-protocol contention patterns, such as the contention frequency between OPC-UA and Modbus on the RS485 interface, or the mixed access behavior between CAN bus and Ethernet. Simultaneously, key performance indicators related to the global communication path, including node hop count, network latency, and communication success rate, are collected through the monitoring interface of the OpenHarmony distributed soft bus. Node hop count reflects the number of logical nodes that must be traversed for communication between the source and target device nodes via the soft bus. A higher node hop count indicates greater path complexity and potential latency risk. Network latency refers to the end-to-end transmission time of a message in a distributed soft bus network. Communication success rate measures the reliability of messages during transmission. Real-time load rate, transmission latency, concurrency, node hop count, network latency, and communication success rate are combined into a feature dataset.

[0037] The calculation involves counting the concurrent access counts of OPC-UA, Modbus, CAN, and serial communication protocols to the same interface within the same time window. This includes: a time window segmentation manager dividing the system runtime into consecutive time windows in 100-millisecond increments and assigning a unique identifier to each time window, while maintaining a sliding window queue to cache the access records of the most recent 10 time windows, thus obtaining a time window segmentation structure; protocol access monitoring probes deploying protocol listeners on each USB, RS232, RS485, CAN bus, and Ethernet interface based on the time window segmentation structure to capture OPC-UA read / write requests, Modbus query responses, CAN message transmission / reception, and serial communication data transmission events in real time, obtaining an interface-level protocol access event stream; and a concurrency counting algorithm engine calculating the number of concurrent accesses to the same interface within each time window based on the interface-level protocol access event stream. The system counts the number of times each protocol accesses the same interface, detects whether the OPC-UA protocol and Modbus protocol access the RS485 interface simultaneously, and whether the CAN protocol and serial communication protocol use the same physical channel concurrently, calculates the concurrent access frequency of each protocol, and obtains the protocol concurrent access statistics. The conflict pattern recognition algorithm identifies typical interface conflict patterns based on the protocol concurrent access statistics. When multiple protocols are detected accessing the same interface within the same time window and the number of accesses exceeds a preset threshold, it is marked as a high-risk conflict. When the protocol access times overlap but the number of accesses is small, it is marked as a potential conflict, and the protocol conflict risk level is obtained. The protocol contention calculation module calculates the protocol contention value of each interface according to the protocol conflict risk level. It uses a weighted average algorithm to comprehensively consider protocol priority, access frequency, and conflict duration to generate a contention score between 0 and 1, and obtains a quantified protocol contention index.

[0038] In one specific embodiment, the process of performing step 104 may specifically include the following steps: Perform conflict detection on the feature dataset to obtain the conflict detection results; The first deep Q-network algorithm is launched based on the conflict detection results. The main network in the first deep Q-network algorithm predicts the action value of the current state, and the target network calculates the target Q value to obtain the value assessment result. Based on the value assessment results, the second deep Q-network algorithm of the OpenHarmony distributed soft bus is executed in parallel to calculate the value decomposition results; Based on the value decomposition results, calculate an interface coordination scheme that includes the optimal interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme; Based on the interface coordination scheme, control commands are issued to various industrial devices and execution feedback is collected to obtain unified management and control data.

[0039] Specifically, the conflict detection module comprehensively analyzes multi-dimensional parameters in the feature dataset to identify resource contention and protocol conflicts in industrial communication networks. The conflict detection process correlates and calculates parameters such as real-time load rate, transmission latency, protocol concurrency, node hop count, network latency, and communication success rate. Through threshold comparison, pattern recognition, and comparison with historical operational data, it determines whether problems such as multiple protocols contending for the same interface, excessive delays in critical tasks, or network path congestion exist, generating conflict detection results that include conflict type, severity, impact range, and probability of occurrence. Based on the conflict detection results, the first deep Q-network algorithm is activated. As one of the core decision models for interface arbitration, the first deep Q-network algorithm uses the real-time state vector provided by the industrial runtime service as input to predict the value of each possible action in the current system state in the main network. These actions include interface switching, task delay, protocol degradation, and bandwidth reallocation. Simultaneously, the target network calculates the corresponding target Q-value based on the estimation result of the next state. By combining the prediction value from the main network and the calculated value from the target network, the bias in value function estimation during reinforcement learning training is reduced, resulting in a more stable and reliable value assessment result. Using the value assessment results as input, a second deep Q-network algorithm, running in conjunction with the OpenHarmony distributed soft bus, is initiated. This second deep Q-network algorithm employs a value decomposition architecture, breaking down the overall Q-value into a state value function and a dominance function. Through this value decomposition method, the importance of a particular interface or protocol in the current network state is clarified, and optimization priorities are quickly identified in complex situations involving mixed access from multiple protocols. This generates a value decomposition result that includes multi-dimensional indicators such as resource utilization contribution, latency sensitivity weight, and reliability score. An interface coordination scheme is calculated based on the value decomposition result. The industrial runtime service comprehensively considers the conflict detection results, value assessment results, and value decomposition results to generate an interface coordination scheme. The interface coordination scheme comprises three core components: an optimal interface resource allocation strategy, which ensures bandwidth for critical tasks and orderly postpones non-critical tasks through the reallocation of bandwidth, time slots, or priorities; protocol access timing arrangement, which designs time-division multiplexing or priority preemption access timing tables to ensure that protocols with high real-time requirements (such as OPC-UA) have priority access rights when multiple protocols concurrently access the same interface; and a data flow redirection scheme, which migrates some non-core data flows to low-load interfaces or other distributed soft bus nodes to achieve network-wide load balancing and avoid single-point bottlenecks. The interface coordination scheme is then translated into executable control commands and distributed to relevant industrial equipment via the OpenHarmony distributed soft bus. These control commands include interface switching commands, communication rate adjustment commands, access timing table distribution, and data flow migration configurations.While controlling command execution, real-time execution feedback information from the device is collected, including command execution success rate, execution latency, interface status changes, and task completion status. This feedback is compared with the original coordination scheme to evaluate scheduling effectiveness and execution consistency. All execution feedback and scheduling process data are aggregated to generate unified management data. This unified management data includes conflict detection results, value assessment data, value decomposition data, and execution feedback within the current scheduling cycle, forming an experience dataset for continuous model training.

[0040] The process involves several steps. First, a deep Q-network algorithm is initiated based on the conflict detection results. The algorithm predicts the action value of the current state through the main network and calculates the target Q-value through the target network, yielding a value assessment result. This includes: a dual industrial deep Q-network module receiving the conflict detection results and initializing a main network architecture comprising an input layer, three fully connected hidden layers, and an output layer. The input layer receives state feature vectors containing interface load rate, transmission delay, protocol contention, and soft bus hop count. Each hidden layer contains 128 neurons and uses the ReLU activation function to obtain the main network initialization configuration. The main network computation engine inputs the feature vectors of the current multi-interface conflict state into the neural network for forward propagation computation based on the main network initialization configuration. The three hidden layers perform nonlinear transformations to process resource allocation actions for the USB, RS232, RS485, CAN bus, and Ethernet interfaces. The output layer generates the corresponding coordination actions for each interface. Q-value prediction yields the main network action value prediction result; the target network calculation module constructs a target network with the same architecture as the main network in parallel and periodically copies network parameters from the main network. It uses the target network to calculate the maximum Q-value of the next state as the target value of the current state action. The training process is stabilized by fixing the target network parameters for a certain period, and the target network Q-value calculation result is obtained; the dual-network co-optimizer calculates the time difference error based on the main network action value prediction result and the target network Q-value calculation result, uses the Adam optimizer to update the main network weight parameters, and periodically copies the main network parameters to the target network, and obtains the network parameter update state; the value evaluation fusion module integrates the current action value prediction of the main network and the stable target value of the target network based on the network parameter update state, and generates the optimal action selection score for OPC-UA protocol, Modbus protocol, CAN protocol and serial communication protocol in a multi-interface environment, and obtains the value evaluation result.

[0041] In one specific embodiment, the execution step of executing the second deep Q-network algorithm of the OpenHarmony distributed soft bus in parallel according to the value assessment result to calculate the value decomposition result can specifically include the following steps: Receive the value assessment results and construct the state value function and advantage function of the second deep Q-network algorithm based on the value assessment results; The first calculation task of the state value function is assigned to the master node for processing by using the OpenHarmony distributed soft bus, and the second calculation task of the advantage function is assigned to the corresponding device nodes for parallel computation. The target value score of the current multi-interface conflict state is calculated based on the master node and the state value function, and the advantage value of each interface coordination action relative to the average action is calculated simultaneously based on the device node and the advantage function. The value decomposition results of each interface coordination action are generated based on the target value score and advantage value.

[0042] Specifically, the industrial runtime service analyzes the received value assessment results, categorizing the features reflecting the global system state and the individual performance indicators of each interface. Based on the categorization results, it constructs a state value function and an advantage function. The state value function characterizes the potential optimizable value of the current multi-interface industrial network under its overall operating state, while the advantage function measures the performance advantage of a specific coordinated action relative to the average performance of all available actions under a specific state. Leveraging the task distribution and collaborative computing capabilities of the OpenHarmony distributed soft bus, the computation tasks of the state value function and the advantage function are separated and deployed in parallel. The first computation task of the state value function is assigned to the master node, a core industrial control computer running on high-performance hardware (such as the RK3588 eight-core ARM64 processor). This master node possesses strong centralized computing capabilities and global state data access permissions, enabling it to calculate the target value score of the current multi-interface conflict state based on the global feature dataset in a short time. The second calculation task of the advantage function is assigned to corresponding subordinate device nodes for parallel processing according to the interface mapping relationship and the distribution of device nodes. These device nodes are edge controllers, sensor gateways, or sub-industrial control computers connected to different physical interfaces. They can quickly utilize local interface performance data and local protocol conflict characteristics to calculate the advantage value of their respective interface coordination actions relative to the average action performance. During distributed computing, the master node periodically broadcasts the current state's global identification information and necessary synchronization clock signals to the device nodes via a soft bus to ensure that the calculation of the state value function and the advantage function is based on a consistent time window and state feature set. Simultaneously, the device nodes send the intermediate results of the advantage value calculation back to the master node in real time. The master node integrates the advantage value with its own calculated target value score. After collecting all advantage values, the master node performs a combination operation on the target value score and each advantage value to generate the value decomposition result for each interface coordination action.

[0043] In one specific embodiment, the process of issuing control commands to each industrial device according to the interface coordination scheme and collecting execution feedback to obtain unified management and control data can specifically include the following steps: The interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme in the interface coordination scheme are converted into control commands corresponding to the industrial equipment connected to each USB interface, RS232 interface, RS485 interface, CAN bus interface, and Ethernet interface. The OpenHarmony distributed soft bus is used to select the optimal transmission path based on the control commands, and the control commands are then sent to the corresponding industrial equipment based on the optimal transmission path. After the monitoring control command is issued, the system acquires the execution feedback data of each industrial device and integrates the execution feedback data to generate unified management and control data.

[0044] Specifically, the industrial runtime service maps control semantics item by item based on interface resource allocation strategies, protocol access timing arrangements, and data flow redirection schemes. It converts parameters such as resource quotas, priority weights, time slice start and end times, channel switching, and data migration targets into low-level control instruction sets for specific physical interfaces and devices. To ensure direct execution of instructions, the runtime service generates differentiated instruction templates according to interface type. The template for four USB 3.0 interfaces includes port number, bandwidth quota, burst transmission threshold, and endpoint rate limiting parameters. The template for four RS232 interfaces and one RS485 interface includes baud rate, data bits, stop bits, parity check, and time slot table. The template for one CAN bus interface loads the arbitration ID priority, transmit mailbox allocation, and retransmission window. The template for two Gigabit Ethernet interfaces configures VLAN tagging, priority queue mapping, and rate shaping strategies. Each control intent is bound to the target device's OpenHarmony device node identifier, protocol type, execution time limit, and acknowledgment level, synthesized into a structured control command, and written into the command issuance cache along with the current interface mapping relationship and authorization credentials, forming a standardized message that can be directly forwarded by the distributed soft bus. The distributed soft bus's path optimization module performs candidate route evaluation for each control command based on real-time topology, node hop count, link latency, communication success rate, and interface load rate, and selects the optimal transmission path after comprehensively balancing real-time performance and reliability. If it is a cross-node collaboration, after the local master node completes the command signing and timestamp alignment, the command is issued to the target device node through the soft bus publish-subscribe or point-to-point channel. If it is a local direct connection, it is sent directly through the corresponding physical interface driver. When necessary, an expedited queue and redundant mirroring channel are opened for high-priority commands such as OPC-UA to reduce latency and packet loss risks. During command issuance, the soft bus side sets transmission monitoring points for key hops, recording the queue entry time, queue exit time, link acknowledgment time, and device reception acknowledgment time. If path congestion or link jitter exceeding the threshold is detected, the system immediately switches to an alternative path according to the data flow redirection rules in the coordination scheme. Simultaneously, it smooths out burst traffic through token bucket or time slot rearrangement. After command issuance, the runtime service enters the feedback listening phase, enabling acknowledgment tracking and status acquisition for all target devices. It collects execution results, execution time, interface layer retransmission count, protocol layer exception codes, buffer level, power consumption, and temperature rise. The system also associates device-side event logs with soft bus link logs by message ID and timestamp. For serial and CAN devices, it additionally parses error flags and arbitration loss records in the acknowledgment frames. For Ethernet and USB devices, it supplements throughput statistics and queue congestion indicators.The runtime service performs bidirectional aggregation based on both instruction and device dimensions. At the instruction level, it establishes an "expected-actual" execution reconciliation, indicating whether resource allocation and timing constraints are met. At the device level, it calculates communication success rate, average round-trip latency, load fluctuation, error code distribution, and health score, and writes abnormal samples into an experience pool to feed back into subsequent learning. All receipts, link monitoring records, and performance statistics are integrated into unified management data, structurally comprising four levels: instruction execution state, interface operation state, network transmission state, and alarm events. It also retains mapping relationships and timing trajectories with four USB 3.0, four RS232, one RS485, one CAN, and two Gigabit Ethernet interfaces. This unified management data is synchronously reported to the northbound platform for operational decisions and OTA orchestration, and simultaneously fed back to the industrial runtime service and deep Q network as training samples and online calibration bases, enabling continuous optimization and closed-loop adaptive scheduling strategies.

[0045] The control method for multi-interface industrial control equipment based on the OpenHarmony industrial operating system in the embodiments of the present invention has been described above. The multi-interface industrial control equipment based on the OpenHarmony industrial operating system in the embodiments of the present invention will be described below. Please refer to [link / reference]. Figure 2 One embodiment of the multi-interface industrial control equipment based on the OpenHarmony industrial operating system in this invention includes: The scanning module 201 is used to scan the interface resource list of the industrial control computer after the OpenHarmony industrial operating system is started. The device discovery module 202 is used to automatically discover industrial devices connected to each interface based on the interface resource list and obtain the device connection table. The protocol conversion module 203 is used to perform protocol conversion based on the device connection table to obtain the device communication data stream and extract feature datasets from the device communication data stream. The interface coordination module 204 is used to calculate the interface coordination scheme based on the feature dataset, issue control commands to various industrial devices and collect execution feedback to obtain unified management and control data.

[0046] Through the collaborative efforts of the aforementioned components, the OpenHarmony distributed soft bus architecture enables unified abstraction and management of various heterogeneous interfaces, overcoming the technical limitations of independent interface management in traditional industrial control systems. It establishes a unified interface mapping mechanism based on device identifiers, achieving collaborative operation and resource sharing among multiple interfaces such as USB, RS232, RS485, CAN bus, and Ethernet. By unifying the driving of multiple protocol adapters through industrial runtime services, it achieves unified management and coordination of heterogeneous industrial protocols such as OPC-UA, Modbus, CAN, and serial communication, solving the technical challenge of independent protocol operation and lack of coordination mechanisms in traditional industrial control systems. It also establishes a standardized data encapsulation system based on the OpenHarmony message format. Through the deep Q-network algorithm, it achieves intelligent identification and automated processing of multi-interface resource conflicts, overcoming the technical problem of static rule scheduling in traditional industrial control systems. It establishes a dynamic resource allocation and protocol priority adjustment mechanism based on machine learning, effectively solving the conflict problem during concurrent access of multiple protocols. Through the device discovery service of the OpenHarmony distributed soft bus, the automatic identification, dynamic registration and plug-and-play functions of industrial equipment are realized, breaking through the technical limitation of traditional industrial control systems that require manual configuration of device connections, and establishing a secure access mechanism based on device certificate verification and a distributed device collaborative management system.

[0047] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0048] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0049] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A control method for multi-interface industrial control equipment based on the OpenHarmony industrial operating system, characterized in that, include: After the OpenHarmony industrial operating system starts, scan the list of interface resources of the industrial control computer; The system automatically discovers industrial devices connected to each interface based on the interface resource list, and obtains the device connection table. Based on the device connection table, a protocol conversion is performed to obtain the device communication data stream, and a feature dataset is extracted from the device communication data stream. Based on the feature dataset calculation interface coordination scheme, control commands are issued to each industrial device and execution feedback is collected to obtain unified management and control data.

2. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 1, characterized in that, The process of scanning the industrial control computer's interface resource list after the OpenHarmony industrial operating system starts includes: After the OpenHarmony industrial operating system starts, the distributed soft bus driver module is loaded and the device management framework is initialized to obtain the soft bus node identifier and driver handle. Based on the soft bus node identifier and the driver handle, scan the USB interface, RS232 interface, RS485 interface, CAN bus interface and Ethernet interface on the industrial control computer to obtain the interface hardware information; Based on the interface hardware information, a unique OpenHarmony device identifier is assigned to each interface, and an interface abstraction layer data structure is established to obtain the interface mapping relationship. Based on the interface mapping relationship, the interface status monitoring mechanism is activated and the interface resource list is collected.

3. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 1, characterized in that, The automatic discovery of industrial devices connected to each interface based on the interface resource list, resulting in a device connection table, includes: Based on the aforementioned interface resource list, start the OpenHarmony distributed soft bus device discovery service and create a local soft bus node; The local soft bus node broadcasts device discovery request messages to the industrial equipment connected to each interface and receives device response information. Based on the device response information, verify the OpenHarmony device certificate of each industrial device and identify the device identity information; Based on the device identity information, each verified industrial device is assigned an OpenHarmony device node identifier and the device connection table is recorded.

4. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 1, characterized in that, The process of performing protocol conversion based on the device connection table to obtain a device communication data stream, and extracting a feature dataset from the device communication data stream, includes: The industrial runtime service is started based on the device connection table, and the corresponding OPC-UA protocol adapter, Modbus protocol adapter, CAN protocol adapter and serial communication protocol adapter are instantiated according to the protocol type of each industrial device. Establish a bidirectional data transmission channel between each protocol adapter and the OpenHarmony distributed soft bus; Based on the bidirectional data transmission channel, the OPC-UA data packets, Modbus data packets, CAN data packets, and serial communication data packets of each industrial device are converted into OpenHarmony message format to obtain standardized message data packets; A protocol scheduling queue is established based on the standardized message data packets, and data stream scheduling is performed based on the protocol scheduling queue to obtain the device communication data stream.

5. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 4, characterized in that, The step of establishing a protocol scheduling queue based on the standardized message data packets and performing data stream scheduling based on the protocol scheduling queue to obtain the device communication data stream includes: A protocol scheduling queue is established based on the protocol type identifier in the standardized message data packet; The protocol type identifier of each standardized message data packet is parsed according to the protocol scheduling queue, and the OPC-UA message data packet is added to the first priority queue, the Modbus message data packet is added to the second priority queue, the CAN message data packet is added to the third priority queue, and the serial communication message data packet is added to the fourth priority queue based on the protocol type identifier, thus obtaining the message queue combination; Priority scheduling is performed based on the aforementioned message queue combination to obtain a message data packet sequence; The device communication data stream is generated by merging the message data packet sequence according to timestamp order. Extract feature datasets from the device communication data stream.

6. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 5, characterized in that, The step of extracting the feature dataset from the device communication data stream includes: The source device node identifier, target device node identifier, protocol type identifier, and timestamp information of each OpenHarmony message format in the device communication data stream are parsed to obtain the message communication parameters; Based on the aforementioned message communication parameters, monitor the data transmission volume of each interface and calculate the real-time load rate and transmission delay of the USB interface, RS232 interface, RS485 interface, CAN bus interface, and Ethernet interface. Count the number of concurrent accesses to the same interface by OPC-UA protocol, Modbus protocol, CAN protocol and serial communication protocol within the same time window; Collect the node hop count, network latency, and communication success rate of the OpenHarmony distributed soft bus, and combine the real-time load rate, transmission latency, concurrency count, node hop count, network latency, and communication success rate into a feature dataset.

7. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 1, characterized in that, The coordination scheme based on the feature dataset calculation interface issues control commands to various industrial devices and collects execution feedback to obtain unified management and control data, including: Conflict detection is performed on the feature dataset to obtain conflict detection results; Based on the conflict detection results, the first deep Q-network algorithm is started. The main network in the first deep Q-network algorithm predicts the action value of the current state, and the target network calculates the target Q value to obtain the value assessment result. Based on the value assessment results, the second deep Q-network algorithm of the OpenHarmony distributed soft bus is executed in parallel to calculate the value decomposition results; Based on the value decomposition results, an interface coordination scheme is calculated, which includes the optimal interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme. According to the interface coordination scheme, control commands are issued to each industrial device and execution feedback is collected to obtain unified management and control data.

8. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 7, characterized in that, The second deep Q-network algorithm of the OpenHarmony distributed soft bus is executed in parallel based on the value assessment results to calculate the value decomposition results, including: Receive the value assessment results, and construct the state value function and advantage function of the second deep Q-network algorithm based on the value assessment results; The first calculation task of the state value function is assigned to the master node for processing using the OpenHarmony distributed soft bus, and the second calculation task of the advantage function is assigned to the corresponding device nodes for parallel computation. The target value score of the current multi-interface conflict state is calculated based on the master control node and the state value function, and the advantage value of each interface coordination action relative to the average action is calculated simultaneously based on the device node and the advantage function. The value decomposition results of each interface coordination action are generated based on the target value score and the advantage value.

9. The multi-interface industrial control equipment control method based on the OpenHarmony industrial operating system according to claim 7, characterized in that, The process of issuing control commands to various industrial devices according to the interface coordination scheme and collecting execution feedback to obtain unified management and control data includes: The interface resource allocation strategy, protocol access timing arrangement, and data flow redirection scheme in the interface coordination scheme are converted into control commands corresponding to the industrial equipment connected to each USB interface, RS232 interface, RS485 interface, CAN bus interface, and Ethernet interface. The OpenHarmony distributed soft bus is used to select the optimal transmission path according to the control command, and the control command is sent to the corresponding industrial equipment based on the optimal transmission path. After the control command is issued, the system acquires the execution feedback data of each industrial device and integrates the execution feedback data to generate unified management and control data.

10. A multi-interface industrial control device based on the OpenHarmony industrial operating system, characterized in that, The method for controlling multi-interface industrial control equipment based on the OpenHarmony industrial operating system as described in any one of claims 1-9 includes: The scanning module is used to scan the list of interface resources of the industrial control computer after the OpenHarmony industrial operating system starts. The device discovery module is used to automatically discover industrial devices connected to each interface based on the interface resource list, and obtain a device connection table; The protocol conversion module is used to perform protocol conversion based on the device connection table to obtain the device communication data stream, and extract feature datasets from the device communication data stream. The interface coordination module is used to calculate the interface coordination scheme based on the feature dataset, issue control commands to various industrial devices and collect execution feedback to obtain unified management and control data.

Images