An industrial equipment remote synchronous control method and system based on OpenHarmony

Abstract

The application relates to the technical field of remote control, in particular to an industrial equipment remote synchronous control method and system based on OpenHarmony, the method comprises the following steps: obtaining equipment information for remote control, and performing initialization operation on a communication environment; performing path selection on the communication environment based on link quality evaluation; constructing a structured message protocol based on application semantics according to the selected communication path; introducing an incremental state synchronization mechanism on the basis of the structured message protocol; constructing an industrial-grade command scheduling engine based on the incremental state synchronization mechanism; establishing an adaptive file transmission protocol; and completing remote synchronous control through a network jitter sensing and intelligent retransmission mechanism. Through the industrial-grade command scheduling engine and the intelligent retransmission mechanism, the application realizes ordered execution of remote commands and reliable completion of file transmission, supports automatic processing of operation and maintenance tasks, and improves the efficiency and reliability of industrial remote operation and maintenance.

Description

Technical Field

[0001] This invention relates to the field of remote control technology, and in particular to a method and system for remote synchronous control of industrial equipment based on OpenHarmony. Background Technology

[0002] As the global manufacturing industry undergoes a profound transformation towards intelligent manufacturing and the Industrial Internet, Manufacturing Execution Systems (MES), as the core hub connecting enterprise management and production workshops, need to interact with a large number of heterogeneous devices at the workshop level in real time and issue commands. Due to the large number, variety, and wide distribution of these devices, which may run different operating systems, their software deployment, updates, configuration, and troubleshooting face enormous challenges. The open-source HarmonyOS, with its distributed architecture, microkernel, componentization, and support for unified OS deployment on multiple devices, provides a new solution for building the next-generation industrial control and MES support platform.

[0003] Currently, to address the control issues of multiple devices, some enterprises are attempting to use traditional remote desktop control technology as an auxiliary means to solve some operational and maintenance problems. However, traditional remote desktop technology achieves remote control by transmitting screen pixel streams. In the complex network environment of factories, network latency and jitter can directly cause remote operation to lag and delay. Since MES systems need to respond quickly to production anomalies, if operational feedback is not timely, it may lead to increased production deviations or extended downtime. In addition, as the application of open-source HarmonyOS in industrial control and edge computing devices increases, MES systems will include more open-source HarmonyOS nodes. However, mature, stable, and industrially optimized remote desktop servers are extremely scarce in the open-source HarmonyOS ecosystem. Even if relevant servers exist, they are difficult to effectively integrate with the native features of open-source HarmonyOS, such as distributed soft bus, distributed task scheduling, and distributed data management. At present, there is a need for a remote synchronous control method and system for industrial equipment based on OpenHarmony. Summary of the Invention

[0004] To address the issues of operational delays and poor compatibility with OpenHarmony devices in traditional remote control methods, this invention provides a remote synchronous control method and system for industrial equipment based on OpenHarmony.

[0005] In a first aspect, the present invention provides a remote synchronous control method for industrial equipment based on OpenHarmony, which adopts the following technical solution:

[0006] A remote synchronous control method for industrial equipment based on OpenHarmony includes:

[0007] Acquire device information for remote control and initialize the communication environment, including achieving full-domain device awareness through a distributed discovery mechanism and building a cross-platform communication infrastructure.

[0008] Path selection for communication environments based on link quality assessment includes real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer.

[0009] Construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and serializing the defined messages.

[0010] An incremental state synchronization mechanism is introduced on the basis of the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm;

[0011] An industrial-grade command scheduling engine is built based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies.

[0012] An adaptive file transfer protocol is established, and remote synchronization control is achieved through network jitter perception and intelligent retransmission mechanisms.

[0013] Furthermore, the initialization operation of the communication environment includes installing a Flutter-based collaborative application within the system performing the operation, and integrating a distributed communication abstraction layer into the collaborative application. The distributed communication abstraction layer consists of a unified interface layer and a platform adaptation layer. The unified interface layer encapsulates the common parameters required for initialization, and the platform adaptation layer loads the corresponding communication plugin and completes the initialization of the core components according to the current operating system type. After the communication components are loaded, the encrypted channel is initialized using the device's pre-set certificate.

[0014] Furthermore, the path selection based on link quality assessment for the communication environment includes collecting round-trip latency, available bandwidth, and packet loss rate for each remote device through a distributed communication abstraction layer. For round-trip latency data, a 128-byte lightweight probe packet is used as the measurement carrier, and a sliding window filter is introduced to weighted smooth the round-trip latency data. For available bandwidth, the number of bytes successfully transmitted on the first transmission is calculated by separating valid data and retransmitted data, and a weighted average of the byte count is performed using time decay weights to obtain the available bandwidth. Finally, the packet loss rate is calculated by monitoring the continuity of data packet sequence numbers. The formula for available bandwidth is:

[0015] ;

[0016] in, This represents the calculated effective bandwidth value at the i-th second within the sliding window. This is represented as a time decay weighting coefficient, used to assign higher weight to recent data. It is represented as the sum of the weighting coefficients.

[0017] Furthermore, the path selection for the communication environment based on link quality assessment also includes using a multi-dimensional assessment method to calculate the link quality index based on round-trip time, available bandwidth, and packet loss rate. When the link quality index values ​​of all paths are higher than the set threshold, the path with the highest link quality index is selected as the main communication channel. When the link quality index values ​​of all paths are lower than the set threshold, a multi-path redundant transmission mode is set, the original data is divided into data blocks and XOR check blocks according to the proportion, and multiple paths are selected to send the reassembled original data according to the link quality index. The data receiving end reassembles the data based on a RAID-like check mechanism.

[0018] Furthermore, the construction of a structured message protocol based on application semantics according to the selected communication path includes defining a layered format for the message structure, dividing the message into a base layer, a semantic layer, and an extension layer, and introducing a message lifetime field in the base layer. The semantic layer includes instruction type, three-level target identifier, and structured data payload with semantic factors. Finally, the message is serialized based on the semantic factors, and a semantic mapping table of common instructions in industrial scenarios is constructed. The serialization formula is expressed as:

[0019] ;

[0020] in, Represented as the i-th structured data field in the message semantic layer. This is represented as the final binary data after serialization. It is represented as the semantic factor of the i-th field.

[0021] Furthermore, the incremental state synchronization mechanism introduced on the basis of the structured message protocol includes abstracting the state of the device that needs to be synchronized across platforms into a three-level synchronizeable state tree composed of a root node, a service node, and an attribute node. The root node represents the global state of the device, the service node represents the functional module, and the attribute node is the smallest state unit. Each node is assigned a unique identifier, and the attribute node is marked with synchronization priority, data type, and update frequency threshold. When the device first connects, a complete snapshot of the state tree is generated and sent to the associated device through the structured message protocol.

[0022] Furthermore, the incremental state synchronization mechanism introduced on the basis of the structured message protocol also includes difference detection based on the ST-Diff algorithm, generating structure hash values ​​for state tree nodes, comparing the hash values ​​of the current state tree with those of the baseline snapshot, locating and extracting the difference items, encapsulating the incremental differences, and sending them to the receiving end based on the compression method determined by the link quality index. The receiving end performs state reconstruction and conflict handling. The structure hash value is represented as:

[0023] ;

[0024] in, This is represented as a unique identifier for the node. Represented as the current value of the node. It is represented as the sum of the hash values ​​of all child nodes.

[0025] Furthermore, the dynamic priority calculation and multi-level queue scheduling strategy includes defining remote command types and metadata, constructing a dynamic priority calculation method based on the command urgency of the command type, calculating the command priority, dividing the command into four-level queues based on the priority, using the scheduling engine to retrieve the command from the corresponding queue and call the local execution interface, and updating the associated status node after execution.

[0026] Furthermore, the remote synchronization control achieved through network jitter perception and intelligent retransmission mechanism includes obtaining round-trip delay data from the sending end based on a sliding window, calculating a jitter factor to quantify network stability based on the round-trip delay data, calculating the block size based on the jitter factor, splitting the file according to the block size and generating a unique index, associating state tree nodes to mark the transmission status, feeding back the block reception status at the receiving end through a block status bitmap, generating a retransmission list at the sending end based on the bitmap, and calculating the retransmission interval using a binary exponential backoff algorithm.

[0027] Secondly, an industrial equipment remote synchronous control system based on OpenHarmony includes:

[0028] The data acquisition module is configured to: acquire device information for remote control and perform initialization operations on the communication environment, including achieving full-domain perception of the device through a distributed discovery mechanism and building a cross-platform communication infrastructure environment;

[0029] The evaluation module is configured to: perform path selection for the communication environment based on link quality assessment, including real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer;

[0030] The structured module is configured to: construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and performing serialization processing on the defined messages;

[0031] The synchronization module is configured to introduce an incremental state synchronization mechanism based on the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm.

[0032] The scheduling module is configured to build an industrial-grade command scheduling engine based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies.

[0033] The transformation module is configured to: establish an adaptive file transfer protocol and complete remote synchronization control through network jitter perception and intelligent retransmission mechanism.

[0034] In summary, the present invention has the following beneficial technical effects:

[0035] 1. This invention achieves low latency and high stability in remote communication of industrial equipment by constructing a distributed communication abstraction layer, dynamically identifying the device operating system type and selecting the optimal communication path, and combining the link quality index to evaluate the path performance in real time. This solves the problems of high latency and poor stability of traditional remote desktop technology in complex industrial networks.

[0036] 2. This invention defines a structured message protocol based on application semantics, which abstracts device status and operation instructions into structured data rather than pixel streams. Combined with an incremental status synchronization mechanism, it realizes deep collaboration between cross-platform devices based on business logic, avoiding the limitations of traditional solutions that can only perform screen mirroring and cannot understand application logic.

[0037] 3. This invention significantly reduces network bandwidth usage for remote communication by using semantic factor filtering and selecting compression algorithms based on link quality, enabling concurrent remote operation and maintenance of large-scale device clusters and solving the problem of traditional solutions being unable to support multi-device collaboration due to high bandwidth consumption.

[0038] 4. This invention achieves the orderly execution of remote commands and the reliable completion of file transfers through an industrial-grade command scheduling engine and intelligent retransmission mechanism, supports the automated processing of operation and maintenance tasks, improves the efficiency and reliability of industrial remote operation and maintenance, and reduces manual operation costs and production risks. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the overall process of an industrial equipment remote synchronous control method based on OpenHarmony according to an embodiment of the present invention. Detailed Implementation

[0040] The present invention will be further described in detail below with reference to the accompanying drawings.

[0041] Example 1

[0042] Reference Figure 1 This embodiment of a remote synchronous control method for industrial equipment based on OpenHarmony includes:

[0043] Acquire device information for remote control and initialize the communication environment, including achieving full-domain device awareness through a distributed discovery mechanism and building a cross-platform communication infrastructure.

[0044] Path selection for communication environments based on link quality assessment includes real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer.

[0045] Construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and serializing the defined messages.

[0046] An incremental state synchronization mechanism is introduced on the basis of the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm;

[0047] An industrial-grade command scheduling engine is built based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies.

[0048] An adaptive file transfer protocol is established, and remote synchronization control is achieved through network jitter perception and intelligent retransmission mechanisms.

[0049] Specifically, a remote synchronous control method for industrial equipment based on OpenHarmony includes the following steps:

[0050] like Figure 1 As shown, S1: Obtain device information for remote control and initialize the communication environment, including achieving full-domain device awareness through a distributed discovery mechanism and building a cross-platform communication infrastructure.

[0051] First, deploy a cross-platform collaborative application. Install Flutter-based collaborative application instances on all supported operating system platforms, including Windows, macOS, Linux, HarmonyOS, and OpenHarmonyOS. Leveraging Flutter's cross-platform capabilities, ensure that the application's core logic (such as device discovery rules and message processing flow) and UI (such as device list layout and status display style) remain consistent across different devices. Next, integrate the Distributed Communication Abstraction Layer (DCAL) and embed it within the Flutter application. DCAL is integrated as an independent module into the Flutter-based collaborative application instance. Its architecture consists of two layers: a unified interface layer and a platform adaptation layer. The unified interface layer provides upper-level access to the device discovery and communication abstraction layer. Standardized communication methods such as backup discovery, connection management, and message sending / receiving are triggered by calling the `initialize()` method of the DCAL unified interface layer. This method encapsulates the common parameters required for initialization (such as communication timeout and encryption level), shielding platform differences and allowing application logic to ignore underlying differences. The platform adaptation layer dynamically calls the optimal communication implementation for different operating systems. The platform adaptation layer includes a platform adaptation plugin, a dynamic routing engine, and a multi-path transmission manager. The core principle of DCAL lies in decoupling and dynamic optimization. When an upper-layer application initiates a communication request, for example, sending a "start batch" command from the Windows MES system to the OpenHarmony host computer, DCAL will execute the following series of automated operations:

[0052] 1. DCAL first identifies the operating system type and network status of the current device and the target device.

[0053] 2. Enumerate all available communication paths. For example, if both the source and the target are OpenHarmony devices, available paths may include distributed soft bus, TCP-based socket connection, WebRTC data channel, etc. If the source is Windows and the target is OpenHarmony, the available paths are mainly TCP and WebRTC.

[0054] 3. DCA does not use a fixed communication method. Instead, it uses its built-in dynamic routing engine to evaluate the quality of all available paths in real time and select the optimal path for communication.

[0055] After deployment, device information is collected. Collaborative applications on OpenHarmony devices call the device discovery interface of the distributed soft bus to broadcast information including the device's unique identifier, operating system version, supported industrial protocols, and a list of application services. Non-OpenHarmony devices broadcast device information via the mDNS protocol, including device name, IP address, supported communication protocols, and port number. The local device receives and parses all broadcast information to generate a device profile containing device type, communication capabilities, and network location. Then, the communication environment is initialized. Collaborative applications initialize the underlying communication components through DCAL, encrypt the communication channel using the TLS 1.3 protocol, and implement two-way authentication through device certificates to ensure communication security.

[0056] After collecting device information, the device list is maintained, and a device status heartbeat mechanism is established. OpenHarmony devices perceive their online status in real time through device status change callbacks via the soft bus, while non-OpenHarmony devices monitor their status via ICMPping. The device list is updated every 30 seconds, and devices offline for more than 120 seconds are removed. Finally, the initial availability score of the devices is calculated using the formula...

[0057]

[0058] in, This represents the initial availability score for the devices, with a score for each device. This is expressed as the percentage of time a device is online in the past hour. This score, represented as a normalized value of the average response time, serves as a reference for subsequent path selection, thereby improving the rationality of communication path selection.

[0059] S2. Path selection for the communication environment based on link quality assessment, including real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer;

[0060] Based on the device list and initialized communication environment obtained in step one, link parameters are collected in real time and the link quality index is calculated through the distributed communication abstraction layer. Link parameter collection is continuously executed through DCAL. For each remote device in the device list, the following key indicators are obtained in real time: round-trip time (RTT), recorded by sending lightweight probe packets. OpenHarmony devices directly obtain hardware-level measurements using the getHardwareRTT() interface of the distributed soft bus, while non-OpenHarmony devices calculate the RTT using the timestamp option of the TCP protocol. All devices store the most recent 20 measurements to form a sliding window to smooth out instantaneous fluctuations, and the result is calculated using the formula:

[0061] ;

[0062] in, This represents the raw RTT measurement value at the i-th time in the sliding window, where RTT stands for Round Trip Delay. i=1 corresponds to the earliest measurement data, and i=20 corresponds to the latest measurement data. This is represented as the time decay weighting coefficient. It is represented as the sum of the weighting coefficients.

[0063] Available bandwidth (BW) is estimated by statistically analyzing the actual data transmission rate over the past 10 seconds. OpenHarmony devices can directly obtain the real-time bandwidth of the soft bus link by calling the SoftBus.getLinkBandwidth() interface. Non-OpenHarmony devices derive it through an improved TCP throughput algorithm. The traditional TCP throughput algorithm directly counts the total number of bytes transmitted per unit time without distinguishing between original data and retransmitted data, leading to an inflated bandwidth estimate in high-packet-loss industrial scenarios. The improved algorithm in this application separates valid data from retransmitted data, only counting the number of bytes successfully transmitted for the first time. The calculation formula is as follows:

[0064] ;

[0065] in, This represents the total number of bytes transmitted in second t. This represents the number of bytes retransmitted within second t, with the denominator "10s" representing the duration of the statistical window. This balances real-time performance with stability. Furthermore, in industrial networks, equipment startup / shutdown and electromagnetic interference can easily cause sudden bandwidth fluctuations. The improved algorithm eliminates instantaneous fluctuations through a sliding window weighted average, maintaining the effective bandwidth calculation results for the most recent 10 seconds. Using time decay weighting, the available bandwidth formula is:

[0066] ;

[0067] in, This represents the calculated effective bandwidth value at the i-th second within the sliding window. This represents the time decay weighting coefficient, used to assign higher weight to recent data. The denominator 55 is the sum of the weighting coefficients. This is used to normalize the weighted summation result, ensuring the final output is accurate. It conforms to the actual physical dimensions of bandwidth.

[0068] Packet loss rate (PLR) is calculated by counting the proportion of unacknowledged packets out of 100 consecutive packets. OpenHarmony devices use the onPacketLost() callback of the soft bus to achieve accurate counting, while other devices detect packet loss by monitoring the continuity of packet sequence numbers. The calculation formula is as follows: ;

[0069] Subsequently, using a multi-dimensional evaluation method, the link quality index is calculated based on round-trip latency, available bandwidth, and packet loss rate. The link quality index is calculated using a weighted summation formula:

[0070] ;

[0071] in, This is represented as the link quality index from device i to device j. This is expressed as the round-trip time from device i to device j. This represents the currently available bandwidth from device i to device j. This represents the theoretical maximum bandwidth of the link. This is expressed as the packet loss rate from device i to device j. , and Represented as configurable weight coefficients, and satisfying The specific values ​​are dynamically adjusted based on the business scenario, and the scenario is controlled in real time. For example, when PLC parameters are issued, low latency is prioritized. In scenarios involving large file transfers, such as firmware upgrades, prioritize bandwidth allocation and configure [the appropriate settings]. In unstable network scenarios, prioritize reliability and configure [the system / configuration]. The path selection strategy follows the principle of "optimal primary path + redundancy backup". DCAL periodically (by default every 1 second) calculates the LQI value of all available paths, selects the path with the highest LQI as the primary communication channel, and marks it as ACTIVE. If the LQI value of all paths is below 0.6 (default threshold), a multi-path redundancy transmission mode is triggered, dividing the original data into blocks in a 4:1 ratio. For example, 1024 bytes of data are divided into four 256-byte data blocks and one parity block. These blocks are sent in parallel through the top three paths with the highest LQI values. The receiving end uses a RAID-like parity mechanism (using XOR operation). Even if one data block is lost on a certain path, the complete data can still be reconstructed from the other four blocks. The parity block is generated through an XOR operation. The receiving end can be accessed via ,in, , , and This represents the four data blocks resulting from the original data being divided in a 4:1 ratio. This is represented as an XOR operation. This is represented as a check block generated through an XOR operation, which is a redundant backup of the four data blocks.

[0072] In addition, DCAL has a built-in path switching mechanism. When the LQI value of the primary path is lower than the threshold for three consecutive times, or the burst packet loss rate exceeds 20%, it immediately switches to the path with the second highest LQI and notifies the application layer through the pathSwitch event to ensure communication continuity. For communication between OpenHarmony devices, the distributed soft bus path is detected first, and its LQI calculation is additionally boosted by 0.1 system adaptation bonus (because the soft bus is deeply integrated with the system kernel) to make full use of its distributed characteristics.

[0073] S3. Construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and serializing the defined messages.

[0074] Once the communication path is determined, a unified cross-platform semantic communication specification is defined to achieve understanding-based interaction between devices based on business logic. First, a layered format for the message structure is defined, using Protocol Buffers as the default format. Messages are divided into a basic layer, a semantic layer, and an extension layer. The basic layer includes the message version number, timestamp, message ID, and checksum. An innovative Time-to-Live (TTL) field is introduced, calculated using the following formula:

[0075] ;

[0076] in, Indicates basic survival time. The message priority is represented by a 1-5 level system, with level 1 being the highest and level 5 the lowest. The priority is specified based on the business scenario during message generation. The calculated Time-to-Live (TTL) value is stored as a 32-bit unsigned integer in a fixed field of the message base layer. This TTL, along with metadata such as the message version number and timestamp, forms the message header, ensuring that the receiving end can obtain the TTL information before parsing the message content. Upon receiving a message, the receiving end immediately calculates the difference between the message reception timestamp and the message sending timestamp. If this difference exceeds the TTL value, the message is considered timed out and discarded without entering the business logic processing flow. For messages that have not timed out, the receiving end uses the TTL to deduce the original priority. The message is then included in the priority sorting criteria of the message scheduling queue, with high-priority messages (corresponding to short TTLs) being processed first.

[0077] The semantic layer, as the core layer, includes instruction types, three-level target identifiers, and structured data payloads with semantic factors. The three-level target identifiers use a string concatenation format of {Device ID}-{Module ID}-{Component ID}. The DCAL identifier parsing module at the receiving end splits the target identifier string using "-" as a separator. First, it matches the Device ID; if a wildcard exists, it scans the device list for matching. Next, it locates the Module ID and Component ID; if no match is found, an error callback is triggered. Additionally, the semantic factor ranges from 0 to 1, used to measure the impact of each field in the data payload on business logic. The extension layer includes optional fields such as priority and timeout to adapt to different real-time scenarios.

[0078] Iterate through all fields in the message data payload, extract the semantic factor corresponding to each field, and retain only fields with a semantic factor greater than 0.3 according to preset rules. Filter out redundant fields with a semantic factor less than 0.3, and then serialize the filtered fields according to the formula:

[0079] ;

[0080] in, Represented as the i-th structured data field in the message semantic layer. This is represented as the final binary data after serialization. Represented as the semantic factor of the i-th field. This means that the field content is associated with semantic factors, rather than being a simple numerical multiplication. In other words, the priority weight of the fields in the serialization result is assigned according to the semantic factors. This means that all fields that meet the criteria are aggregated into a unified serialized data structure according to their weights.

[0081] Finally, a cross-platform semantic mapping and adaptation mechanism is established. A semantic mapping table containing common commands in industrial scenarios is constructed and stored in the platform adaptation layer of DCAL. For example, the "Start Batch Production" command on Windows is mapped to the "Start Production Task" command on OpenHarmony. These mapping relationships are centrally stored in the platform adaptation layer of the Distributed Communication Abstraction Layer (DCAL). When a new device is added, the new device exchanges its semantic mapping table version information with the existing devices in the system. If the versions of the semantic mapping tables of both parties are consistent, it means that there is no difference in their understanding of commands and terms, and they can communicate directly. If there are differences in versions, conversion is performed according to the conversion rules between different version mapping tables. Specifically, the conversion rules are as follows: a version difference matrix is ​​stored in the DCAL platform adaptation layer to record the conversion rules between any two versions. Based on the one-to-one mapping from old fields to new fields, commands or terms that do not conform to the syntax rules of the target platform are identified and converted according to the syntax specifications of the target platform. For example, the function call syntax of a certain platform is converted into a syntax form that can be recognized by another platform, ensuring accurate correspondence between commands and terms between new devices and existing devices. At the same time, a semantic compatibility scoring formula is introduced:

[0082] ;

[0083] when When this occurs, it indicates that the two devices have high semantic compatibility and can communicate directly without additional conversion processing. If the semantics of the two are significantly different, field conversion is required to ensure cross-platform semantic consistency.

[0084] S4. An incremental state synchronization mechanism is introduced on the basis of the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm.

[0085] First, the states that need to be synchronized across platforms, such as MES production parameters, device operating status, and UI component properties, are abstracted into a synchronizeable state tree. This state tree adopts a three-level fixed-hierarchical architecture: root node, business nodes, and attribute nodes. The root node, uniquely identified as Root, represents the global state set of a single device and is used only to manage subordinate nodes without carrying specific data. Business nodes belong to the root node, and each node corresponds to a core functional module of the device, such as Production corresponding to the production control module and Diagnosis corresponding to the device diagnostic module. These nodes must be registered during device initialization and cannot be deleted after registration to avoid cross-device location failures. Attribute nodes belong to business nodes and are the smallest synchronizeable state unit, corresponding to specific parameters or states. The unique ID of each node is generated by concatenating hierarchical separators, in the format shown below. .

[0086] Each attribute node is labeled with core metadata to standardize the synchronization logic. The synchronization priority is a floating-point number between 0 and 1, which is divided according to the degree of impact on the production logic. The data types adopt cross-platform compatible definitions: integer type (Int32 / Int64) is used for counting or quantizing parameters, string type is used for identifying or describing information, boolean type is used for binary states, and floating-point type is used for high-precision measurement values. The data types are fixed when the node is created and cannot be dynamically modified to avoid parsing errors at the receiving end.

[0087] Initial state snapshot generation and transmission: Snapshot generation is triggered by several conditions, including automatic generation when a device first connects to the system, regeneration upon first network connection after a device restart, and passive generation when the receiving end sends a "snapshot request" command. The snapshot contains the current values ​​and metadata (priority, data type, threshold) of all nodes in the state tree. The compression and transmission process uses the semantic factor filtering mechanism defined in step three, retaining only fields with a semantic factor greater than 0.3 and filtering out redundant fields with a factor less than 0.3. The snapshot is encapsulated using a structured message protocol. The base layer carries the message ID and timestamp, while the semantic layer carries the snapshot data payload. OpenHarmony devices transmit via a distributed soft bus, while non-OpenHarmony devices transmit via TCP, ensuring rapid baseline state synchronization upon initial connection. After receiving the snapshot, the receiving end first checks if the node ID format conforms to the "three-level hierarchy" rule. Illegal IDs, such as those lacking a business node hierarchy, are rejected. Then, the snapshot is compared with locally predefined metadata. If the types do not match, a "metadata incompatibility" error is returned. After successful verification, the snapshot is stored as the local baseline state, serving as the comparison benchmark for subsequent incremental synchronization.

[0088] Next, state changes are detected using a semantic tree difference algorithm. The Flutter state management mechanism listens for changes in state tree nodes; when an attribute node value changes, the node is marked as a dirty node, triggering a difference detection. First, a structural hash value is generated for each state tree node, calculated using the following formula:

[0089] ;

[0090] in, This is represented as a unique identifier for the node. Represented as the current value of the node. It represents the sum of the hash values ​​of all child nodes. A change in the root node's hash value indicates a global state change, while a change in the child node's hash value only triggers a local detection.

[0091] Compare the hash values ​​of the current state tree with those of the baseline snapshot. If the node hash values ​​are consistent, it is determined that there is no change, and subsequent detection is skipped. If the node hash values ​​are inconsistent, its child nodes are recursively detected until the specific attribute node is located. The differences, including node ID, old value, and new value, are extracted. The extracted incremental differences are semantically serialized and dynamically transmitted. Combined with the network state adaptation transmission strategy, the incremental differences are encapsulated into STATE_UPDATE type messages according to the semantic protocol in step three. The data payload format includes the target node, difference type, and semantic factor. Based on semantic factor filtering, only differences with a semantic factor greater than 0.3 are transmitted. Combining the link quality index, a compression algorithm is selected. When the link quality index is greater than 0.7, gzip compression is used for the difference data. When the link quality index is not greater than 0.7, lz4 compression is used and the data is transmitted in blocks. The block size is:

[0092] ;

[0093] in, Indicates the size of a single data block. This represents the basic unit coefficient, corresponding to 1024 bytes. This is expressed as a baseline scaling factor, representing the basic block ratio when the link quality is ideal. This is represented as the link quality sensitivity coefficient, used to adjust the responsiveness of the block size to changes in LQI. This coefficient is a positive number and has a small value; in this embodiment, it is 0.3. After receiving the incremental data, the receiving end returns an acknowledgment message containing the node ID and hash value. If the sending end does not receive the acknowledgment, it retryes based on the TTL mechanism in step three, i.e., the high-priority difference TTL is shortened to ensure fast synchronization.

[0094] Finally, the receiving end updates its local state tree based on incremental data and handles potential conflicts during cross-device synchronization. After parsing the STATE_UPDATE message, the receiving end locates the corresponding node in the local state tree based on the target node ID, overwrites the old value with the new value, and updates the node hash value to complete state synchronization. When multiple devices update the same node simultaneously (e.g., two terminals modify production parameters at the same time), arbitration is performed using timestamps and source weights. The arbitration expression is:

[0095] ;

[0096] in, This represents the final state value after conflict arbitration, i.e., the value that the receiving end ultimately updates to its local state tree. This is represented as maximizing the parameters. This is represented by the timestamp of the status update request being sent. This represents the authority weight of the device sending the update request, and is a floating-point number between 0 and 1, ensuring that the final state meets the business priority.

[0097] S5. An industrial-grade command scheduling engine is built based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies.

[0098] An industrial-grade command scheduling engine is built based on an incremental state synchronization mechanism. This includes dynamic priority calculation and multi-level queue scheduling strategies. First, remote command types and metadata are defined, categorizing remote commands into four types: emergency control, real-time operation, routine maintenance, and background tasks. Metadata is added to each command, including command ID, initiating device type, estimated execution time, and associated state nodes. The command ID follows the naming rules for synchronized state tree node IDs, and the associated state nodes are the state tree nodes affected by the command execution. Next, a dynamic priority calculation model is built based on the command metadata. First, the core... The core parameters include command urgency, source weight, waiting time, and estimated execution time. Command urgency is based on a static weight (0-10) for command type; in this embodiment, it is set to 10 for emergency control, 7 for real-time operation, 4 for routine maintenance, and 1 for background tasks. Source weight is based on the authority of the initiating device (0-1), with the MES server at 1.0, operator terminal at 0.7, and debugging device at 0.3. Waiting time is the number of seconds the command waits after entering the queue, and estimated execution time is the number of seconds required to execute the command. Command priority is calculated based on these core parameters using the priority calculation formula:

[0099] ;

[0100] in, Indicates the urgency of the command. Indicates source weight, This is represented as a waiting time adjustment item, with an adjustment coefficient of 0.5. This refers to the waiting time for an order to be queued but not yet executed. This represents the estimated execution time of a command, with a fixed penalty coefficient of 0.3. The command is divided into four priority levels: Q0 (core queue) for commands with a priority ≥ 9.0, using preemptive execution; Q1 (real-time queue) for commands with a priority 6.0 ≤ priority < 9.0, using time-slice round-robin; Q2 (regular queue) for commands with a priority 3.0 ≤ priority < 6.0, using first-in-first-out (FIFO); and Q3 (background queue) for commands with a priority < 3.0, using low-load triggering. A dynamic queue adjustment mechanism is established: if a command in Q1 fails to complete after occupying more than 3 time slices, it is downgraded to Q2; if a command in Q2 or Q3 waits for more than a preset duration, its priority is recalculated and it is upgraded. The scheduling engine retrieves the command from the corresponding queue and calls the local execution interface. After execution, the associated status node is updated.

[0101] S6. Establish an adaptive file transfer protocol and complete remote synchronization control through network jitter perception and intelligent retransmission mechanism.

[0102] The sending end (such as the MES server) sends a FILE_TRANSFER_INIT type message with file metadata to the receiving end (such as the OpenHarmony industrial control equipment) through the structured message protocol in step three. The receiving end, based on the command scheduling engine in step five, adds the request as a "routine operation and maintenance" command to the Q2 queue, and returns an ACCEPT response after receiving confirmation.

[0103] The sending end starts the network status monitoring module, and collects the round-trip time, bandwidth and packet loss rate of the current communication path in real time through the link quality assessment algorithm in step two, and initializes the sliding window. At the same time, based on the state tree model in step four, the network parameters are stored locally as nodes such as "Root.Network.RTT" and "Root.Network.PLR" as the benchmark for subsequent adjustments.

[0104] The sending end calculates the jitter factor to quantify network stability using the RTT data in the sliding window, using the following formula:

[0105] ;

[0106] The value of JF ranges from 0 to 1, where 0 represents no jitter and 1 represents extreme jitter. The block size is dynamically calculated based on JF, using the following formula:

[0107] ;

[0108] in, The base block is 256KB by default. Represented as a negative adjustment coefficient, the file is calculated as follows. The data is split into consecutive blocks, each with a unique index, and associated with the status node from step four. The sending end transmits the blocks in index order. Every five blocks received, the receiving end returns a block status bitmap (BMap) via the BLOCK_STATUS message. Specifically, the BMap (binary array) is converted into a hexadecimal string, compressed using zlib, and embedded into the BLOCK_STATUS message to reduce transmission size. A CRC checksum of the BMap is added to the base layer of the BLOCK_STATUS message. After parsing, the receiving end first checks the CRC; if it is inconsistent, it requests a retransmission bitmap to avoid generating a retransmission list based on an incorrect bitmap. Each bit in the block status bitmap corresponds to one block, with "1" indicating successful reception and "0" indicating loss / check failure. The sending end generates a retransmission list based on the BMap.

[0109] For each block in the retransmission list, the sender calculates the dynamic retransmission interval using the following formula:

[0110] ;

[0111] in, The base interval is given by m, where m is the number of consecutive retransmission failures. This means generating a random number between 0 and 1. After the receiving end collects all the blocks, it reassembles them into a complete file according to the index, calculates the overall MD5 hash value, and compares it with the metadata before transmission to complete the entire remote command control.

[0112] Example 2

[0113] The difference between this embodiment and Embodiment 1 is that this embodiment provides a remote synchronous control system for industrial equipment based on OpenHarmony, including:

[0114] The data acquisition module is configured to: acquire device information for remote control and perform initialization operations on the communication environment, including achieving full-domain perception of the device through a distributed discovery mechanism and building a cross-platform communication infrastructure environment;

[0115] The evaluation module is configured to: perform path selection for the communication environment based on link quality assessment, including real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer;

[0116] The structured module is configured to: construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and performing serialization processing on the defined messages;

[0117] The synchronization module is configured to introduce an incremental state synchronization mechanism based on the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm.

[0118] The scheduling module is configured to build an industrial-grade command scheduling engine based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies.

[0119] The transformation module is configured to: establish an adaptive file transfer protocol and complete remote synchronization control through network jitter perception and intelligent retransmission mechanism.

[0120] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for remote synchronous control of industrial equipment based on OpenHarmony, characterized in that, include: Acquire device information for remote control and initialize the communication environment, including achieving full-domain device awareness through a distributed discovery mechanism and building a cross-platform communication infrastructure. Path selection for communication environments based on link quality assessment includes real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer. Construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and serializing the defined messages. The step of constructing a structured message protocol based on application semantics according to the selected communication path includes defining a layered format for the message structure, dividing the message into a base layer, a semantic layer, and an extension layer, and introducing a message lifetime field in the base layer. The semantic layer includes instruction type, three-level target identifier, and structured data payload with semantic factors. Finally, the message is serialized based on the semantic factors, and a semantic mapping table of common instructions in industrial scenarios is constructed. The serialization formula is expressed as: ， in, Represented as the i-th structured data field in the message semantic layer. This is represented as the final binary data after serialization. Represented as the semantic factor of the i-th field; An incremental state synchronization mechanism is introduced on the basis of the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm; An industrial-grade command scheduling engine is built based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies. An adaptive file transfer protocol is established, and remote synchronization control is achieved through network jitter perception and intelligent retransmission mechanisms.

2. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 1, characterized in that, The initialization operation of the communication environment includes installing a Flutter-based collaborative application in the system performing the operation, and integrating a distributed communication abstraction layer in the collaborative application. The distributed communication abstraction layer consists of a unified interface layer and a platform adaptation layer. The unified interface layer encapsulates the common parameters required for initialization, and the platform adaptation layer loads the corresponding communication plugin and completes the initialization of the core components according to the current operating system type. After the communication components are loaded, the encrypted channel is initialized through the device's pre-set certificate.

3. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 1, characterized in that, The path selection based on link quality assessment for the communication environment includes collecting round-trip latency, available bandwidth, and packet loss rate for each remote device through a distributed communication abstraction layer. For round-trip latency data, a 128-byte lightweight probe packet is used as the measurement carrier, and a sliding window filter is introduced to weighted smooth the round-trip latency data. For available bandwidth, the number of bytes successfully transmitted on the first transmission is calculated by separating valid data and retransmitted data, and a weighted average of the byte count is performed using time decay weights to obtain the available bandwidth. Finally, the packet loss rate is calculated by monitoring the continuity of data packet sequence numbers. The formula for available bandwidth is: ， in, This represents the calculated effective bandwidth value at the i-th second within the sliding window. This is represented as a time decay weighting coefficient, used to assign higher weight to recent data. It is represented as the sum of the weighting coefficients.

4. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 3, characterized in that, The path selection for the communication environment based on link quality assessment also includes using a multi-dimensional assessment method to calculate the link quality index based on round-trip delay, available bandwidth, and packet loss rate. When the link quality index values ​​of all paths are higher than the set threshold, the path with the highest link quality index is selected as the main communication channel. When the link quality index values ​​of all paths are lower than the set threshold, a multi-path redundant transmission mode is set, the original data is divided into data blocks and XOR check blocks according to the proportion, and multiple paths are selected to send the reassembled original data according to the link quality index. The data receiving end reassembles the data based on a RAID-like check mechanism.

5. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 1, characterized in that, The incremental state synchronization mechanism introduced on the basis of the structured message protocol includes abstracting the state of the device that needs to be synchronized across platforms into a three-level synchronizeable state tree composed of a root node, a service node, and an attribute node. The root node represents the global state of the device, the service node represents the functional module, and the attribute node is the smallest state unit. Each node is assigned a unique identifier, and the attribute node is marked with synchronization priority, data type, and update frequency threshold. When the device first connects, a complete snapshot of the state tree is generated and sent to the associated device through the structured message protocol.

6. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 5, characterized in that, The incremental state synchronization mechanism introduced on the basis of the structured message protocol also includes difference detection based on the ST-Diff algorithm, generating structured hash values ​​for state tree nodes, comparing the hash values ​​of the current state tree with those of the baseline snapshot, locating and extracting the difference items, encapsulating the incremental differences, and sending them to the receiving end based on the compression method determined by the link quality index. The receiving end performs state reconstruction and conflict handling. The structured hash value is represented as: ， in, This is represented as a unique identifier for the node. Represented as the current value of the node. It is represented as the sum of the hash values ​​of all child nodes.

7. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 1, characterized in that, The dynamic priority calculation and multi-level queue scheduling strategy includes defining remote command types and metadata, constructing a dynamic priority calculation method based on the command urgency of command types, calculating command priorities, dividing commands into four-level queues based on priorities, using the scheduling engine to retrieve commands from the corresponding queues and calling the local execution interface, and updating the associated status nodes after execution.

8. The method for remote synchronous control of industrial equipment based on OpenHarmony according to claim 1, characterized in that, The remote synchronization control achieved through network jitter perception and intelligent retransmission mechanism includes obtaining round-trip delay data from the sending end based on a sliding window, calculating a jitter factor to quantify network stability based on the round-trip delay data, calculating the block size based on the jitter factor, splitting the file according to the block size and generating a unique index, associating state tree nodes to mark the transmission status, feeding back the block reception status at the receiving end through a block status bitmap, generating a retransmission list at the sending end based on the bitmap, and calculating the retransmission interval using a binary exponential backoff algorithm.

9. A remote synchronous control system for industrial equipment based on OpenHarmony, executing the method described in claim 1, characterized in that, include: The data acquisition module is configured to: acquire device information for remote control and perform initialization operations on the communication environment, including achieving full-domain perception of the device through a distributed discovery mechanism and building a cross-platform communication infrastructure environment; The evaluation module is configured to: perform path selection for the communication environment based on link quality assessment, including real-time collection of link parameters and calculation of link quality index through a distributed communication abstraction layer; The structured module is configured to: construct a structured message protocol based on application semantics according to the selected communication path, including defining the message structure in layers and performing serialization processing on the defined messages; The synchronization module is configured to introduce an incremental state synchronization mechanism based on the structured message protocol, including transmitting incremental data of device state changes by constructing a synchronizeable state tree and a difference detection algorithm. The scheduling module is configured to build an industrial-grade command scheduling engine based on an incremental state synchronization mechanism, including dynamic priority calculation and multi-level queue scheduling strategies. The transformation module is configured to: establish an adaptive file transfer protocol and complete remote synchronization control through network jitter perception and intelligent retransmission mechanism.

Images