A voice wake-up triggered local agent inference resource scheduling method and terminal

Abstract

The application discloses a voice wake-up triggered local agent reasoning resource scheduling method and a terminal; belongs to the technical field of local intelligent agent reasoning, voice interaction and edge control, the method responds to a voice wake-up event, obtains voice instruction text, computing power state and candidate device state; the voice instruction text is analyzed, and a control plan including a target device, a candidate control action and an execution condition is obtained; according to the device risk level of the target device, the action risk level of the candidate control action and the computing power state, the first resource quota for plan reasoning and the second resource quota for pre-control verification are determined; the local agent reasoning is carried out according to the first resource quota to obtain a candidate execution sequence, and the counterfactual verification is carried out on the candidate execution sequence, the candidate device state and the execution condition according to the second resource quota; according to the verification result, a local control instruction is output, or a restriction reason and a confirmation request are output, so as to reduce the risk that the pre-control verification resource is squeezed by the previous reasoning.

Description

Technical Field

[0001] This application belongs to the fields of local intelligent agent reasoning, voice interaction and edge control technology, specifically a method and terminal for scheduling local agent reasoning resources triggered by voice wake-up. Background Technology

[0002] As voice interaction terminals evolve into local agent inference terminals, upon detecting a voice wake-up event, the terminal not only needs to perform voice recognition and semantic understanding, but also needs to generate a device control plan based on user instructions and complete control judgment and instruction output locally. Existing local agent terminals typically emphasize wake-up response speed and local inference capabilities, enabling them to generate device control actions based on voice commands in offline or weak network environments. However, when it comes to control tasks involving device start / stop, mode switching, alarm deactivation, valve opening / closing, etc., simply generating a control plan is insufficient to meet the safety judgment requirements before execution. It is also necessary to determine whether the control plan will violate device interlocking relationships, current operating status, or safe execution sequence before control execution.

[0003] Existing solutions typically treat pre-control verification as an additional process after plan generation, failing to adequately consider the limited computing power of local terminals and the sharing of local resources by multiple processing stages. After voice wake-up, speech recognition, semantic parsing, agent plan generation, and dialogue response often prioritize the use of processor, inference threads, and cache resources, resulting in insufficient processing resources for interlock verification, state conflict verification, and action consequence verification. In other words, existing technologies focus more on whether voice commands can be quickly understood and control plans generated, without adequately addressing whether the pre-control verification stage still has stable processing resources and processing time limits after plan generation.

[0004] For example, in an industrial drying production line, an operator wakes up the local terminal and says, "Switch this line to maintenance mode." The local agent might generate control actions such as stopping the conveyor, shutting off the heating, reducing the fan speed, and clearing some alarm prompts. If the terminal devotes its main processing resources to understanding the voice command and generating the sequence of actions, while the pre-execution action consequence verification and interlock verification do not receive sufficient processing resources, it may not be able to determine in time whether "reducing the fan speed first and then shutting off the heating" will cause residual heat accumulation, or whether clearing alarm prompts will mask any abnormal conditions that have not yet been eliminated.

[0005] If this problem cannot be effectively resolved, the local agent may output control commands with incomplete pre-control verification processing, leading to incorrect control action sequence, equipment interlock conflicts, masking of abnormal states, or increased risks associated with manual maintenance. Especially in industrial sites, park energy control, and vehicle edge control scenarios, control plans following voice wake-up often have both real-time and security requirements. When verification processing resources are consumed by preceding voice recognition, semantic parsing, plan generation, or dialogue responses, issues such as verification timeouts, incomplete comparison of conflict states, and failure to output limiting reasons in a timely manner can easily occur, thus affecting the control reliability of the local agent terminal.

[0006] Therefore, how to balance the local resource requirements of plan inference processing and pre-control verification processing during the process of voice wake-up triggering the local agent to generate a control plan, and reduce the risk that the pre-control verification resources will be squeezed out by the preceding processing steps, resulting in the failure to limit erroneous control plans in a timely manner, has become a technical problem that needs to be solved. Summary of the Invention

[0007] This application provides a method and terminal for scheduling local agent inference resources triggered by voice wake-up, which improves the problem that after voice wake-up, the local agent terminal prioritizes the use of computing resources for speech recognition, semantic parsing, plan generation and dialogue response, resulting in insufficient pre-control verification resources and making it difficult to intercept erroneous control plans in a timely manner.

[0008] Firstly, this application provides a method for scheduling local agent inference resources triggered by voice wake-up, including: In response to a voice wake-up event detected by the local terminal, the voice command text corresponding to the voice wake-up event, the current computing power status, and the candidate device status are obtained. The voice command text is parsed to obtain a control plan that includes the target device, candidate control actions, and execution conditions; Based on the device risk level of the target device, the action risk level of the candidate control action, and the current computing power status, determine the first resource quota for planned inference and the second resource quota for pre-control verification. Based on the first resource quota, perform local agent inference on the control plan to obtain the candidate execution order; The candidate execution order, candidate device status, and execution conditions are counterfactually verified according to the second resource quota to obtain the verification result. When the verification result indicates that execution is allowed, the local control instruction corresponding to the candidate execution order is output; when the verification result indicates that execution is restricted, the reason for the restriction and a confirmation request are output.

[0009] Using the above method, this application does not passively determine whether there is remaining computing power for pre-control verification after the local agent completes the planning inference. Instead, after the voice wake-up event is triggered, it pre-allocates a first resource quota for planning inference and a second resource quota for pre-control verification, based on the target device risk, candidate control action risk, and current computing power status. This allows pre-control counterfactual verification to participate in closed-loop control as a protected processing step in high-risk control tasks, reducing the risk that candidate execution sequences are output as local control commands without sufficient verification.

[0010] In one possible implementation, obtaining the voice command text, current computing power status, and candidate device status corresponding to the voice wake-up event includes: performing endpoint detection and local speech recognition on the voice segment following the voice wake-up event to obtain the voice command text; reading the processor utilization rate, neural network processor task queue length, available cache capacity, and number of current control tasks of the local terminal to form the current computing power status; and reading the running status, alarm status, interlocking status, and mode status from the device control interface or device status cache to form the candidate device status.

[0011] This implementation method allows subsequent resource allocation to simultaneously incorporate voice command input, terminal computing power input, and device on-site status input, avoiding resource allocation based solely on voice command complexity or a fixed computing power ratio.

[0012] In one possible implementation, the equipment risk level is determined based on an equipment risk table, which includes equipment identification, equipment type, number of interlocks, downtime impact level, and human access risk level; the action risk level is determined based on an action risk table, which includes action name, action category, whether it changes the equipment operating status, whether it involves alarm deactivation, and whether it involves valves or power components; the equipment risk table and the action risk table are formed from equipment ledgers, control permission configurations, and historical anomaly records, and are stored on the local terminal.

[0013] Through this implementation method, the equipment risk level and action risk level are not vague risk assessment results, but are formed by the equipment ledger, control permission configuration and historical anomaly records that can be read by the local terminal, which can provide a reproducible basis for determining the second resource quota.

[0014] In one possible implementation, determining a first resource quota for planned inference and a second resource quota for pre-control verification includes: reading candidate values ​​for planned inference quota and candidate values ​​for verification quota from a resource reservation mapping table based on the device risk level of the target device, the action risk level of the candidate control action, and the current computing power status; reading the device high-risk determination field corresponding to the target device and the action high-risk determination field corresponding to the candidate control action; when the device risk level reaches the level boundary recorded in the device high-risk determination field, or the action risk level reaches the level boundary recorded in the action high-risk determination field, a verification quota priority guarantee method is adopted, first determining the candidate value for verification quota as the second resource quota, and then determining the first resource quota based on the candidate value for planned inference quota and the current remaining computing power after deducting the second resource quota; when neither the device risk level nor the action risk level reaches the corresponding level boundary, a proportional allocation method is adopted, dividing the current remaining computing power into the first resource quota and the second resource quota according to the low-risk planned inference ratio and the low-risk verification ratio in the resource reservation mapping table.

[0015] This implementation method allows pre-control verification resources to be prioritized in high-risk devices or high-risk action scenarios, avoiding the compression of security verification resources due to excessive computing power consumed by local agent plan search, dialogue generation, or multi-round interactions.

[0016] In one possible implementation, the resource reservation mapping table includes risk combination conditions, minimum number of verification threads, minimum verification time slice, minimum cache usage, maximum search depth for planned inference, and dialogue response degradation flag. The resource reservation mapping table is generated based on local terminal hardware specifications, device control cycle, historical control plan length, and counterfactual verification time test results. When the current remaining computing power is insufficient to simultaneously meet the candidate values ​​for planned inference quota and verification quota, the maximum search depth for planned inference is reduced or the dialogue response degradation flag is enabled.

[0017] This implementation method clarifies the basis for the formation of the resource reservation mapping table, the calling method, and the output content, so that the allocation of resource quotas does not rely solely on abstract strategies, but can be read and executed by the local terminal according to the table entries.

[0018] In one possible implementation, obtaining the candidate execution order includes: limiting the planned inference time slice, the number of candidate actions to be deployed, and the planned search depth of the local agent according to the first resource quota; reading the target device, candidate control actions, and execution conditions in the control plan to generate at least one candidate action sequence; reading the candidate device status and the execution conditions, checking the action preconditions in each candidate action sequence item by item, and deleting candidate action sequences that do not meet the candidate device status or the execution conditions; sorting the remaining candidate action sequences level by level according to the action sequence sorting table, and determining the candidate action sequence that is sorted first as the candidate execution order.

[0019] In this implementation, the first resource quota is not an abstract resource name, but rather participates in local agent inference by limiting the time slice of the plan inference, the number of candidate action unfoldings, and the plan search depth. This can transform the control plan into a candidate execution order and provide explicit input for subsequent counterfactual verification.

[0020] In one possible implementation, obtaining the verification result includes: copying the candidate device state within the verification thread, verification time slice, and cache space limited by the second resource quota to form a temporary device state; reading candidate control actions one by one according to the candidate execution order, and simulating writing each candidate control action into the temporary device state to obtain a post-action temporary state; comparing each post-action temporary state with interlocking rules, state conflict rules, and safety order rules, and comparing the time triggering condition, state triggering condition, manual confirmation condition, and prohibition condition in the execution conditions with the post-action temporary state to generate the verification result.

[0021] With this implementation method, the local terminal can simulate the execution consequences of candidate control actions in a temporary device state before actually outputting control commands, instead of directly writing actions to the device control interface, thereby achieving counterfactual verification before control.

[0022] In one possible implementation, the interlocking rules include device identifiers, interlocked device identifiers, prohibited actions, and prohibited state combinations; the state conflict rules include the current operating mode, candidate switching modes, and prohibited switching conditions; the safety sequence rules include preceding actions, subsequent actions, and allowed time relationships; when a temporary state after any action matches the prohibited state combination, the prohibited switching condition, or does not meet the allowed time relationship, the verification result is determined as restricted execution, and the corresponding restriction reason is recorded.

[0023] This implementation method allows the counterfactual verification results to have a clear source, making it easier to output the reasons for the restriction to the operators, and also facilitating the subsequent review of the intercepted control plan.

[0024] In one possible implementation, during the counterfactual verification process according to the second resource quota, if the simulation verification of all candidate control actions in the candidate execution order is not completed within the verification time slice corresponding to the second resource quota, or the cache space corresponding to the second resource quota is insufficient to copy the candidate device state, or the time difference between the sampling time of the candidate device state and the current verification time is greater than the preset state validity period, or the interlocking rule, state conflict rule, or security sequence rule corresponding to the target device is missing, then the verification result is determined as restricted execution; the reason for the restriction is recorded as the type of insufficient verification resources, the number of candidate control actions that have not completed the simulation verification, the number of candidate control actions that have completed the simulation verification, the verification timeout flag, the state expiration flag, or the rule missing flag.

[0025] With this implementation method, when the local terminal has insufficient computing power or the pre-control verification cannot be completed, this application does not allow the candidate execution order by default, but keeps the control plan that has not been fully verified in a restricted execution state, thereby forming a closed relationship between the second resource quota and the pre-control security interception.

[0026] Secondly, this application provides a voice wake-up triggered local agent inference terminal for implementing any of the aforementioned voice wake-up triggered local agent inference resource scheduling methods. The terminal includes a wake-up acquisition module, an intent parsing module, a resource scheduling module, an agent inference module, a counterfactual verification module, and a control output module.

[0027] The wake-up acquisition module is used to respond to a voice wake-up event detected by the local terminal and acquire the voice command text corresponding to the voice wake-up event, the current computing power status, and the candidate device status. The intent parsing module is used to perform intent parsing on the voice command text to obtain a control plan including the target device, candidate control actions, and execution conditions. The resource scheduling module is used to determine a first resource quota for plan inference and a second resource quota for pre-control verification based on the device risk level of the target device, the action risk level of the candidate control actions, and the current computing power status. The agent inference module is used to perform local agent inference on the control plan according to the first resource quota to obtain a candidate execution order. The counterfactual verification module is used to perform counterfactual verification on the candidate execution order, the candidate device status, and the execution conditions according to the second resource quota to obtain a verification result. The control output module is used to output a local control instruction corresponding to the candidate execution order when the verification result is "allow execution" and output the restriction reason and confirmation request when the verification result is "restricted execution".

[0028] Compared with related technologies, this application has the following advantages: In general, this application obtains the voice command text, current computing power status, and candidate device status after the voice wake-up event is triggered. The voice command text is then parsed into a control plan that includes the target device, candidate control actions, and execution conditions. Based on the device risk level of the target device, the action risk level of the candidate control actions, and the current computing power status, a first resource quota for plan inference and a second resource quota for pre-control verification are determined. This ensures that the local agent's plan inference and pre-control verification no longer share undifferentiated remaining computing power resources. Instead, they complete candidate execution order generation and counterfactual verification within their respective resource quotas, thereby reducing the risk that pre-control verification resources will be squeezed out by pre-processing such as speech recognition, semantic parsing, plan generation, or dialogue response.

[0029] First, this application responds to the voice wake-up event detected by the local terminal and simultaneously obtains the voice command text, the current computing power status, and the candidate device status. This enables the subsequent control plan generation and resource quota determination to not only be processed based on the user's voice command, but also to be judged in combination with the real-time computing power conditions of the local terminal and the current status of the device. This reduces the situation where the control plan is generated solely based on the content of the voice command while ignoring the constraints of local resource load and device status.

[0030] Second, this application obtains a control plan including the target device, candidate control actions, and execution conditions by performing intent parsing on the voice command text. This enables the voice control commands in natural language form to be converted into structured objects that can be read by local agent reasoning and pre-control verification, thereby providing a unified input for subsequent resource scheduling, sequential reasoning, and verification judgment based on device risk level, action risk level, and execution conditions.

[0031] Third, this application determines the first resource quota for planning inference and the second resource quota for pre-control verification based on the device risk level of the target device, the action risk level of the candidate control action, and the current computing power status. This makes the local agent's planning inference and pre-control verification subject to resource quota constraints, thereby reducing the risk that the processing of planning inference, dialogue response, etc., will excessively occupy processor time slices, inference threads, or cache space and affect the execution of pre-control verification.

[0032] Fourth, this application obtains the candidate execution order by performing local agent reasoning on the control plan according to the first resource quota, so that the candidate control actions in the control plan can form a verifiable action sequence within the limited local reasoning resources, thereby avoiding the local agent from continuously expanding the plan search process when resources are not constrained, and providing clear action sequence input for subsequent counterfactual verification.

[0033] Fifth, this application obtains the verification result by performing counterfactual verification on the candidate execution order, candidate device status, and execution conditions according to the second resource quota. This enables the local terminal to make a pre-execution judgment on the matching relationship between the candidate execution order and the device status and execution conditions before outputting control instructions, thereby reducing the risk that control plans with incorrect control action order, conflicting device status, or unmet execution conditions will be directly output as local control instructions.

[0034] Sixth, this application outputs local control instructions corresponding to the candidate execution order when the verification result is allowed to execute, and outputs the reason for restriction and confirmation request when the verification result is restricted to execute. This enables the local terminal to generate differentiated outputs based on the pre-control verification results. For control plans that fail the verification, local control instructions are not directly output, but the reason for restriction and confirmation request are output. This makes it easier for operators to know the specific reasons why the control plan is restricted and provides a basis for subsequent manual review or reconfirmation. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments are briefly described below. Obviously, the accompanying drawings described below are only some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of an application environment for a local agent inference terminal triggered by voice wake-up, provided in an embodiment of this application. Figure 2 This is a flowchart of a local agent inference resource scheduling method triggered by voice wake-up provided in an embodiment of this application; Figure 3 This is a flowchart of a voice command text parsing into a control plan provided in an embodiment of this application; Figure 4 This is a flowchart of a counterfactual verification process provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a local agent inference terminal triggered by voice wake-up provided in an embodiment of this application. Detailed Implementation

[0037] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only some embodiments of this application, and not all embodiments. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application.

[0038] In the embodiments of this application, the terms "first" and "second" are used only to distinguish similar objects and do not indicate a specific order or degree of importance. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion. The term "module" can be implemented by software, hardware, or a combination of software and hardware. The term "Agent" refers to an intelligent agent program capable of generating task plans and invoking local tools or control interfaces based on input instructions. CPU refers to the Central Processing Unit, and NPU refers to the Neural Processing Unit.

[0039] like Figure 1 As shown in the embodiments of this application, the local agent inference terminal can be deployed in industrial production line control cabinets, park energy control terminals, vehicle-mounted edge control terminals, or other local control scenarios. The local agent inference terminal may include a voice acquisition component, a local voice recognition module, a local agent inference module, a device status interface, a device control interface, and a security verification module. The device status interface is used to read the status of candidate devices, and the device control interface is used to output local control commands after verification is allowed. The aforementioned terminal can perform voice recognition, intent parsing, plan inference, resource scheduling, and pre-control verification in offline or weak network environments.

[0040] like Figure 2 As shown, this application embodiment provides a local agent inference resource scheduling method triggered by voice wake-up, which can be executed by a local agent inference terminal. The method includes steps S101 to S106.

[0041] Step S101: In response to the voice wake-up event detected by the local terminal, obtain the voice command text, current computing power status and candidate device status corresponding to the voice wake-up event.

[0042] In this step, the local terminal continuously collects ambient speech through a microphone array, a single microphone, or other speech acquisition components, and inputs the ambient speech into the wake-up detection module. The wake-up detection module can be implemented using existing technologies, such as keyword matching models, acoustic wake-up models, or local speech wake-up algorithms to detect the speech wake-up word. The input to the wake-up detection module is the ambient speech, and the processing method involves comparing the ambient speech with the acoustic features or textual features of the wake-up word, outputting a speech wake-up event. The improvement focus of this application is not on the wake-up detection algorithm itself, but on how to allocate resources for local agent inference and pre-control verification after the speech wake-up event is triggered.

[0043] When a wake-up word is detected, the local terminal generates a voice wake-up event. The voice wake-up event may include the wake-up time, wake-up channel identifier, wake-up confidence level, and the starting position of the voice buffer after wake-up.

[0044] Upon detecting a voice wake-up event, the local terminal reads subsequent voice segments starting from the beginning of the wake-up voice buffer and performs endpoint detection on these segments. Endpoint detection can be performed based on short-time energy, zero-crossing rate, a voice activity detection model, or silence duration rules. For example, the local terminal can consider audio frames with continuous voice energy greater than a voice energy threshold as valid voice frames and determine the end of a voice segment when the continuous silence duration reaches a silence end threshold. This voice energy threshold and silence end threshold can be set by the local terminal during the installation and debugging phase based on environmental noise sampling results and stored in the local voice configuration table.

[0045] The local terminal performs local speech recognition on valid speech segments to obtain voice command text. Speech recognition can be implemented using existing technologies, such as a local speech recognition method combining acoustic and language models, an end-to-end speech recognition model, or a miniaturized speech recognition model. The input to speech recognition is a valid speech segment, and the output is the voice command text, word-level confidence score, and speech timestamp. The improvement focus of this application is not on the speech recognition model itself, but on using the voice command text as input for subsequent control plan generation and resource scheduling.

[0046] If the word-level confidence level is lower than the preset recognition confidence threshold, the local terminal can mark low-confidence words in the voice command text and write them into the confirmation field during subsequent intent parsing. The preset recognition confidence threshold can be determined based on the test recognition results of the local speech recognition model in the installation scenario, for example, by selecting a confidence boundary that ensures the false recognition rate is lower than the acceptance requirements. The confirmation field, together with the device non-unique field and the parameter confirmation field, constitutes part of the execution conditions when the control plan is subsequently generated, and is used to generate a confirmation request when restricting execution.

[0047] Simultaneously, the local terminal reads the current computing power status. The current computing power status can consist of at least two of the following: processor utilization, NPU task queue length, available cache capacity, number of current control tasks, number of current speech recognition tasks, and number of current dialogue response tasks. Processor utilization can be read from the operating system task management interface, NPU task queue length can be read from the local inference runtime interface, available cache capacity can be read from the memory management interface, and the number of current control tasks can be read from the control task queue. After reading, the local terminal generates a current computing power status record in the form of fields. This record is used in step S103 to determine the first resource quota and the second resource quota.

[0048] The local terminal also reads the candidate device status. The candidate device status can be a set of candidate device statuses, sourced from the device controller, programmable logic controller, vehicle controller, park energy controller, or local device status cache. Candidate device statuses may include device identifier, current operating status, current mode status, alarm status, interlock status, manual maintenance identifier, device controllable identifier, and the most recent control command. Reading can be done periodically from the device status cache or actively queried via the device status interface after a voice wake-up event. Once generated, the candidate device statuses are used in subsequent counterfactual verification steps to extract the operating status, alarm status, interlock status, and mode status of the target device and its associated interlocked devices.

[0049] When the local terminal fails to read the candidate device status from the device control interface, it reads the most recent valid status from the local device status cache and compares the sampling time of the most recent valid status with the current time. The preset status validity duration is determined based on the device status acquisition cycle and the control response cycle; if the device status acquisition cycle is a fixed cycle, the preset status validity duration is not less than one acquisition cycle and not greater than the control response cycle. When the time difference between the sampling time of the most recent valid status and the current time is not greater than the preset status validity duration, the most recent valid status is used as the candidate device status and written into the status source identifier; when the time difference is greater than the preset status validity duration, a candidate device status can still be generated, but a status expiration identifier is written into the candidate device status for the counterfactual verification in step S105 to determine whether to restrict execution.

[0050] Step S102: Perform intent parsing on the voice command text to obtain a control plan including the target device, candidate control actions, and execution conditions.

[0051] like Figure 3 As shown, the local terminal reads the voice command text obtained in step S101 and performs normalization processing on the voice command text. Normalization processing may include removing interjections, replacing synonymous control words with standard control words, and replacing colloquial device names with standard device names from the device list. Standard control words and standard device names can be stored in the local action dictionary and the local device list. The local device list can be imported from the device ledger and includes at least the device identifier, device name, device alias, device type, and device control interface address. The local action dictionary can be generated from control permission configuration and device control command sets and includes at least the action name, action alias, action category, action parameter requirements, and control interface commands.

[0052] The local terminal performs word segmentation and sentence segmentation on the standardized voice command text, identifying device name words, control action words, time condition words, status condition words, and human confirmation words. The identification method can employ dictionary matching, a lightweight semantic classification model, or a combination of both. During dictionary matching, the local terminal compares the text words with the device names and aliases in the local device list item by item, obtaining device name words upon matching. It also compares the text words with the action names and aliases in the local action dictionary item by item, obtaining control action words upon matching. Words indicating time relationships such as "now," "five minutes later," and "after maintenance is completed" are used as time condition words. Words indicating status relationships such as "temperature is below the upper limit," "after alarm is cleared," and "after fan stops" are used as status condition words. Words indicating "after confirmation," "after the person in charge agrees," and "authorization required" are used as human confirmation words.

[0053] The lightweight semantic classification model can be implemented using existing text classification models, such as rule-enhanced Naive Bayes classification models, small Transformer text classification models, or local intent classification models. The input to this lightweight semantic classification model is normalized speech command text. The processing method involves classifying words or phrases in the text, and the output is the label results for device name words, control action words, time condition words, state condition words, and human confirmation words. It should be noted that the improvement focus of this application is not on the lightweight semantic classification model itself, but on forming a continuous processing chain between its output results and control plan generation, resource allocation determination, and counterfactual verification.

[0054] The local terminal compares the device name with the local device list to obtain at least one candidate target device. For each candidate target device, the local terminal reads the current controllable identifier, the device's region, and the location word in the voice command text from the candidate device status. First, it deletes candidate target devices whose current controllable identifier is uncontrollable. Among the remaining candidate target devices, if the voice command text contains a location word, it retains the candidate target device whose region matches the region corresponding to the location word. If only one candidate target device remains, it is determined as the target device. If multiple candidate target devices remain, and one of them has a device name or alias that is completely identical to the device name, it is determined as the target device. If multiple candidate target devices still exist, or the voice command text does not contain a location word sufficient to distinguish the device's region, it is determined that the target device cannot be uniquely identified, the control plan is marked as a pending confirmation plan, and the "device not unique" field is written into the pending confirmation field of the control plan. The target device includes a device identifier, device type, and device control interface address.

[0055] When the same voice command involves multiple target devices, the local terminal generates multiple device control objects according to the order in which device names appear in the voice command text, and reads the interlocking relationships between devices in the device interlocking configuration. If there is no interlocking relationship between multiple devices, candidate control actions are generated for each device separately; if there is an interlocking relationship between multiple devices, the multiple device control objects are merged into a single multi-device control plan, and multi-device interlocking check conditions are written into the execution conditions. This multi-device control plan is used by the subsequent local agent inference steps to generate cross-device candidate execution order.

[0056] The local terminal compares the control action words with the action dictionary to obtain candidate control actions. Candidate control actions include the action name, action category, action parameters, and corresponding control interface command. If the voice command does not explicitly specify action parameters, the local terminal reads the default parameter requirements from the action dictionary; if the default parameter requirements indicate that manual confirmation is required, a parameter confirmation condition is written into the execution conditions, and the parameter confirmation field is written into the confirmation field of the control plan.

[0057] The local terminal merges time-triggered words, status-triggered words, manual confirmation words, and fields awaiting confirmation into execution conditions. Execution conditions can include time-triggered conditions, status-triggered conditions, manual confirmation conditions, prohibition conditions, and fields awaiting confirmation. Time-triggered conditions limit the execution time or waiting duration of control actions; status-triggered conditions limit the execution based on the device's state; manual confirmation conditions limit whether authorized personnel confirmation is required; prohibition conditions record actions or states explicitly prohibited in voice commands; and fields awaiting confirmation record low-confidence words, non-unique device fields, and parameter fields awaiting confirmation.

[0058] For example, the voice command text is "Lower the fan of drying line No. 1, wait until the temperature is below 60 degrees Celsius, then switch to maintenance mode, and have the team leader confirm." After recognizing the voice command text, the local terminal identifies "fan" and "drying line No. 1" as equipment name words, "lower" and "switch to maintenance mode" as control action words, "wait until the temperature is below 60 degrees Celsius" as a status condition word, and "have the team leader confirm" as a manual confirmation word.

[0059] When the local terminal compares the command "reduce" with the action dictionary, it determines that the corresponding candidate control action is "reduce fan speed" and the action category is "adjust operating parameters". If the voice command text does not explicitly state the target fan speed, the local terminal reads the default parameter requirement corresponding to "reduce fan speed" in the action dictionary. When the default parameter requirement states "If no target speed is given, manual confirmation of the target speed or use of a preset safe speed reduction gear is required", the local terminal writes the parameter confirmation condition into the execution conditions and writes "target fan speed not specified" into the parameter confirmation field of the control plan.

[0060] When the local terminal compares "switch to maintenance mode" with the action dictionary, it determines that the corresponding candidate control action is "switch maintenance mode," the action category is "operation mode switch," and reads its corresponding control interface command. Subsequently, the local terminal writes "temperature below 60 degrees Celsius" into the status trigger condition, "team leader confirmation" into the manual confirmation condition, and "fan target speed not clear" into the pending confirmation condition, thus forming the execution conditions. These execution conditions are used by the subsequent local agent to infer and generate candidate execution sequences, and by the counterfactual verification step to determine whether the temporary state after the action meets the temperature condition, the manual confirmation condition, and the parameter confirmation condition.

[0061] After the above processing is completed, the local terminal generates a control plan. The control plan includes the target device, candidate control actions, execution conditions, resolution confidence level, and fields to be confirmed. This control plan is used by the subsequent resource quota determination step to read the target device and candidate control actions, and also by the subsequent local agent inference step to read and generate candidate execution order.

[0062] Step S103: Based on the equipment risk level of the target device, the action risk level of the candidate control action, and the current computing power status, determine the first resource quota for planning inference and the second resource quota for pre-control verification.

[0063] The local terminal reads the target device and candidate control actions obtained in step S102, and reads the locally stored device risk table and action risk table. The device risk table includes device identifier, device type, number of interlocks, shutdown impact level, human proximity risk level, and device risk level. The action risk table includes action name, action category, whether it changes the equipment operating status, whether it involves alarm deactivation, whether it involves valves or power components, whether sequential protection is required, and action risk level.

[0064] The setup method for the equipment risk table can include equipment ledgers, equipment interlock configurations, equipment control permission configurations, and historical anomaly records. Specifically, the local terminal or configuration tool reads the equipment type and downtime impact description from the equipment ledger, the number of interlocked devices from the interlock configuration, the manual access restrictions from the control permission configuration, and the number and type of anomalies from the historical anomaly records; these items are then mapped to equipment risk levels according to the equipment risk configuration rules. Equipment risk levels can be categorized into three levels: low, medium, and high risk, or into five levels. For ease of local execution, equipment risk levels are stored as table entries, and the current step retrieves the information by looking up the table using the target equipment's equipment identifier.

[0065] The method for setting up the action risk table can include equipment control command sets, control permission configurations, alarm configurations, and historical control interception records. For actions that change equipment start / stop status, change operating modes, clear alarm prompts, open or close valves, or change the speed of power components, a higher action risk level can be configured; for actions that only read status, only display information, or do not change equipment status, a lower action risk level can be configured. Action risk levels are also stored in the form of table entries, and the current step retrieves the information by looking up the action name of the candidate control action.

[0066] For example, in an industrial drying production line scenario, the equipment ledger records that the "No. 1 Drying Line Heater" is a heating device with a high downtime impact level. The equipment interlock configuration shows that this heater is interlocked with the circulating fan, exhaust damper, and temperature alarm unit, with three interlocked devices. The equipment control permission configuration indicates that there is a risk of human access to this heater during maintenance. The historical anomaly record shows that this heater has triggered two residual heat alarms within a preset statistical period. After reading the above items, the configuration tool configures the equipment risk level of "No. 1 Drying Line Heater" as high risk according to the equipment risk configuration rules, and writes the equipment identifier, equipment type, number of interlocks, downtime impact level, human access risk level, and equipment risk level into the equipment risk table. In the current step, when the target equipment is "No. 1 Drying Line Heater," the corresponding equipment risk level is read from the equipment risk table using the equipment identifier.

[0067] For example, the equipment control commands are recorded as actions such as "switching maintenance mode," "shutting down heating," "reducing fan speed," and "reading current temperature." For "switching maintenance mode," the control permission configuration records that this action requires confirmation from the maintenance supervisor, and that this action changes the equipment's operating mode; therefore, the action risk table sets the action risk level for this action as high risk. For "shutting down heating," because this action changes the heater's start / stop status and may affect the waste heat dissipation sequence, the action risk level is set as medium or high risk. For "reading current temperature," because this action only reads the status and does not change the equipment's operating status, the action risk level is set as low risk. In the current step, when the candidate control action is "switching maintenance mode," the corresponding action category, whether it changes the equipment's operating status, whether manual confirmation is required, and the action risk level are read from the action risk table by action name. The read action risk level and the target equipment's equipment risk level are then used as the lookup input for the resource reservation mapping table.

[0068] To ensure that subsequent high-risk assessments have a readable basis, a high-risk determination field is simultaneously written to the local terminal or configuration tool when generating the device risk table and action risk table. Specifically, the high-risk determination field in the device risk table records the boundary of the device risk level that prioritizes resource protection before triggering control, and the high-risk determination field in the action risk table records the boundary of the action risk level that prioritizes resource protection before triggering control. If the device risk level or action risk level uses three levels—low risk, medium risk, and high risk—the corresponding high-risk determination field records it as high risk; if the device risk level or action risk level uses five levels, the corresponding high-risk determination field records it as level four and level five. The high-risk determination field is determined by the device safety acceptance rules, control permission configuration, and historical anomaly records, and is stored in the device risk table and action risk table, respectively, along with the device risk level and action risk level. The current step reads the equipment risk level and high-risk determination field corresponding to the target equipment, reads the action risk level and high-risk determination field corresponding to the candidate control action, and compares them respectively. When the equipment risk level reaches the level boundary recorded in the high-risk determination field, or the action risk level reaches the level boundary recorded in the high-risk determination field, it is determined that the current control plan belongs to a high-risk equipment or high-risk action scenario. The judgment result is used as the lookup input of the resource reservation mapping table to determine whether to use the verification quota candidate value as the priority guarantee quota.

[0069] For example, in an industrial drying production line scenario, the equipment risk level of "Exhaust Door No. 2" in the equipment risk table is represented by three levels: low risk, medium risk, and high risk. The configuration tool, based on equipment safety acceptance rules and control permissions, determines that any equipment whose exhaust channel closure might affect waste heat dissipation, and whose equipment risk level reaches high risk, requires priority for pre-control verification resources. Therefore, in the equipment risk table entry corresponding to "Exhaust Door No. 2," the high-risk determination field is recorded as high risk. When the current step reads that the target equipment is "Exhaust Door No. 2," its equipment risk level is read as medium risk from the equipment risk table, and simultaneously, the high-risk determination field is read as high risk. Since medium risk does not reach the level boundary recorded in the high-risk determination field, the local terminal does not separately determine it as a high-risk equipment scenario based solely on the equipment risk level.

[0070] For example, the action risk table records the action risk level of "Cancel Residual Heat Alarm" as level 1 to 5. Based on alarm configuration, control permission configuration, and historical control interception records, the configuration tool determines that both level 4 and level 5 actions may affect alarm display or safety alerts, requiring priority to ensure pre-control verification resources. Therefore, in the action risk table entry corresponding to "Cancel Residual Heat Alarm," the high-risk judgment field is recorded as level 4 and level 5. When the current step reads the candidate control action as "Cancel Residual Heat Alarm," it reads its action risk level as level 4 from the action risk table, and simultaneously reads the high-risk judgment field as level 4 and level 5. Since level 4 reaches the level boundary recorded in the high-risk judgment field, the local terminal determines that the current control plan belongs to a high-risk action scenario, and uses this judgment result, along with the current computing power status, as the lookup input for the resource reservation mapping table to determine whether to prioritize the verification quota candidate value.

[0071] The local terminal reads the current computing power status obtained in step S101 and determines the remaining processor time slice, available inference threads, and remaining cache space based on the current computing power status. Specifically, the local terminal calculates the remaining processor time slice based on the processor utilization rate and the preset control cycle; determines the available inference threads based on the NPU task queue length and the number of parallelizable tasks during local inference; and obtains the remaining cache space after deducting the speech recognition cache, control task cache, and dialogue response cache from the available cache capacity. The remaining processor time slice, available inference threads, and remaining cache space together constitute the current remaining computing power, which is used for resource reservation mapping table lookup and resource deduction processing.

[0072] The local terminal uses the device risk level, action risk level, and current computing power status as lookup inputs to search for matching risk combination conditions in the resource reservation mapping table. The resource reservation mapping table includes risk combination conditions, minimum number of verification threads, minimum verification time slice, minimum cache usage, maximum search depth for planned inference, planned inference time slice, and dialogue response degradation flag. Risk combination conditions can be formed based on device risk level and action risk level, such as "high-risk device and high-risk action," "high-risk device and medium-risk action," "medium-risk device and high-risk action," and "low-risk device and low-risk action."

[0073] The method for forming the resource reservation mapping table includes local terminal hardware specifications, device control cycle, historical control plan length, number of candidate device status fields, and counterfactual verification time test results. The resource reservation mapping table may include hardware specification identifiers, device control cycle, risk combination conditions, candidate action number range, device status field number range, candidate plan inference time slice value, candidate plan inference maximum search depth value, minimum number of verification threads, minimum verification time slice, minimum cache usage, low-risk plan inference ratio, low-risk verification ratio, and dialogue response degradation identifier.

[0074] When the resource reservation mapping table is set for the first time, the local terminal or configuration tool reads the local terminal hardware specifications, which include the number of processor cores, whether the NPU is available, the number of parallel inference threads, and the cache capacity available for control tasks. These hardware specifications are then combined and written into the hardware specification identifier. The device control cycle is determined by the device controller configuration, the allowed response time of the device control task, or the on-site control acceptance requirements. When the same control plan involves multiple controlled devices, the shortest allowed response time of the control task among the multiple controlled devices is selected as the device control cycle.

[0075] Risk combination conditions are generated based on the equipment risk level, action risk level, and high-risk determination field. Specifically, the local terminal or configuration tool reads the equipment risk level and high-risk determination field from the equipment risk table, and the action risk level and high-risk determination field from the action risk table; the equipment risk level and action risk level are combined to form risk combination conditions. If the equipment risk level reaches the level boundary recorded in the high-risk determination field, or the action risk level reaches the level boundary recorded in the high-risk determination field, the corresponding risk combination condition is marked as a high-risk combination; if neither the equipment risk level nor the action risk level reaches the level boundary recorded in the corresponding high-risk determination field, the corresponding risk combination condition is marked as a low-risk combination.

[0076] The range of candidate action numbers is set based on the length of the historical control plan and the action dependencies in the action dictionary. Specifically, the local terminal or configuration tool reads the number of candidate control actions contained in each control plan in the historical control log, and reads the number of pre-, post-, and mutually exclusive actions associated with each candidate control action in the action dictionary. When the historical control log is insufficient, a test control plan containing one to six candidate control actions is constructed according to the action dictionary. Based on the number of candidate control actions in the aforementioned historical or test control plans, the range of candidate action numbers is set to no more than two actions, three to four actions, or five to six actions. If the field control task allows for control plans with more than six candidate control actions, then the range of more than six actions is added.

[0077] The range of the number of device status fields is set based on the candidate device status template. Specifically, the local terminal or configuration tool reads the target device status template and the associated interlocking device status template, and counts the number of status fields that need to be copied and compared during counterfactual verification. These status fields include operating status, alarm status, interlocking status, mode status, manual maintenance indicator, device controllability indicator, and the most recent control command. Based on the counted number of status fields, the range of the number of device status fields is set to no more than ten fields, eleven to twenty fields, or twenty-one to thirty fields. If the number of status fields for the target device and its associated interlocking devices exceeds thirty, an additional range of more than thirty fields is added.

[0078] The candidate values ​​for the planned inference time slice and the candidate values ​​for the planned inference maximum search depth are set based on the local agent inference test results. Specifically, during the installation or factory testing phase, the local terminal or configuration tool constructs a test control plan for each range of candidate action quantities and executes local agent inference tests at plan search depths of one, two, three, and four, respectively, recording the inference time required to generate the candidate execution order at each plan search depth. For each range of candidate action quantities, the minimum plan search depth that can generate a candidate execution order that satisfies the action preconditions and execution conditions is selected as the candidate value for the planned inference maximum search depth, and the inference time actually measured at that plan search depth is written into the candidate value for the planned inference time slice; if multiple test control plans correspond to different inference times, the maximum inference time among them is taken as the candidate value for the planned inference time slice for that range.

[0079] The minimum number of verification threads, minimum verification time slice, and minimum cache usage are set based on the counterfactual verification test results. Specifically, during the installation or factory testing phase, the local terminal or configuration tool constructs corresponding candidate execution orders and candidate device states for each range of candidate action quantity and each range of device state field quantity. Then, it tests the verification time and cache usage required to complete interlock rule comparison, state conflict rule comparison, and safe order rule comparison under one verification thread, two verification threads, and more verification threads. For each range of candidate action quantity and device state field quantity, the minimum number of threads that can complete all counterfactual verifications within the device control cycle is selected as the minimum number of verification threads, the maximum verification time actually measured under this number of threads is selected as the minimum verification time slice, and the maximum cache usage actually used when copying candidate device states, forming temporary device states, and reading rule table entries is selected as the minimum cache usage.

[0080] The low-risk plan inference ratio and low-risk verification ratio are set based on the candidate values ​​of the plan inference time slice and the minimum verification time slice under the low-risk combination. Specifically, the local terminal or configuration tool selects a test control plan with a low-risk combination condition and reads its candidate values ​​of the plan inference time slice and the minimum verification time slice. When the candidate value of the plan inference time slice is greater than the minimum verification time slice, the low-risk plan inference ratio is set higher than the low-risk verification ratio; when the minimum verification time slice is greater than the candidate value of the plan inference time slice, the low-risk verification ratio is set higher than the low-risk plan inference ratio; when the difference between the two is within a preset range, the low-risk plan inference ratio and the low-risk verification ratio are set to be the same. The low-risk verification ratio must not be lower than the ratio boundary that can meet the minimum number of verification threads, the minimum verification time slice, and the minimum cache usage.

[0081] The dialogue response degradation flag is set based on risk combination conditions and resource availability. Specifically, when the risk combination conditions are high-risk, or the current remaining computing power is insufficient to simultaneously meet the candidate values ​​for both the planned inference quota and the verification quota, the dialogue response degradation flag in the resource reservation mapping table is set to enabled. When the risk combination conditions are low-risk and the current remaining computing power can simultaneously meet the candidate values ​​for both the planned inference quota and the verification quota, the dialogue response degradation flag is set to disabled. When the dialogue response degradation flag is enabled, the local terminal reduces the generation of natural language interpretations, pauses unnecessary voice broadcasts, or only outputs a brief prompt asking whether execution is allowed, in order to free up processor time slices, inference threads, and cache space.

[0082] When the local terminal is running, it first reads the number of candidate control actions in the control plan and determines the range of candidate action numbers based on the pre- and post-action actions associated with the candidate control actions in the action dictionary. Then, it reads the number of status fields of the target device and its associated interlocking devices in the candidate device status to determine the range of device status field numbers. Subsequently, it uses the risk combination conditions, the range of candidate action numbers, the range of device status field numbers, the hardware specification identifier, and the device control cycle as lookup inputs to read the corresponding candidate values ​​for plan inference time slices, maximum search depth, minimum number of verification threads, minimum verification time slice, minimum cache usage, low-risk plan inference ratio, low-risk verification ratio, and dialogue response degradation identifier from the resource reservation mapping table. Among these, the candidate values ​​for plan inference time slices and maximum search depth constitute the candidate values ​​for plan inference quota; the minimum number of verification threads, minimum verification time slice, and minimum cache usage constitute the candidate values ​​for verification quota.

[0083] In low-risk device and low-risk action scenarios, the local terminal generates a first resource quota and a second resource quota using a proportional allocation method. Specifically, the local terminal reads the low-risk planned inference ratio and the low-risk verification ratio from the resource reservation mapping table, allocates the current remaining processor time slices to planned inference according to the low-risk planned inference ratio, and allocates the current remaining processor time slices to pre-control verification according to the low-risk verification ratio; at the same time, it divides the current remaining cache space and available inference threads according to the same proportional relationship. After the division, the local terminal compares the processor time slices, available inference threads, and cache space allocated to planned inference with the candidate values ​​of planned inference time slices and the candidate values ​​of the maximum search depth of planned inference, and selects the resource combination that does not exceed the current remaining computing power and meets the candidate values ​​of the planned inference quota as the first resource quota; it compares the processor time slices, available inference threads, and cache space allocated to pre-control verification with the minimum number of verification threads, the minimum verification time slice, and the minimum cache usage, and selects the resource combination that meets the candidate values ​​of the verification quota as the second resource quota.

[0084] In high-risk equipment or high-risk action scenarios, the local terminal uses a verification quota priority guarantee method to generate a first resource quota and a second resource quota. Specifically, the local terminal first determines the lowest number of verification threads, the lowest verification time slice, and the lowest cache usage among the verification quota candidate values ​​as the second resource quota; then, it deducts the resource amount corresponding to the second resource quota from the current remaining processor time slice, the number of available inference threads, and the remaining cache space to obtain the remaining resources available for planned inference; then, it compares the remaining resources available for planned inference with the planned inference quota candidate values. If the remaining resources can satisfy the planned inference time slice candidate value and the planned inference maximum search depth candidate value, the corresponding resource combination is determined as the first resource quota; if the remaining resources are insufficient to satisfy the planned inference quota candidate value, the planned inference maximum search depth is reduced, the number of candidate actions is reduced, or a dialogue response degradation flag is enabled, and the downgraded resource combination is determined as the first resource quota.

[0085] If the remaining computing power is insufficient to simultaneously satisfy both the candidate values ​​for planned inference and verification, the local terminal will first reduce the maximum search depth of planned inference, decrease the number of candidate actions to be deployed, or enable the dialogue response degradation flag, without reducing the minimum number of verification threads, minimum verification time slice, and minimum cache usage in the second resource quota. If the remaining computing power cannot even satisfy the minimum number of verification threads, minimum verification time slice, and minimum cache usage, the local terminal will not output control commands, but will output the reason for the limitation "Insufficient local security verification resources" and a confirmation request.

[0086] For example, in a park energy control terminal scenario, the local terminal is used to control chilled water pump units, air conditioning units, and power distribution interlock switches. The configuration tool first reads the hardware specifications of the local terminal, determining that its hardware specifications are identified as "quad-core processor, one local NPU, two parallel inference threads, and fixed cache space"; then it reads the device controller configuration, determining that the device control cycle is two hundred milliseconds. After reading the device risk table and action risk table, the configuration tool generates four types of risk combination conditions: "low-risk device and low-risk action," "low-risk device and high-risk action," "high-risk device and low-risk action," and "high-risk device and high-risk action." Any risk combination condition where any risk level reaches the level boundary recorded in the high-risk judgment field is marked as a high-risk combination.

[0087] Based on historical control logs and the action dictionary, the configuration tool determines the range of candidate action counts to be no more than two, three to four, or five to six. Based on the status templates of the chilled water pump unit, air conditioning unit, and power distribution interlock switches, it determines the range of device status field counts to be no more than ten, eleven to twenty, or twenty-one to thirty. Subsequently, the configuration tool constructs test control plans containing two, four, and six candidate control actions, and constructs candidate device statuses containing ten, twenty, and thirty device status fields, respectively. It then tests the resources required for the local terminal to complete candidate execution order generation, interlock rule comparison, status conflict rule comparison, and safety sequence rule comparison.

[0088] Test results show that when the number of candidate actions is three to four and the number of device status fields is eleven to twenty, the local terminal can generate a candidate execution order with a planned inference time slice of eighty milliseconds and a maximum planned inference search depth of three levels. Furthermore, at least one verification thread, a sixty-millisecond verification time slice, and corresponding cache space are required to complete the counterfactual verification within a two-hundred-millisecond device control cycle. Based on this, the configuration tool writes the following to the resource reservation mapping table: the number of candidate actions is three to four, the number of device status fields is eleven to twenty, the candidate planned inference time slice is eighty milliseconds, the candidate maximum planned inference search depth is three levels, the minimum number of verification threads is one, the minimum verification time slice is sixty milliseconds, and the minimum cache usage is the maximum cache usage measured in the corresponding test.

[0089] For low-risk combinations, if test results show a candidate inference time slice of 80 milliseconds and a minimum verification time slice of 60 milliseconds, the configuration tool will set the low-risk inference ratio higher than the low-risk verification ratio, and ensure that the processor time slice corresponding to the low-risk verification ratio is not less than 60 milliseconds; for example, the low-risk inference ratio can be set to 60%, and the low-risk verification ratio can be set to 40%. For high-risk combinations, the resource reservation mapping table still retains the above candidate values ​​for inference time slices and verification quotas, but at runtime, a verification quota priority guarantee method is adopted, that is, one verification thread, a 60-millisecond verification time slice, and the corresponding cache space are guaranteed first, and then the remaining resources are allocated to inference.

[0090] During runtime, if the local terminal detects that the control plan involves switching the operating mode of the chilled water pump group, and the candidate execution order is expected to include four candidate control actions and the candidate device status includes twenty device status fields, then the local terminal reads the above entries from the resource reservation mapping table. If the current control plan belongs to a low-risk combination, the local terminal allocates the current remaining processor time slice, available inference threads, and cache space according to the low-risk plan inference ratio and low-risk verification ratio, and generates the first resource quota and the second resource quota respectively. If the current control plan belongs to a high-risk combination, the local terminal first determines one verification thread, a 60-millisecond verification time slice, and the corresponding cache space as the second resource quota, and then deducts the second resource quota from the current remaining computing power, using the remaining resources after deduction to determine the first resource quota; if the remaining resources after deduction are insufficient to support an 80-millisecond plan inference time slice or a three-layer plan search depth, the local terminal reduces the plan search depth, reduces the number of candidate action expansions, or enables the dialogue response degradation flag, without compressing the already determined second resource quota.

[0091] Through the above processing, the local terminal generates a first resource quota and a second resource quota. The first resource quota is used for inference by the local agent in step S104, and the second resource quota is used for counterfactual verification in step S105.

[0092] Step S104: Perform local agent reasoning on the control plan according to the first resource quota to obtain the candidate execution order.

[0093] The local terminal reads the control plan obtained in step S102 and the first resource quota obtained in step S103. The first resource quota may include the plan inference time slice, the number of candidate action expansions, the plan search depth, and the available cache limit. The plan inference time slice limits the processor time allowed for the local agent from the start of reading the control plan to the output of the candidate execution order; the number of candidate action expansions limits the maximum number of pre-actions, subsequent actions, or mutually exclusive actions that the local agent can read and expand under each inference node; the plan search depth limits the number of layers the local agent can recursively expand from candidate control actions to pre-actions or subsequent actions; and the available cache limit limits the number of candidate action nodes, action conditions, and candidate action sequences that the local agent can cache when generating candidate action sequences. When any limit reaches the upper limit corresponding to the first resource quota, the local agent stops expanding new action nodes and forms a candidate action sequence based on the already generated candidate action nodes.

[0094] The local terminal reads the local action dictionary. The action dictionary includes action name, action category, action parameter requirements, control interface command, action preconditions, pre-action identifier, subsequent action identifier, mutually exclusive action identifier, and default wait time. Action preconditions record the state conditions that the target device or related interlocking devices must meet before executing a candidate control action; pre-action identifiers record actions that must be executed before the candidate control action; subsequent action identifiers record actions that are allowed or required to be executed after the candidate control action; mutually exclusive action identifiers record actions that must not appear in the same candidate action sequence as the candidate control action; and the default wait time records the time interval required between two sequential actions. The action dictionary can be formed from device control command sets, device safety operating procedures, control permission configurations, and historical control interception records, and stored on the local terminal.

[0095] The local agent reads the target device, candidate control actions, and execution conditions from the control plan, and uses the candidate control actions as target action nodes. When generating a candidate action sequence, the local agent first reads the action preconditions, pre-action identifiers, subsequent action identifiers, and mutually exclusive action identifiers corresponding to the target action node from the action dictionary; then, within the plan search depth limit, it expands the pre-action nodes forward according to the pre-action identifiers and the subsequent action nodes backward according to the subsequent action identifiers, and deletes the action nodes corresponding to the mutually exclusive action identifiers. For each expanded action node, the local agent records the action name, action sequence number, target device identifier, action preconditions, default wait time, and control interface command of that action node. If an action node still has pre-action identifiers or subsequent action identifiers, and the current expansion layer has not reached the plan search depth, then expansion continues; if the current expansion layer reaches the plan search depth, or the number of expanded action nodes reaches the candidate action expansion limit, then expansion stops.

[0096] The local agent generates candidate action sequences based on the expanded action nodes. When generating candidate action sequences, the local agent prioritizes preceding action nodes that must be executed before the target action node, and prioritizes subsequent action nodes that need to be executed after the target action node. For adjacent action nodes with default wait times, the corresponding wait relationships are written into the candidate action sequences. For action nodes with mutually exclusive action relationships, candidate action sequences containing both mutually exclusive action nodes are not generated. Each candidate action sequence includes a sequence identifier, action number, target device identifier, candidate control action, action preconditions, default wait time, expected output command, and sequence generation source. The expected output command is generated from the control interface commands and action parameter requirements in the action dictionary, but this expected output command is only used as counterfactual verification input and is not directly sent to the device control interface.

[0097] The local terminal checks the preconditions for each candidate action sequence item by item. During the check, the local terminal reads the operating status, alarm status, interlock status, mode status, manual maintenance flag, equipment controllability flag, and most recent control command from the candidate device status, and reads the time-triggered conditions, status-triggered conditions, manual confirmation conditions, prohibition conditions, and pending confirmation conditions from the control plan. For device status-related preconditions, the local terminal compares the field values ​​required by the action precondition with the corresponding field values ​​in the candidate device status; for time-related preconditions, the local terminal compares the default waiting time or expected execution time with the time-triggered conditions in the execution conditions; for manual confirmation-related preconditions, the local terminal determines whether there is a manual confirmation condition in the execution conditions that meets the permission requirements; for prohibition-related conditions, the local terminal determines whether the action name in the candidate action sequence matches a prohibition condition in the execution conditions. If any precondition for an action in a candidate action sequence cannot be satisfied by the candidate device status or execution conditions, or if the candidate action sequence matches a prohibition condition, the candidate action sequence is deleted; if all action preconditions are satisfied and no prohibition conditions are matched, the candidate action sequence is retained.

[0098] For the retained candidate action sequences, the local terminal sorts them hierarchically according to the action sequence sorting table. The action sequence sorting table is formed by the device safety operation procedures, historical manual confirmation records, device control command sets, and historical control interception records, and is stored on the local terminal. The action sequence sorting table includes a first sorting field, a second sorting field, a third sorting field, a fourth sorting field, and a parallel processing field. The first sorting field is the number of safety pre-actions satisfied; the larger the value, the higher the ranking. The second sorting field is the number of actions in the candidate action sequence; the fewer the actions, the higher the ranking. The third sorting field is a voice command action sequence consistency identifier; when the order of the target action nodes in the candidate action sequence matches the order of the control action words in the voice command text, this identifier indicates consistency, and the sequence ranks higher. The fourth sorting field is a manual confirmation condition completeness identifier; when all the required manual confirmation conditions for the candidate action sequence have been written into the execution conditions, this identifier indicates completeness, and the sequence ranks higher. The parallel processing field is used to prioritize candidate action sequences that do not contain alarm cancellation actions when all the aforementioned sorting fields are the same. If a unique determination is still not possible, a candidate execution order selection request is output.

[0099] During the specific sorting process, the local terminal first compares the number of security prerequisite actions satisfied for each candidate action sequence and retains the candidate action sequence with the largest value. If multiple candidate action sequences still exist, the number of actions is compared, and the candidate action sequence with the fewest actions is retained. If multiple candidate action sequences still exist, the voice command action sequence consistency identifier is compared, and the candidate action sequence that matches the order of the control action words in the voice command text is retained. If multiple candidate action sequences still exist, the manual confirmation condition completeness identifier is compared, and the candidate action sequence that meets the manual confirmation condition is retained. If a unique determination is still not possible, the candidate action sequence that does not contain an alarm cancellation action is selected based on the parallel processing field, or a candidate execution order selection request is output. The final retained candidate action sequence is determined as the candidate execution order.

[0100] If no candidate action sequence satisfying the preconditions and execution conditions is generated within the planned inference time slice corresponding to the first resource quota, the local terminal generates a planned inference constraint record without expanding the first resource quota. The planned inference constraint record includes the control plan identifier, target device identifier, candidate control actions, number of deployed action nodes, plan search depth, inference time, unmet action preconditions, and planned inference failure identifier. This planned inference constraint record is used by the control output module to generate constraint reasons and confirmation requests.

[0101] For example, in the scenario of the park's energy control terminal, the voice command text is "Switch the No. 2 chilled water pump to standby operation, and first confirm that the interlock switch is normal." In step S102, the local terminal identifies "No. 2 chilled water pump" as the target device, identifies "switch to standby operation" as a candidate control action, and writes "first confirm that the interlock switch is normal" into the status trigger condition. The first resource quota determined in step S103 includes a planned inference time slice of 80 milliseconds, four candidate action expansions, a planned search depth of three layers, and the corresponding available cache limit.

[0102] The local agent uses "switch to standby pump operation" as the target action node. It reads the corresponding action prerequisites from the action dictionary: "target pump is currently controllable, standby pump is in standby mode, power distribution interlock switch is normal, and there is no pump fault alarm." It reads the preceding action identifiers: "confirm power distribution interlock switch status" and "confirm standby pump standby status." It reads the subsequent action identifier: "output standby pump operation command." It reads the mutually exclusive action identifier: "clear pump fault alarm." The local agent expands the above action nodes within the three-layer plan search depth, generating the first candidate action sequence: "confirm power distribution interlock switch status, confirm standby pump standby status, switch to standby pump operation, output standby pump operation command," and the second candidate action sequence: "confirm standby pump standby status, confirm power distribution interlock switch status, switch to standby pump operation, output standby pump operation command."

[0103] Subsequently, the local terminal reads the status of the candidate devices, confirming that the standby pump is in standby mode, the power distribution interlock switch is in normal mode, and there is currently no pump fault alarm. Simultaneously, it reads the execution conditions, confirming that the state trigger condition of "first confirm the interlock switch is normal" has been written into the execution conditions. Since both the first and second candidate action sequences meet the action preconditions, the local terminal retains both. During sorting, the local terminal first compares the number of safety precondition actions met, which are the same; then it compares the number of actions, both being four actions; finally, it compares the voice command action sequence consistency indicator. Since the voice command text explicitly requires "first confirm the interlock switch is normal," and "confirm the power distribution interlock switch status" in the first candidate action sequence precedes "confirm the standby pump status," consistent with the voice command action sequence, the first candidate action sequence is ranked first and determined as the candidate execution order. This candidate execution order is then input into step S105 for counterfactual verification, rather than being directly output as a local control command.

[0104] In one optional implementation, when the local agent fails to generate a candidate action sequence that satisfies the preconditions and execution conditions within the planned inference time slice corresponding to the first resource quota, the local terminal does not directly increase the first resource quota, but instead generates a planned inference restriction record. Specifically, the local terminal records the current control plan identifier, target device identifier, candidate control actions, number of deployed action nodes, upper limit of the number of candidate action deployments, plan search depth, planned inference time slice, actual inference time, unmet action preconditions, unmet execution conditions, and planned inference failure identifier. The unmet action preconditions are read from the action precondition field in the action dictionary, and the unmet execution conditions are determined from time-triggered conditions, status-triggered conditions, manual confirmation conditions, prohibited conditions, or pending confirmation conditions in the control plan. When the actual inference time reaches the planned inference time slice, or the number of deployed action nodes reaches the upper limit of the number of candidate action deployments, and a candidate action sequence that satisfies the conditions is still not generated, the local terminal records the planned inference failure identifier as "Insufficient planned inference resources" or "Execution conditions not met". The plan inference restriction record is sent to the control output module, which generates the restriction reason and confirmation request according to the restriction reason template. After the plan inference restriction record is generated, the local terminal does not output local control commands.

[0105] In one optional implementation, when multiple candidate action sequences are generated and still have parallel candidate action sequences after being sorted hierarchically according to the action sequence sorting table, the local terminal processes them according to the parallel processing field. The parallel processing field is formed by the equipment safety operation procedures, the action risk table, and historical control interception records, and is stored in the action sequence sorting table. If only one candidate action sequence in the parallel candidate action sequences does not contain a candidate control action marked as alarm cancellation, interlock bypass, or safety prompt suppression in the action risk table, then that candidate action sequence is determined as the candidate execution order; if multiple parallel candidate action sequences do not contain the aforementioned highly sensitive actions, or if multiple parallel candidate action sequences contain the aforementioned highly sensitive actions, then the local terminal outputs a candidate execution order selection request pending manual confirmation.

[0106] The candidate execution order selection request includes the sequence identifier, action number, target device identifier, candidate control action, action preconditions, expected output command, reason for parallel selection, and reason for manual selection for each parallel candidate action sequence. The reasons for parallel selection include the same number of safety preconditions, the same number of actions, the same voice command action sequence identifier, or the same complete manual confirmation condition identifier. The reason for manual selection is generated based on the parallel processing field, for example, "Multiple candidate action sequences meet the current execution conditions, and the actual execution order needs to be selected." The manual confirmation permission requirement is read from the control permission configuration and associated with the target device identifier, the action category of the candidate control action, and the action risk level. When a confirmation input is received, the local terminal verifies whether the personnel identifier, permission level, confirmation time, and confirmation object in the confirmation input meet the manual confirmation permission requirements; if not, the candidate execution order remains undetermined, and a permission insufficient prompt is output; if satisfied, the selected candidate action sequence is determined as the candidate execution order, and the counterfactual verification in step S105 continues. The manual selection result is only used to determine the candidate execution order to be verified and does not directly trigger the local control command output.

[0107] The candidate execution order includes a sequence identifier, action number, target device identifier, candidate control action, action preconditions, action execution conditions, default waiting time, and expected output instruction. The action execution conditions are obtained by combining the time-triggered conditions, state-triggered conditions, manual confirmation conditions, prohibition conditions, and pending confirmation conditions in the control plan with the action preconditions in the action dictionary. The expected output instruction is generated from the control interface command, action parameter requirements, and the target device's device control interface address in the action dictionary. The expected output instruction is only used as a simulated write object in subsequent counterfactual verification and is not directly sent to the device control interface. This candidate execution order is read by the counterfactual verification in step S105; only when the verification result obtained in step S105 indicates that execution is allowed will the local terminal generate and output local control instructions according to the candidate execution order.

[0108] For example, in a vehicle edge control terminal scenario, the voice command text is "Switch to rain / fog driving mode, first turn on the defroster, then lower the window opening." The local terminal determines candidate control actions in the control plan, including "turn on the windshield defroster," "lower the window opening," and "switch to rain / fog driving mode." It reads the preconditions for "switch to rain / fog driving mode" from the action dictionary as "windshield defroster is on, window opening is lower than the preset opening, and driver confirmation." If the local agent only performs "turn on the windshield defroster" and "switch to rain / fog driving mode" within the plan inference time slice corresponding to the first resource quota, but fails to perform the precondition "lower the window opening," the local terminal generates a plan inference constraint record, recording the unmet precondition as "window opening is lower than the preset opening," and records the plan inference failure as "execution conditions not met." Subsequently, it outputs the constraint reason and confirmation request instead of directly outputting the control command.

[0109] For example, the local agent generates two candidate action sequences: the first candidate action sequence is "turn on windshield defroster, lower window opening, switch to rain / fog driving mode," and the second candidate action sequence is "lower window opening, turn on windshield defroster, switch to rain / fog driving mode." If both meet the preconditions for the action, and the order of execution cannot be uniquely determined after comparing the sorting fields, the local terminal determines, based on the parallel processing fields, that neither contains alarm cancellation, interlock bypass, or safety warning suppression actions, and then outputs a candidate execution order selection request. After the driver or a person with the appropriate permissions selects the first candidate action sequence, the local terminal determines it as the candidate execution order and uses the expected output instruction as a simulated write object for counterfactual verification; only when the counterfactual verification confirms that the candidate execution order will not cause state conflicts or safety order conflicts will the corresponding local control instruction be output.

[0110] Step S105: Perform counterfactual verification on the candidate execution order, candidate device status, and execution conditions according to the second resource quota to obtain the verification result.

[0111] like Figure 4 As shown, the local terminal reads the candidate execution order obtained in step S104, the candidate device state obtained in step S101, the execution conditions obtained in step S102, and the second resource quota obtained in step S103. The second resource quota may include the number of verification threads, the verification time slice, and the cache space. Counterfactual verification refers to copying the candidate device state and simulating the execution consequences of the candidate control actions without directly changing the real device state, and then determining whether the simulated consequences satisfy the interlocking rules, state conflict rules, safe order rules, and execution conditions.

[0112] The local terminal first checks the validity period of the candidate device status. The validity period is determined by the time difference between the sampling time of the candidate device status and the current verification time. When this time difference is greater than the preset validity period of the status, the local terminal determines that the candidate device status has expired and sets the verification result as restricted execution; when the time difference is not greater than the preset validity period of the status, the status copying process continues.

[0113] The local terminal copies the candidate device status within the cache space limited by the second resource quota, forming a temporary device status. The temporary device status includes the operating status, alarm status, interlock status, mode status, manual maintenance identifier, and most recent control command of the target device and associated interlocked devices. Associated interlocked devices can be identified by the interlock device identifier in the interlocking rules. When the cache space is insufficient to copy the status fields of the target device and associated interlocked devices, the local terminal determines the verification result as restricted execution and writes the insufficient cache space as the reason for the restriction.

[0114] Subsequently, the local terminal reads the candidate control actions one by one according to the candidate execution order, and simulates each candidate control action and writes it into the temporary device state to obtain the temporary state after the action. For example, if the candidate control action is "turn off heating", the local terminal updates the heating status field in the temporary device state from "on" to "off"; if the candidate control action is "reduce fan speed", the local terminal simulates and updates the fan speed field in the temporary device state to the target speed or "reduced"; if the candidate control action is "clear alarm", the local terminal simulates and updates the alarm indication field to "cleared", while retaining the original alarm source field for subsequent rule comparison.

[0115] For example, in an industrial drying production line scenario, the operator wakes up the local terminal and issues a voice command: "Switch drying line number one to maintenance mode, first turn off the heating, reduce the fan speed to low, and then clear the alarm." In step S102, the local terminal parses the target equipment as drying line number one. Candidate control actions include "turn off heating," "reduce fan speed," "clear alarm," and "switch to maintenance mode." Execution conditions include "manual confirmation of permission fulfillment" and "no unresolved alarm sources must be covered before entering maintenance." The candidate execution sequence obtained by the local terminal in step S104 is: turn off heating, reduce fan speed, clear alarm, and switch to maintenance mode.

[0116] During counterfactual verification, the local terminal reads the candidate device status obtained in step S101. This candidate device status records: Drying line No. 1 is in operation mode, heating is on, fan speed is rated, conveyor belt is stopped, furnace temperature is 125℃, waste heat exhaust interlock is active, alarm status is "high temperature waste heat alarm," and manual maintenance is not initiated. The time difference between the current verification time and the candidate device status sampling time is 2 seconds, which does not exceed the preset state validity period of 5 seconds; therefore, the state replication process continues.

[0117] The local terminal copies the status fields of drying line 1 and its associated equipment into the cache space limited by the second resource quota, forming a temporary equipment status. Then, the local terminal simulates writing "Heating Off" into the temporary equipment status according to the candidate execution order, obtaining the temporary status after the first action; in this status, the heating status changes from on to off, but the furnace temperature remains at 125℃, and the waste heat exhaust interlock status remains valid. Next, the local terminal simulates writing "Reducing Fan Speed" into the temporary status after the first action, obtaining the temporary status after the second action; in this status, the fan speed changes from rated speed to low speed.

[0118] The local terminal compares the temporary state after the second action with the safety sequence rules. The safety sequence rules state that when the furnace temperature is greater than the preset waste heat temperature threshold of 80°C and the waste heat exhaust interlock is active, it is prohibited to reduce the fan speed to the preset low speed level within the preset delay exhaust time after heating is turned off. Since the furnace temperature in the temporary state after the second action is 125°C, and the fan speed has been simulated and updated to low speed, the prohibited condition in the safety sequence rules is met. The local terminal determines the verification result as a restriction and records the reason for the restriction: "The furnace temperature has not dropped below the waste heat temperature threshold; reducing the fan speed after turning off heating will disrupt the waste heat exhaust sequence."

[0119] If the simulation of "clearing the alarm prompt" continues, the local terminal will compare the temporary state after this action with the prohibition conditions in the execution conditions. Since the original alarm source field is still "high temperature waste heat alarm", and this alarm source has not yet been simulated to be cleared, simply updating the alarm prompt field to "cleared" would mask the abnormal state. Therefore, the local terminal further records the reason for the restriction: "Clearing the alarm prompt is prohibited before the alarm source is cleared". Finally, the local terminal does not output the local control command corresponding to this candidate execution order, but instead outputs the reason for the restriction and a confirmation request, prompting the operator to first maintain the rated exhaust of the fan until the furnace temperature does not exceed 80°C, or to reconfirm the modified execution order.

[0120] The local terminal compares the temporary state after each action with the interlocking rules. The interlocking rules include device identifiers, interlocked device identifiers, prohibited actions, and prohibited state combinations. During the comparison, the local terminal reads the target device state and the interlocked device state from the temporary state after the action and combines them into a state combination to be verified. If the state combination to be verified matches the prohibited state combination in the interlocking rules, or if the current candidate control action is a prohibited action, then an interlocking conflict is determined to have occurred.

[0121] The local terminal compares the temporary status after each action with the status conflict rules. The status conflict rules include the current operating mode, candidate switching modes, and conditions for prohibiting switching. During the comparison, the local terminal reads the current operating mode and candidate switching modes from the temporary status after the action, and reads the alarm status, maintenance flag, or operating status from the candidate device status; if these fields meet the conditions for prohibiting switching, a status conflict is determined to have occurred.

[0122] The local terminal also compares the candidate execution order with the safe ordering rules. The safe ordering rules include preceding actions, succeeding actions, and allowed time relationships. During the comparison, the local terminal reads the preceding and succeeding actions in the candidate execution order according to the action sequence number, and determines whether a succeeding action is executed after the required preceding action, or whether the allowed time relationship is satisfied. If a candidate execution order contains a situation where "the succeeding action is earlier than the preceding action" or "the waiting time between actions does not meet the allowed time relationship," a safe ordering conflict is determined to have occurred.

[0123] Continuing with the industrial drying production line example, the candidate execution sequence is: shut down heating, reduce fan speed, clear alarm prompts, and switch to maintenance mode. The candidate equipment status records are as follows: the current operating mode of drying line No. 1 is production mode, heating is on, the exhaust fan is at rated speed, the furnace temperature is 125℃, alarm status includes high temperature waste heat alarm, and manual maintenance is indicated as not initiated. During the counterfactual verification process, the local terminal copies the above status as temporary equipment status and simulates and writes candidate control actions item by item according to the candidate execution sequence, obtaining multiple temporary statuses after each action. This processing chain is consistent with the counterfactual verification logic of "simulating and writing candidate control actions item by item and comparing rules" in the text.

[0124] In the interlocking rule comparison, the interlocking rule table records: the equipment is identified as the heating unit of the No. 1 drying line, the interlocked equipment is identified as the No. 1 exhaust fan, the prohibited action is to reduce the exhaust fan speed to low speed when the waste heat exhaust interlock is effective, and the prohibited state combination is "furnace temperature is greater than the preset waste heat temperature threshold, heating status is off, exhaust fan speed is low speed, waste heat exhaust interlock status is effective". When the local terminal simulates the execution of "turn off heating", the heating status in the generated first action post-temporary state is updated to off; after continuing to simulate the execution of "reduce fan speed", the exhaust fan speed in the generated second action post-temporary state is updated to low speed. At this time, the local terminal reads the heating status, furnace temperature, exhaust fan speed and waste heat exhaust interlock status in the second action post-temporary state, and combines them to obtain the state combination to be verified: "heating off, furnace temperature 125℃, fan low speed, waste heat exhaust interlock effective". Since the state combination to be verified is consistent with the prohibited state combination in the interlocking rule, and "reducing the fan speed" is a prohibited action limited by the interlocking rule, the local terminal determines that an interlocking conflict has occurred and records the reason for the restriction as "the waste heat exhaust interlock is effective and the furnace temperature has not dropped below the preset waste heat temperature threshold, so reducing the exhaust fan speed is prohibited".

[0125] In the state conflict rule comparison, the state conflict rule table records: the current operating mode is production mode, the candidate switching mode is maintenance mode, and the switching prohibition condition is "there is an unresolved alarm state, or the manual maintenance indicator has not been entered, or the equipment is still in operation." When the local terminal continues to simulate executing "switching to maintenance mode," it reads the current operating mode and candidate switching mode in the temporary state after the action, and reads the alarm state, manual maintenance indicator, and operating state in the candidate equipment state. Since there is still a high temperature waste heat alarm in the candidate equipment state, and the manual maintenance indicator has not been entered, the switching prohibition condition in the state conflict rule is met. The local terminal determines that a state conflict has occurred and records the restriction reason as "there is an unresolved high temperature waste heat alarm and the manual maintenance indicator has not been entered; the production mode is prohibited from being directly switched to the maintenance mode."

[0126] In the safety sequence rule comparison, the safety sequence rule table states: the preceding action is to shut down the heating and maintain the rated exhaust fan, and the following action is to reduce the exhaust fan speed. The allowed time relationship is that "reducing the exhaust fan speed should be done after shutting down the heating, and the time interval between shutting down the heating and the exhaust fan being no less than the preset delayed exhaust time, or the furnace temperature is no greater than the preset waste heat temperature threshold." The local terminal reads the candidate execution order according to the action number and determines that "shutting down the heating" is the first action and "reducing the fan speed" is the second action. Since the second action is executed immediately after the first action, the waiting time between actions is 0, the preset delayed exhaust time has not been reached, and the furnace temperature in the temporary state after the second action is still 125℃, which is greater than the preset waste heat temperature threshold of 80℃. The local terminal determines that a safety sequence conflict has occurred and records the reason for the restriction as "the delayed exhaust time has not been met after shutting down the heating and the furnace temperature is still higher than the waste heat temperature threshold, and reducing the fan speed does not meet the safety sequence rule."

[0127] Therefore, the local terminal writes the interlocking conflict, state conflict, and safety sequence conflict together into the verification result, determines the verification result as a restricted execution, and outputs the reason for the restriction and a confirmation request. The confirmation request may include: maintaining the exhaust fan at its rated speed until the furnace temperature does not exceed 80°C, confirming that the high-temperature waste heat alarm source has been eliminated, and regenerating the candidate execution order and re-performing counterfactual verification after the manual maintenance flag is updated to indicate that manual maintenance has been initiated.

[0128] The local terminal also compares the time-triggered conditions, status-triggered conditions, manual confirmation conditions, and prohibition conditions in the execution conditions with the temporary state after the action. For time-triggered conditions, the local terminal reads the expected execution time of each candidate control action in the candidate execution sequence and determines whether the expected execution time meets the execution time or waiting time limit specified by the time-triggered condition. For status-triggered conditions, the local terminal reads the running status, alarm status, mode status, or manual maintenance flag in the temporary state after the action and determines whether it meets the status-triggered condition. For manual confirmation conditions, the local terminal determines whether there is a confirmation input in the control plan or confirmation record that meets the manual confirmation permission requirements. For prohibition conditions, the local terminal determines whether the candidate control action or the temporary state after the action in the candidate execution sequence hits the prohibition condition. If any time-triggered condition, status-triggered condition, or manual confirmation condition is not met, or if any prohibition condition is hit, the local terminal determines that the execution conditions are not met and determines the verification result as restricted execution.

[0129] For example, the execution conditions in the control plan include time-triggered conditions, state-triggered conditions, manual confirmation conditions, and prohibition conditions. Specifically, the time-triggered condition is "after shutting down the heater, maintain the exhaust fan's rated exhaust for at least 180 seconds, or until the furnace temperature does not exceed 80°C before allowing the fan speed to be reduced"; the state-triggered condition is "before entering maintenance mode, the heating status should be off, the conveyor belt status should be stopped, and there should be no unresolved high-temperature residual heat alarms in the alarm state"; the manual confirmation condition is "the confirmation command must be entered by an operator with maintenance confirmation authority"; and the prohibition condition is "the alarm prompt cannot be cleared before the alarm source is eliminated, and switching to maintenance mode cannot be prohibited before the manual maintenance indicator is entered."

[0130] After simulating the execution of "shutting down heating," the local terminal obtains the temporary state after the first action. In this temporary state, the heating status is off, the furnace temperature is 125℃, and the exhaust fan is still at its rated speed. The local terminal reads the expected execution time of "reducing fan speed" in the candidate execution sequence. If the expected execution time of "shutting down heating" is 10:00:00 and the expected execution time of "reducing fan speed" is 10:00:20, then the waiting time between the two actions is 20 seconds, which is less than the 180 seconds limit set by the time trigger condition; at the same time, the furnace temperature in the temporary state after the action is 125℃, which is still greater than 80℃. Therefore, the local terminal determines that the candidate execution sequence does not meet the time trigger condition and records the reason for the restriction: "The preset delay exhaust time has not been reached after shutting down heating, and the furnace temperature has not dropped below the preset waste heat temperature threshold."

[0131] The local terminal continues to read the operating status, alarm status, mode status, and manual maintenance indicator in the temporary status after the action. If the heating status in the temporary status after the action has been simulated and updated to "off," and the conveyor belt status is "stopped," but the alarm status still includes a high-temperature residual heat alarm, and the manual maintenance indicator is still "not entered," then the temporary status after the action does not meet the status triggering condition of "there must be no unresolved high-temperature residual heat alarm before entering maintenance mode," nor does it meet the status requirement of "the manual maintenance indicator should be entered." Therefore, the local terminal determines that the status triggering condition is not met and records the reason for the restriction: "The high-temperature residual heat alarm has not been resolved and the manual maintenance indicator has not been entered; therefore, the system cannot switch to maintenance mode."

[0132] For manual confirmation conditions, the local terminal reads the confirmation records in the control plan. If the confirmation record is empty, or if the confirmation record only contains the "Confirm Execution" voice input from a regular operator account, but that account is not marked as a maintenance confirmation permission account in the permission table, the local terminal determines that no confirmation input meeting the manual confirmation permission requirements has been received. Even if some actions in the candidate execution sequence are executable in terms of status, the local terminal still determines that the manual confirmation condition is not met and records the reason for the restriction: "No manual confirmation input meeting the maintenance confirmation permission requirements has been obtained."

[0133] For the prohibition condition, the local terminal reads the "Clear Alarm Prompt" action from the candidate execution sequence and reads the original alarm source field in the temporary state after the action. If the original alarm source field is still a high temperature residual heat alarm, and the alarm source elimination flag is not eliminated, then "Clear Alarm Prompt" meets the prohibition condition of "Clearing the alarm prompt is prohibited before the alarm source is eliminated." Furthermore, since the candidate execution sequence also includes "Switch to Maintenance Mode," and the manual maintenance flag in the temporary state after the action is still not entered, this candidate control action also meets the prohibition condition of "Switch to Maintenance Mode is prohibited before the manual maintenance flag is entered." Based on this, the local terminal records the reason for the restriction: "Clearing the alarm prompt is prohibited before the alarm source is eliminated; Switching to Maintenance Mode is prohibited before the manual maintenance flag is entered."

[0134] During the counterfactual verification process, the local terminal continuously records the number of candidate control actions that have completed simulated verification and the verification time. If the verification time reaches the verification time slice in the second resource quota, and the number of candidate control actions that have completed simulated verification is less than the total number of candidate control actions in the candidate execution order, the local terminal determines the verification result as restricted execution and writes the verification timeout into the restriction reason. If the interlocking rule, state conflict rule, or security sequence rule lacks a rule item corresponding to the target device, and the candidate control action is an action that changes the device's operating state, the local terminal determines the verification result as restricted execution and writes the missing security rule into the restriction reason.

[0135] When no interlocking conflict, state conflict, or safety sequence conflict is detected, all execution conditions are met, and there are no verification timeouts, state expirations, insufficient cache, or missing security rules, the local terminal determines the verification result as allowing execution. The verification result includes an allowed execution flag, a list of actions that passed the verification, and the corresponding candidate execution order. When any conflict is detected or the execution conditions are not met, the local terminal determines the verification result as restricting execution. The verification result for restricted execution includes the restriction type, restriction action, conflicting device, trigger rule flag, and restriction reason.

[0136] For example, the verification time slice limited by the second resource quota is 50ms. The candidate execution sequence includes four candidate control actions: shutting off heating, maintaining exhaust ventilation, reducing fan speed, and switching to maintenance mode. The local terminal starts the verification timer when counterfactual verification begins and initializes the number of candidate control actions that have completed simulation verification to 0. After each candidate control action completes the simulation writing, post-action temporary state generation, interlock rule comparison, state conflict rule comparison, safety sequence rule comparison, and execution condition comparison, the local terminal increments the number of candidate control actions that have completed simulation verification by 1.

[0137] For example, the local terminal completes the simulation verification of "turn off heating" at 20ms and updates the number of candidate control actions that have completed the simulation verification to 1; it completes the simulation verification of "keep exhaust" at 35ms and updates the number of candidate control actions that have completed the simulation verification to 2; when the verification time reaches 50ms, if "reduce fan speed" and "switch maintenance mode" have not yet completed the simulation verification, the number of candidate control actions that have completed the simulation verification is 2, which is less than the total number of candidate control actions in the candidate execution order of 4. Based on this, the local terminal does not allow the unverified actions by default, but determines the verification result as restricted execution, and writes "verification timed out, total number of candidate control actions is 4, number of candidate control actions that have completed the simulation verification is 2, number of candidate control actions that have not completed the simulation verification is 2" in the restriction reason.

[0138] For example, when verifying "switching maintenance mode," the local terminal needs to read the state conflict rules and safety sequence rules corresponding to drying line No. 1. If the rule base contains interlocking rules between the heating unit and the exhaust fan of drying line No. 1, but lacks a state conflict rule corresponding to switching drying line No. 1 from production mode to maintenance mode, and "switching maintenance mode" is a candidate control action for changing the equipment's operating mode, the local terminal cannot use the absence of the rule as a basis for allowing execution. Instead, it will determine the verification result as restricted execution and write "Safety rule missing, target equipment is drying line No. 1, restricted action is switching maintenance mode, missing rule type is state conflict rule" in the restriction reason. If the safety sequence rule for "reducing fan speed after turning off heating" is also missing, the restriction reason can also be "missing rule type includes safety sequence rule."

[0139] In another scenario where verification passes, the candidate execution order is adjusted by the local terminal as follows: shut off heating, maintain exhaust for 180 seconds, reduce fan speed after the furnace temperature does not exceed 80°C, and switch to maintenance mode after the high-temperature waste heat alarm source is eliminated and the manual maintenance indicator is entered. During counterfactual verification, the local terminal simulates the above candidate control actions one by one and records the number of candidate control actions that have completed simulation verification. When all four candidate control actions are simulated and verified within the verification time slice limited by the second resource quota, and the temporary state after each action does not match the prohibited state combination in the interlocking rules, does not match the prohibited switching condition in the state conflict rules, the candidate execution order satisfies the allowed time relationship in the safety order rules, and the time trigger condition, state trigger condition, and manual confirmation condition in the execution conditions are all met, and the prohibited condition is not met, the local terminal determines the verification result as allowed execution.

[0140] In the verification result that allows execution, the allowed execution identifier is "Allowed". The list of actions that passed the verification includes "Turn off heating", "Keep exhaust", "Reduce fan speed", and "Switch maintenance mode". The corresponding candidate execution order is: turn off heating, keep exhaust for 180 seconds, reduce fan speed, and switch maintenance mode. This verification result is read by step S106 so that step S106 outputs local control commands according to the candidate execution order.

[0141] In cases where execution is restricted, such as when the verification result is triggered by any of the following: verification timeout, missing safety rules, interlock conflict, state conflict, safety sequence conflict, or failure to meet execution conditions, the verification result for restricted execution may include: the restriction type being verification timeout, missing rules, interlock conflict, state conflict, safety sequence conflict, or failure to meet execution conditions; the restricted action being a candidate control action that has not completed simulation verification or a candidate control action that has hit a conflict; the conflicting device being the heating unit of the No. 1 drying line, the No. 1 exhaust fan, or the corresponding interlocking device; the triggering rule identifier being a waste heat exhaust interlock rule, a maintenance mode switching rule, or a rule for waiting for exhaust after heating is turned off; and the restriction reason being verification timeout, missing safety rules, furnace temperature not dropping below the preset waste heat temperature threshold, alarm source not being cleared, manual maintenance identifier not being entered, or manual confirmation permission not being met. This verification result for restricted execution is read by step S106 so that step S106 does not output a local control command, but instead outputs the restriction reason and confirmation request.

[0142] Step S106: When the verification result is "execution allowed", output the local control instruction corresponding to the candidate execution order; when the verification result is "execution restricted", output the reason for the restriction and the confirmation request.

[0143] The local terminal reads the verification result obtained in step S105. If the verification result allows execution, the local terminal reads the control interface command corresponding to each candidate control action according to the candidate execution order and generates a local control instruction. The local control instruction includes the target device identifier, control interface address, action command, action parameters, action sequence number, and output time. The control output module sends the local control instruction to the device control interface and records the control output log. The control output log may include the voice wake-up event identifier, voice command text, control plan, first resource quota, second resource quota, candidate execution order, verification result, and local control instruction.

[0144] If the verification result indicates restricted execution, the local terminal reads the restriction type, restricted action, conflicting device, and trigger rule identifier from the verification result. Restriction types can include interlocking conflicts, state conflicts, security sequence conflicts, execution conditions not met, target device unclear, insufficient computing power, expired state, missing rules, verification timeout, and missing manual confirmation. The trigger rule identifier points to the corresponding interlocking rule, state conflict rule, or security sequence rule.

[0145] The reason for the restriction can be generated according to a preset prompt template. The preset prompt template includes fields for restriction type, restricted action, conflicting device, trigger rule identifier, and suggested handling. The local terminal selects the corresponding template based on the restriction type in the verification result and fills in the restricted action, conflicting device, and trigger rule identifier into the corresponding fields to generate the restriction reason text. For example, when the restriction type is a security sequence conflict, the prompt template can generate the restriction reason text "A certain action in the current plan is earlier than the specified preceding action; the action order needs to be confirmed before execution." The preset prompt template is formed from the device's security operating procedures, control permission configuration, and historical interception prompt records, and is stored in the local prompt template table.

[0146] The local terminal simultaneously outputs a confirmation request. The confirmation request includes the action to be confirmed, the manual confirmation permission requirement, the confirmation input method, and the timeout handling method. The action to be confirmed can be determined based on the confirmation fields in the control plan and the restricted actions in the verification results. Confirmation fields can include low-confidence words, non-unique device fields, and parameter confirmation fields. The manual confirmation permission requirement can come from the control permission configuration, such as requiring confirmation from the team leader, maintenance supervisor, or vehicle driver. The confirmation input method can include keypad confirmation, touchscreen confirmation, voiceprint confirmation, password confirmation, or employee ID confirmation. The timeout handling method can be to cancel the control output and record the control interception log.

[0147] The preset confirmation duration is determined based on the effective duration of the device control command, the confirmation response test duration for on-site personnel, and the allowed waiting time for the control task. During configuration, the local terminal or configuration tool selects a duration that does not exceed the allowed waiting time for the control task and covers the normal confirmation operation by on-site personnel as the preset confirmation duration, and writes it into the confirmation permission configuration table. The current step reads the preset confirmation duration from the confirmation permission configuration table when outputting a confirmation request and starts timing from the moment the confirmation request is output.

[0148] If no confirmation input meeting the manual confirmation permission requirements is received within the preset confirmation time, the local terminal cancels the output of local control commands and records a control interception log. The control interception log includes the voice command text, control plan, candidate execution order, reason for restriction, confirmation request, and timeout result.

[0149] If a confirmation input that meets the manual confirmation permission requirements is received, the local terminal does not directly output a local control command. Instead, it updates the manual confirmation conditions in the control plan based on the confirmation input and re-executes steps S103 to S105. During re-execution, the local terminal rereads the current computing power status and candidate device status, redetermines the first and second resource quotas, and performs a counterfactual verification again. Only when the re-verification result indicates that execution is allowed will the local terminal output a local control command; if the re-verification result still indicates that execution is restricted, the restricted execution status will continue to be maintained and the updated reason for the restriction will be output.

[0150] In a specific example, in an industrial drying production line scenario, the operator wakes up the local terminal and issues a voice command: "Switch drying line number one to maintenance mode." After processing through steps S101 to S105, the local terminal obtains the following candidate execution sequence: turn off heating, maintain exhaust for 180 seconds, reduce fan speed, and switch to maintenance mode. When the verification result indicates that execution is allowed, the verification result includes an allowed execution flag, a list of verified actions, and the corresponding candidate execution sequence.

[0151] After reading the execution permission flag, the local terminal reads the control interface commands one by one according to the candidate execution order. For example, the local terminal reads the "No. 1 drying line heating unit shutdown command" from the control interface command table, corresponding to the control interface address PLC-01 / DO-12, with the action command being to shut down heating and the action parameter being heating output 0; it reads the "No. 1 exhaust fan maintain exhaust command", corresponding to the control interface address PLC-01 / AO-03, with the action command being to maintain rated exhaust and the action parameter being rated speed; it reads the "No. 1 exhaust fan speed reduction command", corresponding to the control interface address PLC-01 / AO-03, with the action command being to reduce the fan speed and the action parameter being low speed; and it reads the "No. 1 drying line mode switching command", corresponding to the control interface address PLC-01 / MODE-02, with the action command being to switch to maintenance mode and the action parameter being the maintenance mode flag.

[0152] The local terminal generates local control instructions accordingly. The first instruction includes the target equipment identifier "No. 1 Drying Line Heating Unit", the control interface address "PLC-01 / DO-12", the action command "Turn off heating", the action parameter "Heating output 0", the action sequence number "1", and the output time "10:00:00". The second instruction includes the target equipment identifier "No. 1 Exhaust Fan", the control interface address "PLC-01 / AO-03", the action command "Maintain rated exhaust", the action parameter "Rated speed", the action sequence number "2", and the output time "10:00:00 to 1". The first instruction is "0:03:00"; the second instruction includes the target equipment identifier "No. 1 exhaust fan", the control interface address "PLC-01 / AO-03", the action command "reduce fan speed", the action parameter "low speed", the action sequence number "3", and the output time "10:03:00"; the third instruction includes the target equipment identifier "No. 1 drying line", the control interface address "PLC-01 / MODE-02", the action command "switch maintenance mode", the action parameter "maintenance mode identifier", the action sequence number "4", and the output time "10:03:05". The control output module sends the above local control instructions to the equipment control interface and records the voice wake-up event identifier, voice command text, control plan, first resource quota, second resource quota, candidate execution order, verification result, and local control instructions in the control output log.

[0153] For example, if the verification result obtained in step S105 is a restriction execution, the restriction type is a safety sequence conflict, the restricted action is "reduce fan speed", the conflicting devices are "exhaust fan No. 1" and "drying line heating unit No. 1", and the triggering rule is "exhaust waiting rule after heating is turned off", the local terminal reads the local prompt template table and generates the restriction reason text according to the preset prompt template corresponding to the safety sequence conflict. The generated restriction reason text is: "The currently planned action of reducing fan speed does not meet the delayed exhaust requirement after heating is turned off. The conflicting devices are exhaust fan No. 1 and drying line heating unit No. 1. The triggering rule is the exhaust waiting rule after heating is turned off. Please wait until the furnace temperature is no greater than 80°C or maintain exhaust for no less than 180 seconds before reconfirming."

[0154] The local terminal simultaneously outputs a confirmation request. The actions to be confirmed in the confirmation request are "reduce fan speed" and "switch maintenance mode". The manual confirmation permission requires the authorization of the maintenance supervisor. The confirmation input method can be touch screen confirmation, password confirmation, or voiceprint confirmation. The timeout handling method is to cancel the control output and record the control interception log. If the preset confirmation duration recorded in the confirmation permission configuration table is 60 seconds, the local terminal will start counting from the moment the confirmation request is output.

[0155] If no confirmation input meeting the maintenance supervisor's authority requirements is received within 60 seconds, the local terminal cancels the output of local control commands and generates a control interception log. The control interception log records the voice command text "Switch Drying Line 1 to Maintenance Mode", the control plan, the candidate execution order, the reason for the restriction, the confirmation request, and the timeout result "Maintenance supervisor confirmation not completed within the preset confirmation time".

[0156] If the local terminal receives confirmation information from the maintenance supervisor via password or voiceprint input within 60 seconds, it will not directly send control commands to "reduce fan speed" or "switch maintenance mode." Instead, it will write the confirmation information into the manual confirmation conditions in the control plan and re-execute steps S103 to S105. During re-execution, the local terminal will reread the current computing power status and candidate device status. If the re-read candidate device status still shows a furnace temperature of 125°C and the high-temperature waste heat alarm not being cleared, the local terminal will continue to determine the verification result as restricted execution because the status trigger condition or prohibition condition is not met, and will output the updated restriction reason.

[0157] When re-verifying, if the candidate equipment status shows that the furnace temperature has dropped to 78℃, the high-temperature waste heat alarm source has been eliminated, the manual maintenance indicator has been updated to "entered," and the manual confirmation conditions contain confirmation inputs that meet the maintenance supervisor's authority requirements, the local terminal re-determines the first and second resource quotas and performs a counterfactual check again. If this check does not detect interlocking conflicts, status conflicts, or safety sequence conflicts, and all execution conditions are met, the local terminal will then determine the re-verification result as allowing execution and output local control commands according to the candidate execution order that passed the re-verification.

[0158] like Figure 5 As shown in the illustration, this application also provides a local agent inference terminal triggered by voice wake-up. The terminal includes a wake-up acquisition module, an intent parsing module, a resource scheduling module, an agent inference module, a counterfactual verification module, and a control output module.

[0159] The wake-up acquisition module is used to respond to voice wake-up events detected by the local terminal and acquire the corresponding voice command text, current computing power status, and candidate device status. The wake-up acquisition module may include a voice caching unit, a voice recognition unit, a computing power sampling unit, and a device status reading unit. The voice caching unit caches voice segments following the voice wake-up event; the voice recognition unit performs local voice recognition on the voice segments; the computing power sampling unit reads the processor utilization rate, NPU task queue length, and available cache capacity; and the device status reading unit reads the candidate device status from the device control interface or the device status cache.

[0160] The intent parsing module parses the voice command text to obtain a control plan that includes the target device, candidate control actions, and execution conditions. The intent parsing module may include a text normalization unit, a device recognition unit, an action recognition unit, and a condition extraction unit. The text normalization unit removes interjections and replaces synonyms; the device recognition unit compares device names with a local device list; the action recognition unit compares control action words with an action dictionary; and the condition extraction unit extracts time conditions, status conditions, manual confirmation conditions, and conditions requiring confirmation.

[0161] The resource scheduling module determines the first resource allocation for planned inference and the second resource allocation for pre-control verification based on the target device's device risk level, the action risk level of candidate control actions, and the current computing power status. The resource scheduling module may include a risk reading unit, a resource lookup unit, and a resource degradation unit. The risk reading unit reads the risk level from the device risk table and the action risk table; the resource lookup unit searches for candidate values ​​for planned inference and verification allocations in the resource reservation mapping table; and the resource degradation unit reduces the planned inference search depth or dialogue response resources when the remaining computing power is insufficient.

[0162] The Agent inference module performs local Agent inference on the control plan according to the first resource quota to obtain a candidate execution order. The Agent inference module may include a plan reading unit, an action expansion unit, a precondition checking unit, and a sequence output unit. The plan reading unit reads the target device, candidate control actions, and execution conditions from the control plan; the action expansion unit generates a sequence of candidate actions within the plan search depth; the precondition checking unit deletes candidate action sequences that do not meet the execution conditions; and the sequence output unit outputs the candidate execution order with the highest priority. The sequence output unit also determines the candidate execution order based on the number of actions, whether it includes an alarm cancellation action, and manual selection input when there are parallel candidate action sequences, and sends the candidate execution order to the counterfactual verification module.

[0163] The counterfactual verification module performs counterfactual verification on the candidate execution order, candidate device status, and execution conditions according to the second resource quota, and obtains the verification result. The counterfactual verification module may include a state copying unit, an action simulation unit, a rule comparison unit, a condition checking unit, and a result generation unit. The state copying unit copies the candidate device status to form a temporary device status; the action simulation unit simulates and writes candidate control actions item by item according to the candidate execution order; the rule comparison unit compares the temporary state after the action with interlocking rules, state conflict rules, and safety order rules; the condition checking unit compares the time-triggered conditions, state-triggered conditions, manual confirmation conditions, and prohibition conditions in the execution conditions with the temporary state after the action; and the result generation unit generates a verification result indicating whether execution is allowed or restricted. If the state copying unit determines that the cache space is insufficient, or the rule comparison unit determines that the verification has timed out, the status has expired, or the safety rules are missing, or the condition checking unit determines that the execution conditions are not met, the result generation unit determines the verification result as restricted execution.

[0164] The control output module outputs local control instructions corresponding to the candidate execution order when the verification result indicates "execution allowed"; and outputs the reason for the restriction and a confirmation request when the verification result indicates "execution restricted". The control output module may include an instruction generation unit, a prompt generation unit, a confirmation request unit, a re-verification trigger unit, and a log recording unit. The instruction generation unit converts the candidate execution order into local control instructions recognizable by the device control interface; the prompt generation unit generates the restriction reason based on the restriction type and triggering rules; the confirmation request unit outputs the action to be confirmed and the manual confirmation permission requirement; the re-verification trigger unit re-triggers resource quota determination and counterfactual verification after receiving confirmation input that meets the manual confirmation permission requirement; and the log recording unit records control output logs or control interception logs.

[0165] This application also provides a computer device. The computer device includes a processor, a memory, a communication interface, and a bus. The memory stores a computer program, a device risk table, an action risk table, a resource reservation mapping table, interlocking rules, state conflict rules, and security sequence rules. The processor loads and executes the computer program in the memory to implement the aforementioned voice wake-up triggered local agent inference resource scheduling method. The communication interface communicates with the voice acquisition component, the device status interface, and the device control interface. The bus connects the processor, the memory, and the communication interface.

[0166] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the aforementioned voice wake-up-triggered local agent inference resource scheduling method. The computer-readable storage medium may include a read-only memory, random access memory, flash memory, hard disk, solid-state drive, or other media capable of storing a computer program.

[0167] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of this application. Although this application has been described in conjunction with the above embodiments, those skilled in the art can combine, substitute, or make equivalent modifications to the technical features in the above embodiments without departing from the essence of the technical solutions of this application, and such combinations, substitutions, or equivalent modifications should all fall within the scope of protection of this application.

Claims

1. A method for scheduling local agent inference resources triggered by voice wake-up, characterized in that, include: In response to a voice wake-up event detected by the local terminal, the voice command text corresponding to the voice wake-up event, the current computing power status, and the candidate device status are obtained. The voice command text is parsed to obtain a control plan that includes the target device, candidate control actions, and execution conditions; Based on the device risk level of the target device, the action risk level of the candidate control action, and the current computing power status, determine a first resource quota for planned inference and a second resource quota for pre-control verification; including: Based on the equipment risk level of the target device, the action risk level of the candidate control action, and the current computing power status, read the candidate values ​​of the planned inference quota and the candidate values ​​of the verification quota from the resource reservation mapping table; Read the device high-risk determination field corresponding to the target device and the action high-risk determination field corresponding to the candidate control action; When the risk level of the device reaches the level boundary recorded in the high-risk determination field of the device, or when the risk level of the action reaches the level boundary recorded in the high-risk determination field of the action, the verification quota priority protection method is adopted. First, the verification quota candidate value is determined as the second resource quota, and then the first resource quota is determined according to the planned inference quota candidate value and the current remaining computing power after deducting the second resource quota. When neither the device risk level nor the action risk level reaches the corresponding level boundary, a proportional allocation method is adopted. According to the low-risk planned inference ratio and low-risk verification ratio in the resource reservation mapping table, the current remaining computing power is divided into the first resource quota and the second resource quota. The resource reservation mapping table includes risk combination conditions, minimum number of verification threads, minimum verification time slice, minimum cache usage, maximum search depth of planned inference, and dialogue response degradation flag. The resource reservation mapping table is generated based on the local terminal hardware specifications, device control cycle, historical control plan length, and counterfactual verification time test results. If the remaining computing power is insufficient to simultaneously satisfy both the candidate values ​​for the planned inference quota and the candidate values ​​for the verification quota, first reduce the maximum search depth of the planned inference or enable the dialogue response downgrade flag; Based on the first resource quota, perform local agent inference on the control plan to obtain the candidate execution order; The candidate execution order, candidate device status, and execution conditions are counterfactually verified according to the second resource quota to obtain the verification result. When the verification result indicates that execution is allowed, the local control instruction corresponding to the candidate execution order is output; when the verification result indicates that execution is restricted, the reason for the restriction and a confirmation request are output.

2. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 1, characterized in that, Obtaining the voice command text, current computing power status, and candidate device status corresponding to the voice wake-up event includes: Endpoint detection and local speech recognition are performed on the speech segment following the voice wake-up event to obtain the voice command text; The processor utilization rate, neural network processor task queue length, available cache capacity, and number of current control tasks of the local terminal are read to form the current computing power status; The candidate device status is formed by reading the operating status, alarm status, interlock status, and mode status from the device control interface or device status cache.

3. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 1, characterized in that, The equipment risk level is determined based on the equipment risk table, which includes equipment identification, equipment type, number of interlocks, downtime impact level, and human access risk level. The risk level of the action is determined according to the action risk table, which includes the action name, action category, whether it changes the equipment operating status, whether it involves alarm deactivation, and whether it involves valves or power components. The equipment risk table and the action risk table are formed from the equipment ledger, control permission configuration and historical anomaly records, and are stored on the local terminal.

4. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 1, characterized in that, The candidate execution order is obtained, including: The local agent's planned inference time slice, number of candidate actions to be deployed, and planned search depth are limited according to the first resource quota. Read the target device, candidate control actions, and execution conditions from the control plan, and generate at least one candidate action sequence; Read the candidate device status and the execution conditions, check the action preconditions in each candidate action sequence item by item, and delete the candidate action sequences that do not meet the candidate device status or the execution conditions; The retained candidate action sequences are sorted level by level according to the action sequence sorting table, and the candidate action sequences that are sorted first are determined as the candidate execution order.

5. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 1, characterized in that, The verification results include: The candidate device state is copied within the verification thread, verification time slice, and cache space limited by the second resource quota to form a temporary device state; Candidate control actions are read one by one according to the candidate execution order, and each candidate control action is simulated and written into the temporary device state to obtain the temporary state after the action; The temporary state after each action is compared with the interlocking rules, state conflict rules, and safety sequence rules. The time triggering condition, state triggering condition, manual confirmation condition, and prohibition condition in the execution conditions are compared with the temporary state after the action to generate the verification result.

6. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 5, characterized in that, The interlocking rules include combinations of equipment identifiers, interlocked equipment identifiers, prohibited actions, and prohibited states. The state conflict rules include the current operating mode, candidate switching modes, and conditions for prohibiting switching. The safety sequence rules include preceding actions, following actions, and allowed time relationships; When any action's temporary state matches the prohibited state combination, the prohibited switching condition, or does not satisfy the allowed time relationship, the verification result is determined as restricted execution, and the corresponding restriction reason is recorded.

7. The method for scheduling local agent inference resources triggered by voice wake-up according to claim 1, characterized in that, During the counterfactual verification process according to the second resource quota, if the simulation verification of all candidate control actions in the candidate execution order is not completed within the verification time slice corresponding to the second resource quota, or the cache space corresponding to the second resource quota is insufficient to copy the candidate device state, or the time difference between the sampling time of the candidate device state and the current verification time is greater than the preset state validity duration, or the interlocking rules, state conflict rules or security order rules corresponding to the target device are missing, then the verification result will be determined as restricted execution; The reasons for the limitation include the type of insufficient verification resources, the number of candidate control actions that have not completed simulation verification, the number of candidate control actions that have completed simulation verification, verification timeout flag, status expiration flag, or rule missing flag.

8. A voice-wake-up triggered local agent inference terminal, used to implement the voice-wake-up triggered local agent inference resource scheduling method according to any one of claims 1 to 7, characterized in that, include: The wake-up acquisition module is used to respond to a voice wake-up event detected by the local terminal and acquire the voice command text, current computing power status, and candidate device status corresponding to the voice wake-up event. The intent parsing module is used to parse the voice command text to obtain a control plan including the target device, candidate control actions, and execution conditions. The resource scheduling module is used to determine a first resource quota for planned inference and a second resource quota for pre-control verification based on the device risk level of the target device, the action risk level of the candidate control action, and the current computing power status. The Agent inference module is used to perform local Agent inference on the control plan according to the first resource quota to obtain the candidate execution order; The counterfactual verification module is used to perform counterfactual verification on the candidate execution order, the candidate device status, and the execution conditions according to the second resource quota, and obtain the verification result; The control output module is used to output a local control instruction corresponding to the candidate execution order when the verification result is "execution allowed"; and to output the reason for the restriction and a confirmation request when the verification result is "execution restricted".

Images