AIoT physical device control-oriented end-edge-cloud intelligent entity trusted execution method and system

Abstract

The application discloses an AIoT physical device control-oriented end-edge-cloud intelligent agent trusted execution method and system, and relates to the technical field of artificial intelligence. The method comprises the following steps: acquiring an input event, and analyzing a control task from the input event; querying a device state graph based on a target space; determining a physical risk level according to a candidate control action; determining an end-edge-cloud execution position according to the physical risk level; performing pre-control trusted verification on the candidate control action to obtain a pre-control trusted verification result; determining a final execution strategy according to the physical risk level and the pre-control trusted verification result; issuing a control action according to the final execution strategy, and collecting a device feedback state after execution; comparing the device feedback state with an expected state, triggering rollback compensation when a deviation exceeds a threshold, and writing a control action whole process into an audit record to form a control evidence chain. The application can improve the safety of AIoT physical device control.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a trusted execution method and system for edge-cloud intelligent agents for AIoT physical device control. Background Technology

[0002] With the development of artificial intelligence, large language models, the Internet of Things (IoT), and edge computing, AIoT systems are gradually evolving from traditional device access, data collection, rule-based alerts, and visualization to new intelligent systems in which intelligent agents participate in perception, analysis, decision-making, and control. In smart buildings, smart parks, energy management, urban operations, and security maintenance scenarios, the system not only needs to detect anomalies, generate reports, or make suggestions, but also needs to control real physical devices such as air conditioning, ventilation, lighting, elevators, access control, power supply and distribution, energy storage, and security systems under certain conditions.

[0003] Existing multi-agent solutions can already achieve complex task decomposition, agent capability matching, task node routing, and execution result output. For example, existing multi-agent task decomposition and capability routing methods and systems mainly protect external agent registration, memory recall, candidate task graph generation, relevance and coverage filtering, capability routing, and SLA scoring for optimization. Their core challenge is how cross-platform agents can collaboratively complete complex software tasks. This solution is suitable as a foundation for agent collaboration, but its protection focus is not the AIoT physical device control actions themselves.

[0004] When intelligent agents enter physical device control scenarios, the problems faced by the system are significantly different from those of ordinary software tasks. Physical device control can affect personnel safety, equipment safety, business continuity, and emergency response. For example, air conditioning and fresh air control affect comfort and air quality; elevator control affects access safety; access control policies affect security and evacuation; and power supply and distribution control affects critical business systems. Therefore, the system must not only determine "which intelligent agent can perform the action," but also "whether the action can be performed, where it should be performed, whether it needs to be reviewed, how to verify it before execution, how to correct errors after execution, and how to audit the entire process."

[0005] Existing edge-cloud collaboration solutions typically focus on computing power, latency, network status, and resource scheduling; existing trusted execution, access management, and zero-trust solutions typically focus on identity, permissions, data transmission, and access control; and existing device early warning and health diagnosis solutions typically focus on anomaly detection, risk prediction, and maintenance recommendations. These solutions each address specific problems, but a complete trusted execution chain for controlling AIoT physical devices has not yet been established.

[0006] Existing multi-agent task orchestration schemes can complete agent registration, task decomposition, task graph generation, capability matching, and execution result output, suitable for software tasks such as question answering, analysis, retrieval, report generation, and policy planning. However, when tasks involve the control of real physical devices, task decomposition and capability routing alone are insufficient to guarantee control security. Specifically, existing schemes typically describe "which agent possesses what capabilities," but do not adequately describe "which device is currently allowed to be controlled, which related objects will be affected by the control action, whether there are interlocking or linkage constraints, and whether rollback is possible after control failure." Therefore, such schemes cannot directly solve the problem of reliable execution of AIoT device control actions. Existing edge-cloud collaborative schemes mainly determine the task execution location based on network status, computing load, latency requirements, bandwidth, and resource costs. However, in AIoT control scenarios, the execution location of control actions depends not only on resource conditions but also on device security level, action impact range, reversibility, linkage complexity, and manual confirmation requirements. For example, read-only sensing tasks can be executed on the edge or the device side; reversible control tasks can be executed on the edge and asynchronously audited by the cloud; high-impact control tasks require cloud review and manual confirmation; actions involving personal safety or critical assets should be prohibited from automatic execution. Existing edge-cloud scheduling solutions typically lack the aforementioned execution location selection mechanism constrained primarily by physical risks. Existing trusted transmission, permission management, and zero-trust access control solutions can guarantee the trustworthiness of identity, permissions, or communication links, but the trustworthiness required for AIoT device control also includes whether the control action itself is suitable for execution. Even if a smart agent has a genuine identity and valid permissions, issues such as inconsistent device states, rule conflicts, excessive linkage impact, mis-execution of high-risk actions under weak network conditions, and abnormal states after execution may occur. Therefore, AIoT device control requires a trusted execution chain covering pre-control verification, in-control feedback, post-control rollback compensation, and full-process auditing, rather than simply relying on identity authentication or data encryption. Existing device early warning, health prediction, and intelligent diagnostic solutions can identify device anomalies, predict faults, or generate maintenance suggestions, but typically do not further address the issue of how control actions are executed reliably. For example, a system can identify abnormal elevator vibration and suggest maintenance, but whether it can automatically switch to maintenance mode, whether manual confirmation is required, whether it will affect passenger passage, and how to recover in case of false alarms all require additional reliable control mechanisms. Similarly, a system can detect abnormal energy consumption and suggest adjusting air conditioning strategies, but whether this strategy affects comfort, violates air quality regulations, and achieves the expected energy-saving effect after implementation also requires a closed-loop control system to ensure compliance.

[0007] Therefore, a new technical solution is needed to unify the process of device state graph, physical risk classification, edge-cloud execution routing, pre-control trusted verification, post-control state feedback, rollback compensation, multi-agent conflict arbitration, and audit solidification, so that the control of real physical devices by intelligent agents has clear boundaries, security constraints, error correction mechanisms, and a chain of evidence for responsibility. Summary of the Invention

[0008] To address the technical challenge of ensuring the secure, controllable, and traceable execution of control actions by intelligent agents in AIoT physical device control scenarios, this invention provides a trusted execution method and system for edge-cloud intelligent agents in AIoT physical device control. The technical solution is as follows: On the one hand, a trusted execution method for edge-cloud intelligent agents in AIoT physical device control is provided. This method is implemented by a trusted execution device for edge-cloud intelligent agents in AIoT physical device control, and includes: S1. Acquire input events, wherein the input events include user instructions, service events, device alarms, and planned control targets; S2. Parse the control task from the input event to identify the target device, target space, candidate control actions, and service constraints; S3. Based on the target space query device status map, extract relevant sub-graphs from the device status map to determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control authority and linkage constraints; S4. Determine the physical risk level based on the criticality level of the equipment involved in the candidate control actions, the scope of influence, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; determine the edge-cloud execution location based on the physical risk level. S5. Perform a pre-control credibility verification on the candidate control action to obtain the pre-control credibility verification result; determine the final execution strategy based on the physical risk level and the pre-control credibility verification result. S6. Issue control actions according to the final execution strategy and collect the device feedback status after execution; S7. Compare the device feedback status with the expected status. When the deviation exceeds the threshold, trigger rollback compensation and write the entire control action process into the audit record to form a control evidence chain.

[0009] On the other hand, a trusted execution system for edge-cloud intelligent agents oriented towards AIoT physical device control is provided. This system is applied to the trusted execution method for edge-cloud intelligent agents oriented towards AIoT physical device control. The system includes: The event access module is used to acquire input events, including user commands, business events, device alarms, and planned control targets. The semantic parsing module is used to parse control tasks from the input events and identify target devices, target spaces, candidate control actions, and business constraints. The device status graph module is used to query the device status graph based on the target space, extract relevant subgraphs from the device status graph, and determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control permissions, and linkage constraints. The physical risk assessment module is used to determine the physical risk level based on the criticality level of the equipment involved in the candidate control action, the scope of impact, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; and to determine the execution location of the edge-cloud based on the physical risk level. The pre-control credibility verification module is used to perform pre-control credibility verification on the candidate control actions, obtain the pre-control credibility verification result, and determine the final execution strategy based on the physical risk level and the pre-control credibility verification result. The control execution and feedback acquisition module is used to issue control actions according to the final execution strategy and to acquire the device feedback status after execution. The rollback compensation and audit module is used to compare the device's feedback status with the expected status. When the deviation exceeds a threshold, rollback compensation is triggered, and the entire process of the control action is written into the audit record to form a control evidence chain.

[0010] On the other hand, a trusted execution device for edge-cloud intelligent agents for AIoT physical device control is provided. The trusted execution device for edge-cloud intelligent agents for AIoT physical device control includes: a processor; and a memory, wherein computer-readable instructions are stored in the memory. When the computer-readable instructions are executed by the processor, any one of the methods described above for trusted execution of edge-cloud intelligent agents for AIoT physical device control is implemented.

[0011] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement any of the above-described edge-cloud intelligent agent trusted execution methods for AIoT physical device control.

[0012] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following: The embodiments of the present invention can improve the security of AIoT physical device control. The embodiments of the present invention identify the current state of the target device, associated devices, scope of influence, interlocking relationships, permission relationships and rule constraints before the control action is issued by the device state map, so that the control action is no longer an isolated call to the device interface, thereby reducing the risk of miscontrol, unauthorized control and cross-system linkage conflict.

[0013] This invention enables edge-cloud collaboration to upgrade from resource scheduling to risk-driven execution. It determines the execution location of control tasks—on the device, edge, or cloud—based on physical risk levels. Low-risk tasks can be executed quickly locally, while high-risk tasks can be reviewed in the cloud or confirmed manually. For tasks prohibited from automatic execution, only suggestions are generated without automatically issuing control actions. Therefore, edge-cloud collaboration no longer relies solely on computing power, latency, or network status, but also considers both real-time performance and physical security boundaries.

[0014] The embodiments of the present invention can enhance the reliable execution capability of control actions. Before the control action is issued, the embodiments of the present invention introduce instruction source verification, identity authentication, permission verification, device status consistency verification, business rule verification, linkage constraint verification and risk threshold verification. It can detect control requests that do not meet the conditions before the control action is actually applied to the physical device, and block them, transfer them to manual confirmation or generate alternative strategies.

[0015] This invention improves the error correction capability of abnormal control results and supports conflict resolution in multi-agent, multi-objective control. Before executing a control action, this invention records a snapshot of the device state and generates an expected state template. After execution, it collects the actual feedback state and compares it. When the deviation between the actual state and the expected state exceeds a threshold, the system can trigger a rollback, alternative compensation, or manual takeover, enabling the system to have post-control error correction capabilities instead of simply outputting the execution result. When multiple agents propose different control suggestions for the same device, the same space, or the same event, this invention arbitrates based on security priority, risk level, rule enforcement level, business objective weight, and historical execution effects. This reduces conflicts between goals such as energy saving, safety, comfort, and operation and maintenance, and improves the reliability of collaborative control in complex AIoT scenarios.

[0016] This invention provides a traceable chain of control evidence that can be easily reused in various AIoT scenarios. The embodiment records the instruction source, target device, control action, risk level, execution location, verification result, manual confirmation result, feedback status, rollback compensation process, conflict arbitration reasons, and responsible party in the audit log, forming a chain of control evidence. This chain of control evidence facilitates subsequent auditing, review, responsibility delineation, and strategy optimization. Based on device status graphs, physical risk classification, edge-cloud risk routing, and trusted execution chains, this invention is not limited to specific devices or single industry scenarios and can be extended to various AIoT scenarios such as buildings, parks, hospitals, schools, urban infrastructure, energy stations, and data centers. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a trusted execution method for edge-cloud intelligent agents for AIoT physical device control provided by an embodiment of the present invention; Figure 2 This is a flowchart illustrating a trusted execution method for edge-cloud intelligent agents in AIoT physical device control, provided by an embodiment of the present invention. Figure 3 This is a diagram showing the module composition and layered deployment relationship of an edge-cloud intelligent agent trusted execution system for AIoT physical device control, provided by an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of a device status map provided in an embodiment of the present invention; Figure 5 This is a reliable execution chain diagram of control actions provided in an embodiment of the present invention; Figure 6 This is a rollback compensation flowchart provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of a multi-agent conflict arbitration provided in an embodiment of the present invention; Figure 8 This is a block diagram of a trusted execution system for edge-cloud intelligent agents for AIoT physical device control, provided by an embodiment of the present invention. Figure 9 This is a schematic diagram of the structure of a trusted execution device for edge-cloud intelligent agents in AIoT physical device control, provided by an embodiment of the present invention. Detailed Implementation

[0019] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0020] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0021] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0022] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0023] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0024] This invention provides a trusted execution method for edge-cloud intelligent agents in AIoT physical device control. This method can be implemented by a trusted execution device for edge-cloud intelligent agents in AIoT physical device control, which can be a terminal or a server. Figure 1 The flowchart shown is for a trusted execution method of edge-cloud intelligent agents for AIoT physical device control. The processing flow of this method may include the following steps: S1. Acquire input events, including user commands, business events, device alarms, and planned control objectives.

[0025] In one feasible implementation, this invention provides a trusted execution method and system for edge-cloud intelligent agents in AIoT physical device control. This solution takes AIoT physical device control tasks as the object, uses device state graphs as the basis for controlling object identification, physical risk classification as the basis for execution boundary judgment, edge-side, and cloud-based intelligent agents as collaborative execution entities, and uses trusted execution chains, rollback compensation, and audit solidification as control security mechanisms.

[0026] Among them, such as Figure 2 The diagram shows a flowchart illustrating a trusted execution method for edge-cloud intelligent agents in AIoT physical device control, as provided in this invention. It includes steps such as event input, control task parsing, device status graph query, physical risk classification, edge-cloud execution location selection, pre-control trusted verification, control action execution, feedback status acquisition, rollback compensation, conflict arbitration, and audit solidification. This invention can be applied to scenarios with multiple types of IoT devices, multi-level control systems, and multiple security constraints, such as smart buildings, smart parks, hospital logistics and security operations, schools, urban infrastructure, energy stations, and data centers. AIoT refers to Artificial Intelligence of Things, which is an intelligent system formed by combining artificial intelligence technology with IoT devices, sensors, controllers, edge nodes, and cloud platforms.

[0027] Among them, such as Figure 3 The diagram shown illustrates the module composition and layered deployment relationship of an edge-cloud intelligent agent trusted execution system for AIoT physical device control, as provided in an embodiment of the present invention. The system may include an event access and semantic parsing module, a device status graph module, a physical risk assessment module, an edge-cloud execution routing module, a pre-control trusted verification module, a control execution and feedback acquisition module, a rollback compensation module, a multi-agent conflict arbitration module, and an audit and experience accumulation module. Figure 3 This reflects the collaborative relationship between the device side, edge side, and cloud side. The device side is mainly responsible for collecting device status and executing low-risk actions; the edge side is mainly responsible for local control, rapid response, and local caching; and the cloud side is mainly responsible for complex review, global policies, audit solidification, and experience accumulation.

[0028] S2. Parse control tasks from input events to identify target devices, target spaces, candidate control actions, and business constraints.

[0029] S3. Based on the target space query, query the device status map, extract relevant sub-graphs from the device status map, and determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control permissions, and linkage constraints.

[0030] Optionally, the device state graph is used to describe the relationships between devices, sensors, controllers, spaces, rules, events, work orders, and audit records in an AIoT scenario; wherein, the device state graph includes nodes and edges; Among them, such as Figure 4 This is a schematic diagram of a device status map provided in an embodiment of the present invention.

[0031] The nodes include device nodes, sensor nodes, controller nodes, spatial nodes, rule nodes, event nodes, work order nodes, and audit nodes. Among them, edges include perception relationships, control relationships, spatial ownership relationships, dependency relationships, interlocking relationships, influence relationships, permission relationships, rule constraint relationships, and rollback association relationships.

[0032] Before issuing control actions, the system extracts relevant sub-graphs from the device state graph based on the target device or target space to identify the controlled object, associated devices, control permissions, rule constraints, and scope of influence. For example, in an air conditioning control scenario, the target device may be associated with fresh air equipment, temperature and humidity sensors, occupancy sensors, comfort rules, and energy consumption rules; in an elevator control scenario, the target device may be associated with door operator controllers, load sensors, group control systems, maintenance work orders, and safety rules.

[0033] The device state graph differs from the ordinary capability graph. The ordinary capability graph mainly describes "which intelligent agent can do what", while the device state graph in this embodiment mainly describes "which device can be controlled at present, which objects will be affected by the control, which rules and permissions the control action is subject to, or whether there is a rollback path after the control fails".

[0034] S4. Determine the physical risk level based on the criticality level of the equipment involved in the candidate control action, the scope of impact, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; determine the execution location of the edge-cloud based on the physical risk level.

[0035] Physical risk grading is used to determine the automation boundary of control actions. The system can determine the physical risk level of control actions based on equipment criticality level, action impact range, action reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual verification requirements.

[0036] Optionally, physical risk levels include: R0 is a read-only sensing level that only reads device status, sensor data, or operation logs and does not have any control effects. R1 is an execution level suggestion that generates suggestions, reports, or work orders but does not directly issue control actions. R2 is a reversible control stage that involves control actions that can be recovered through rollback. R3 High Impact Control Level: Control actions involving personnel safety, business continuity, or critical equipment status; R4 prohibits automatic execution level, involving control actions such as fire linkage, power failure of critical loads, large-scale access control unlocking, or emergency evacuation.

[0037] The aforementioned grading can be determined through weighted scoring, rule matrices, expert rules, machine learning models, or a combination thereof. Specific scoring formulas and weights can be configured according to industry, scenario, and device type, and are not limited to a single implementation method.

[0038] In this embodiment of the invention, the edge-cloud execution routing is not based solely on computing power, latency, and network status to offload tasks. Instead, it is primarily constrained by physical risk level, and combines real-time requirements, network status, edge node load, data locality, and permission boundaries to determine the execution location.

[0039] Optionally, the execution location of the edge-cloud can be determined based on the physical risk level, including: R0 and R1 tasks are preferentially executed by the end side or edge side; R2 tasks are executed at the edge and audited asynchronously by the cloud. The R3 task involves data collection at the edge, cloud verification, and manual confirmation before execution. R4 tasks are prohibited from being executed automatically; they only provide suggestions or prompts for authorized personnel to handle through a dedicated control system.

[0040] In scenarios with weak or no network coverage, the system allows low-risk actions within a pre-defined whitelist to be executed at the edge, and audit records are uploaded to the cloud after the network is restored. For high-risk actions, the system disables automatic execution or enters the fail-safe policy by default.

[0041] The specific implementation process of edge-cloud risk-driven routing includes: inputting decision-making factors into the routing decision module for risk priority assessment and multi-factor comprehensive assessment; the decision-making input factors include: physical risk level (primary constraint), real-time requirements (supporting constraint), network status (supporting constraint), edge node load (supporting constraint), data locality (supporting constraint), and permission boundaries (supporting constraint); the risk priority assessment is based on the primary constraint, and only when the physical risk level meets the security threshold for automatic execution will it proceed to the subsequent multi-factor assessment; the multi-factor comprehensive assessment is based on the supporting constraints; combining real-time requirements, network status, edge node load, data locality, and permission boundary factors to calculate the optimal execution location and output the routing decision result. The decision result is input into the edge execution domain, edge execution domain, and cloud execution domain respectively, and the corresponding execution decisions are output, including: edge execution (local automatic execution), edge execution (edge ​​automatic execution), and cloud review execution (cloud review or execution); when the routing decision result is judged to be too risky or does not meet the constraints, automatic execution is prohibited or manual confirmation is required.

[0042] S5. Perform pre-control credibility verification on candidate control actions and obtain the pre-control credibility verification results; determine the final execution strategy based on the physical risk level and the pre-control credibility verification results.

[0043] Optionally, pre-control trusted verification includes: instruction source verification, subject identity verification, control authority verification, device status consistency verification, business rule verification, linkage constraint verification, and risk threshold verification.

[0044] In one feasible implementation, the system only allows entry into the execution phase when all pre-control trust checks pass; if any check fails, the system blocks the control action and generates an alternative strategy, a manual confirmation request, or a prohibition on execution. For control actions requiring manual confirmation, the system displays the target device, control action, risk level, scope of impact, expected state, and potential risks to authorized personnel, pending confirmation before execution. During control execution, the system records the execution location, executing entity, control action, issuance time, and execution result. After control execution, the system collects device feedback status to provide a basis for subsequent status comparison, rollback compensation, and audit consolidation.

[0045] Among them, such as Figure 5 This is a reliable execution chain diagram of control actions provided in an embodiment of the present invention; Figure 5 This is used to demonstrate the trusted execution chain before, during, and after the issuance of control actions. Trusted execution of control actions is divided into pre-execution verification (trusted pre-chain) and in-execution and post-execution verification (trusted execution chain). Pre-execution verification includes: instruction source verification, identity authentication, authorization verification, device status consistency verification, business rule verification, linkage constraint verification, risk threshold verification, and manual confirmation verification (optional). Instruction source verification verifies the legality and completeness of the instruction source, including signatures or timestamps; identity authentication verifies the authenticity of the author or system identity; authorization verification verifies whether the operator has the authority to execute the action; device status consistency verification verifies whether the device status is consistent with the digital twin or baseline; business rule verification verifies whether it meets business process, strategy, or timing rules; linkage constraint verification and risk threshold verification verify whether the risk assessment result is within an acceptable threshold; manual confirmation verification indicates that critical operations require manual confirmation (configurable). The process of execution and verification during the event includes: control action issuance, feedback status acquisition, status comparison, audit consolidation, and loop closure. Control action issuance refers to issuing control commands to the target device or system; feedback status acquisition refers to collecting the device or system's execution feedback status and events; status comparison refers to comparing the feedback status with the expected status or baseline; audit consolidation refers to recording and consolidating the entire execution process log (for tamper-proof evidence preservation); and loop closure refers to outputting the execution result and audit credentials. In one feasible implementation, it is determined whether all pre-verifications have passed. If not, verification failure handling is performed, including: blocking execution, downgrading or rerouting the alternative strategy, adjusting parameters, recording the reason for execution, and issuing an alarm. If not, execution and verification during the event are performed.

[0046] Optionally, the final execution strategy includes: automatic execution, edge review, cloud review, manual confirmation, or disabling automatic execution.

[0047] S6. Issue control actions according to the final execution strategy and collect the device feedback status after execution.

[0048] S7. Compare the device feedback status with the expected status. When the deviation exceeds the threshold, trigger rollback compensation and write the entire process of control actions into the audit log to form a control evidence chain.

[0049] In one feasible implementation, the system records a snapshot of the status of the target device and associated devices before the control action is executed, and generates a template of the expected status. After the control action is executed, the system collects the actual feedback status and compares it with the expected status. When the deviation exceeds a preset threshold, the system prioritizes performing a rollback along the original path; if the rollback conditions are not met, an alternative compensation action is performed; if the compensation still cannot meet the safety requirements, manual takeover is initiated.

[0050] Among them, such as Figure 6 This is a rollback compensation flowchart provided in an embodiment of the present invention; Figure 6 This diagram illustrates the process of taking a snapshot of the state before the control action is executed, generating a expected state template, collecting feedback state after execution, comparing the actual state with the expected state, judging deviations, rolling back along the original path, alternative compensation, and manual takeover. It highlights the difference between this embodiment of the invention and ordinary intelligent agent tool calls, demonstrating that this embodiment can correct errors when the physical control result does not meet expectations. In one feasible implementation, the rollback compensation process includes: taking a snapshot of the state before control and generating an expected state template; based on the expected state template, executing the control action, collecting the actual feedback state, comparing the actual feedback state with the expected state, judging whether the deviation exceeds a threshold, and if the deviation does not exceed the threshold, performing an audit and solidification operation to complete the rollback compensation process; if the deviation exceeds the threshold, prioritizing the original path rollback step and judging whether the rollback is successful, and if the rollback is successful, performing an audit and solidification step to complete the rollback compensation process; if the rollback fails, executing an alternative compensation action and judging whether safety requirements are met, and if they are met, performing an audit and solidification step to complete the rollback compensation process; if safety requirements are not met, transferring to manual takeover and generating an audit record.

[0051] When multiple agents generate different control recommendations for the same device, space, or event, the system triggers multi-agent conflict arbitration. Arbitration criteria may include security priority, risk level, rule enforcement level, business objective weight, historical execution results, and manual configuration strategies. The system can output a final control strategy, alternative strategies, a manual confirmation request, or a result prohibiting automatic execution.

[0052] One feasible implementation method is, for example Figure 7The diagram shown is a schematic diagram of a multi-agent conflict arbitration provided by an embodiment of the present invention; Figure 7 This demonstrates how the system arbitrates different control suggestions from multiple intelligent agents (such as energy-saving, safety, comfort, and operation and maintenance agents) for the same device, space, or event, based on safety priority, risk level, rule enforcement level, business objective weight, and historical execution results. Specific implementation steps include: Step 1: Multiple intelligent agents output corresponding control suggestions respectively. Specifically: the energy-saving intelligent agent outputs control suggestion A as an energy-saving optimization strategy; the safety intelligent agent outputs control suggestion B as a safety assurance strategy; the comfort intelligent agent outputs control suggestion C as a comfort optimization strategy; and the operation and maintenance intelligent agent outputs control suggestion D as an operation and maintenance optimization strategy. Step 2: Input control recommendations A, B, C, and D into the multi-agent conflict arbitration module. Arbitrate the conflict based on the evaluation criteria and output the arbitration result. The evaluation criteria include: security priority, risk level, rule enforcement level, business objective weight, historical execution effect, and manual configuration strategy. The arbitration result may include: final control strategy (automatic execution), alternative strategy (alternative solution), manual confirmation request (requires manual confirmation), and prohibition of automatic execution (irreconcilable conflict).

[0053] Optionally, the control evidence chain includes: source of instruction, target device, target space, control action, risk level, execution location, verification result, manual confirmation result, pre-execution state, expected state, actual feedback state, rollback compensation process, conflict arbitration grounds and responsible party.

[0054] In one feasible implementation, Embodiment 1 of the present invention provides a coordinated energy-saving control of building air conditioning and fresh air systems; the specific implementation steps include: Step 1: The system receives the user's instruction: "Maintain the comfort level of the third floor of Building A while reducing energy consumption from 18:00 to 21:00 on weekdays"; Step 2: The system identifies the target space as the third-floor office area of ​​Building A. Candidate control actions include adjusting the air conditioning temperature setpoint, adjusting the fresh air volume, and adjusting the lighting strategy. Step 3: The system extracts the air conditioning units, fresh air equipment, temperature and humidity sensors, occupancy rate sensors, comfort rules, and energy consumption rules related to the third floor of Building A from the equipment status map; Step 4: Based on the equipment's criticality level, the scope of the action's impact, and the reversibility of the action, the system assesses the temperature setpoint fine-tuning and fresh air volume fine-tuning as R2 reversible control level. Since this action is reversible and the edge node has control authority, the system selects to have the edge-side agent execute the control, with asynchronous auditing by the cloud. Before control, the system completes verification of permissions, equipment status, comfort rules, and linkage constraints. After control, the system collects temperature, carbon dioxide concentration, energy consumption, and equipment operating status. If the feedback status deviates from expectations, such as temperature or air quality exceeding thresholds, the system restores the pre-control settings or executes alternative compensation actions, and writes the results to the audit log.

[0055] This embodiment demonstrates the graph identification, risk classification, edge execution, cloud auditing, and rollback compensation mechanisms of the present invention in low- to medium-risk reversible control scenarios.

[0056] In one feasible implementation, Embodiment 2 of the present invention provides a review of elevator anomalies and high-risk control; the specific implementation steps include: Step 1: The system receives an edge-side alarm: "Elevator E2 is vibrating abnormally and the door operator's opening and closing time deviates from the historical range"; Step 2: The system identifies the target device as elevator E2. Candidate control actions include generating a maintenance work order, exiting group control, or switching maintenance modes.

[0057] Step 3: The system identifies elevator E2, door operator controller, load sensor, group control system, maintenance work order system, and safety rule node from the equipment status map. Since switching maintenance modes may affect passenger access and business continuity, the system assesses this action as R3 high-impact control level. For this type of action, the system does not allow the edge side to directly issue control. Instead, the edge side collects data, and the cloud-based intelligent agent reviews it in conjunction with historical fault samples and safety rules, and initiates a manual confirmation request to authorized maintenance personnel. After manual confirmation is passed, the system issues the control action and creates a maintenance work order. If subsequent review determines it to be a false alarm or the equipment status returns to normal, the system can trigger the status recovery process and write the confirmation, control, recovery, and work order results into the audit log.

[0058] This embodiment demonstrates the cloud-based review, manual confirmation, control boundary, and control evidence chain mechanisms of the present invention in high-impact control scenarios.

[0059] The embodiments of the present invention can improve the security of AIoT physical device control. The embodiments of the present invention identify the current state of the target device, associated devices, scope of influence, interlocking relationships, permission relationships and rule constraints before the control action is issued by the device state map, so that the control action is no longer an isolated call to the device interface, thereby reducing the risk of miscontrol, unauthorized control and cross-system linkage conflict.

[0060] This invention enables edge-cloud collaboration to upgrade from resource scheduling to risk-driven execution. It determines the execution location of control tasks—on the device, edge, or cloud—based on physical risk levels. Low-risk tasks can be executed quickly locally, while high-risk tasks can be reviewed in the cloud or confirmed manually. For tasks prohibited from automatic execution, only suggestions are generated without automatically issuing control actions. Therefore, edge-cloud collaboration no longer relies solely on computing power, latency, or network status, but also considers both real-time performance and physical security boundaries.

[0061] The embodiments of the present invention can enhance the reliable execution capability of control actions. Before the control action is issued, the embodiments of the present invention introduce instruction source verification, identity authentication, permission verification, device status consistency verification, business rule verification, linkage constraint verification and risk threshold verification. It can detect control requests that do not meet the conditions before the control action is actually applied to the physical device, and block them, transfer them to manual confirmation or generate alternative strategies.

[0062] This invention improves the error correction capability of abnormal control results and supports conflict resolution in multi-agent, multi-objective control. Before executing a control action, this invention records a snapshot of the device state and generates an expected state template. After execution, it collects the actual feedback state and compares it. When the deviation between the actual state and the expected state exceeds a threshold, the system can trigger a rollback, alternative compensation, or manual takeover, enabling the system to have post-control error correction capabilities instead of simply outputting the execution result. When multiple agents propose different control suggestions for the same device, the same space, or the same event, this invention arbitrates based on security priority, risk level, rule enforcement level, business objective weight, and historical execution effects. This reduces conflicts between goals such as energy saving, safety, comfort, and operation and maintenance, and improves the reliability of collaborative control in complex AIoT scenarios.

[0063] This invention provides a traceable chain of control evidence that can be easily reused in various AIoT scenarios. The embodiment records the instruction source, target device, control action, risk level, execution location, verification result, manual confirmation result, feedback status, rollback compensation process, conflict arbitration reasons, and responsible party in the audit log, forming a chain of control evidence. This chain of control evidence facilitates subsequent auditing, review, responsibility delineation, and strategy optimization. Based on device status graphs, physical risk classification, edge-cloud risk routing, and trusted execution chains, this invention is not limited to specific devices or single industry scenarios and can be extended to various AIoT scenarios such as buildings, parks, hospitals, schools, urban infrastructure, energy stations, and data centers.

[0064] Figure 8This is a block diagram of a trusted execution system for edge-cloud intelligent agents in AIoT physical device control, provided by an embodiment of the present invention. This system is used for a trusted execution method for edge-cloud intelligent agents in AIoT physical device control. (Refer to...) Figure 8 The system includes an event access module 810, a semantic parsing module 820, a device status graph module 830, a physical risk assessment module 840, a pre-control reliability verification module 850, a control execution and feedback acquisition module 860, and a rollback compensation and auditing module 870. Among them: The event access module 810 is used to acquire input events, wherein the input events include user instructions, business events, device alarms and planned control targets; Semantic parsing module 820 is used to parse control tasks from the input events and identify target devices, target spaces, candidate control actions, and business constraints; The device status graph module 830 is used to query the device status graph based on the target space, extract relevant subgraphs from the device status graph, and determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control authority, and linkage constraints. The physical risk assessment module 840 is used to determine the physical risk level based on the criticality level of the equipment involved in the candidate control action, the scope of impact, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; and to determine the execution location of the edge-cloud based on the physical risk level. The pre-control credibility verification module 850 is used to perform pre-control credibility verification on the candidate control action, obtain the pre-control credibility verification result, and determine the final execution strategy based on the physical risk level and the pre-control credibility verification result. The control execution and feedback acquisition module 860 is used to issue control actions according to the final execution strategy and to acquire the device feedback status after execution. The rollback compensation and audit module 870 is used to compare the device feedback status with the expected status. When the deviation exceeds the threshold, rollback compensation is triggered, and the entire process of the control action is written into the audit record to form a control evidence chain.

[0065] Optionally, the device state graph is used to describe the relationships between devices, sensors, controllers, spaces, rules, events, work orders, and audit records in an AIoT scenario; wherein, the device state graph includes nodes and edges; The nodes include device nodes, sensor nodes, controller nodes, spatial nodes, rule nodes, event nodes, work order nodes, and audit nodes. Among them, edges include perception relationships, control relationships, spatial ownership relationships, dependency relationships, interlocking relationships, influence relationships, permission relationships, rule constraint relationships, and rollback association relationships.

[0066] Optionally, the physical risk level includes: R0 is a read-only sensing level that only reads device status, sensor data, or operation logs and does not have any control effects. R1 is an execution level suggestion that generates suggestions, reports, or work orders but does not directly issue control actions. R2 is a reversible control stage that involves control actions that can be recovered through rollback. R3 High Impact Control Level: Control actions involving personnel safety, business continuity, or critical equipment status; R4 prohibits automatic execution level, involving control actions such as fire linkage, power failure of critical loads, large-scale access control unlocking, or emergency evacuation.

[0067] Optionally, the control evidence chain includes: instruction source, target device, target space, control action, risk level, execution location, verification result, manual confirmation result, pre-execution state, expected state, actual feedback state, rollback compensation process, conflict arbitration grounds, and responsible party.

[0068] Optionally, determining the edge-cloud execution location based on the physical risk level includes: R0 and R1 tasks are preferentially executed by the end side or edge side; R2 tasks are executed at the edge and audited asynchronously by the cloud. R3 tasks involve data collection at the edge, cloud verification, and execution after manual confirmation. R4 tasks are prohibited from being executed automatically; they only provide suggestions or prompts for authorized personnel to handle through a dedicated control system.

[0069] Optionally, the final execution strategy includes: automatic execution, edge review, cloud review, manual confirmation, or disabling automatic execution.

[0070] Optionally, the pre-control trusted verification includes: instruction source verification, subject identity verification, control authority verification, device status consistency verification, business rule verification, linkage constraint verification, and risk threshold verification.

[0071] The embodiments of the present invention can improve the security of AIoT physical device control. The embodiments of the present invention identify the current state of the target device, associated devices, scope of influence, interlocking relationships, permission relationships and rule constraints before the control action is issued by the device state map, so that the control action is no longer an isolated call to the device interface, thereby reducing the risk of miscontrol, unauthorized control and cross-system linkage conflict.

[0072] This invention enables edge-cloud collaboration to upgrade from resource scheduling to risk-driven execution. It determines the execution location of control tasks—on the device, edge, or cloud—based on physical risk levels. Low-risk tasks can be executed quickly locally, while high-risk tasks can be reviewed in the cloud or confirmed manually. For tasks prohibited from automatic execution, only suggestions are generated without automatically issuing control actions. Therefore, edge-cloud collaboration no longer relies solely on computing power, latency, or network status, but also considers both real-time performance and physical security boundaries.

[0073] The embodiments of the present invention can enhance the reliable execution capability of control actions. Before the control action is issued, the embodiments of the present invention introduce instruction source verification, identity authentication, permission verification, device status consistency verification, business rule verification, linkage constraint verification and risk threshold verification. It can detect control requests that do not meet the conditions before the control action is actually applied to the physical device, and block them, transfer them to manual confirmation or generate alternative strategies.

[0074] This invention improves the error correction capability of abnormal control results and supports conflict resolution in multi-agent, multi-objective control. Before executing a control action, this invention records a snapshot of the device state and generates an expected state template. After execution, it collects the actual feedback state and compares it. When the deviation between the actual state and the expected state exceeds a threshold, the system can trigger a rollback, alternative compensation, or manual takeover, enabling the system to have post-control error correction capabilities instead of simply outputting the execution result. When multiple agents propose different control suggestions for the same device, the same space, or the same event, this invention arbitrates based on security priority, risk level, rule enforcement level, business objective weight, and historical execution effects. This reduces conflicts between goals such as energy saving, safety, comfort, and operation and maintenance, and improves the reliability of collaborative control in complex AIoT scenarios.

[0075] This invention provides a traceable chain of control evidence that can be easily reused in various AIoT scenarios. The embodiment records the instruction source, target device, control action, risk level, execution location, verification result, manual confirmation result, feedback status, rollback compensation process, conflict arbitration reasons, and responsible party in the audit log, forming a chain of control evidence. This chain of control evidence facilitates subsequent auditing, review, responsibility delineation, and strategy optimization. Based on device status graphs, physical risk classification, edge-cloud risk routing, and trusted execution chains, this invention is not limited to specific devices or single industry scenarios and can be extended to various AIoT scenarios such as buildings, parks, hospitals, schools, urban infrastructure, energy stations, and data centers.

[0076] Figure 9 This is a schematic diagram of the structure of a trusted execution device for edge-cloud intelligent agents in AIoT physical device control, provided by an embodiment of the present invention. Figure 9As shown, the edge-cloud intelligent agent trusted execution device for AIoT physical device control may include the above-mentioned Figure 8 The illustrated edge-cloud intelligent agent trusted execution system for AIoT physical device control. Optionally, the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control may include a first processor 2001.

[0077] Optionally, the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control may also include a memory 2002 and a transceiver 2003.

[0078] The first processor 2001, memory 2002, and transceiver 2003 can be connected via a communication bus.

[0079] The following is combined Figure 9 The following is a detailed introduction to the various components of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control: The first processor 2001 is the control center of the edge-cloud intelligent agent trusted execution device 910 for controlling AIoT physical devices. It can be a single processor or a collective term for multiple processing elements. For example, the first processor 2001 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0080] Optionally, the first processor 2001 can execute various functions of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control by running or executing software programs stored in the memory 2002 and calling data stored in the memory 2002.

[0081] In a specific implementation, as one example, the first processor 2001 may include one or more CPUs, for example... Figure 9 CPU0 and CPU1 are shown in the diagram.

[0082] In a specific implementation, as one example, the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control may also include multiple processors, for example... Figure 9The first processor 2001 and the second processor 2004 are shown in the diagram. Each of these processors can be a single-core processor or a multi-core processor. Here, a processor can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0083] The memory 2002 is used to store the software program that executes the present invention, and is controlled by the first processor 2001 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0084] Optionally, the memory 2002 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 2002 may be integrated with the first processor 2001 or exist independently, and may be connected via an interface circuit of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control. Figure 9 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0085] The transceiver 2003 is used to communicate with network devices or with terminal devices.

[0086] Alternatively, transceiver 2003 may include a receiver and a transmitter. Figure 9 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0087] Optionally, the transceiver 2003 can be integrated with the first processor 2001 or exist independently, and can be connected via the interface circuit of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control. Figure 9(Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0088] It should be noted that, Figure 9 The structure of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control shown in the figure does not constitute a limitation on the router. Actual edge-cloud intelligent agent trusted execution devices for AIoT physical device control may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0089] Furthermore, the technical effects of the edge-cloud intelligent agent trusted execution device 910 for AIoT physical device control can be referred to the technical effects of the edge-cloud intelligent agent trusted execution method for AIoT physical device control described in the above method embodiments, and will not be repeated here.

[0090] It should be understood that the first processor 2001 in the embodiments of the present invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or it may be any conventional processor, etc.

[0091] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0092] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable system. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0093] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0094] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0095] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0096] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

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

[0098] In the embodiments provided by this invention, it should be understood that the disclosed devices, systems, and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0100] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

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

[0102] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A trusted execution method for edge-cloud intelligent agents in AIoT physical device control, characterized in that, The method includes: S1. Acquire input events, wherein the input events include user instructions, service events, device alarms, and planned control targets; S2. Parse the control task from the input event to identify the target device, target space, candidate control actions, and service constraints; S3. Based on the target space query device status map, extract relevant sub-graphs from the device status map to determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control authority and linkage constraints; S4. Determine the physical risk level based on the criticality level of the equipment involved in the candidate control actions, the scope of influence, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; determine the edge-cloud execution location based on the physical risk level. S5. Perform a pre-control credibility verification on the candidate control action to obtain the pre-control credibility verification result; determine the final execution strategy based on the physical risk level and the pre-control credibility verification result. S6. Issue control actions according to the final execution strategy and collect the device feedback status after execution; S7. Compare the device feedback status with the expected status. When the deviation exceeds the threshold, trigger rollback compensation and write the entire control action process into the audit record to form a control evidence chain.

2. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, The device state graph is used to describe the relationships between devices, sensors, controllers, spaces, rules, events, work orders, and audit records in an AIoT scenario; the device state graph includes nodes and edges. The nodes include device nodes, sensor nodes, controller nodes, spatial nodes, rule nodes, event nodes, work order nodes, and audit nodes. Among them, edges include perception relationships, control relationships, spatial ownership relationships, dependency relationships, interlocking relationships, influence relationships, permission relationships, rule constraint relationships, and rollback association relationships.

3. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, The physical risk levels include: R0 is a read-only sensing level that only reads device status, sensor data, or operation logs and does not have any control effects. R1 is an execution level suggestion that generates suggestions, reports, or work orders but does not directly issue control actions. R2 is a reversible control stage that involves control actions that can be recovered through rollback. R3 High Impact Control Level: Control actions involving personnel safety, business continuity, or critical equipment status; R4 prohibits automatic execution level, involving control actions such as fire linkage, power failure of critical loads, large-scale access control unlocking, or emergency evacuation.

4. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, The control evidence chain includes: source of instruction, target device, target space, control action, risk level, execution location, verification result, manual confirmation result, pre-execution state, expected state, actual feedback state, rollback compensation process, conflict arbitration grounds and responsible party.

5. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, Determining the edge-cloud execution location based on the physical risk level includes: R0 and R1 tasks are preferentially executed by the end side or edge side; R2 tasks are executed at the edge and audited asynchronously by the cloud. R3 tasks involve data collection at the edge, cloud verification, and execution after manual confirmation. R4 tasks are prohibited from being executed automatically; they only provide suggestions or prompts for authorized personnel to handle through a dedicated control system.

6. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, The final execution strategy includes: automatic execution, edge review, cloud review, manual confirmation, or prohibition of automatic execution.

7. The edge-cloud intelligent agent trusted execution method for AIoT physical device control according to claim 1, characterized in that, The pre-control trusted verification includes: instruction source verification, subject identity verification, control authority verification, device status consistency verification, business rule verification, linkage constraint verification, and risk threshold verification.

8. A trusted execution system for edge-cloud intelligent agents in AIoT physical device control, wherein the trusted execution system for edge-cloud intelligent agents in AIoT physical device control is used to implement the trusted execution method for edge-cloud intelligent agents in AIoT physical device control as described in any one of claims 1-7, characterized in that, The system includes: The event access module is used to acquire input events, including user commands, business events, device alarms, and planned control targets. The semantic parsing module is used to parse control tasks from the input events and identify target devices, target spaces, candidate control actions, and business constraints. The device status graph module is used to query the device status graph based on the target space, extract relevant subgraphs from the device status graph, and determine the current status of the target device, dependent devices, interlocking relationships, space ownership, scope of influence, control permissions, and linkage constraints. The physical risk assessment module is used to determine the physical risk level based on the criticality level of the equipment involved in the candidate control action, the scope of impact, reversibility, linkage complexity, historical anomaly rate, current environmental hazard factors, and manual confirmation requirements; and to determine the execution location of the edge-cloud based on the physical risk level. The pre-control credibility verification module is used to perform pre-control credibility verification on the candidate control actions, obtain the pre-control credibility verification result, and determine the final execution strategy based on the physical risk level and the pre-control credibility verification result. The control execution and feedback acquisition module is used to issue control actions according to the final execution strategy and to acquire the device feedback status after execution. The rollback compensation and audit module is used to compare the device's feedback status with the expected status. When the deviation exceeds a threshold, rollback compensation is triggered, and the entire process of the control action is written into the audit record to form a control evidence chain.

9. A trusted execution device for edge-cloud intelligent agents in AIoT physical device control, characterized in that, The edge-cloud intelligent agent trusted execution device for AIoT physical device control includes: processor; A memory storing computer-readable instructions that, when executed by the processor, implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1 to 7.

Images