Industrial configuration software cross-platform collaborative control method and system based on hon g meng

Abstract

This invention relates to the field of industrial automatic control technology, and discloses a cross-platform collaborative control method and system based on HarmonyOS industrial configuration software. By fully utilizing the distributed communication and microkernel characteristics of HarmonyOS, it achieves flexible initialization of control terminals and dynamic task distribution. Through structured analysis of the configuration control model and construction of the task graph, it supports granular reorganization of the control flow and parallel execution of tasks. Furthermore, by combining the execution requirements of control tasks with terminal capability tag information to generate a task terminal recommendation mapping table, it effectively improves the compatibility between control tasks and execution terminals. At the same time, it constructs a distributed collaborative channel to establish a communication binding path between the master control terminal and the slave control terminal, providing a guarantee for rapid task scheduling and execution. Compared with the prior art, this invention can significantly improve heterogeneous compatibility, task scheduling efficiency, and protocol adaptation flexibility, and is suitable for highly complex industrial automation control scenarios with multi-terminal collaboration.

Description

Technical Field

[0001] This invention relates to the field of industrial automatic control technology, and more specifically to a cross-platform collaborative control method and system based on HarmonyOS industrial configuration software. Background Technology

[0002] In existing technologies, most industrial configuration control systems are built on closed platforms, executing control processes on fixed terminals. They lack compatibility with heterogeneous devices and cross-platform control collaboration capabilities, failing to achieve dynamic decomposition and flexible scheduling of control tasks in complex processes. This results in poor system scalability, low resource utilization, and difficulty in meeting the demands of modern intelligent manufacturing for multi-device collaborative control and dynamic allocation of heterogeneous terminal resources. Furthermore, the failure to intelligently match terminal capabilities with task characteristics easily leads to scheduling imbalances and response delays. Summary of the Invention

[0003] In view of this, the purpose of this invention is to provide a cross-platform collaborative control method and system for industrial configuration software based on HarmonyOS, so as to solve the technical problem that current industrial configuration software is difficult to adapt to the needs of multi-device collaborative control and dynamic allocation of heterogeneous terminal resources in modern intelligent manufacturing when performing cross-platform collaborative control.

[0004] The first aspect of this invention discloses a cross-platform collaborative control method for industrial configuration software based on HarmonyOS, the method comprising the following steps:

[0005] S1. Initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal;

[0006] S2. Load the configuration control model on the main control terminal through the industrial configuration software platform;

[0007] S3. Based on the configuration control model, analyze the set of control tasks to be executed in the current control process, extract the control logic information of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic information as scheduling information to the HarmonyOS distributed task scheduling engine.

[0008] S4. The scheduling engine determines the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal, maps the control task to the target slave terminal, and the target slave terminal completes the protocol adaptation and instruction issuance operation for the controlled device.

[0009] Furthermore, the construction process of the configuration control model includes:

[0010] Based on user-configured process logic nodes, equipment connection relationships, and control strategy templates, an initial distributed control diagram structure is automatically generated.

[0011] Based on the type of controlled equipment, the complexity of control logic, and the granularity of control tasks, the initial distributed control graph structure is optimized in terms of model nodes and their dependencies are adjusted to generate a configuration control model. The configuration control model includes multiple model nodes, which include task units, data sensing nodes, and control logic blocks.

[0012] Furthermore, after generating the configuration control model, the method also includes deconstructing and reconstructing the configuration control model, specifically including:

[0013] The distributed control graph structure in the configuration control model is deconstructed according to control logic blocks, and the control objectives, preconditions and dependency paths corresponding to each control logic block are extracted.

[0014] Based on the control dependency structure formed by the control objectives, preconditions and dependency paths, as well as the control coupling relationship between control logic blocks, the corresponding controlled device types and scheduling parallelism, the control logic blocks are recombined into multiple task subgraphs, and a cross-platform execution task graph is constructed based on the task subgraphs.

[0015] Furthermore, the process of constructing a cross-platform execution task graph based on the task subgraph specifically includes:

[0016] The task subgraph performs terminal adaptation attribute annotation, resource requirement mapping, and scheduling granularity constraint optimization operations to generate a cross-platform execution task graph that adapts to heterogeneous terminals and supports distributed collaborative execution.

[0017] Furthermore, the determination of control tasks based on the configuration control model includes determining control tasks based on a cross-platform execution task graph, specifically including:

[0018] Based on the task subgraph structure in the cross-platform execution task graph, the connection relationship between task units, data sensing nodes, and control logic blocks is analyzed to determine the triggering conditions and control dependency paths of each task unit. Based on the triggering conditions and control dependency paths, the executable state of the task unit is determined, and the set of task units in the current control flow is determined as the first control task set.

[0019] Furthermore, after determining the first set of control tasks, the method further includes:

[0020] The control tasks in the first set of control tasks are classified by task type, and the classified set of control tasks is used as the second set of control tasks and connected to the scheduling engine; the task types include periodic control tasks, event-triggered control tasks and conditional logic control tasks.

[0021] Furthermore, after executing step S1, the process also includes establishing a distributed cooperative channel, specifically including:

[0022] The master control terminal initiates service discovery requests to each slave control terminal based on the distributed communication mechanism of the HarmonyOS system. Each slave control terminal broadcasts its own control protocol type, execution response latency, concurrent control capabilities, and device binding information through the capability tag registration mechanism.

[0023] The master control terminal constructs a logical virtual channel table based on the capability tag registration information of each slave control terminal and the network topology, and completes communication session binding with each slave control terminal to form a distributed collaborative channel.

[0024] Furthermore, the process of generating the task terminal recommendation mapping table includes:

[0025] Based on the execution requirements of each control task and the capability tag registration information of each slave terminal, candidate slave terminals that meet the basic execution requirements are identified.

[0026] An adaptation score is performed between each control task and its candidate slave terminals to form a task-terminal score matrix;

[0027] Based on the scoring results, candidate terminals are prioritized and a task terminal recommendation mapping table is generated.

[0028] Furthermore, the target slave terminal completing the protocol adaptation operation for the controlled device includes:

[0029] Based on the protocol type of the controlled device corresponding to the control task, the corresponding protocol adaptation template in the local protocol adaptation library is called to convert the control task instruction into a target protocol instruction that the controlled device can recognize, and protocol parameter mapping and instruction structure verification operations are performed before the instruction is issued.

[0030] The second aspect of this invention discloses a cross-platform collaborative control system based on HarmonyOS industrial configuration software, comprising an industrial configuration software platform, a control terminal, controlled devices, an initialization module, a model loading module, a task parsing module, and a task mapping module; wherein,

[0031] The initialization module is used to initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal.

[0032] The model loading module is used to load the configuration control model on the main control terminal through the industrial configuration software platform;

[0033] The task parsing module is used to parse the set of control tasks to be executed in the current control process based on the configuration control model, extract the control logic of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic as scheduling information to the HarmonyOS distributed task scheduling engine.

[0034] The task mapping module is used to determine the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal through the scheduling engine, and to map the control task to the target slave terminal, so that the target slave terminal can complete the protocol adaptation and instruction issuance operation of the controlled device.

[0035] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0036] This invention fully leverages the distributed communication and microkernel features of the HarmonyOS system to achieve flexible initialization of control terminals and dynamic task distribution. Through structured analysis of the configuration control model and construction of the task graph, it supports granular reorganization of control flows and parallel execution of tasks. Furthermore, by combining the execution requirements of control tasks with terminal capability tag information, it generates a task terminal recommendation mapping table, effectively improving the compatibility between control tasks and execution terminals. Simultaneously, it constructs a distributed collaborative channel, establishing a communication binding path between the master control terminal and slave control terminals, ensuring rapid task scheduling and execution. Compared to existing technologies, this invention significantly improves heterogeneous compatibility, task scheduling efficiency, and protocol adaptation flexibility, making it suitable for highly complex industrial automation control scenarios involving multiple terminals. Attached Figure Description

[0037] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, do not constitute a limitation thereof. In the drawings:

[0038] Figure 1 This is a flowchart illustrating a cross-platform collaborative control method for industrial configuration software based on HarmonyOS, as disclosed in an embodiment of the present invention. Detailed Implementation

[0039] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0040] Example 1

[0041] The first aspect of this invention discloses a cross-platform collaborative control method for industrial configuration software based on HarmonyOS. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart illustrating a cross-platform collaborative control method for industrial configuration software based on HarmonyOS, as disclosed in an embodiment of the present invention. The method includes the following steps:

[0042] S1. Initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal;

[0043] S2. Load the configuration control model on the main control terminal through the industrial configuration software platform;

[0044] S3. Based on the configuration control model, analyze the set of control tasks to be executed in the current control process, extract the control logic information of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic information as scheduling information to the HarmonyOS distributed task scheduling engine.

[0045] S4. The scheduling engine determines the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal, maps the control task to the target slave terminal, and the target slave terminal completes the protocol adaptation and instruction issuance operation for the controlled device.

[0046] In this embodiment of the invention, the industrial configuration software platform serves as the core configuration platform, used to model user-defined control logic, process flows, and equipment connection relationships. It acts as the upper-level logic configuration center and issues control tasks through the master control terminal. The control terminal is the industrial control execution entity, divided into master and slave terminals. The master control terminal is deployed on the HarmonyOS system and is typically a powerful edge server or industrial control host with high system privileges and scheduling and coordination capabilities, performing scheduling and task mapping. Slave terminals are various control terminal nodes deployed in the field, capable of performing specific protocol adaptation and instruction issuance operations according to the tasks issued by the master control terminal. The controlled equipment refers to specific control objects in the industrial field, such as valves, motors, and sensors, controlled by the slave terminals, and their status is also fed back to the master control terminal for scheduling reference.

[0047] Furthermore, the process of constructing the configuration control model includes:

[0048] Based on user-configured process logic nodes, equipment connection relationships, and control strategy templates, an initial distributed control diagram structure is automatically generated.

[0049] Based on the type of controlled equipment, the complexity of control logic, and the granularity of control tasks, the initial distributed control graph structure is optimized in terms of model nodes and their dependencies are adjusted to generate a configuration control model. The configuration control model includes multiple model nodes, which include task units, data sensing nodes, and control logic blocks.

[0050] Specifically, when constructing the configuration control model, users define the process logic nodes, equipment connection relationships, and control strategy templates required for process control through the platform configuration interface. Process logic nodes abstractly represent the core control behavior units in the industrial process, such as temperature control, equipment start / stop, and data acquisition. Equipment connection relationships describe the physical connections and control links between various devices, including port mappings, communication protocol relationships, and network topology of field devices. Control strategy templates preset typical control logic modes, such as periodic control, event-driven control, or conditional logic control. Users can select a strategy template that matches their scenario and assign specific parameter configurations.

[0051] After the user completes the above configuration, the industrial configuration software platform automatically constructs an initial distributed control graph structure based on the configuration. Specifically, the platform instantiates each process logic node as a control logic block in the model and establishes dependency paths between control logic blocks based on equipment connection relationships, thereby forming a directed graph structure with semantic connections. At the same time, according to the triggering mechanism bound to the control strategy template, the platform marks perception-type nodes (such as sensor inputs) as data perception nodes and generates corresponding task unit nodes based on control action outputs, so that the initial graph structure has a complete perception-decision-execution process closed loop.

[0052] After completing the initial modeling, the platform further optimizes the nodes and adjusts the dependencies of the initial control diagram structure based on three factors: the type of controlled equipment, the complexity of the control logic, and the granularity of the control tasks. The type of controlled equipment mainly refers to the functional differences and interface characteristics of the terminal controlled objects, such as switch-type, analog-type, and complex bus-type devices, which directly affect the adaptation strategy of the control tasks at the execution end. The complexity of the control logic reflects the hierarchical complexity of the logical judgments and execution paths within the control logic block; the platform prioritizes breaking down high-complexity blocks into smaller task units to enhance execution efficiency and scheduling flexibility. The granularity of the control tasks reflects the rationality and schedulability of the task breakdown; while ensuring logical integrity, the platform uniformly adjusts the granularity to a range suitable for distributed parallel scheduling.

[0053] Through the above optimization operations, the final configuration control model generated by the platform contains a variety of model nodes with a clear structure and user-friendly scheduling, mainly including task units, data sensing nodes, and control logic blocks. The task unit is the smallest executable control unit, encapsulating specific instructions and triggering mechanisms; the data sensing node serves as the input prerequisite for the control logic, representing data sensing operations from the device or environment; the control logic block is a logical combination of task units and sensing nodes, representing a complete control strategy logic, possessing deployability and independent execution capabilities.

[0054] By using structured configuration-driven modeling and optimizing the control graph structure based on the characteristics of the controlled object, the generated configuration control model has strong configurability, good structural hierarchy, and excellent scheduling friendliness. It provides a standardized model foundation for the subsequent construction of cross-platform execution task graphs, control task parsing, and distributed scheduling, and has significant adaptability and engineering practical value in heterogeneous HarmonyOS terminal environments.

[0055] Furthermore, after generating the configuration control model, the method also includes deconstructing and reconstructing the configuration control model, specifically including:

[0056] The distributed control graph structure in the configuration control model is deconstructed according to control logic blocks, and the control objectives, preconditions and dependency paths corresponding to each control logic block are extracted.

[0057] Based on the control dependency structure formed by the control objectives, preconditions and dependency paths, as well as the control coupling relationship between control logic blocks, the corresponding controlled device types and scheduling parallelism, the control logic blocks are recombined into multiple task subgraphs, and a cross-platform execution task graph is constructed based on the task subgraphs.

[0058] Furthermore, the process of constructing a cross-platform execution task graph based on the task subgraph specifically includes:

[0059] The task subgraph performs terminal adaptation attribute annotation, resource requirement mapping, and scheduling granularity constraint optimization operations to generate a cross-platform execution task graph that adapts to heterogeneous terminals and supports distributed collaborative execution.

[0060] Specifically, in order to improve the schedulability and execution efficiency of the configuration control model on various types of terminals, after the configuration control model is constructed, this invention further performs deconstruction and reorganization operations on it to construct a cross-platform execution task graph adapted to the distributed HarmonyOS system environment.

[0061] The process begins by deconstructing the distributed control graph structure within the generated configuration control model, according to the structural boundaries of the control logic blocks. Each control logic block is a core unit encapsulating control behavior and logical judgments, containing one or more task units along with their corresponding triggering conditions, logical judgment statements, execution order, and other information. During deconstruction, the semantic composition of each control logic block is analyzed one by one, extracting its corresponding control objective, preconditions, and upstream and downstream dependencies within the entire control flow.

[0062] Based on the extracted information, a control dependency structure graph oriented towards the control flow is constructed to reconstruct the actual control relationships and sequential execution dependencies between logic blocks. The control objective identifies the execution function of the control logic block, such as opening / closing a valve, adjusting motor speed, or issuing an alarm signal. These objectives are typically associated with a specific controlled device or behavioral instruction. Preconditions represent the triggering conditions of the control logic block, including threshold judgments based on data collected by sensing nodes (e.g., temperature > 50°C), upstream control status (e.g., a device has completed an action), or the result of a conditional expression. Dependency paths reflect the direct / indirect calling relationships between control logic blocks, especially the strong logical order of execution followed by triggering. These three types of information from all control logic blocks are transformed into node attributes and edge weights in the graph structure. For example, if the control objective of control logic block A depends on the output state of block B, and its preconditions include the data sensing node values ​​controlled by B, then a directed edge connecting A←B is created in the dependency graph, and the edge attributes record a double marker of triggering and data dependency. This structure graph provides a graph theory foundation for subsequent operations such as determining the mandatory sequential order of control logic, parallelizable regions, and critical path identification.

[0063] Based on this, and combining the control coupling relationship between control logic blocks (i.e., whether a control logic block depends on the state or output of another block), the type of controlled device corresponding to each block (e.g., whether it is the same type of execution end, whether it supports a unified protocol), and its scheduling parallelism (i.e. whether the block can be executed in parallel with other blocks, and whether there is a forced sequential dependency), the control logic blocks are divided into several relatively independent task subgraphs through clustering and structural reorganization algorithms.

[0064] This algorithm does not rely solely on the adjacency relationships of control logic blocks in the topological structure for coarse partitioning. Instead, it comprehensively considers three key factors: control coupling relationships, terminal adaptation characteristics, and scheduling parallelism, thereby improving the accuracy and applicability of task subgraph partitioning. Specifically, by analyzing the interaction characteristics between each control logic block, its behavioral coupling strength is extracted, such as whether control variables are frequently shared and whether there is a strong dependency between output state and triggering conditions. Based on this, the coupling relationships between logic blocks are established to characterize the tightness of each module in the control flow. Secondly, considering the controlled device type associated with each logic block and the protocol constraints of the control instructions, combined with the protocol support type, execution performance indicators, and interface compatibility in each terminal capability tag, the adaptability of control logic blocks on different slave terminals is evaluated, thereby determining whether multiple control logic blocks are suitable to be uniformly distributed to the same terminal for execution. Finally, a scheduling parallelism analysis mechanism is introduced. Combining control dependency paths and task triggering conditions, the sequential constraints and parallel execution potential between each control logic block are evaluated to avoid forcibly partitioning serial logic into parallelizable subgraphs.

[0065] Supported by the aforementioned multidimensional features, clustering and recombination algorithms divide the control logic block into several relatively independent task subgraphs. Each subgraph ensures both the tightness of its internal control logic and the compatibility and scheduling efficiency of cross-terminal deployment. This partitioning strategy significantly improves the quality of subsequent cross-platform execution task graph generation, enabling control tasks to have stronger adaptability and execution stability in the complex HarmonyOS heterogeneous environment.

[0066] Each task subgraph represents a relatively closed, logically clear, and independently deployable control task chain, with a clearly defined three-part structure: input (sensing nodes), processing (logic blocks), and output (control instructions). After verifying the structural rationality of each task subgraph, they are further integrated into the task scheduling system to generate a task set structure with cross-platform execution capabilities.

[0067] After completing the task subgraph partitioning, terminal adaptation attribute labeling is performed on each task subgraph. Adaptation conditions are marked based on the protocol requirements, real-time needs, and concurrency control characteristics of its contained control logic blocks. Resource requirement mapping operations are also performed, analyzing the computing resources, memory usage, communication bandwidth, and I / O access frequency required for subgraph operation to form a resource mapping vector corresponding to the terminal resource capabilities. Furthermore, the scheduling granularity is dynamically adjusted based on the dependencies between subgraphs and the schedulable window. This includes merging lightweight quantum graphs with short execution paths and parallel execution capabilities to improve scheduling efficiency, or splitting heavyweight subgraphs with complex execution paths and concentrated resource consumption to achieve load balancing. This constructs a cross-platform execution task graph that meets the characteristics of heterogeneous terminal deployment and possesses high scheduling efficiency. This task graph is platform-independent, scheduling-friendly, and parallelizable, enabling deployment on heterogeneous HarmonyOS control terminals and supporting efficient scheduling and stable control.

[0068] Through the above deconstruction and reorganization process, this invention transforms the control structure oriented towards logic modeling in the original configuration control model into a task structure oriented towards terminal scheduling, breaking down the structural isolation between model design and task execution, enabling the control process to have cross-platform migration capabilities and distributed execution capabilities, providing a data and structural foundation for subsequent task allocation and terminal mapping of the scheduling engine, and significantly improving the application adaptability and intelligent scheduling capabilities of industrial configuration in multi-terminal heterogeneous control scenarios.

[0069] As a preferred embodiment, the structural dependency graph consisting of control logic blocks is represented as a directed graph:

[0070]

[0071] in, Represents the set of control logic nodes; The set of edges representing control dependencies; This represents the edge weight matrix, where each element... Represents control logic block arrive The coupling strength.

[0072] The weight of each edge is... It is defined as a weighted combination of multiple semantic coupling factors, such as the degree of overlap of logical constraints between control objectives, and the degree of sharing of perceived data paths (e.g., shared sensors, data sources). By introducing control semantics, the interpretability of edge weights is improved.

[0073] The standard symmetric normalized Laplace matrix for constructing the coupling graph of the control logic block is:

[0074] in,

[0075] in, D is the identity matrix; D is the degree matrix, which is a diagonal matrix, with each element on the diagonal... Represents a node The degree (i.e., the total weight of the edges connecting it to other nodes) represents the element in the i-th row and i-th column of the matrix, i.e., the degree value of the i-th node.

[0076] Next, for Perform eigenvalue decomposition and take the eigenvectors corresponding to the k smallest eigenvalues ​​to form the spectral embedding matrix: , where each row This represents the low-dimensional embedded representation of control logic block i. A constraint index vector is then introduced into it, let... For the device compatibility feature vector of control logic block i; To control the parallel constraint mask of logic block i, if the j-th constraint is satisfied, then ; , This is a hyperparameter that controls the trade-off between embedding quality and constraint matching degree.

[0077] Constructing a multi-constraint objective clustering function:

[0078]

[0079] in, Clustering assignment results ; The center of the cluster; The device compatibility loss function penalizes the incompatibility of control logic blocks within the same cluster. The parallel matching penalty term penalizes cases where parallel scheduling is not possible but the devices are grouped together. This is an indicator function; its value is 1 when control logic blocks i and j are assigned to the same subgraph.

[0080] In this implementation, by introducing device compatibility features and scheduling parallelism vectors of control logic blocks, the clustering algorithm not only considers the semantic coupling relationship in the graph structure when completing the partitioning of control logic blocks, but also integrates the feasibility factors of deployment and execution, which enables it to have higher actual execution adaptability and independence between subgraphs, and can effectively improve the efficiency of subsequent cross-platform task scheduling and system stability.

[0081] Furthermore, determining control tasks based on the configuration control model includes determining control tasks based on cross-platform execution task graphs, specifically including:

[0082] Based on the task subgraph structure in the cross-platform execution task graph, the connection relationship between task units, data sensing nodes, and control logic blocks is analyzed to determine the triggering conditions and control dependency paths of each task unit. Based on the triggering conditions and control dependency paths, the executable state of the task unit is determined, and the set of task units in the current control flow is determined as the first control task set.

[0083] Furthermore, after determining the first set of control tasks, the method further includes:

[0084] The control tasks in the first set of control tasks are classified by task type, and the classified set of control tasks is used as the second set of control tasks and connected to the scheduling engine; the task types include periodic control tasks, event-triggered control tasks and conditional logic control tasks.

[0085] Specifically, after completing the construction of the cross-platform execution task graph, it is used as the structural basis for task parsing. The task subgraph structure in the task graph is parsed first.

[0086] During the execution status determination of a task unit, a condition judgment tree for status parsing is constructed based on the triggering conditions and dependency path information of each task unit in the task subgraph. Specifically, the triggering conditions of each task unit are first identified, including whether real-time monitoring data (such as temperature, current, flow rate, etc.) from the data sensing node meets a specific threshold, whether a specific logic signal is true, or whether there is an external event triggering signal, etc. At the same time, the execution status of the preceding control logic block or task unit on which the task unit depends is also extracted, such as whether the preceding task has been completed, whether the control logic has been transferred to the current stage, etc.

[0087] The aforementioned triggering conditions and dependency path structure are organized into a set of judgment rules with logical operation relationships. For example, if the execution of task A requires that "the voltage value of sensing node X is greater than a certain set threshold" and "task B has been completed," then the judgment structure is expressed as: task A is marked as executable only if and only if the voltage value of sensing node X meets the threshold condition and the state of task B is completed. Based on this judgment result, all task units that currently meet the execution conditions are dynamically selected and a first control task set is formed for subsequent task type classification and scheduling mapping operations.

[0088] Furthermore, the task units in the first set of control tasks are classified to improve scheduling efficiency and concurrent coordination capabilities. The task type classification rules are as follows: if a task has a fixed execution cycle or a time-slice driven flag, it is classified as a periodic control task; if a task depends on external events such as button triggers or sensor alarms, it is classified as an event-triggered control task; if the execution of a task is based on a multi-condition judgment chain or logical expression (such as IF / ELSE, Boolean logic tree), it is classified as a conditional logic control task. For example, a device's temperature control adjustment task is executed every 10 seconds, which is a periodic task; an alarm light control is triggered by a vibration sensor input, which is an event-triggered task; and a device reset task needs to be executed under conditions of temperature <40℃ and stable pressure, which is a conditional logic task.

[0089] After the above classification is completed, the classified second set of control tasks is connected to the distributed task scheduling engine, enabling the scheduling engine to formulate differentiated scheduling strategies based on task type, realize parallel coordination of time slice scheduling, event response and logical judgment path, and improve the real-time performance, responsiveness and resource utilization of the overall scheduling.

[0090] After determining the executability and classifying the task types of the first set of control tasks, the classification results are used as the second set of control tasks, entering the scheduling preparation phase. At this stage, based on the structural information of each control task, the control logic information of the associated controlled device is extracted. This control logic information includes, but is not limited to, key information such as the control protocol type corresponding to the device, command format structure, execution parameter range, response latency requirements, and execution status feedback method. Simultaneously, combined with the type of control task, the above control logic information and task scheduling metadata are uniformly encapsulated to form a standardized scheduling information package. This scheduling information package includes fields such as task identifier, execution type, control logic parameters, status expectation, priority information, and scheduling direction suggestion. Finally, the scheduling information package set is used as the data structure of the scheduling input interface and interfacing with the HarmonyOS distributed task scheduling engine, providing complete basic information support for subsequent terminal matching, capability tag parsing, and protocol adaptation operations.

[0091] Furthermore, after executing step S1, the process also includes establishing a distributed cooperative channel, specifically including:

[0092] The master control terminal initiates service discovery requests to each slave control terminal based on the distributed communication mechanism of the HarmonyOS system. Each slave control terminal broadcasts its own control protocol type, execution response latency, concurrent control capabilities, and device binding information through the capability tag registration mechanism.

[0093] The master control terminal constructs a logical virtual channel table based on the capability tag registration information of each slave control terminal and the network topology, and completes communication session binding with each slave control terminal to form a distributed collaborative channel.

[0094] Specifically, after completing the basic driver initialization of the control terminal, the distributed collaborative channel establishment operation is further executed to ensure the communication coordination capability between the master control terminal and each heterogeneous slave control terminal. Specifically, based on the distributed communication mechanism of the HarmonyOS operating system, the master control terminal actively initiates service discovery requests to reachable slave control terminals within the local area network. This process implements service discovery broadcasting and callback listening mechanisms through a distributed soft bus. Upon receiving a service discovery request, each slave control terminal broadcasts its own capability information through a capability tag registration mechanism based on its hardware characteristics and registered control components. These capability tags include, but are not limited to, control protocol type (such as Modbus, CAN, OPC, etc.), execution response latency, concurrent control capabilities, and the identifier and type of the bound controlled device. After receiving the capability tag information returned by each slave control terminal, the master control terminal constructs a logical virtual channel table based on the current network topology and service quality parameters. This channel table is used to identify the communication path mapping, capability adaptation status, and communication priority from the master control terminal to each slave control terminal. Subsequently, the master control terminal binds communication sessions with each slave control terminal based on the channel table, establishing point-to-point control channel connections, thereby forming a complete distributed collaborative channel system.

[0095] Through the above operations, not only was the structured identification and abstract mapping of the capabilities of heterogeneous control terminals achieved, but also the communication foundation and resource cognition prerequisite were laid for the subsequent terminal matching, task distribution and protocol adaptation operations of the scheduling engine, which significantly enhanced the cross-platform deployment capability and the efficiency of multi-terminal collaborative control.

[0096] Furthermore, the process of generating the task terminal recommendation mapping table includes:

[0097] Based on the execution requirements of each control task and the capability tag registration information of each slave terminal, candidate slave terminals that meet the basic execution requirements are identified.

[0098] An adaptation score is performed between each control task and its candidate slave terminals to form a task-terminal score matrix;

[0099] Based on the scoring results, candidate terminals are prioritized and a task terminal recommendation mapping table is generated.

[0100] Specifically, firstly, a task profile model is created for each control task based on its execution requirements. These requirements include the protocol type (e.g., Modbus, OPC UA), real-time performance level (e.g., millisecond or second-level response requirements), data interaction frequency, execution concurrency requirements, and the type of controlled device and interface constraints corresponding to the task. Simultaneously, capability tag information for each registered slave terminal is obtained. This capability tag is actively registered by the terminal during the service discovery phase, and specific fields include supported protocol types, minimum response time, maximum number of concurrent tasks, and type of bound device.

[0101] Based on the above information, a task-terminal adaptation and matching operation is performed. Specifically, the set of candidate slave terminals for each control task is identified, i.e., all slave terminals whose capability tag information meets the execution requirements of the control task. Then, for each task-candidate terminal pair, an adaptation scoring operation is performed. This scoring comprehensively considers multiple dimensions such as matching degree, resource sufficiency, network response latency, and historical execution success rate, and uses a weighted scoring model to form a task-terminal scoring matrix. The scoring result is usually a floating-point value between 0 and 1, with higher values ​​indicating higher adaptation. Finally, the candidate terminals for each task are sorted in descending order according to their adaptation scores. Combining task scheduling priority and terminal load balancing strategies, the preferred and alternative terminals are determined, generating a task-terminal recommendation mapping table. This mapping table is a mapping relationship structure used to describe the terminal sequence and scoring basis for the recommended mapping of each control task, and serves as an important basis for the scheduling engine to execute mapping decisions.

[0102] Through the above operations, this invention enables precise matching between task requirements and terminal capabilities, improving the rationality and adaptability of scheduling strategies. In environments with complex and variable heterogeneous control terminal resources, the constructed task terminal recommendation mapping mechanism significantly enhances the intelligence and reliability of control task distribution, reduces resource conflicts and response bottleneck risks during task scheduling, and provides crucial support for the efficient operation of distributed control systems.

[0103] Furthermore, the target control terminal completes the protocol adaptation operation for the controlled device, including:

[0104] Based on the protocol type of the controlled device corresponding to the control task, the corresponding protocol adaptation template in the local protocol adaptation library is called to convert the control task instruction into a target protocol instruction that the controlled device can recognize, and protocol parameter mapping and instruction structure verification operations are performed before the instruction is issued.

[0105] In the process of mapping control tasks to the final target slave terminals through the scheduling engine, the scheduling engine first reads the task terminal recommendation mapping table to obtain a list of priority candidate slave terminals corresponding to each control task. Based on this, the current capability label status of each slave terminal is used as dynamic input. The capability label status includes the terminal's current operating load, the number of assigned tasks, instantaneous response latency, connection stability, and resource availability (such as CPU utilization and memory usage). The scheduling engine uses the immediate needs of task execution as the matching basis to dynamically filter and reorder the candidate terminals, ultimately determining the target slave terminal with the optimal load and meeting real-time requirements.

[0106] It is important to note that although preliminary screening and scoring based on static capability tags are performed during the generation of the task terminal recommendation mapping table, this process is pre-calculated before scheduling and cannot reflect the real-time operating status of the terminal at the moment of scheduling. Therefore, when the scheduling engine actually executes the mapping, introducing capability tag status as a supplementary judgment criterion can avoid deviations between the static recommendation results and the actual terminal load, ensuring that control tasks are assigned to terminals with optimal status and responsiveness, effectively improving scheduling accuracy and stability.

[0107] After the target terminal is assigned, the target slave terminal executes the corresponding control task instruction adaptation and delivery process. This process relies on a local protocol adaptation library for protocol standard conversion. Specifically, the target terminal identifies the communication protocol type used by the controlled device corresponding to the control task and loads the matching protocol format conversion logic from a locally pre-set protocol adaptation template. Subsequently, the control parameters, action instructions, and other content in the control task are mapped and reorganized according to the adaptation template to generate a protocol instruction data packet that can be recognized and executed by the target device. Before the instruction is delivered, protocol parameter mapping verification (ensuring that units, precision, and address ranges conform to the protocol) and instruction structure integrity checks are also performed to ensure that the delivered instructions are semantically and structurally correct, avoiding communication failures or control malfunctions caused by protocol deviations.

[0108] By introducing a dynamic capability perception mechanism before scheduling and a protocol adaptive conversion mechanism for the target terminal, a cross-platform control task execution path with intelligent scheduling and protocol compatibility is constructed. These operations not only improve the flexibility of protocol adaptation in complex control task scenarios but also enhance the collaborative scheduling efficiency and control accuracy among heterogeneous terminals in the HarmonyOS distributed control environment.

[0109] Example 2

[0110] The second aspect of this invention discloses a cross-platform collaborative control system based on HarmonyOS industrial configuration software, comprising an industrial configuration software platform, a control terminal, controlled devices, an initialization module, a model loading module, a task parsing module, and a task mapping module; wherein,

[0111] The initialization module is used to initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal.

[0112] The model loading module is used to load the configuration control model on the main control terminal through the industrial configuration software platform;

[0113] The task parsing module is used to parse the set of control tasks to be executed in the current control process based on the configuration control model, extract the control logic of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic as scheduling information to the HarmonyOS distributed task scheduling engine.

[0114] The task mapping module is used to determine the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal through the scheduling engine, and to map the control task to the target slave terminal, so that the target slave terminal can complete the protocol adaptation and instruction issuance operation of the controlled device.

[0115] It should be noted that the specific implementation process of Example 2 is similar to that of Example 1, and will not be repeated in Example 2.

[0116] Finally, it should be noted that the above-described embodiments include multiple parallel implementations of the present invention. Deleting or otherwise adjusting one or more implementations will not affect the implementation of the solution. Furthermore, the cross-platform collaborative control method and system for industrial configuration software based on HarmonyOS disclosed in the embodiments of the present invention are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not 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; and these 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 cross-platform collaborative control method for industrial configuration software based on HarmonyOS, characterized in that, The method includes the following steps: S1. Initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal; S2. Load the configuration control model on the main control terminal through the industrial configuration software platform; S3. Based on the configuration control model, analyze the set of control tasks to be executed in the current control process, extract the control logic information of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic information as scheduling information to the HarmonyOS distributed task scheduling engine. S4. The scheduling engine determines the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal, maps the control task to the target slave terminal, and the target slave terminal completes the protocol adaptation and instruction issuance operation for the controlled device. The process of constructing the configuration control model includes: Based on user-configured process logic nodes, equipment connection relationships, and control strategy templates, an initial distributed control diagram structure is automatically generated. Based on the type of controlled equipment, the complexity of control logic, and the granularity of control tasks, the initial distributed control graph structure is optimized in terms of model nodes and their dependencies are adjusted to generate a configuration control model. The configuration control model includes multiple model nodes, which include task units, data sensing nodes, and control logic blocks. After generating the configuration control model, the distributed control graph structure in the configuration control model is deconstructed according to the control logic blocks, and the control objectives, preconditions and dependency paths corresponding to each control logic block are extracted. Based on the control dependency structure formed by the control objectives, preconditions and dependency paths, as well as the control coupling relationship between control logic blocks, the corresponding controlled device types and scheduling parallelism, the control logic blocks are recombined into multiple task subgraphs, and a cross-platform execution task graph is constructed based on the task subgraphs.

2. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to claim 1, characterized in that, The process of constructing a cross-platform execution task graph based on the task subgraph specifically includes: The task subgraph performs terminal adaptation attribute annotation, resource requirement mapping, and scheduling granularity constraint optimization operations to generate a cross-platform execution task graph that adapts to heterogeneous terminals and supports distributed collaborative execution.

3. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to claim 2, characterized in that, The determination of control tasks based on the configuration control model includes determining control tasks based on a cross-platform execution task graph, specifically including: Based on the task subgraph structure in the cross-platform execution task graph, the connection relationship between task units, data sensing nodes, and control logic blocks is analyzed to determine the triggering conditions and control dependency paths of each task unit. Based on the triggering conditions and control dependency paths, the executable state of the task unit is determined, and the set of task units in the current control flow is determined as the first control task set.

4. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to claim 3, characterized in that, After determining the first set of control tasks, the method further includes: The control tasks in the first set of control tasks are classified by task type, and the classified set of control tasks is used as the second set of control tasks and connected to the scheduling engine; the task types include periodic control tasks, event-triggered control tasks and conditional logic control tasks.

5. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to any one of claims 1-4, characterized in that, After executing step S1, the process also includes establishing a distributed cooperative channel, specifically including: The master control terminal initiates service discovery requests to each slave control terminal based on the distributed communication mechanism of the HarmonyOS system. Each slave control terminal broadcasts its own control protocol type, execution response latency, concurrent control capabilities, and device binding information through the capability tag registration mechanism. The master control terminal constructs a logical virtual channel table based on the capability tag registration information of each slave control terminal and the network topology, and completes communication session binding with each slave control terminal to form a distributed collaborative channel.

6. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to claim 5, characterized in that, The process of generating the task terminal recommendation mapping table includes: Based on the execution requirements of each control task and the capability tag registration information of each slave terminal, candidate slave terminals that meet the basic execution requirements are identified. An adaptation score is performed between each control task and its candidate slave terminals to form a task-terminal score matrix; Based on the scoring results, candidate terminals are prioritized and a task terminal recommendation mapping table is generated.

7. The cross-platform collaborative control method for industrial configuration software based on HarmonyOS according to any one of claims 1-4 and 6, characterized in that, The target slave terminal completes the protocol adaptation operation for the controlled device, including: Based on the protocol type of the controlled device corresponding to the control task, the corresponding protocol adaptation template in the local protocol adaptation library is called to convert the control task instruction into a target protocol instruction that the controlled device can recognize, and protocol parameter mapping and instruction structure verification operations are performed before the instruction is issued.

8. A cross-platform collaborative control system for industrial configuration software based on HarmonyOS, comprising an industrial configuration software platform, a control terminal, and controlled equipment, characterized in that, The system also includes an initialization module, a model loading module, a task parsing module, and a task mapping module; among which, The initialization module is used to initialize the control terminal based on the HarmonyOS underlying microkernel architecture and load the basic control driver components of the control terminal. The model loading module is used to load the configuration control model on the main control terminal through the industrial configuration software platform; The task parsing module is used to parse the set of control tasks to be executed in the current control process based on the configuration control model, extract the control logic of the controlled device associated with each control task, and connect the set of control tasks and the corresponding control logic as scheduling information to the HarmonyOS distributed task scheduling engine. The task mapping module is used to determine the target slave terminal based on the task terminal recommendation mapping table and the current capability tag status of each slave terminal through the scheduling engine, and to map the control task to the target slave terminal, so that the target slave terminal can complete the protocol adaptation and instruction issuance operation of the controlled device. The process of constructing the configuration control model includes: Based on user-configured process logic nodes, equipment connection relationships, and control strategy templates, an initial distributed control diagram structure is automatically generated. Based on the type of controlled equipment, the complexity of control logic, and the granularity of control tasks, the initial distributed control graph structure is optimized in terms of model nodes and their dependencies are adjusted to generate a configuration control model. The configuration control model includes multiple model nodes, which include task units, data sensing nodes, and control logic blocks. After generating the configuration control model, the distributed control graph structure in the configuration control model is deconstructed according to the control logic blocks, and the control objectives, preconditions and dependency paths corresponding to each control logic block are extracted. Based on the control dependency structure formed by the control objectives, preconditions and dependency paths, as well as the control coupling relationship between control logic blocks, the corresponding controlled device types and scheduling parallelism, the control logic blocks are recombined into multiple task subgraphs, and a cross-platform execution task graph is constructed based on the task subgraphs.

Images