Industrial Internet of Things agent virtual-real collaborative dynamic grading decision response method and system, terminal equipment and medium

Abstract

The invention discloses an industrial internet-of-things intelligent agent virtual-real cooperation dynamic grading decision response method and system, terminal equipment and a medium, and relates to the technical field of industrial internet-of-things intelligent control. The method comprises the steps of obtaining a real-time data stream of an industrial Internet of Things terminal device and performing structured processing to obtain structured task data; the tasks are classified into simple tasks or complex tasks through a stage perceptron; the simple task generates a candidate action and a pre-execution candidate set through an edge lightweight reasoning model and determines a final control instruction, and the complex task generates a main action through a core reasoning model and matches or directly generates the final control instruction through the pre-execution candidate set; and controlling the terminal equipment to execute decision response through the final control instruction. According to the method, task sub-path accurate processing is realized, the pre-execution control instruction is multiplexed, the response delay is greatly shortened, the resource utilization efficiency is improved, and the safety and reliability of industrial scene decision making are guaranteed.

Description

Technical Field

[0001] This invention relates to the field of intelligent control technology for the Industrial Internet of Things (IIoT), and in particular to an IIoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method, system, terminal equipment, and medium. Background Technology

[0002] The Industrial Internet of Things (IIoT) is widely used in areas such as production line control in smart factories, energy network scheduling, and safety in high-risk operations. Its core requirement is to enable rapid response and accurate decision-making for equipment tasks.

[0003] Existing technologies mostly employ a serial architecture of sensing, inference, and execution, resulting in decision-making delays that increase linearly with the number of steps, with delays exceeding 30 minutes for complex production line control tasks. Simultaneously, edge devices use fixed scheduling strategies, making it difficult to adapt to dynamic changes in task complexity, and easily leading to system congestion under high load. Furthermore, the separation of industrial protocol verification from the decision engine results in a lack of real-time risk awareness during high-risk scenario execution, and reliance on manual intervention leads to delayed safety responses.

[0004] Therefore, there is an urgent need for an integrated decision-making and response method that can reduce task control latency, load balancing, and real-time perception to fill the gaps in existing technologies. Summary of the Invention

[0005] The technical problem this invention aims to solve is that, in the field of intelligent control for the Industrial Internet of Things (IIoT), existing technologies suffer from accumulated decision-making delays, uneven resource allocation, and a lack of security mechanisms, resulting in low task response efficiency, poor system adaptability, and insufficient risk control in high-risk scenarios. Therefore, an effective solution is urgently needed to address these technical problems.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a dynamic hierarchical decision-making and response method for virtual-real collaboration of intelligent agents in the Industrial Internet of Things, the method comprising: Acquire real-time data streams from industrial IoT terminal devices, and perform structured processing on the real-time data streams to obtain structured task data; Based on the structured task data, the tasks are classified using a stage perceptron; wherein the tasks are classified as simple tasks or complex tasks. For the simple task, a number of candidate actions and a pre-execution candidate set are generated through an edge lightweight inference model, and the final control command is determined; for the complex task, the main action is generated through a core inference model, and the final control command is obtained by matching or directly generating the pre-execution candidate set. The final control command controls the industrial IoT terminal device to perform decision-making and response operations for the task.

[0007] In one implementation, acquiring the real-time data stream of the industrial IoT terminal device includes: Real-time operating data is collected through the sensors and controllers of the industrial IoT terminal equipment. The collected real-time running data is preprocessed to reduce noise, resulting in the real-time data stream.

[0008] In one implementation, the step of structuring the real-time data stream to obtain structured task data includes: The real-time data stream is parsed using an industrial protocol to extract key feature vectors. The key feature vectors are subjected to feature standardization processing to obtain structured task data; wherein, the structured task data is used to express the content of the task to be processed.

[0009] In one implementation, the step of classifying tasks based on the structured task data using a stage perceptron includes: Based on the structured task data, the task complexity is calculated. The task complexity is compared with a dynamic threshold; If the task complexity is lower than the dynamic threshold, the task is classified as a simple task; otherwise, the task is classified as a complex task.

[0010] In one implementation, the structured task data includes at least a decision timeframe, equipment risk level, and data dimensionality. The calculation of task complexity based on the structured task data includes: The task complexity is dynamically calculated based on the decision time limit, equipment risk level, and data dimensionality in the structured task data.

[0011] In one implementation, the dynamic threshold is calculated from a preset base threshold and the device risk level in the structured task data, wherein the device risk level is positively correlated with the dynamic threshold.

[0012] In one implementation, after classifying the tasks based on the structured task data using a stage perceptron, the method further includes: Based on the current load and the expected benefits of the task, tasks are selected for release through preset filtering rules; wherein, the released tasks are those that are allowed to generate actions, and the expected benefits of the task are determined by a comprehensive assessment of time saved by action overlap, hit probability, transmission overhead and computational overhead.

[0013] In one implementation, the edge lightweight inference model is an inference model deployed at the edge node of an industrial IoT system or locally. It is obtained through model structure simplification and parameter pruning optimization. For the simple task, the edge lightweight inference model generates several candidate actions and a pre-execution candidate set, and determines the final control command, including: Based on the structured task data corresponding to the simple task, a preset number of candidate actions are generated using an edge lightweight inference model; wherein, the candidate actions are used to respond to the requirements of the task. In a pre-set simulation environment, pre-execution operations are performed on all candidate actions to generate a corresponding number of control commands and simulation results. The candidate actions, corresponding control commands, and simulation results are cached to obtain a pre-execution candidate set in the cache. Based on a preset scoring mechanism, the final control command is determined from the candidate actions and their corresponding control commands.

[0014] In one implementation, caching the candidate actions, corresponding control instructions, and simulation results to obtain a cached pre-execution candidate set includes: The candidate actions, corresponding control commands, and simulation results are associated and stored, and associated with the lifecycle timeliness of the industrial IoT terminal device to form a pre-execution candidate set; wherein, the pre-execution candidate set is stored using a time-series database tag.

[0015] In one implementation, determining the final control command from the candidate actions and corresponding control commands based on a preset scoring mechanism includes: Based on the candidate actions and the goal of the task, a similarity score is obtained through semantic similarity evaluation; The control instruction corresponding to the candidate action with the highest similarity score is selected as the final control instruction.

[0016] In one implementation, the core inference model is a high-precision inference model with a complete inference architecture for handling complex tasks, deployed in a high-performance device in the cloud or at the edge of an industrial IoT node. For the complex task, the core inference model generates the main action, and the final control command is obtained through matching the pre-execution candidate set or by direct generation, including: Based on the structured task data corresponding to the complex task, the main action is generated through reasoning using the core reasoning model; Verify whether the main action exists in the pre-execution candidate set; If it exists, the control instruction corresponding to the main action in the pre-execution candidate set shall be used as the final control instruction; If it does not exist, the final control command is generated based on the main action.

[0017] In one implementation, before generating the main action based on the structured task data corresponding to the complex task through the core reasoning model, the method further includes: Based on the computing power demand vector of the complex task, the task is dynamically assigned to edge nodes through a distributed soft bus, and the computing resources of the edge nodes are allocated first to provide computing power; wherein, the distributed soft bus realizes low-latency collaboration between edge devices through a network topology distance optimization mechanism.

[0018] In one implementation, the step of using the control instruction corresponding to the main action in the pre-execution candidate set as the final control instruction includes: Based on a pre-set industrial protocol whitelist and hardware signature, the control instructions corresponding to the main actions in the pre-execution candidate set and the simulation results are executed to verify compliance. If the verification passes, the control command corresponding to the main action will be used as the final control command.

[0019] In one implementation, after obtaining the final control command, the method further includes: For simple tasks, obtain the similarity score between the candidate actions corresponding to the final control command and the target of the task; The similarity score is compared with a switching threshold; wherein the switching threshold is calculated from a preset base threshold and the structured task data. If the similarity score is lower than the switching threshold, the simple task will be switched to a complex task.

[0020] Secondly, embodiments of the present invention also provide an industrial Internet of Things (IoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response system, the system comprising: The structured task data acquisition module is used to acquire real-time data streams from industrial IoT terminal devices, and to perform structured processing on the real-time data streams to obtain structured task data. The task segmentation module is used to classify tasks based on the structured task data using a stage perceptron; wherein the tasks are classified as simple tasks or complex tasks. The final control command generation module is used to generate several candidate actions and a pre-execution candidate set for the simple task through an edge lightweight inference model, and determine the final control command; for the complex task, it generates the main action through a core inference model, and obtains the final control command by matching or directly generating the pre-execution candidate set. The decision response module is used to control the industrial IoT terminal device to perform decision response operations for the task through the final control command.

[0021] Thirdly, embodiments of the present invention also provide a terminal device, the terminal device including a memory, a processor, and an industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision response program stored in the memory and executable on the processor. When the processor executes the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision response program, it implements the steps of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision response method described in any of the above schemes.

[0022] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing an industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making response program. When the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making response program is executed by a processor, it implements the steps of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making response method described in any of the above schemes.

[0023] Beneficial Effects: This invention discloses a method, system, terminal device, and medium for dynamic hierarchical decision-making and response of virtual and real-world collaboration in the field of industrial IoT intelligent agents, relating to the field of intelligent control technology in the industrial IoT. The method first acquires the real-time data stream of the industrial IoT terminal device and performs structured processing on the real-time data stream to obtain structured task data. Then, based on the structured task data, the task is hierarchically classified using a stage sensor; wherein the task is classified as a simple task or a complex task. Next, for the simple task, several candidate actions and a pre-execution candidate set are generated using an edge-lightweight inference model, and the final control command is determined; for the complex task, a main action is generated using a core inference model, and the final control command is obtained by matching or directly generating the pre-execution candidate set. Finally, the final control command controls the industrial IoT terminal device to execute the decision-making and response operation for the task. This invention significantly shortens task response latency and solves the latency accumulation problem of traditional serial architectures through virtual-real collaboration and dynamic hierarchical mechanisms. Furthermore, by reusing control commands through the pre-execution candidate set, it effectively improves action execution efficiency and achieves synergistic optimization of real-time performance, resource efficiency, and security. Attached Figure Description

[0024] Figure 1 A flowchart illustrating a specific implementation of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in this embodiment of the invention.

[0025] Figure 2 This is a schematic diagram of the core architecture of the Industrial Internet of Things (IoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in an embodiment of the present invention.

[0026] Figure 3This is a flowchart illustrating the steps of obtaining real-time data streams from industrial IoT terminal devices in the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in this embodiment of the invention.

[0027] Figure 4 This is a flowchart illustrating the steps of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in this embodiment of the invention for structuring the real-time data stream.

[0028] Figure 5 This is a schematic diagram illustrating the steps of classifying tasks using a stage sensor in the Industrial Internet of Things (IIoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-response method provided in this embodiment of the invention.

[0029] Figure 6 This is a flowchart illustrating the steps of generating the final control command for a simple task in the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-response method provided in this embodiment of the invention.

[0030] Figure 7 This is a flowchart illustrating the steps involved in generating final control commands for a complex task in the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in this embodiment of the invention.

[0031] Figure 8 This is a schematic diagram of the industrial Internet of Things (IoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response device provided in this embodiment of the invention.

[0032] Figure 9 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation

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

[0034] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0035] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0036] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, "first control information" and "second control information" are only used to distinguish different control information and do not limit their order.

[0037] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.

[0038] It should also be understood that the term “and / or” as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0039] Industrial Internet of Things (IIoT) technology has been widely applied in several key areas such as real-time industrial control, energy network dispatching, and safety in high-risk operations. Its main function is to enable rapid response, accurate decision-making, and safe execution of tasks by terminal devices, thereby ensuring the continuity, efficiency, and reliability of industrial production. However, existing IIoT decision-response technologies still face many prominent problems in practical application scenarios.

[0040] Specifically, in smart factory production line control scenarios, abnormal data such as sudden temperature rises and vibration changes frequently occur during equipment operation. These tasks require rapid identification and response to prevent the fault from escalating. However, existing technologies employ a serial architecture of sensing, inference, and execution, where response latency increases linearly with the number of processing steps. Even for simple abnormal tasks like the one mentioned above, a complete inference and verification process is still required, hindering rapid handling. Furthermore, the lack of an effective action reuse mechanism means that recurring equipment anomalies necessitate re-executing inference and verification steps, wasting computational resources and time, further impacting response speed.

[0041] In dynamic energy network scheduling scenarios, power fluctuations in renewable energy equipment such as photovoltaic power plants are frequent, requiring timely handling to maintain regional power balance. Existing edge devices generally employ fixed scheduling strategies, which struggle to dynamically adapt to changes in task complexity. When power fluctuation tasks occur in concentrated bursts, a large number of speculative requests under high load conditions exacerbate system congestion, leading to degraded decision-making efficiency and hindering rapid regional power balance control. Furthermore, high communication latency during cross-device collaboration further impacts scheduling timeliness.

[0042] In high-risk operational safety scenarios, such as toxic gas leaks in chemical plants, rapid and reliable emergency response is crucial to prevent secondary accidents caused by misoperation. However, current technologies often operate with independent industrial protocol verification and decision-making engines, lacking real-time risk awareness. In high-risk scenarios, manual intervention for safety review is frequently required, leading to decision-making delays and the potential for human error to cause accidents. Furthermore, fixed task classification thresholds cannot be dynamically adjusted based on risk levels, making it difficult to balance speed and safety.

[0043] In addition to the scenario-specific issues mentioned above, existing technologies also suffer from common problems. Firstly, there is a bottleneck due to accumulated decision-making delays; traditional serial architectures result in excessively high task response latency, failing to meet the rapid processing requirements of industrial real-time control scenarios. Secondly, resource allocation is rigid; fixed scheduling strategies cannot adapt to dynamic changes in task complexity, easily leading to system congestion under high load. Thirdly, security mechanisms are fragmented; there is a lack of real-time security verification mechanisms deeply integrated with the decision-making process, resulting in insufficient risk prevention and control in high-risk scenarios. Fourthly, action execution efficiency is low; there is a lack of effective cross-scenario action reuse mechanisms, requiring repetitive tasks to repeatedly execute the complete processing flow, leading to a waste of computing resources.

[0044] Although some existing technologies attempt to optimize the decision-making process of the Industrial Internet of Things, none of them have effectively solved the problem of coordinating the specific issues and common defects of the above-mentioned scenarios. They cannot simultaneously achieve a balance between low latency, high resource utilization and high security, making it difficult to meet the increasingly complex application needs of industrial scenarios.

[0045] Figure 2 This is a schematic diagram of the core architecture of the Industrial Internet of Things (IIoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method provided in this embodiment of the invention. The architecture takes real-time data streams from IIoT terminal devices as input and includes a virtual-real collaborative response engine (with an adaptive inference mechanism at the algorithm layer and a resource scheduling engine deployed at the system layer), an IIoT platform, a decision optimization layer (integrating stage sensors and load-sensing schedulers), integrated interfaces, and a device collaboration network, adapting to application scenarios such as smart factories and energy IoT. In terms of process, the system divides tasks into early simple tasks and later complex tasks. Simple tasks generate several candidate actions through aggressive action prediction, while complex tasks achieve inference and action synchronization through verification-based parallel execution. Simultaneously, it configures action cache reuse (single task memory usage <200B), inference-level scheduling (load shaving based on the real-time engine), request-to-request scheduling (prioritizing short tasks based on a short job priority mechanism), and a dynamic switching module (threshold triggering), forming a complete methodological framework of data input, hierarchical processing, scheduling optimization, and action execution.

[0046] This embodiment provides an industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method, such as... Figure 1 As shown, the specific steps include the following: Step S100: Obtain the real-time data stream of the industrial IoT terminal device, and perform structured processing on the real-time data stream to obtain structured task data.

[0047] In this embodiment, the real-time data stream of the industrial IoT terminal device is a collection of various raw data generated during the operation of the terminal device in an industrial scenario. Specifically, it can be temperature, vibration, and current data collected by sensors, equipment status signals transmitted by the controller, and operation command feedback. Structured processing is the process of transforming heterogeneous, non-standardized real-time data streams into a unified format that can be directly recognized by the inference model. This is achieved through industrial protocol parsing, key feature extraction, and standardized operations. Structured task data is the output data after structured processing, used to clearly and accurately express the core content and constraints of the task to be processed. Specifically, it can be a feature vector containing key indicators such as decision time limits, equipment risk levels, and data dimensionality.

[0048] Acquiring and structuring real-time data streams is a fundamental step in the entire decision-making and response process. By collecting real-time operational data from terminal devices, device status and task requirements are captured. Structured processing eliminates format differences and redundant information from multi-source, heterogeneous data, transforming the data into a standardized form suitable for subsequent hierarchical and inference processes. This operation provides high-quality, uniformly formatted input data for subsequent task hierarchies and action generation, avoiding decision delays or misjudgments caused by chaotic or low-quality data formats, thus providing a data foundation for low-latency, high-accuracy responses throughout the overall process.

[0049] In one implementation, such as Figure 3 As shown, the acquisition of real-time data streams from industrial IoT terminal devices specifically includes the following steps: Step S110: Collect real-time operating data through the sensors and controllers of the industrial IoT terminal device; Step S120: Perform noise reduction preprocessing on the collected real-time running data to obtain the real-time data stream.

[0050] In this embodiment, real-time data streams from industrial IoT terminal devices are obtained through data acquisition and noise reduction preprocessing.

[0051] Specifically, data acquisition is achieved through sensors and controllers integrated into industrial IoT terminal devices. Sensors are components used to sense the operating status of equipment and environmental parameters; these can be temperature sensors, vibration sensors, current sensors, pressure sensors, etc., capturing physical quantities such as temperature changes, vibration frequency, current magnitude, and operating pressure in real time. Controllers are components used to transmit equipment control signals and provide feedback on operating status; these can be PLC controllers, microcontrollers, embedded controllers, etc., outputting data such as equipment operating status and operational feedback in real time. Through these two types of components, various raw data generated during equipment operation are comprehensively collected, including temperature values, vibration waveform data, current curve data, equipment on / off status, and fault alarm signals.

[0052] Noise reduction preprocessing is an operation that cleanses the raw, real-time operational data to eliminate noise interference and outliers. The raw data may contain invalid information such as random noise and abnormal peaks due to factors such as sensor accuracy limitations, transmission link interference, and momentary equipment failures. Specific processing methods include filtering algorithms, outlier removal, and data smoothing. For example, Kalman filtering can be used to remove random fluctuation noise from temperature sensor data, and moving averages can be used to smooth vibration data, ensuring data stability and reliability.

[0053] Through the collaborative acquisition of data by sensors and controllers, the comprehensiveness and authenticity of the real-time data stream are ensured, providing a complete data foundation for subsequent structured processing and task classification, and avoiding decision-making biases caused by missing data. Furthermore, noise reduction preprocessing effectively eliminates invalid interference information, improving data quality and ensuring that subsequent data-driven complexity calculations and action generation can be carried out based on accurate data, thus guaranteeing the accuracy and reliability of the entire decision-making and response process.

[0054] In one implementation, such as Figure 4 As shown, the step of structuring the real-time data stream to obtain structured task data specifically includes the following steps: Step S130: Parse the real-time data stream using an industrial protocol and extract key feature vectors; Step S140: Perform feature standardization processing on the key feature vector to obtain structured task data; wherein, the structured task data is used to express the content of the task to be processed.

[0055] In this embodiment, structured task data is obtained by performing two steps: industrial protocol parsing and feature standardization. The mathematical logic formula for input preprocessing is as follows:

[0056] in, This represents the data vector after parsing and processing. This is an industrial protocol parsing function used to decode and convert the merged data. This refers to the raw data vector collected by the sensor, containing physical quantities such as temperature, vibration, and current. Control command data transmitted to the device controller. This indicates a data fusion operation, which integrates sensor data and control command data into a unified input data format according to preset rules, providing a complete data source for subsequent analysis.

[0057] Industrial protocol parsing is a process of decoding and extracting key information from fused sensor data and controller command data based on standard protocols for data transmission between devices in industrial scenarios. Specific industrial protocols can include common industrial communication protocols such as Modbus / TCP, Profinet, and OPC UA, each with different data transmission formats and encoding rules. During parsing, the system extracts key information related to task processing based on the industrial protocol type of the data stream, forming a key feature vector. This key feature vector is a vector-like data containing core task constraints and requirements, specifically a multi-dimensional vector composed of key indicators such as decision timeframe, equipment risk level, data dimension, current operating parameters, and target parameters.

[0058] Feature standardization is an operation that applies a uniform scale to the extracted key feature vectors. Its purpose is to eliminate differences in magnitude between different features and avoid deviations in subsequent model inference and complexity calculations caused by varying feature scales. The specific standardization formula used is as follows:

[0059] in, This represents the standardized feature vector. This represents the original key feature vector obtained after protocol parsing. This represents the mean of all elements in the original key feature vector. This represents the standard deviation of all elements in the original key feature vector. Calculation using this formula can transform feature indicators of different magnitudes into standardized data with a mean of 0 and a variance of 1, ensuring that each feature has equal weight and influence in subsequent calculations.

[0060] Through data fusion and protocol parsing functions, integrated processing of sensor data and control commands was achieved, ensuring the integrity and consistency of the data source. Specifically, industrial protocol parsing decodes heterogeneous real-time data streams, accurately extracting key feature vectors from the chaotic raw data, focusing on core task information, removing redundant data, and improving data processing efficiency. Feature standardization eliminates scale differences between features, providing standardized input data for subsequent task complexity calculations and model inference, ensuring the accuracy and fairness of calculation results, preventing a single feature from dominating the calculation process due to excessive magnitude, and guaranteeing the rationality of task classification and action generation.

[0061] Step S200: Based on the structured task data, the tasks are classified using a stage perceptron; wherein the tasks are classified as simple tasks or complex tasks.

[0062] In this embodiment, the stage perceptron is a functional component used to dynamically identify and classify task complexity. Specifically, it can be an inference module that integrates complexity calculation algorithms, dynamic threshold adjustment logic, and classification judgment rules, enabling automated differentiation of task types based on structured task data. Task classification is the process of dividing tasks into different processing paths according to their complexity, constraints, and safety requirements. Specifically, in this embodiment, tasks are divided into two categories: simple tasks and complex tasks. Simple tasks in this embodiment are defined as tasks involving aggressive action prediction, which are early-stage tasks with complexity below the dynamic threshold, low safety risk, and no need for complex inference. Examples include routine equipment parameter calibration and adjustments for minor abnormal fluctuations. Complex tasks in this embodiment are defined as verification-based parallel execution tasks, which are later-stage tasks with complexity higher than or equal to the dynamic threshold, high safety risk, or requiring multi-dimensional constraint considerations. Examples include large-scale power fluctuation control in new energy power plants and fault handling in high-risk scenarios.

[0063] This system, based on structured task data and using a stage-based perceptron for hierarchical processing, addresses the fixed processing patterns prevalent in traditional Industrial Internet of Things (IIoT). By dynamically calculating task complexity and combining it with dynamic thresholds for classification, different task types are matched with appropriate processing resources and workflows. Simple tasks in the early stages do not require the computational resources of high-precision models and can be responded to quickly through lightweight paths, while complex tasks in the later stages rely on high-precision models to ensure processing accuracy and security. This hierarchical processing achieves precise resource allocation, preventing simple tasks from consuming excessive computing power or complex tasks from experiencing processing delays due to insufficient resources, significantly improving the overall system's decision-making response efficiency and resource utilization effectiveness.

[0064] In one implementation, such as Figure 5 As shown, the step of classifying tasks based on the structured task data using a stage perceptron specifically includes the following steps: Step S210: Calculate the task complexity based on the structured task data; Step S220: Compare the task complexity with the dynamic threshold; Step S230: If the task complexity is lower than the dynamic threshold, the task is classified as a simple task; otherwise, the task is classified as a complex task.

[0065] In this embodiment, tasks are classified based on structured task data using a stage perceptron, which includes three steps: calculating task complexity, comparing it with a dynamic threshold, and determining the task type.

[0066] First, calculating task complexity is the primary function of the stage perceptron. This is achieved through a comprehensive assessment using multi-dimensional metrics derived from structured task data. The specific calculation formula used is as follows:

[0067] in, This represents the task complexity; a higher value indicates a more complex task. It is the L2 norm of the structured task data after standardization, reflecting the comprehensive strength and distribution range of the data features; This refers to the decision timeframe for a task, which is the maximum time threshold required to complete a response. The shorter the decision timeframe, the higher the relative complexity of the task. This represents the equipment risk level, with a value ranging from [0,1]. A higher value indicates a higher safety risk during equipment operation, and correspondingly, a greater weight in task complexity. This function... It is a pre-defined multi-dimensional indicator fusion algorithm, which can be weighted summation, nonlinear mapping, etc., and can dynamically adjust the weight of each indicator according to the needs of industrial scenarios.

[0068] The calculated task complexity is compared with a dynamic threshold, which is a criterion that is dynamically adjusted based on the equipment's risk level. The dynamic threshold changes with the equipment's risk level; the higher the risk level, the larger the dynamic threshold. Finally, the task type is determined based on the comparison results. If the task complexity is lower than the dynamic threshold, the task is classified as a simple task; if the task complexity is higher than or equal to the dynamic threshold, the task is classified as a complex task.

[0069] By integrating multiple dimensions of indicators to calculate task complexity, a more comprehensive reflection of the actual complexity of the task can be achieved compared to judging it with a single indicator, avoiding classification bias caused by one-sided judgment. In particular, the introduction of dynamic thresholds allows the classification standard to adapt to different equipment risk scenarios, ensuring accurate identification of complex tasks in high-risk scenarios and rapid screening of simple tasks in low-risk scenarios. This provides an accurate basis for subsequent path-based processing, further improving the adaptability and decision-making efficiency of the entire system.

[0070] In one implementation, the structured task data includes at least decision timeframe, equipment risk level, and data dimensionality. The calculation of task complexity based on the structured task data specifically includes the following steps: Step S211: Based on the decision time limit, equipment risk level, and data dimension in the structured task data, dynamically calculate the task complexity.

[0071] In this embodiment, the structured task data includes at least three indicators: decision time limit, equipment risk level, and data dimension. These three indicators together form the basis for task complexity calculation. The decision time limit refers to the maximum time limit for the task to complete the response. Specifically, it can be a value set according to the real-time requirements of the industrial scenario, such as 100ms, 500ms, or 1s. For example, the decision time limit for handling production line faults in a smart factory is usually set to within 200ms, while the decision time limit for calibrating parameters of ordinary equipment can be set to 1s. The equipment risk level is an indicator reflecting the safety risk of equipment operation, with a value range of [0,1]. It is specifically set according to factors such as the importance of the equipment in the industrial system and the hazardousness of the operating environment. For example, the risk level of a core reaction device in a chemical plant can be set to 0.9, and the risk level of auxiliary conveying equipment can be set to 0.3. The data dimension refers to the number of key features contained in the structured task data. Specifically, it can be 5-dimensional, 8-dimensional, or 10-dimensional. For example, the task data dimension containing only two indicators, temperature and current, is 2, while the task data dimension containing five indicators, temperature, vibration, pressure, flow rate, and voltage, is 5.

[0072] Task complexity is dynamically calculated based on the aforementioned indicators, specifically through a pre-defined fusion algorithm. This algorithm assigns a corresponding weight to each indicator according to the actual needs of the industrial scenario, with equipment risk level typically having the highest weight, followed by decision timeframe, and then data dimensionality. For example, a weighted summation method can be used to calculate task complexity, with weights set for decision timeframe, equipment risk level, and data dimensionality, respectively. Through weighted summation, the three different dimensions of indicators can be merged into a single complexity value, achieving a quantitative assessment of task complexity.

[0073] By clarifying the core basis for task complexity calculation, the process becomes more operational and targeted. Through the integrated calculation of three key indicators—decision timeframe, equipment risk level, and data dimensionality—the time constraints, security risks, and data complexity of the task are comprehensively considered. This avoids the bias caused by calculating a single indicator, ensuring that the task complexity assessment results accurately reflect the actual processing difficulty of the task, and providing more accurate support for subsequent hierarchical decision-making and path selection.

[0074] In one implementation, the dynamic threshold is calculated from a preset base threshold and the device risk level in the structured task data, wherein the device risk level is positively correlated with the dynamic threshold. In this embodiment, the dynamic threshold is the criterion for task classification. Its value is calculated jointly by a preset basic threshold and the equipment risk level in the structured task data. The basic threshold is the initial judgment benchmark preset by the system. Specifically, it can be a fixed value determined based on industrial scenario statistics and historical task processing experience. For example, by analyzing the processing of industrial tasks, the basic threshold can be set to 0.5. The equipment risk level is an indicator in the structured task data, with a value range of [0,1]. It is positively correlated with the dynamic threshold, that is, the higher the equipment risk level, the larger the value of the dynamic threshold, indicating that the task needs to reach a lower complexity to be judged as a simple task.

[0075] The specific formula for calculating the dynamic threshold is as follows:

[0076] in, Indicates a dynamic threshold. Indicates the basic threshold. Represents the equipment risk level. This is a natural constant. A nonlinear mapping of equipment risk level is applied using an exponential function, allowing changes in equipment risk level to reasonably influence the adjustment of the dynamic threshold. Specifically, when the equipment risk level... A value of 0 indicates that it is a low-risk device. Dynamic threshold At this point, the grading standards are lenient, and more tasks will be classified as simple tasks. When the equipment risk level... A value of 1 indicates that it is a high-risk device. Dynamic threshold At this point, the classification criteria are strict, and only tasks with extremely low complexity will be judged as simple tasks.

[0077] By dynamically adjusting the risk level thresholds based on equipment risk grades, a risk-adaptive risk grading mechanism is achieved. In high-risk equipment scenarios, strict grading standards ensure that most tasks are processed through complex task paths with high precision and safety, avoiding safety incidents caused by potential action deviations in simple task paths. In low-risk equipment scenarios, lenient grading standards allow more tasks to be processed through fast and efficient simple task paths, improving overall response efficiency. This dynamic adjustment mechanism allows the system to flexibly adapt the grading strategy according to the equipment risk status, balancing safety and efficiency requirements in different scenarios.

[0078] In one implementation, after classifying the tasks based on the structured task data using a stage perceptron, the process further includes the following steps: Step S240: Based on the current load and the expected benefits of the task, select the tasks to be allowed through preset filtering rules; wherein, the tasks to be allowed are those that are allowed to generate actions, and the expected benefits of the tasks are determined by a comprehensive assessment of time saved by action overlap, hit probability, transmission overhead and computational overhead.

[0079] In this embodiment, after task classification is completed through a stage perceptron based on structured task data, load perception screening is performed to determine the tasks that are allowed to generate actions. Current load refers to the current computing resource usage of the decision-response system, specifically assessed through a comprehensive evaluation of indicators such as CPU utilization, memory usage, task queue length, and remaining computing power at edge nodes. For example, a system with 60% CPU utilization, 55% memory usage, and a task queue length of 8 can be classified as having a medium load. Expected task benefit is a prediction of the benefits that can be obtained after task execution. Its core is to measure the difference between the time savings and resource optimization benefits brought by task execution and the overhead incurred during execution. Specifically, it is determined through a comprehensive assessment of action overlap time savings, hit probability, transmission overhead, and computational overhead. The corresponding calculation formula is:

[0080] in, This represents the expected return on the task. A positive value indicates that the task execution has a positive return, while a negative value indicates that the return is less than the cost. This indicates the time saved by overlapping actions, specifically the time saved in instruction generation and execution when the task's actions overlap with existing actions in the cache. This represents the cache hit probability, that is, the probability that the action of this task will be selected from the pre-execution candidate set. This represents the transmission link loss coefficient, reflecting signal attenuation and delay loss during data transmission. This indicates data transmission latency, specifically the time it takes for task data to be transmitted between nodes. This represents computational processing latency, specifically the time consumed in generating task actions and reasoning.

[0081] The preset filtering rule is a revenue threshold set by the system based on the current load. When the expected revenue of a task is higher than this threshold, the task is approved and allowed to proceed to the subsequent action generation stage. When the expected revenue of a task is lower than this threshold, it is not approved and is placed in the task queue to wait or discarded according to system policies. For example, in a high-load scenario with CPU utilization above 85%, the revenue threshold is set to 0.8, and only high-value tasks with expected revenue higher than 0.8 are approved. In a low-load scenario with CPU utilization below 30%, the revenue threshold is set to 0.2, allowing more low-value tasks to be approved.

[0082] In addition, the preset filtering rules can also include load constraint logic, and the expression that needs to satisfy the load constraint condition is:

[0083] in, This is the load ratio factor, which is configured according to the specific industrial scenario. The current system load can be a normalized value calculated by weighting indicators such as CPU utilization and memory usage.

[0084] A task is only allowed to proceed to the subsequent action generation stage if it simultaneously meets both the expected return exceeding the threshold and the load constraint condition. If either condition is not met, the task is temporarily not allowed to proceed and is placed in the task queue to wait, or low-value tasks are discarded according to system policy.

[0085] The load-aware filtering mechanism, by combining revenue calculation with load constraints, prevents the influx of low-value tasks under high load scenarios from causing system congestion, ensuring that high-value tasks receive priority computing resources and improving resource utilization efficiency. Simultaneously, the comprehensive calculation of expected task revenue allows the system to accurately identify high-value tasks, avoiding resource waste on ineffective tasks where the revenue is less than the cost. This mechanism enables the system to maintain efficient and stable operation under different load conditions, and is particularly suitable for the characteristics of large task volume fluctuations in industrial scenarios, ensuring the system's robustness and practicality.

[0086] Step S300: For the simple task, generate several candidate actions and a pre-execution candidate set through the edge lightweight inference model, and determine the final control command; for the complex task, generate the main action through the core inference model, and obtain the final control command by matching or directly generating the pre-execution candidate set.

[0087] In this embodiment, the lightweight edge inference model is a simplified inference model deployed on industrial IoT edge nodes or local devices. It is obtained through optimization methods such as model structure simplification, redundant layer pruning, and parameter quantization. Specifically, it can be a lightweight neural network model with fewer than 10% of the original model parameters and an inference speed improvement of more than 5 times, adapting to the computing power and energy consumption constraints of edge devices. Candidate actions are multiple alternative operation intentions generated by the lightweight edge inference model for simple task requirements. Specifically, they can be explicit action descriptions such as "reduce motor power to 30Hz", "close valve A and open backup valve B", and "start the equipment cooling system". Each candidate action corresponds to a potential solution for the task. The pre-execution candidate set is a set of associated data formed after the candidate actions are simulated and executed. Specifically, it includes the candidate action itself, the corresponding simulation control command, and the simulation results. It is stored using a time-series database label and associated with the device lifecycle timeliness.

[0088] The core inference model is a high-precision inference model with a complete inference architecture capable of handling multi-dimensional constraints. Deployed in high-performance devices in the cloud or at the edge nodes of the Industrial Internet of Things (IIoT), it can specifically be a deep learning model capable of fusing multi-source data and considering complex scenario constraints, ensuring the accuracy of generating complex task actions. The main action is a single, definite operational intent generated by the core inference model for a complex task. Specifically, it can be a precise action description such as "adjust the tilt angle of photovoltaic modules within the area by 15° to match changes in sunlight" or "coordinate the flow rate of three pump groups to ensure stable pipeline pressure." The final control command is a concrete signal that drives the IIoT terminal device to perform specific operations. Specifically, it can be a standardized control signal containing execution parameters, timing requirements, and industrial protocol formats.

[0089] By employing a path-splitting and pre-execution caching reuse mechanism, simple tasks can quickly generate candidate actions using a lightweight edge model. After pre-execution, these actions are cached to form reusable resources, shortening the instruction generation time for the current task and providing a foundation for reuse in subsequent tasks. Furthermore, complex tasks can generate high-precision main actions through the core model, and parallel querying of the pre-execution candidate set enables control instruction reuse. If no candidate is found, the instruction is directly generated, balancing accuracy and efficiency. Based on this path-splitting mechanism, the overall time for control instruction generation is significantly reduced. The pre-execution process verifies the feasibility of actions in advance, avoiding the execution of invalid or high-risk actions. Simultaneously, path-splitting allows for more rational resource allocation, further improving the system's response speed and security.

[0090] In one implementation, the lightweight edge inference model is an inference model deployed at the edge node of an industrial IoT system or locally, obtained through model structure simplification and parameter pruning optimization, such as... Figure 6As shown, for the simple task, generating several candidate actions and a pre-execution candidate set through an edge lightweight inference model, and determining the final control command, specifically includes the following steps: Step S311: Based on the structured task data corresponding to the simple task, a preset number of candidate actions are generated using an edge lightweight inference model; wherein, the candidate actions are used to respond to the requirements of the task; Step S312: In the preset simulation environment, perform pre-execution operations on all candidate actions to generate a corresponding number of control commands and simulation results; Step S313: Cache the candidate actions, corresponding control instructions and simulation results to obtain a pre-execution candidate set in the cache; Step S314: Based on a preset scoring mechanism, determine the final control command from the candidate actions and corresponding control commands.

[0091] In this embodiment, the lightweight edge inference model is a core model specifically adapted for simple task processing. Deployed at industrial IoT edge nodes or local devices, it is obtained through optimization methods such as model structure simplification, redundant network layer pruning, and parameter quantization and compression. For example, a deep learning model with 10 million parameters is pruned into a lightweight model with 1 million parameters, while maintaining the inference accuracy required for simple task processing. For simple tasks, this model generates several candidate actions and a pre-execution candidate set, and determines the final control command, specifically including four steps.

[0092] First, candidate actions are generated. Based on structured task data corresponding to simple tasks, the edge lightweight inference model outputs a preset number of candidate actions according to task requirements. This preset number can be flexibly adjusted according to the needs of the industrial scenario, specifically 3, 5, or 8. Candidate actions are specific operational intentions proposed for the core requirements of the task. For example, for a simple task of overheating equipment, candidate actions such as "reduce motor power by 10Hz," "turn on the backup cooling fan," and "reduce equipment operating load by 50%" are generated. Each action points to a potential solution to the task. Specifically, the mathematical logic formula for generating candidate actions, i.e., the aggressive action prediction formula, is as follows:

[0093] in, Indicates the generated A set of candidate actions, This represents the sequence number of the candidate action. The preset number of candidate actions. The term "edge-weighted lightweight inference model" refers to a specialized model that has undergone structural simplification and parameter quantization. This represents the standardized feature vector after structured processing. It represents the contextual characteristics of the task, including auxiliary information such as task type and historical operating status of the device; The representative feature fusion operation integrates standardized data with contextual features as model input. Based on structured task data corresponding to simple tasks, the model can quickly output a preset number of candidate actions using the above formula. These candidate actions are used to respond to task requirements.

[0094] Secondly, pre-execution operations are performed, executing pre-execution operations one by one on all candidate actions within a pre-set simulation environment. The simulation environment is a virtual environment built based on the physical model and operating rules of the industrial field equipment, capable of accurately reproducing the equipment's operating state and action execution effects. Specifically, it can be a device simulation model built using MATLAB / Simulink, or a virtual device scenario built based on digital twin technology. During pre-execution, the system simulates the execution process of the candidate actions, generating corresponding control commands and simulation results. The control commands are concrete execution signals, including execution parameters, timing requirements, and industrial protocol formats. The simulation results are the state data of the equipment after the simulated execution, such as changes in parameters like temperature, current, and pressure after the action is executed. Specifically, the mathematical logic formula for action pre-execution is:

[0095] This indicates that all candidate actions will be pre-executed via the pre-execution service.

[0096] Next, a pre-execution candidate set is constructed, associating each candidate action with its corresponding control command and simulation results for storage. The stored procedure can use a time-series database tag storage method, adding tags such as device ID, task type, action type, and generation time to each data entry for easy subsequent quick querying and reuse. Simultaneously, it is associated with the lifecycle validity of the industrial IoT terminal device to ensure the effectiveness of the cached data.

[0097] Finally, the final control command is determined. Candidate actions and their corresponding control commands are screened based on a preset scoring mechanism. The scoring mechanism uses the fit between the candidate action and the task objective as the indicator. Specifically, the score is calculated through semantic similarity evaluation, simulation result fit analysis, and other methods. Finally, the control command corresponding to the candidate action with the highest score is selected as the final control command for the simple task.

[0098] The edge-lightweight model significantly reduces inference latency for simple tasks, adapts to the computing power constraints of edge nodes and local devices, and avoids simple tasks consuming high-precision cloud model resources. Specifically, through the mathematical logic formula of aggressive action prediction, it achieves deep fusion of standardized data and contextual features, enabling the edge-lightweight model to quickly generate several candidate actions that accurately meet the task requirements, avoiding the generation of invalid actions and improving action generation efficiency. Furthermore, pre-execution operations verify the feasibility and execution effect of candidate actions in advance, eliminating invalid and high-risk actions and improving the security of subsequent actual execution. In addition, the construction of the pre-execution candidate set provides a foundation for cache reuse of subsequent tasks. Subsequent identical or similar tasks can directly reuse control instructions in the cache without repeated generation and pre-execution, significantly shortening response latency.

[0099] In one implementation, caching the candidate actions, corresponding control instructions, and simulation results to obtain a pre-execution candidate set in the cache specifically includes the following steps: Step S3131: The candidate actions, corresponding control instructions, and simulation results are associated and stored, and associated with the lifecycle timeliness of the industrial IoT terminal device to form a pre-execution candidate set; wherein, the pre-execution candidate set is stored using a time-series database tag.

[0100] In this embodiment, a pre-execution candidate set is obtained by caching candidate actions, corresponding control instructions, and simulation results through an associated storage mechanism and lifecycle timeliness association. Associated storage is a storage method that binds each candidate action to its corresponding simulation control instruction and simulation result in a one-to-one correspondence, ensuring that the logical relationship between the three is not broken, so that instructions and simulation data can be retrieved synchronously when the action is queried subsequently. Specifically, the mathematical expression of the cache structure is:

[0101] in, Indicates cached content. Indicates the actions in the cache. This indicates the content corresponding to the cached action, including the operation instructions and simulation results. Indicates the expiration time of cached data.

[0102] The lifecycle validity period of industrial IoT terminal equipment refers to the effective time period from the equipment's formal operation to its retirement and scrapping. It is specifically determined based on factors such as the equipment's design lifespan, maintenance cycle, and technology update cycle. For example, if a certain model of motor has a design lifespan of 10 years, its corresponding lifecycle validity period is 10 years. The expiration time of cached data is calculated by associating it with the lifecycle validity period, using the following formula:

[0103] in, This represents the expiration time of cached data. Represents the current time. The timeliness coefficient represents the efficiency factor, which is determined based on specific industrial needs. Represents device ID, This represents the lifecycle validity period corresponding to the device ID. Once expired, the data is automatically removed from the pre-execution candidate set.

[0104] The pre-execution candidate set adopts a time-series database tag storage method. A time-series database is a database specifically designed for storing time-series data, capable of efficiently handling data writing and querying operations with timestamps. During storage, multi-dimensional tags are added to each associated data entry, specifically including device ID, task type (e.g., temperature regulation, power control), action type (e.g., power reduction, device startup), generation timestamp, and expiration timestamp. In this embodiment, an example tag combination stored in the time-series database is "Device ID: M1001, Task Type: Temperature Regulation, Action Type: Power Reduction, Generation Time: 2025-01-01 10:30:00, Expiration Time: 2030-01-01 10:30:00".

[0105] Associative storage ensures the logical consistency of actions, instructions, and simulation results, preventing data matching errors during subsequent reuse. Furthermore, the lifecycle-based expiration mechanism establishes a cache invalidation mechanism to prevent the use of expired or outdated cached data from causing erroneous actions by the device, which is particularly suitable for the rapid technological iteration of industrial equipment. In addition, time-series database tag storage significantly improves the efficiency of cache queries; tag filtering allows for quick location of the cached data corresponding to the target action, providing efficient data support for the parallel verification and reuse of complex tasks.

[0106] In one implementation, determining the final control command from the candidate actions and corresponding control commands based on a preset scoring mechanism specifically includes the following steps: Step S3141: Based on the candidate action and the goal of the task, obtain a similarity score through semantic similarity evaluation; Step S3142: Select the control instruction corresponding to the candidate action with the highest similarity score as the final control instruction.

[0107] In this embodiment, the final control command is determined from candidate actions and their corresponding control commands based on a preset scoring mechanism. The core of this process is to select the optimal solution through semantic similarity evaluation. Semantic similarity evaluation is the process of measuring the semantic fit between candidate actions and the task objective. Specifically, a deep learning model is used to extract, map, and compare the semantic features of candidate actions and the task objective. The corresponding calculation formula is as follows:

[0108] in, Representing the The similarity score for each candidate action ranges from [0,1]. The closer the value is to 1, the higher the fit between the candidate action and the task objective. This represents a multilayer perceptron model used for nonlinear mapping of semantic similarity features, transforming raw similarity values ​​into standardized scoring results to ensure the discriminative power and reasonableness of the scores. Representing the Each candidate action is a specific operational intent representation generated by the edge-lightweight inference model. The core objective of a simple task is the clearly defined task requirement in the structured task data, such as "controlling the equipment temperature within the range of 60℃±5℃" or "ensuring that the motor current is stable between 10A and 12A". This represents a semantic similarity calculation function, which can specifically be a commonly used similarity calculation method such as cosine similarity or Euclidean distance, used to measure semantic similarity. and The degree of similarity between semantic feature vectors.

[0109] In the execution process of the scoring mechanism, firstly through The function calculates the original semantic similarity between each candidate action and the task target. Then, the original similarity values ​​are input into an MLP model for non-linear mapping to obtain a standardized similarity score. Finally, the scores of all candidate actions are ranked, and the control instruction corresponding to the candidate action with the highest similarity score is selected as the final control instruction for the simple task. For example, if candidate action A has a score of 0.92, candidate action B has a score of 0.78, and candidate action C has a score of 0.85, then the control instruction corresponding to candidate action A is selected as the final control instruction.

[0110] Semantic similarity assessment delves into the intrinsic relationship between candidate actions and task objectives. Compared to simple keyword matching, it can more accurately determine whether an action truly meets task requirements. The non-linear mapping of the MLP model makes the scoring results more discriminative, avoiding the problem of difficulty in filtering when multiple candidate actions are close in similarity. Selecting the instruction corresponding to the action with the highest score ensures that the final executed action is the current optimal solution, maximizing the fulfillment of the task objective and improving the accuracy and effectiveness of responses to simple tasks.

[0111] In one implementation, the core inference model is a high-precision inference model with a complete inference architecture for handling complex tasks, deployed in high-performance devices in the cloud or industrial IoT edge nodes, such as... Figure 7As shown, for the complex task, the main action is generated through the core inference model, and the final control command is obtained by matching the pre-execution candidate set or by direct generation, specifically including the following steps: Step S331: Based on the structured task data corresponding to the complex task, generate the main action through the core reasoning model; Step S332: Verify whether the main action exists in the pre-execution candidate set; Step S333: If it exists, then the control instruction corresponding to the main action in the pre-execution candidate set shall be the final control instruction; Step S334: If it does not exist, then generate the final control command based on the main action.

[0112] In this embodiment, the core inference model is a high-precision inference model with a complete inference architecture for handling complex tasks. It is deployed in high-performance devices in the cloud or industrial IoT edge nodes. Specifically, it can be a deep learning model capable of fusing multi-source data and considering complex scenario constraints to ensure the accuracy of complex task action generation. For complex tasks, the model generates the main action and generates the final control command by matching a pre-execution candidate set or directly. This process includes three steps and deeply integrates the mathematical logic of verification-based parallel execution.

[0113] First, the main action is generated, and its mathematical logic formula is as follows:

[0114] in, This represents the inference timestamp, recording the moment when the core model completes inference, used for timing alignment in subsequent processes. This represents the single active action generated, which is the core solution for complex tasks. Representing the core reasoning model, it possesses a complete reasoning layer and constraint optimization module. This represents the standardized feature vector after structured processing. Multi-dimensional contextual features representing complex tasks include information such as device risk level, multi-device collaborative constraints, and task priority. The representative feature fusion operation integrates standardized data with multi-dimensional contextual features, providing comprehensive input for high-precision inference. Based on structured task data corresponding to complex tasks, this formula allows the core model to generate a single, definite primary action by comprehensively considering multi-dimensional constraints, which can then serve as the basis for execution.

[0115] Subsequently, the mathematical logic formula for verifying cache matching is as follows:

[0116]

[0117] in, The main action representing the generation of the core model. This represents the set of all candidate actions stored in the pre-execution candidate set. Represents the set membership determination operation. This represents the operation when the cache is hit, i.e., reusing the control instructions corresponding to the main action. This represents the operation when the cache is not hit, i.e., directly generating control instructions based on the main action. After generating the main action, the system will query the pre-execution candidate set in parallel, and quickly determine whether the main action exists in the cache using this logical formula. If the query result shows that the main action exists in the pre-execution candidate set, and the corresponding control instruction and simulation results meet the constraints of the complex task, then the control instruction is directly reused as the final control instruction. If no matching main action is found, or the cached data does not meet the constraints, the system proceeds to the next step of directly generating control instructions.

[0118] Direct control instruction generation refers to generating the final control instruction directly based on the active action when a cache miss occurs. The generation process requires consideration of the precision requirements of complex tasks, and clarification of the control instruction's execution parameters, timing logic, industry protocol format, and security verification rules.

[0119] The core mathematical logic of verification-based parallel execution ensures the accuracy of complex task action generation through core inference, while multi-dimensional feature fusion allows the main action to adapt to multiple constraints in complex scenarios. Furthermore, through parallel decision logic, core model inference and cache verification are performed synchronously, avoiding latency caused by serial processing. This eliminates the need to regenerate instructions for recurring complex task actions, significantly reducing response latency. The direct generation mechanism in case of a miss ensures a closed-loop process, avoiding task blocking caused by cache dependencies, and balancing the processing accuracy, efficiency, and reliability of complex tasks.

[0120] In one implementation, before generating the main action based on the structured task data corresponding to the complex task through the core reasoning model, the following steps are further included: Step S320: Based on the computing power demand vector of the complex task, the task is dynamically assigned to the edge node through a distributed soft bus, and the computing resources of the edge node are allocated first to provide computing power; wherein, the distributed soft bus realizes low-latency collaboration between edge devices through a network topology distance optimization mechanism.

[0121] In this embodiment, the computational power requirement vector for complex tasks is a quantitative description of the computational resources required during task inference, specifically including indicators such as computational load, memory requirements, computational accuracy requirements, and parallel computing support requirements. The distributed soft bus is the core architecture for realizing low-latency collaborative communication and resource scheduling between industrial IoT edge nodes. For the OpenHarmony integration interface of the HarmonyOS system, its coupling logic with the scheduling mechanism is implemented through the following pseudocode: def on_data_received(sensor_data): # Computational complexity based on industrial protocol parsing complexity = calc_task_complexity(sensor_data) if complexity < β_threshold: # Trigger lightweight prediction at the edge (suitable for simple tasks) launch_aggressive_speculation() else: # Dispatch verification tasks via soft bus (adapting to complex tasks) schedule_via_OH_distributed_bus() In the pseudocode above, the `on_data_received` function is the core entry point for data reception and task assignment. When sensor data is received, the `calc_task_complexity` function first calculates the task complexity based on the industrial protocol parsing result, and then compares it with the dynamic threshold `β_threshold`. If the complexity of a complex task exceeds the threshold, the `schedule_via_OH_distributed_bus` function is triggered, and the task assignment is completed through the OpenHarmony distributed soft bus, ensuring that complex tasks are accurately connected to the computing resources of edge nodes.

[0122] The low-latency collaboration of distributed soft buses relies on a network topology distance optimization mechanism, the mathematical formula of which is:

[0123] in, Represents the communication latency between nodes. This represents the optimization coefficient, and its value range is dynamically adjusted according to the network environment. Represents the communication bandwidth of the distributed soft bus. This represents the network topology distance between two nodes, which is the number of hops or physical distance mapping value of the nodes in the network topology structure. The core logic of this formula is that the closer the network topology distance, the lower the communication latency and the higher the priority of task assignment. It accurately quantifies the impact of topology distance on latency through an exponential decay model, ensuring the low-latency characteristics of collaboration between edge nodes.

[0124] The complete execution process of dynamic computing power allocation first involves parsing the computing power demand vector of a complex task to clarify its specific requirements for computing resources. Then, a distributed soft bus scans all available edge nodes to obtain information such as the current load, remaining computing power, and network topology distance for each node. Finally, based on the computing power demand vector and node information, combined with the scheduling logic of the pseudocode and the network topology distance optimization formula, the inference computing tasks of complex tasks are allocated to the optimal edge nodes according to the principles of prioritizing those with closer topology distances, sufficient remaining computing power, and low loads. If the computing power of an edge node cannot meet the demand, it is automatically allocated to high-performance devices in the cloud to ensure the continuity of computing power supply.

[0125] The pseudocode coupling the scheduling mechanism with the OpenHarmony soft bus clarifies the dispatch triggering logic for complex tasks, achieving precise matching between task complexity and computing power allocation paths, thus avoiding blind resource allocation. Furthermore, the network topology distance optimization mechanism quantifies latency impact through mathematical formulas, significantly reducing communication latency between nodes and ensuring rapid task data transmission and computing resource scheduling. In addition, the strategy of prioritizing edge node computing power reduces task dependence on cloud resources, lowers latency and loss in long-distance data transmission, and improves the utilization rate of edge node computing resources. This allows complex tasks to obtain sufficient computing power support under low latency conditions, further guaranteeing the accuracy and efficiency of complex task processing.

[0126] In one implementation, the step of using the control instruction corresponding to the main action in the pre-execution candidate set as the final control instruction specifically includes the following steps: Step S3331: Based on the pre-set industrial protocol whitelist and hardware signature, perform execution compliance verification on the control instructions corresponding to the main action in the pre-execution candidate set and the simulation results. Step S3332: If the verification passes, the control command corresponding to the main action is taken as the final control command.

[0127] In this embodiment, when the main action of a complex task is matched in the pre-execution candidate set, a compliance check can be performed before the control instruction corresponding to that main action is used as the final control instruction. This is achieved through dual verification using an industrial protocol whitelist and hardware signature. The industrial protocol whitelist is a pre-defined set of allowed industrial communication protocols, specifically including standard protocols such as Modbus / TCP, Profinet, OPC UA, and EtherNet / IP that have undergone security verification and are applied in industrial scenarios. Protocol formats not included in the whitelist will be deemed non-compliant. The hardware signature is a unique identifier for industrial IoT terminal devices, pre-defined and embedded in the device hardware by the device manufacturer. It can be the device's MAC address, a digital signature generated by an encryption chip, etc., and is used to verify the legitimacy of the target device for the control instruction.

[0128] The compliance verification process first involves extracting the control instructions corresponding to the main actions from the pre-execution candidate set, parsing their protocol format, and verifying whether the protocol exists in the industrial protocol whitelist. Simultaneously, the target device identifier contained in the control instructions is extracted and compared with the device's hardware signature to verify whether the target device is a legitimate industrial IoT terminal device. Then, the simulation results are validated to confirm whether they meet the constraints of the complex task, such as whether the device parameters after action execution are within safety thresholds and whether the task objectives are met. If the control instruction's protocol format is in the whitelist, the hardware signature verification passes, and the simulation results are valid, the compliance verification is passed, and the control instruction is used as the final control instruction. If any step fails, it is deemed non-compliant, cache reuse is abandoned, and a new final control instruction is generated based on the main action.

[0129] The mathematical logic behind compliance verification is embodied in hardware signature verification and protocol whitelist filtering. Hardware signature verification ensures the legitimacy of the device's identity through encryption algorithms. Specifically, the mathematical logic expressions for hardware signature verification and protocol whitelist filtering are as follows:

[0130] in, This represents the cached results corresponding to actions that meet validation and filtering criteria. Represents active action The corresponding target device hardware signature, This represents the whitelist filtering function for industrial protocols. The verification function calculates the product of the hardware signature and the protocol filtering result, and then performs a threshold determination to obtain the final verification result.

[0131] Industrial protocol whitelisting prevents the execution of illegal protocol commands, avoiding security issues such as equipment malfunctions and data leaks caused by protocol incompatibility or malicious protocols. Hardware signature verification ensures the legitimacy of the target device for control commands, preventing security incidents caused by sending commands to the wrong or unauthorized devices. Simulation result verification further guarantees the effectiveness of control command execution, avoiding the reuse of invalid or non-compliant cached data. Multiple verifications construct a robust security barrier, significantly improving the security of cache reuse for complex tasks, and are particularly suitable for the security needs of high-risk industrial scenarios.

[0132] In one implementation, after obtaining the final control command, the method further includes the following steps: Step S341: For simple tasks, obtain the similarity score between the candidate action corresponding to the final control command and the target of the task; Step S342: Compare the similarity score with the switching threshold; wherein the switching threshold is calculated from a preset base threshold and the structured task data; Step S343: If the similarity score is lower than the switching threshold, then the simple task is switched to a complex task.

[0133] In this embodiment, after obtaining the final control command for the simple task, a dynamic switching mechanism needs to be set up to ensure that the task can be switched to a complex task when the action adaptability of the simple task is insufficient. The similarity score refers to the semantic similarity score between the candidate action corresponding to the final control command and the target of the simple task, i.e., the score calculated above. This reflects the degree to which the action aligns with the task objective.

[0134] The switching threshold is a key criterion for determining whether a task type switch is necessary. It is calculated from a preset base threshold and structured task data. In this embodiment, the aforementioned dynamic threshold is used directly. .

[0135] In the dynamically switching execution flow, the similarity scores between the control instructions and the task target corresponding to all candidate actions of the simple task are first obtained. Subsequently, the maximum score, which is the score of the candidate action corresponding to the final control command, is determined. , and switching threshold A comparison is performed. If the score is higher than or equal to the switching threshold, the simple task type is maintained, and the final control instruction is executed according to the original process. If the score is lower than the switching threshold, i.e. If the candidate action is deemed insufficiently aligned with the task objective, and the simple task path cannot guarantee the accuracy of the decision, then the simple task is switched to a complex task. The subsequent processing flow of the complex task is followed, that is, the main action is generated through the core reasoning model, and the final control instruction is obtained and executed after cache matching and compliance verification.

[0136] While simple task paths offer fast response times, the accuracy of edge-based lightweight inference models is relatively limited, potentially leading to insufficient alignment between actions and task objectives. The dynamic switching mechanism, by comparing similarity scores with switching thresholds, accurately identifies these low-alignment tasks and promptly switches to higher-precision, more complex task paths. This prevents erroneous execution of poorly adapted actions in simple task paths, avoiding decision-making errors or equipment malfunctions. This mechanism, combining rapid processing with precise fallback, ensures fast response times for most simple tasks while compensating for the accuracy deficiencies of simple task paths through the switching mechanism, achieving a dual guarantee of response speed and decision-making accuracy.

[0137] Step S400: Control the industrial IoT terminal device to perform decision-response operations for the task through the final control command.

[0138] In this embodiment, the final control command is a standardized control signal that has been generated, reused, or verified and can be directly recognized and executed by the industrial IoT terminal device. Specifically, it may include key information such as execution parameters, timing requirements, and industrial protocol adaptation formats. The industrial IoT terminal device is the hardware carrier that performs specific operations in an industrial production scenario, and may include various industrial equipment such as motors, valves, photovoltaic modules, sensor controllers, pump sets, and conveying equipment. The decision-response operation is the operation behavior of the terminal device to change its own state according to the final control command, and may include actual response behaviors to task requirements such as power adjustment, switch switching, parameter calibration, position movement, and flow regulation.

[0139] The control commands generated through the hierarchical, inference, and reuse processes described above are transformed into actual actions of the equipment, realizing the implementation of an engineering workflow from data acquisition to task resolution. Based on the dynamic hierarchical, path-based processing, and pre-execution caching and reuse mechanisms described earlier, the execution of the final control commands ensures low latency. Furthermore, due to the reuse of cached commands for simple tasks, parallel reuse of queries for complex tasks, generation of main actions by the core model, selection of optimal commands based on semantic similarity, and pre-execution verification and safety threshold screening, the operational safety and accuracy of industrial equipment are guaranteed. The implementation of this engineering workflow ensures that various task requirements in industrial scenarios can be responded to quickly, safely, and accurately, effectively solving the problems of high response latency and high execution risk in traditional serial architectures, and adapting to the needs of industrial real-time control, energy scheduling, and high-risk operations.

[0140] In summary, this invention addresses the low latency, high resource efficiency, and high security requirements of industrial IoT decision-making and response. It constructs an integrated technical system for virtual-physical collaboration and dynamic optimization. First, real-time operational data from industrial IoT terminal devices is collected. This data is then processed through industrial protocol parsing and feature standardization to obtain structured task data. Next, task complexity is dynamically calculated based on decision timeframes, device risk levels, and data dimensionality. Combined with a dynamic threshold for adjusting device risk levels, a stage sensor categorizes tasks into simple or complex tasks. For simple tasks, a lightweight edge inference model generates multiple candidate actions, which are pre-executed in a simulation environment to obtain control commands and simulation results. These results are then associated with the device lifecycle timeline and stored using a time-series database with tags. The system stores a pre-execution candidate set, and then uses semantic similarity evaluation to filter and determine the final control command. For complex tasks, the core inference model generates a single main action, queries the pre-execution candidate set in parallel, and reuses the corresponding control command after the industrial protocol whitelist and hardware signature verification. If the candidate is not found, the control command is generated directly. Before inference, complex tasks can be dynamically assigned to edge nodes through a distributed soft bus to obtain computing power support. At the same time, a load-aware scheduler dynamically filters and releases tasks based on the expected benefits of the task and the current load to avoid high-concurrency congestion. An embedded risk scoring mechanism automatically switches to complex task processing when the semantic similarity score of a simple task action is lower than the dynamic threshold, achieving coordinated optimization of real-time performance, resource efficiency, and security.

[0141] like Figure 8 As shown in the figure, this embodiment of the invention provides an industrial Internet of Things (IoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-response system, which includes: a structured task data acquisition module 10, a task division module 20, a final control instruction generation module 30, and a decision-response module 40.

[0142] Specifically, the structured task data acquisition module 10 is used to acquire real-time data streams from industrial IoT terminal devices, perform structured processing on the real-time data streams, and obtain structured task data; the task division module 20 is used to classify tasks based on the structured task data using a stage sensor; wherein the tasks are classified into simple tasks or complex tasks; the final control instruction generation module 30 is used to generate several candidate actions and a pre-execution candidate set for the simple tasks using an edge lightweight inference model, and determine the final control instruction; for the complex tasks, it generates a main action using a core inference model, and obtains the final control instruction by matching or directly generating the pre-execution candidate set; the decision response module 40 is used to control the industrial IoT terminal devices to perform decision response operations for the task using the final control instruction.

[0143] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 9As shown, the terminal device includes a processor, memory, network interface, display screen, and temperature sensor connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a dynamic hierarchical decision-making and response method for virtual-real collaboration in the Industrial Internet of Things (IIoT). The display screen can be an LCD or an e-ink display. The temperature sensor is pre-installed inside the terminal device to detect the operating temperature of internal components.

[0144] Those skilled in the art will understand that Figure 9 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0145] In one embodiment, a terminal device is provided, including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs including instructions for performing operations as described in the embodiments of the methods above.

[0146] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0147] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0148] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A dynamic hierarchical decision-making and response method for virtual-real collaboration of intelligent agents in the Industrial Internet of Things, characterized in that, The method includes: Acquire real-time data streams from industrial IoT terminal devices, and perform structured processing on the real-time data streams to obtain structured task data; Based on the structured task data, the tasks are classified using a stage perceptron; wherein the tasks are classified as simple tasks or complex tasks. For the simple task, a number of candidate actions and a pre-execution candidate set are generated through an edge lightweight inference model, and the final control command is determined; for the complex task, the main action is generated through a core inference model, and the final control command is obtained by matching or directly generating the pre-execution candidate set. The final control command controls the industrial IoT terminal device to perform decision-making and response operations for the task.

2. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, The acquisition of real-time data streams from industrial IoT terminal devices includes: Real-time operating data is collected through the sensors and controllers of the industrial IoT terminal equipment. The collected real-time running data is preprocessed to reduce noise, resulting in the real-time data stream.

3. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, The process of structuring the real-time data stream to obtain structured task data includes: The real-time data stream is parsed using an industrial protocol to extract key feature vectors. The key feature vectors are subjected to feature standardization processing to obtain structured task data; wherein, the structured task data is used to express the content of the task to be processed.

4. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, The step of classifying tasks based on the structured task data using a stage perceptron includes: Based on the structured task data, the task complexity is calculated. The task complexity is compared with a dynamic threshold; If the task complexity is lower than the dynamic threshold, the task is classified as a simple task; otherwise, the task is classified as a complex task.

5. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 4, characterized in that, The structured task data includes at least decision timeframe, equipment risk level, and data dimensionality. The calculation of task complexity based on the structured task data includes: The task complexity is dynamically calculated based on the decision time limit, equipment risk level, and data dimensionality in the structured task data.

6. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 4, characterized in that, The dynamic threshold is calculated from a preset base threshold and the device risk level in the structured task data, and the device risk level is positively correlated with the dynamic threshold.

7. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, After classifying the tasks based on the structured task data using a stage perceptron, the process further includes: Based on the current load and the expected benefits of the task, tasks are selected for release through preset filtering rules; wherein, the released tasks are those that are allowed to generate actions, and the expected benefits of the task are determined by a comprehensive assessment of time saved by action overlap, hit probability, transmission overhead and computational overhead.

8. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, The edge-lightweight inference model is an inference model deployed at the edge node of an industrial IoT system or locally. It is obtained through model structure simplification and parameter pruning optimization. For the simple task, the edge-lightweight inference model generates several candidate actions and a pre-execution candidate set, and determines the final control command, including: Based on the structured task data corresponding to the simple task, a preset number of candidate actions are generated using an edge lightweight inference model; wherein, the candidate actions are used to respond to the requirements of the task. In a pre-set simulation environment, pre-execution operations are performed on all candidate actions to generate a corresponding number of control commands and simulation results. The candidate actions, corresponding control commands, and simulation results are cached to obtain a pre-execution candidate set in the cache. Based on a preset scoring mechanism, the final control command is determined from the candidate actions and their corresponding control commands.

9. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 8, characterized in that, The step of caching the candidate actions, corresponding control commands, and simulation results to obtain a pre-execution candidate set in the cache includes: The candidate actions, corresponding control commands, and simulation results are associated and stored, and associated with the lifecycle timeliness of the industrial IoT terminal device to form a pre-execution candidate set; wherein, the pre-execution candidate set is stored using a time-series database tag.

10. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 8, characterized in that, The predetermined scoring mechanism determines the final control command from the candidate actions and corresponding control commands, including: Based on the candidate actions and the goal of the task, a similarity score is obtained through semantic similarity evaluation; The control instruction corresponding to the candidate action with the highest similarity score is selected as the final control instruction.

11. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 1, characterized in that, The core inference model is a high-precision inference model with a complete inference architecture for handling complex tasks. It is deployed in high-performance devices in the cloud or industrial IoT edge nodes. For the complex task, the core inference model generates the main action, and the final control command is obtained by matching the pre-execution candidate set or by direct generation, including: Based on the structured task data corresponding to the complex task, the main action is generated through reasoning using the core reasoning model; Verify whether the main action exists in the pre-execution candidate set; If it exists, the control instruction corresponding to the main action in the pre-execution candidate set shall be used as the final control instruction; If it does not exist, the final control command is generated based on the main action.

12. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 11, characterized in that, Before generating the main action based on the structured task data corresponding to the complex task through the core reasoning model, the process also includes: Based on the computing power demand vector of the complex task, the task is dynamically assigned to edge nodes through a distributed soft bus, and the computing resources of the edge nodes are allocated first to provide computing power; wherein, the distributed soft bus realizes low-latency collaboration between edge devices through a network topology distance optimization mechanism.

13. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 11, characterized in that, The step of using the control instruction corresponding to the main action in the pre-execution candidate set as the final control instruction includes: Based on a pre-set industrial protocol whitelist and hardware signature, the control instructions corresponding to the main actions in the pre-execution candidate set and the simulation results are executed to verify compliance. If the verification passes, the control command corresponding to the main action will be used as the final control command.

14. The industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method according to claim 10, characterized in that, After obtaining the final control command, the process also includes: For simple tasks, obtain the similarity score between the candidate actions corresponding to the final control command and the target of the task; The similarity score is compared with a switching threshold; wherein the switching threshold is calculated from a preset base threshold and the structured task data. If the similarity score is lower than the switching threshold, the simple task will be switched to a complex task.

15. An industrial Internet of Things (IoT) intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response system, characterized in that, The system includes: The structured task data acquisition module is used to acquire real-time data streams from industrial IoT terminal devices, and to perform structured processing on the real-time data streams to obtain structured task data. The task segmentation module is used to classify tasks based on the structured task data using a stage perceptron; wherein the tasks are classified as simple tasks or complex tasks. The final control command generation module is used to generate several candidate actions and a pre-execution candidate set for the simple task through an edge lightweight inference model, and determine the final control command; for the complex task, it generates the main action through a core inference model, and obtains the final control command by matching or directly generating the pre-execution candidate set. The decision response module is used to control the industrial IoT terminal device to perform decision response operations for the task through the final control command.

16. A terminal device, characterized in that, The terminal device includes a memory, a processor, and an industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response program stored in the memory and capable of running on the processor. When the processor executes the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response program, it implements the steps of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method as described in any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response program. When the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response program is executed by a processor, it implements the steps of the industrial IoT intelligent agent virtual-real collaborative dynamic hierarchical decision-making and response method as described in any one of claims 1-14.

Images