Anti-terrorism scene control system based on multi-source perception and embodiment robot fusion

Abstract

This invention discloses a counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots, belonging to the field of process control technology. This counter-terrorism and emergency response collaborative control system includes the following steps: a multi-terminal data acquisition module for collecting and normalizing various types of emergency response datasets; an evidence graph fusion module for generating emergency response evidence graphs through consistency constraint fusion; a risk constraint collaborative planning module for generating a collaborative control instruction set through robot task allocation; a linkage execution and backtracking closed-loop module for compiling the collaborative control instruction set into a linkage contract set; and an evidence closure and audit playback module for constructing a closed-loop verification element set to trigger online replanning. This invention effectively improves the collaborative control efficiency and traceability of execution in counter-terrorism and emergency response tasks, solving the problem of reachability deviations caused by the lack of consistent feedback verification in linkage control transmission.

Description

Technical Field

[0001] This invention relates to the field of process control technology, specifically to a counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots. Background Technology

[0002] With the expansion of urban public spaces, the increased density of interconnected equipment in rail transit and large complexes, the deep integration of security and fire protection systems, and the gradual participation of embodied robots in emergency response, existing technologies utilize fixed cameras, thermal imagers, millimeter-wave radar, perimeter sensing units, and environmental sensor arrays to achieve continuous monitoring of areas such as station halls, platforms, transfer passages, and entrances / exits. Edge gateways are commonly used to collect and aggregate video streams, radar target lists, equipment status readbacks, link indicators, and robot telemetry data, creating emergency response process records in session and event windows to provide data support for command-line situational awareness, task assignment, and post-event review.

[0003] For example, the invention patent with announcement number CN111399509B discloses a multi-mobile robot cooperative transfer control method and system, including: (1) selecting two robot subsystems from multiple robot subsystems to form a negotiation navigation layer, and the remaining robot subsystems to form a follower layer; (2) the robot subsystems in the negotiation navigation layer simultaneously receive instructions and calculate their respective target poses according to the destination of the workpiece, and perform path planning based on environmental information; (3) calculating the speed control quantities respectively; (4) negotiating and determining the common speed along the workpiece direction; (5) correcting their respective original speed control quantities to achieve cooperative operation; at the same time, the robot subsystems in the follower layer perform motion control to ensure that the relative distance between themselves and the two robot subsystems in the negotiation navigation layer remains unchanged. This invention improves utilization efficiency, saves a lot of costs, and has good versatility.

[0004] In existing technologies, after issuing control commands to access control, display screens, broadcasting, and fire protection equipment, current systems often consider the sending of commands or the display of information on the interface as the basis for successful execution. However, when equipment is offline, there is link jitter, permission verification fails, there is a delay in effectiveness, or there is inconsistency in the status feedback from the device, the actual on-site status may not reach the expected configuration within the specified time limit. Due to the lack of a unified execution feedback mechanism, status readback and consistency verification process, as well as timeout handling and rollback constraints, discrepancies arise between the command center's situation map and the on-site accessibility lockdown status, which in turn affects the reliability of evacuation guidance and isolation strategies and makes it difficult to prove "when, why, which device, and whether it was effective" in post-event review.

[0005] Therefore, in order to address the above problems, there is an urgent need for a counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots. Summary of the Invention

[0006] Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots, which solves the problem of reachability deviation caused by the lack of consistent feedback verification when the linkage control is successfully sent.

[0007] Technical solution To achieve the above objectives, this invention employs the following technical solution: a counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots, comprising a multi-terminal data acquisition module for acquiring multiple types of emergency response datasets, performing unified time-base alignment, quality labeling, and normalization on these datasets to form emergency response acquisition data frames; an evidence graph fusion module for constructing evidence itemsets based on the emergency response acquisition data frames, performing consistency constraint fusion on the evidence itemsets to generate an emergency response evidence graph, and outputting a re-observation suggestion set based on the emergency response evidence graph; a risk-constrained collaborative planning module for constructing a collaborative task graph based on a situational object set, performing robot task allocation to generate a collaborative control instruction set, executing online replanning to output the collaborative control instruction set; a linkage execution and rollback closed-loop module for compiling the collaborative control instruction set into a linkage contract set, generating an execution proof package and executing evidence graph write-back to drive online replanning; and an evidence closure and audit playback module for constructing a closed-loop verification element set, performing closed-loop verifiable output of a closed-loop verification annotation frame, and triggering online replanning.

[0008] Furthermore, the specific process of collecting multiple types of emergency response datasets and performing unified time base alignment, quality labeling, and normalization on these datasets to form emergency response data frames is as follows: Multiple types of emergency response datasets are collected collaboratively by multi-source sensing devices and embodied robots. Within the same emergency response session, these datasets are classified, labeled, and prioritized. Based on the event windows and emergency response stage marker datasets in the datasets, timestamp alignment is performed on each record using a unified time base from the edge acquisition gateway to obtain the processed multi-type emergency response datasets. Each collected record is encapsulated using a unified data structure to construct an emergency response data frame, and a state snapshot data frame is constructed simultaneously. The collected multi-type emergency response datasets are then organized and cached using a unified data frame format, queue management, and frame dropping strategy. Finally, the emergency response data frames undergo normalization processing with a unified dictionary encoding mapping.

[0009] Furthermore, the specific process of constructing an evidence itemset based on emergency response data frames and performing consistency constraint fusion on the evidence itemset to generate an emergency response evidence graph is as follows: Input the emergency response data frame sequence, construct an evidence itemset within the same session and event window number context, and encapsulate the evidence itemset with a unified evidence structure to construct an emergency response evidence item structure; within the event window, perform in-window alignment and clustering of the evidence items based on the corrected sorting timestamp, and aggregate evidence items from different modalities within the same time slice and area into candidate evidence clusters using temporal and spatial neighborhood gating; establish consistency constraint edges between the candidate evidence clusters and the status snapshot evidence items of access control, screen display, broadcast, and fire-fighting linkage target equipment to construct an emergency response evidence graph; multiply the judgment result of whether each readback equals the expected state by the weight of this readback and sum them to obtain the weighted sum of the achieved readbacks; determine whether each readback does not equal the expected state. The judgment result is multiplied by the weight of this readback and summed to obtain the weighted sum of contradictory readbacks; the contribution weight of achieving the readback is multiplied by the weighted sum of achieving the readback, the penalty weight of contradictory readback is multiplied by the weighted sum of contradictory readbacks, and a bias parameter is added to obtain the provable term; the support probability is converted into a log-probability value, multiplied by the corroboration weight, and summed to obtain the corroboration weighted evidence sum; the contribution weight of multi-source corroboration is multiplied by the corroboration weighted evidence sum as the corroboration term, and the effective delay is divided by the action timeout limit to obtain the delay ratio; the effective delay penalty weight is multiplied by the delay ratio to obtain the delay penalty term; the comprehensive penalty weight is multiplied by the conflict comprehensive penalty term to obtain the comprehensive penalty term. The provable term, corroboration term, delay penalty term, and comprehensive penalty term are input into the mapping function to obtain the proof confidence value; the proof confidence value is written as the confidence attribute of the state node and the confidence attribute of the constraint edge into the emergency response evidence graph snapshot, and the conflict cause code and evidence graph snapshot are output.

[0010] Furthermore, the specific process of outputting a re-observation suggestion set based on the emergency response evidence map is as follows: input an evidence map snapshot, generate a situational object set under the context of event window number and stage marker, use the proof confidence value of each linked state node in the emergency response evidence map as the evaluation index of the linkage effectiveness credibility view, and bind the proof confidence value with the topology region node set and the channel edge set, determine the associated linked state node set for each channel edge, and use the minimum proof confidence value in the set as the edge credibility value of the channel edge; perform a blockade effectiveness judgment and situational update for each channel edge.

[0011] Furthermore, the specific process of constructing a collaborative task graph based on the situational object set and generating a collaborative control instruction set for robot task allocation is as follows: Input the situational object set, construct a collaborative task graph under the same session ID, event window number, and stage marker context, generate a task contract record for each task node, and perform multi-robot task allocation and path generation based on the collaborative task graph: generate a candidate path set for each robot and each task, and perform constraint pruning and satisfiability evaluation on the candidate path set to form a feasible candidate set; multiply the time consistency cost by the time dimension weight coefficient, multiply the link unreliability cost by the communication dimension weight coefficient, and multiply the energy insufficiency cost by the energy dimension weight coefficient. The cost is calculated by multiplying the cost of unstable mapping and localization by the weighting coefficients of the mapping and localization dimensions, multiplying the cost of insufficient proof by the weighting coefficients of the provable dimensions, and summing all five products. The comprehensive cost is then gating the comprehensive cost using path control gating to obtain a satisfaction evaluation value. This satisfaction evaluation value is used as the basis for task allocation and ranking: for each task, the combination that maximizes the satisfaction evaluation value is selected from all robots and feasible candidate paths as the task execution combination. Channels are maintained at the edge; when candidate paths and execution sequences are generated, each channel edge is written to the time slice reservation table via an action, and conflict detection is performed before writing. A collaborative control instruction set is output.

[0012] Furthermore, the specific process of executing the online replanning output collaborative control instruction set is as follows: During the execution of the collaborative control instruction set, incremental updates of emergency response data frames, state snapshot data frames, and evidence graph snapshots are continuously received, and the satisfaction evaluation value of the set of unfinished tasks is recalculated in each scheduling cycle; for each unfinished task, the current robot telemetry information, the current channel edge time slice reservation table, the current link index, the current blockade validity field, and the channel edge credibility field are read, and the satisfaction evaluation value of the robot's task execution is recalculated. When the abnormal handling rules are met, the unexecuted reserved time slices are frozen and the corresponding reservation records are revoked, the affected task subgraph is reconstructed, and the updated collaborative control instruction set is generated; for each updated task, the robot and path combination with the largest satisfaction evaluation value is reselected from the candidate robot set and the candidate path set, and the execution order table, communication relay dependency edge, and supplementary evidence dependency edge are regenerated; and the collaborative control instruction set is output.

[0013] Furthermore, the specific process of compiling the collaborative control instruction set into a linkage contract set is as follows: Input the collaborative control instruction set, and under the same session ID, event window number, and stage marker context, compile each instruction into a linkage contract set; the linkage contract set includes: a subset of device linkage contracts and a subset of robot action contracts; perform pre-validation of permissions and executability checks on each linkage contract, generating a contract executability flag; when any check fails, mark the contract as unexecutable and output the failure reason code, simultaneously writing the failure reason code into the linkage execution annotation frame; execute and issue linkage contracts that pass the checks. Receipt closure: In the distribution phase, action commands are issued to the target device or target robot according to the contract ID and idempotent key, and the distribution timestamp, target interface identifier, and link indicator snapshot are recorded; in the receipt phase, the receipt from the target end is received within the completion time limit. When the target end does not have the receipt capability, the contract is forcibly bound to the status readback and evidence closure requirements, and the status snapshot and on-site evidence are used to replace the receipt; when there are cases where the receipt is successful but the readback is inconsistent, the readback is consistent but the evidence is missing, or the receipt is missing and the readback fails, the contract is marked as pending supplementary evidence or pending rollback, and the execution process is uniformly encapsulated into a linkage execution annotation frame and output.

[0014] Furthermore, the specific process of generating execution proof packages and performing evidence graph write-back to drive online replanning is as follows: Input the linkage execution annotation frame, state snapshot data frame, and evidence graph snapshot. Under the same session ID, event window number, and stage marker context, generate an execution proof package for each linkage contract; perform versioned archiving on the execution proof packages: generate proof package version keys according to event window number, contract ID, and idempotent key, and prohibit overwriting historical versions; when the same contract is executed multiple times due to retry, rollback, or replacement of linkage objects, retain multiple version proof packages; construct version chains of retry, rollback, and replacement objects in the evidence graph based on version causality, and perform deambiguation verification on the target state transition in the state snapshot to avoid the state drift caused by retry being misjudged as effective or ineffective; record the failure reason code, consistency judgment result, and remedial action corresponding to each version in the ledger, and write the execution proof package back to the protruding evidence graph: add execution annotation nodes and contract association edges in the evidence graph, and bind the execution annotation nodes to the corresponding state nodes and channel edge resource nodes.

[0015] Furthermore, the specific process of constructing a closed-loop verification element set and outputting a closed-loop verification annotation frame is as follows: Input the execution proof package set, the state snapshot data frame set, and the emergency response evidence graph snapshot. Under the same session ID, event window number, and stage marker context, uniformly verify and traceably encapsulate the deliverable evidence elements, delivered evidence elements, execution dependency satisfaction, version evolution, and timing alignment within the event window, generating a closed-loop verification annotation frame and writing it back to the emergency response evidence graph. For each linked contract set within the event window, count the number of proof package versions and extract the causal relationships between versions to form a version evolution. When the same contract generates multiple proof packages due to retry, rollback, or replacement of linked objects, write the version link relationship into the version evolution link to construct a timing alignment. The alignment deviation is calculated by merging the verification records; for each record, the corrected sorting timestamp and edge reception timestamp are read, the absolute deviation is calculated, and the median is taken to obtain the median delay difference of the event window; at the same time, the duration of the event window is read, and the penalty values ​​for missing evidence closure, execution causality violation, version drift, and timing alignment deviation are added together to obtain the total penalty; the total penalty is obtained by subtracting the total penalty from the absolute value of the closed-loop verification dimension set; the closed-loop verifiable value is obtained by dividing the effective value by the absolute value of the closed-loop verification dimension set; the closed-loop verifiable value and the alignment deviation of the version evolution link are uniformly encapsulated into a closed-loop verification annotation frame and output; the closed-loop verification annotation frame is written into the emergency response evidence graph as an execution annotation node, and the association edges between the contract node, channel edge resource node, and linkage status node are established.

[0016] Furthermore, the specific process of triggering online replanning is as follows: Under the same session ID, event window number, and stage marker context, corresponding handling actions are generated based on the closed-loop verification annotation frame. These actions include executable completion tasks, rollback actions, retry convergence actions, and alignment repair actions. The actions and tasks are then written back to the collaborative task graph and the emergency response evidence graph to drive online replanning. A closed-loop completion condition set is generated for the event window, and a closed-loop status marker is output based on the closed-loop verifiable value and the closed-loop completion condition set. A closed-loop completion task is generated based on the closed-loop verification annotation frame. When the missing feature index set is not empty, a completion task node set is generated by grouping missing features by feature type. For missing status readback field indexes, a status rereadback task is generated. For missing supporting evidence fragment indexes, a supplementary evidence re-observation is generated. For tasks involving missing link indicator snapshot indexes or upload record indexes, generate evidence upload and retransmission tasks and write them into the target link condition set; generate rollback and sequential repair actions; when the violation dependency edge index set is not empty, generate a causal repair action set for each violation dependency edge, and generate idempotent convergence and replacement strategies based on the version evolution link; write the closed-loop verification annotation frame back to the task graph and evidence graph, and trigger online replanning: merge all repair tasks and actions into a closed-loop repair task set, write the closed-loop repair task nodes and dependencies into the collaborative task graph, write the repair actions into the linkage contract set, and synchronize them to the execution annotation frame; when the closed-loop repair task is completed or the rollback action takes effect, recalculate and generate a new closed-loop verification record; all closed-loop verification records will retain the version.

[0017] Beneficial effects The present invention has the following beneficial effects: (1) This invention improves the accuracy of task execution by introducing a task execution verification mechanism. Compared with the traditional assumption that sending is successful, this invention ensures that the actual effectiveness of the task can be accurately reflected by dynamically verifying the device status, link quality and permission verification, thereby avoiding execution deviations caused by device failure, link jitter or permission errors.

[0018] (2) This invention enhances the adaptability of the counter-terrorism and emergency response process through multi-source data fusion and real-time replanning. By fusing various sensing data from fixed-end video, thermal imagers, radar, and robots, the system can monitor the mission status in real time and trigger replanning in critical situations, thereby ensuring that the best execution path and execution order are always selected in dynamic environments.

[0019] (3) This invention ensures that the task status is traceable and verifiable by establishing a closed-loop feedback mechanism. By recording key data in real time during the task execution process and combining it with evidence diagrams for closed-loop repair and verification, it can provide comprehensive traceable records and support real-time review and subsequent debriefing of task execution results.

[0020] (4) This invention ensures the efficiency and accuracy of multi-task collaboration through closed-loop repair and evidence graph write-back. By synchronously writing back and versioning the task graph, evidence graph and execution annotations, all updates to tasks and paths during task collaboration can be accurately recorded, facilitating querying and retrospective analysis.

[0021] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0022] Figure 1 This is a structural diagram of the anti-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot of the present invention; Figure 2 This is a time sequence diagram of the data collected during emergency response in this invention; Figure 3 This is a distribution and priority diagram of the collaborative task satisfaction score of the present invention; Figure 4 This is a graph showing the real-time changes in the task satisfaction score of this invention. Figure 5 This is a flowchart of the closed-loop verifiable calculation and evidence graph write-back process of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Please see Figures 1-5 This invention provides a technical solution: a counter-terrorism and emergency response collaborative control system based on multi-source perception and embodied robot fusion, comprising a multi-terminal data acquisition module for acquiring multiple types of emergency response datasets, performing unified time base alignment, quality labeling, and normalization on the datasets to form emergency response acquisition data frames; an evidence graph fusion module for constructing evidence itemsets based on the emergency response acquisition data frames, performing consistency constraint fusion on the evidence itemsets to generate an emergency response evidence graph, and outputting a re-observation suggestion set based on the evidence graph; a risk-constrained collaborative planning module for constructing a collaborative task graph based on a situational object set, performing robot task allocation to generate a collaborative control instruction set, and executing online replanning to output the collaborative control instruction set; a linkage execution and rollback closed-loop module for compiling the collaborative control instruction set into a linkage contract set, generating an execution proof package and executing evidence graph write-back to drive online replanning; and an evidence closure and audit playback module for constructing a closed-loop verification element set, performing closed-loop verifiable output of a closed-loop verification annotation frame, and triggering online replanning.

[0025] Specifically, the process of collecting multiple types of emergency response datasets and performing unified time-base alignment, quality labeling, and normalization on these datasets to form emergency response data frames is as follows: Multiple types of emergency response datasets are collected collaboratively by multi-source sensing devices and embodied robots. These datasets include: fixed-end video and thermal imaging datasets, fixed-end radar and perimeter sensing datasets, access control and channel control status datasets, screen display and broadcast operation status datasets, fire linkage and safety facility status datasets, environmental risk and visibility datasets, power supply and communication link status datasets, robot near-field multimodal sensing datasets, robot operation telemetry and health status datasets, timestamp datasets, event windows, and emergency response stage markers. The dataset includes a device identity and permission verification dataset; the fixed-end video and thermal imaging dataset includes: visible light image frame sequences, low-light enhanced image frame sequences, thermal imaging temperature pseudo-color image frame sequences, and corresponding frame segment indices from fixed cameras. This data is obtained through continuous output from multiple cameras and thermal imagers deployed in station halls, platforms, transfer passages, entrances / exits, and bottleneck areas using RTSP or vendor SDKs, and is used for crowd situation estimation, suspicious area alerts, and on-site evidence verification; the fixed-end radar and perimeter sensing dataset includes: a millimeter-wave target list, point trajectory, coverage area confidence, blind zone markers, and echo quality indicators. This data is obtained through periodic acquisition by fixed millimeter-wave radar or perimeter sensing units and is used for smoke detection. The dataset includes supplementary evidence of target existence and motion consistency under low light and occlusion conditions; the access control and channel control status dataset includes: door opening / closing status, lock mode, normally open and normally closed policy flags, linkage coverage flags, alarm codes, and readback failure reason codes, which are collected through access controllers, turnstile controllers, and fire door controllers using polling readback and mutation reporting methods, and are used to update channel accessibility and control status; the display and broadcast operation status dataset includes: display partition number, current display template number, direction indicator parameters, broadcast partition number, channel number, playback status, content ID, volume level, device online status, and fault codes, which are obtained through the control interface and readback interface between the display controller and the broadcast host. The dataset is collected synchronously and used for evacuation guidance linkage and effectiveness verification; the fire linkage and safety facility status dataset includes: smoke and heat detector alarm status, smoke exhaust fan status, roller shutter door status, emergency lighting status, sprinkler zone status, and fire control panel event codes. It is continuously collected by the fire control panel and linkage controller during emergency response sessions and is used for risk stratification and safety facility linkage consistency verification; the environmental risk and visibility dataset includes: smoke concentration, particulate matter concentration, combustible gas concentration, toxic gas concentration, temperature and humidity, pressure, visibility estimates, and abrupt change detection markers. It is obtained through environmental sensor arrays and edge-side visibility estimation algorithms and is used to construct multi-layer risk fields and drive sampling strategy switching.The power supply and communication link status data set includes: switch port status, wireless access point load, link bandwidth estimation, round-trip delay RTT, jitter, packet loss rate, retransmission count, UPS status, and critical node power supply alarm, which are collected through the management interfaces of network devices and power supply devices by the edge gateway and are used for flow selection under communication jitter and linkage timeout determination; the robot near-field multi-modal perception data set includes: robot on-board camera image frames, thermal image frames, lidar point cloud slices, millimeter-wave target lists, acoustic array positioning results, gas sensing readings, and near-field key segment indexes, which are collected by ground robots and indoor drones during mission execution at the task window granularity and are used for near-field confirmation, blind spot filling and re-observation, and on-site verification; the robot operation telemetry and health status data set includes: robot pose, speed, local map quality score, obstacle avoidance status, task ID, power, temperature, computing power load, communication signal strength, robot-side packet loss rate, and link gear, which are collected synchronously through the robot controller and the edge-side telemetry channel and are used for collaborative scheduling, risk constraint cropping, and degradation; the timestamp data set includes: device local timestamp, edge reception timestamp, platform storage timestamp, time calibration deviation, time calibration quality index, and delay estimation parameters, which are appended to each record through the time service and link measurement services provided by the edge node and are used for unified time series sorting and window alignment; the event window and emergency response phase marking data set includes: event window number, phase marking, trigger reason code, window quality score, and window boundary marking, which are generated by the edge-side event trigger and the command-side phase switching instruction and are used to organize the mixed data stream into an emergency response window that can be replayed and reproduced; the device identity and permission verification data set includes: device identity identifier, certificate fingerprint, token verification result, authorization domain, rejection reason code, and session signature, which are generated synchronously by the access authentication and access control component during collection and read-back and are used to bind the collection record to the permission context and support the verification of linkage preconditions.

[0026] Classify and mark multiple types of emergency response datasets and manage their priorities within the same emergency response session. Mark the status read-back records of access control, screen display, broadcasting, and fire protection as receipt corroboration class priority records, mark the robot near-field confirmation segments and fixed-end key frames as evidence class priority records, and mark the continuous background videos and low-value point clouds as background class priority records; Set up independent queues and guaranteed bandwidth budgets for priority records within the event window to ensure that linkage effect certificates and key risk evidence are not crowded out by background traffic under communication jitter conditions; Based on the event window and emergency response phase marker datasets in multiple types of emergency response datasets, use the edge acquisition gateway to perform timestamp alignment on each record with a unified time base to obtain the processed multiple types of emergency response datasets. Increase the sampling frequencies of thermal imaging, millimeter wave, environmental mutation, and robot near-field in the confirmation phase, and perform encrypted read-back on key fields of access control and fire protection; Increase the read-back frequencies of screen display and broadcast partitions and bind the on-site corroboration segment indexes in the isolation prompt and evacuation guidance phases to ensure that the linkage effect is provable; Reduce the background flow sampling in the review phase and prioritize filling in the missing records within the window to complete the evidence package closure; Perform NTP time calibration mapping on the device local timestamp, perform deviation compensation on controllers with fixed deviations, and online calculate the correction time for channels with link jitter by combining RTT statistics and queue delay estimation, so that video key frames, status read-back, robot telemetry, and environmental mutations share a unified time index at the same physical moment; Maintain an incrementing sequence number for each data source and perform gap detection, out-of-order rearrangement, and duplicate removal. Write the out-of-order marker and gap marker into the record header to ensure reproducibility within the window; Package each acquisition record with a unified data structure to construct an emergency response acquisition data frame, and synchronously construct a status snapshot data frame. The emergency response acquisition data frame includes: frame, session, data source, modality type, event window number, phase marker, trigger reason code, device timestamp, edge reception timestamp, platform storage timestamp, correction sorting timestamp, spatial reference, pose uncertainty, payload index, payload, quality score, failure label, link metrics, and security context; The quality score is used to record the reduced availability caused by low light, overexposure, blur, strong occlusion, smoke degradation, point cloud degradation, and link packet loss. The failure label is used to record the specific failure mode category of the reduction. The payload index is used to bind large-scale video segments and point cloud slices to the unified frame header in a reference manner to avoid occupying the main message bus. The status snapshot data frame includes: snapshot, target device, session, event window number, phase marker, device online status, permission verification status, key read-back fields, device health fields, link metrics, effective corroboration index, device timestamp, edge reception timestamp t_edge, platform storage timestamp, and correction sorting timestamp; The key read-back fields include access control opening / closing and locking control, screen display template and direction parameters, broadcast partition and playback status, fire protection linkage status, and event code. The effective corroboration index is used to bind the index of the fixed-end key frame or robot near-field confirmation segment at the read-back moment.

[0027] The collected emergency response datasets are organized and cached using a unified data frame format, queue management, and frame dropping strategy. Data frames are archived by session ID and event window number, and local queues are sorted by source ID, prioritizing the retention of status snapshot frames and evidence frames. When the cache approaches its upper limit, background frames are discarded while retaining key mutation frames and supporting evidence frames within the event window, ensuring demonstrable linkage and recapable risks. At the edge, a missing frame list and re-collection plan are maintained for each event window. After link recovery, missing frames are re-transmitted according to the corrected sorting time, ensuring window evidence closure. The collected emergency response data frames undergo normalization processing using a unified dictionary encoding mapping. Environmental fields such as smoke concentration, gas concentration, and temperature, humidity, and pressure are uniformly mapped according to sensor ranges and linearly scaled to a unified interval to eliminate scale differences caused by different manufacturers and different ranges; link indicators are normalized according to statistical windows to form comparable link quality dimensions; device status enumeration values ​​are mapped using a unified dictionary encoding to ensure semantic consistency of fields across systems; and quality scores, failure tags, and security contexts are bound to each record at edge acquisition nodes.

[0028] like Figure 2 The time-series graph of emergency response data collection shows the trends of event number, data quality score, lockdown status, and network signal strength over different time periods. Observation reveals abrupt changes in event numbers at specific points in time, potentially indicating a switch in tasks or phases; significant fluctuations in data quality scores suggest unstable data collection quality; marked changes in lockdown status within a specific time period may be related to the implementation of lockdown measures; and fluctuations in network signal strength reveal fluctuations in communication quality, which may affect task execution and the reliability of data transmission. Overall, the graph provides a clear view of the dynamic data changes during emergency response, helping to analyze the reliability of task execution and the need for adjustments to control strategies.

[0029] In this implementation plan, gap detection, disordered rearrangement, deduplication, and missing list supplementation mechanisms achieve window evidence closure, improving the completeness and traceability of post-event review; unified dictionary encoding and dimensional normalization eliminate semantic differences in fields across vendors, ranges, and systems, improving the consistency of multi-source fusion and the stability of automated processing; and it enables reliable collaboration of risk stratification, lockdown and evacuation linkage, near-field verification, and evidence archiving within the same window context during emergency response, making response decisions more verifiable, coordinated execution more provable, and situation evolution more reviewable.

[0030] Specifically, the process of constructing an evidence itemset based on emergency response data frames and performing consistency constraint fusion on the evidence itemset to generate an emergency response evidence graph is as follows: Input the emergency response data frame sequence, construct an evidence itemset within the same session and event window number context, and encapsulate the evidence itemset with a unified evidence structure to construct an emergency response evidence item structure; within the event window, perform in-window alignment and clustering organization of the evidence items based on the corrected sorting timestamp, and aggregate evidence items from different modalities within the same time slice and the same region into candidate evidence clusters using temporal neighborhood gating and spatial neighborhood gating; introduce a time-series tolerance window for data sources with link jitter, and adaptively adjust the size of the tolerance window according to the link indicators to avoid misjudging the disorder caused by link jitter as physical event disorder.

[0031] To construct an emergency response evidence graph, establish consistency constraint edges between candidate evidence clusters and status snapshot evidence items of access control, display screens, broadcasting, and fire-fighting linkage target equipment. Multiply the result of each readback's determination of whether it equals the expected state by the current readback weight and sum them to obtain the weighted sum of achieved readbacks. Multiply the result of each readback's determination of whether it does not equal the expected state by the current readback weight and sum them to obtain the weighted sum of contradictory readbacks. Multiply the achieved readback contribution weight by the achieved readback weighted sum, multiply the contradictory readback penalty weight by the contradictory readback weighted sum, and add a bias parameter to obtain the provable item. Convert the support probability to a log-probability value, multiply it by the corroboration weight, and sum to obtain the corroboration weighted evidence sum. Multiply the multi-source corroboration contribution weight by the corroboration weight. Evidence, as supporting evidence, is obtained by dividing the effective delay by the action timeout limit to get the delay ratio; the delay penalty is obtained by multiplying the delay effective penalty weight by the delay ratio; the comprehensive penalty is obtained by multiplying the comprehensive penalty weight by the conflict comprehensive penalty. The provable item, supporting evidence, delay penalty, and comprehensive penalty are input into the mapping function to obtain the proof confidence value. The proof confidence value is written into the snapshot of the emergency response evidence graph as the confidence attribute of the state node and the confidence attribute of the constraint edge, so that the linkage control no longer relies on the sending of instructions and the display of the interface as the basis for success, but on the provable results of state readback, multi-source supporting evidence, and interpretable link and permission penalties. The specific calculation method of the proof confidence value is as follows: ; In the formula, This represents the confidence level value, which is used as the basis for the confidence level of state nodes in the evidence graph, the confidence level of reachability topology edges, and the situation classification. This represents the Sigmoid mapping function, used to map the real number score within the parentheses to the interval (0,1); The bias parameter is obtained by fitting the overall bias through offline calibration of achieved and unachieved labels. Its value range is [-10, 10], and it is used to provide baseline confidence when there is a lack of readbacks and corroboration. The readback contribution weight is obtained by filtering out a set of samples that have readbacks and whose readbacks are equal to the desired state. The value range is [0,10], which is used to avoid mismatch caused by a single abnormal readback. This represents the weight of the k-th readback, calculated by correcting the sorting timestamp, with a value range of [0,1], used to reflect the contribution of this readback to whether it has taken effect; This indicates the number of times the target device's status is read back within the timeout window. It is obtained by counting the status snapshot data frames within the event window and is used to limit readback overhead and ensure that the judgment is completed within the time limit. This indicates an indicator function, which is obtained directly through comparison and judgment, and is used to map logical conditions to numerical values; The key field combination representing the k-th state readback is obtained by extracting the readback fields from the state snapshot data frame and mapping them through a unified dictionary encoding, and is used for consistency comparison with the expected state. It represents the expected state of an action, which is generated before the action is issued by linking the action semantics and action parameters according to the same state dictionary mapping rule, and is used as the sole comparison benchmark for whether it has been achieved. The value represents the penalty weight for contradictory readbacks, which is obtained by filtering out the sample set of readbacks that are not equal to the expected state. The value range is [0,10], and it is used to distinguish between delayed achievement and no achievement at all. This represents the contribution weight of multi-source corroboration, which is obtained by statistically analyzing the correlation between different corroborations within the same event window. The value range is [0,10], and it is used to ensure that the corroboration items are provable, calibrable, and deredundant contributions. denoted as the weight of the i-th corroboration, which is obtained by jointly mapping the quality score of the corroboration fragment, the degradation label, the link jitter and latency statistics, and the spatial matching quality. The value range is [0,1], and it is used to suppress the unexpected impact of degraded corroboration and mismatched corroboration on confidence. The probability that the i-th piece of evidence supports the achievement of the desired state is obtained by outputting the confidence level through the detection, identification and consistency test of the corresponding evidence modality and then calibrating it with probability. The value range is [0.01, 0.99], which is used to convert the evidence into an accumulable strength of evidence. This represents the penalty weight for delayed implementation, which is calculated directly from the time limit constraint configuration. The value range is [0,10], and it is used to fix the rules of counting late arrivals as arrivals and late arrivals as configurable numerical constraints. This indicates a delay in effectiveness, calculated by correcting the sorting timestamp, and is used to penalize delayed effectiveness and non-effectiveness. This indicates the timeout limit for an action, which is given by the linked action configuration and is fixed according to the action type. It is used to limit the readback and supporting statistics window and to standardize the provable judgment within the time limit. The comprehensive penalty weight is determined by the maximum penalty requirement of the penalty matrix and has a value range of [0,10]. It is used to implement constraints that cannot be judged as proven effective when there are permission failures, device offline and significant conflicts into checkable matrix rules. The conflict comprehensive penalty is obtained by normalizing and fusing the normalized values ​​of permission verification status, device online status, read failure rate and link packet loss rate, and the conflict contribution associated with the action in the conflict response evidence graph. It is used to reduce the provable confidence when permission fails, device is offline, link is abnormal or evidence conflicts occur, so as to avoid the misjudgment that sending is successful.

[0032] Based on the proof confidence value, the state nodes and consistency constraint edges in the conflict response evidence graph are labeled with confidence. When the proof confidence value is less than the first-level proof confidence threshold, the state node is marked as unprovable and the corresponding constraint edge is downgraded to a soft constraint pending confirmation. When the first-level proof confidence threshold is less than or equal to the proof confidence value less than the second-level proof confidence threshold, the state node is marked as delayed and a readback or embodied robot re-observation is triggered to supplement the evidence. When the proof confidence value is greater than or equal to the second-level proof confidence threshold, the state node is marked as proven and the corresponding constraint edge is promoted to a reachability hard constraint. The conflict cause code and evidence graph snapshot are output.

[0033] In this implementation scheme, by classifying and labeling state nodes and constraint edges with confidence and switching between soft and hard constraints, the reachability and control status can be prevented from being solidified too early under uncertain or conflicting conditions, reducing situational drift and path misjudgment. At the same time, when the confidence is insufficient, the system triggers a readback and embodied robot re-observation to supplement the evidence, enabling the emergency response process to have online closed-loop verification and evidence self-healing capabilities, thereby improving the reliability, reproducibility and reviewability of the linkage effectiveness determination.

[0034] Specifically, the process of outputting a re-observation suggestion set based on the emergency response evidence map is as follows: Input an evidence map snapshot, and generate a situational object set in the context of event window number and stage marker. The situational object set includes: a multi-layer risk field, a three-dimensional accessibility topology map, a linkage effectiveness confidence view, a conflict list, and a re-observation suggestion set. The multi-layer risk field is jointly derived from the risk source node set, alarm event node set, personnel and asset node set, and spatial grid index in the evidence map snapshot. The risk level, influence radius, propagation parameters, and time freshness parameters of the risk source nodes are mapped to the basic risk intensity of the grid cells, and the confidence, duration, and location of the alarm event nodes are superimposed as dynamic risk increments to obtain a risk voxel field or risk grid field organized by floor and height slices. The location of the risk source nodes is determined by the area identifier bound in the evidence map, the camera field of view area code, the access control and gate installation point code, or the positioning anchor point code.

[0035] The basic topology reads the set of regional nodes and the set of passage edges from the pre-set BIM, indoor map, and electronic map vector layers, and writes the passable structures of elevators, stairs, access control, and passages as edge types. The real-time lockdown status is provided by access control status readback nodes, video recognition occupancy nodes, broadcast and screen display evacuation guidance nodes, and personnel flow observation nodes in the evidence map snapshot. The basic topology is updated by disabling edges, updating edge costs, or updating directional constraints according to the event window number to obtain the three-dimensional reachability topology in the event window context. The linkage effectiveness credibility view uses the triplet of regional nodes, passage edges, and linkage objects as the smallest display unit: the proof confidence of the linkage status node is associated with the corresponding control object identifier, action type, target area code, and action transaction identifier, and mapped to regional and edge-level visual attribute fields. The association between passage edges and linkage status nodes is determined by any of the following methods: based on the control object and topology element mapping table, based on the consistency constraint of the regional code, or based on the causal edge tracing in the evidence map. The effectiveness determination of the blockade includes: when the edge confidence level is lower than the edge activation threshold or there are unresolved mutually exclusive actions marked in the conflict list, the channel edge is marked as unconfirmable blockade and requires re-observation, triggering the generation of a re-observation suggestion set; the re-observation suggestion set includes at least: a list of control objects that need to be read back, suggested readback field definitions, suggested sampling times, time intervals, and recommended supporting channels. Situation updates include incremental updates to the edge status, edge cost, and reachable path set of the 3D reachability topology graph, and simultaneous updates to the risk increment of the multi-layer risk field within the edge's influence area.

[0036] The proof confidence value of each linked status node in the emergency response evidence diagram is used as the evaluation index for the linkage effectiveness credibility view. The proof confidence value is bound to the topology area node set and the channel edge set. The value set of the hierarchical label is limited to: proven effective, suspected delayed effective, unprovable effective, permission verification failed, and device offline. The situation is output in the situation report, with a cause code index and supporting evidence index corresponding to each hierarchical label. The cause code index identifies the category of reason that leads to the hierarchical label, and the supporting evidence index locates the status snapshot and on-site supporting evidence fragments, allowing the command center to directly view whether the linkage is effective, why it was judged this way, and where the corresponding evidence is located. For each channel edge, a set of associated linked status nodes is determined, and the minimum proof confidence value within the set is used as the edge credibility value of the channel edge. The effectiveness of the blockade and situation update are performed for each channel edge. When the readback field indicates that the lockdown configuration is established and the edge confidence value is not less than the second threshold, the lockdown validity field of the channel edge is set to valid and the reachability of the channel edge is marked as unreachable. The readback field indicating that the lockdown configuration is established includes one of the following situations: the access control lock status is locked, the fire door status is closed, the roller shutter door status is falling, and the field comes from the readback field of the status node in the emergency response evidence diagram.

[0037] When the readback field indicates that the blockade configuration is established, and the edge confidence value is not less than the first threshold and less than the second threshold, the blockade validity field of the channel edge is set to pending verification, and the verification task for the channel edge coverage area is output in the re-observation suggestion set. The verification task includes: performing one or more status rereadbacks on the target device and recording the timestamp and readback result of each readback; calling a fixed-end camera or embodied robot to collect on-site supporting evidence segments in the channel edge coverage area and binding the supporting evidence index to the channel edge.

[0038] When the edge confidence value is less than the first threshold, or the status node associated with the channel edge has a permission verification failure label or the device is offline, the channel edge's blocking validity field is set to unprovable blocking, and a set of actions is output. The set of actions includes: performing a status rereadback on the same target device to exclude short-term link anomalies; marking the edge as not participating in reachability calculation as a hard constraint; selecting an alternative passage path or alternative guidance strategy in the reachability topology graph that does not depend on the edge blocking conclusion; and assigning an embodied robot to perform near-field re-observation of the area covered by the edge and send back the supporting evidence fragment index to supplement the provable evidence.

[0039] This enables the linked effectiveness credibility view in the situation object set to share the same provable effective state source with the three-dimensional reachability topology map, allowing the situation map to output executable supplementary verification tasks in the observation suggestion set for closed-loop updates.

[0040] In this implementation plan, by performing hierarchical credibility labeling on the state nodes and consistency constraint edges in the emergency response evidence diagram, and switching between soft and hard constraints according to the hierarchical results, the evidence within the event window is gradually closed and online closed-loop verification is completed. This improves the stability and consistency of the linkage effectiveness determination under complex on-site conditions, and supports the entire process to be replayable and reproduced by window and to be traceable and reviewed afterward.

[0041] Specifically, the process of constructing a collaborative task graph based on a situational object set and generating a collaborative control instruction set for robot task allocation is as follows: Input the situational object set and construct a collaborative task graph under the same session ID, event window number, and stage marker context. The collaborative task graph includes: a set of task nodes, a set of robot nodes, a set of channel edge resource nodes, a set of linked equipment resource nodes, a set of communication resource nodes, a set of constraint edges, and a set of execution dependency edges. The set of task nodes includes: supplementary certification and re-observation tasks, lockdown effectiveness verification tasks, key area coverage tasks, suspected risk source location tasks, evacuation guidance and assistance tasks, and communication relay deployment tasks. The set of constraint edges includes: reachability constraints, lockdown effectiveness constraints, edge credibility constraints, capacity constraints, communication availability constraints, permission domain constraints, and robot health constraints. The set of execution dependency edges includes: dependencies such as supplementary certification before entry, relay before deep area entry, and clearing bottlenecks before diversion.

[0042] When constructing the collaborative task graph, the risk grid values ​​and visibility fields of the multi-layer risk field are read, as well as the node set, channel edge set, channel capacity field, blockade effectiveness field, and edge credibility field of the 3D reachability topology graph. The linkage status classification labels, cause code index, and supporting index of the linkage effectiveness credibility view are read, and the conflict cause code and conflict contribution of the conflict list are read to form the planning input set. The planning input set includes: robot pose, speed, remaining power ratio, motor and load status, local map quality score, robot end link packet loss rate, communication signal strength and link level; channel edge length, channel edge capacity, risk statistics of edge coverage area, edge credibility, and blockade effectiveness; online status of linkage equipment, permission verification status, read-back fields and corresponding proof confidence values; and communication link RTT, jitter, packet loss rate, repetition calculation, and bandwidth estimation.

[0043] For each task node, a task contract record is generated. The task contract record includes: task ID, task type, target area or target object, earliest start time, latest finish time, completion time limit, entry condition set, exit condition set, required sensor set, required communication condition set, required permission domain, success determination condition set, failure reason code set, and exception handling rules. The success determination condition set includes: the coverage rate of the coverage task reaches the preset coverage ratio; the re-observation task obtains stable observation and generates a supporting index within a certain number of consecutive time slices; the lockdown review task ensures that the read-back fields meet the lockdown configuration conditions and can be bound to the supporting index; the relay deployment task ensures that the target area link indicators meet the required communication condition set. The failure reason code set includes: channel unreachable, lockdown unprovable, permission verification failed, device offline, communication conditions not met, local map quality score not meeting the threshold, and capacity constraint conflict. The exception handling rules include: triggering re-read-back, reassigning robots, switching to backup channels, switching to backup linkage objects, and deploying relays before executing deep area tasks.

[0044] Multi-robot assignment and path generation based on collaborative task graph: A candidate path set is generated for each robot and each task, and constraint pruning and satisfiability evaluation are performed on the candidate path set to form a feasible candidate set; constraint pruning includes: when a candidate path contains a channel edge with a valid blockade validity field and a readback field indicating that the blockade configuration is established, the candidate path containing the channel edge is removed; when a candidate path contains a channel edge with a blockade validity field that is pending verification or unprovable blockade, the channel edge is not used as a removal condition, but a verification dependency edge is added to the task contract, so that the re-observation task or state rereadback must be completed before entering the channel edge coverage area; when the robot's local map quality score does not meet the task entry condition set, the robot is prohibited from being assigned to the task that needs to enter the area, and the candidate task is limited to the boundary coverage or communication relay deployment type.

[0045] The time consistency cost is multiplied by the time dimension weight coefficient, the link unreliability cost is multiplied by the communication dimension weight coefficient, the energy insufficiency cost is multiplied by the energy dimension weight coefficient, the mapping and positioning instability cost is multiplied by the mapping and positioning dimension weight coefficients, and the proof insufficiency cost is multiplied by the provable dimension weight coefficient. All five products are then summed to obtain the comprehensive cost. A path containment gating term is then used to gate the comprehensive cost to obtain the satisfaction evaluation value. The specific calculation method for the satisfaction evaluation value is as follows: ; In the formula, This represents the satisfaction assessment value, used to trigger online replanning decisions for reassignment, insertion of relay tasks, or insertion of supplementary certification tasks. This represents the path blocking gating item, which is obtained by traversing the set of channel edges of candidate paths and reading the blocking validity field and the read-back field judgment result of each channel edge. It is used to directly exclude candidate paths that cross proven blocked channel edges as hard constraints, causing the score to be directly set to zero. The time dimension weight coefficient is obtained by using the fields corresponding to the task type and stage marker, and then normalized by weight. The value range is [0,1], and it is used to adjust the contribution ratio of the time consistency cost to the overall cost. The time consistency cost is calculated by comparing the task completion deadline with the expected completion time, and then compressed to the 0-1 range according to the segmentation rule. The value range is [0,1], which is used to characterize the remaining amount of the combination to be completed within the task deadline. This represents the communication dimension weight coefficient, how it is obtained, and its value range is [0,1]. It is used to adjust the contribution ratio of link margin to the overall cost. The unreliable link cost is calculated by combining the link index fusion value of the candidate path coverage area with the lower limit of the task contract communication and then compressing it to the 0 to 1 range according to the segmentation rules. It is used to determine whether a communication relay deployment task needs to be inserted. This represents the energy dimension weight coefficient, which is generated by the dimension priority field and task type field in the task contract record. The value range is [0,1], and it is used to adjust the importance of energy dimension constraints when assigning tasks and selecting paths. The energy shortage cost is calculated by the ratio of the robot's remaining power to the ratio of the expected energy consumption of the task, and then compressed to the range of 0 to 1 according to the segmentation rule. It is used to characterize the remaining amount of energy required to complete the task and return or stay under the energy consumption constraints. This represents the weighting coefficients for mapping and localization dimensions. It is directly calculated based on the mapping degradation risk on the robot side and has a value range of [0,1]. It is used to increase the priority of mapping degradation risk control when allocating tasks and selecting paths. This represents the cost of unstable mapping and localization. It is calculated by using the robot's local map quality score and the lower limit of map quality specified by the task entry condition set, and then compressed to the 0 to 1 range according to the segmentation rules. It is used to trigger restricted entry areas or reassign robots. This represents the provable dimension weight coefficient, which is directly determined by the task's evidentiary obligation level. Its value range is [0,1], and it is used to emphasize provable constraints in task allocation, path selection, and online replanning. The insufficient proof cost is calculated by combining the provable value of the candidate path with the provable lower bound specified in the task contract and then compressed to the 0 to 1 range according to the segmentation rule. It is used to trigger the generation of supplementary proof re-observation or state reread back to the dependency edge.

[0046] The satisfaction evaluation value is used as the basis for task allocation and sorting: for each task, the combination that maximizes the satisfaction evaluation value is selected from all robots and feasible candidate paths as the task execution combination; when multiple combinations have the same satisfaction evaluation value, the order rule is the least number of conflicts and the least time consumed, and the execution order table is output. Channels are maintained at the edge. When candidate paths and execution order are generated, each channel edge passage action is written to the time slice reservation table, and conflict detection is performed before writing; when a reservation conflict is detected, a set of conflict resolution actions is output according to the conflict resolution rules. The set of conflict resolution actions includes adjusting the entry time, selecting an alternative channel edge, splitting the task into segmented passage actions, or reassigning robots, and the resolved results are written to the execution order table, ensuring that the number of concurrent occupancy times for the same channel edge within the same time slice does not exceed the number limited by the channel edge concurrency limit field. Reservation conflict detection includes: for the same channel edge, if a reservation record already exists in the same time slice, it is determined to be an overlapping conflict; or when the time slice intervals of two reservation records overlap and the safety interval slice count is not met, it is determined to be a safety interval conflict; and based on the channel edge concurrency limit field, the concurrency occupancy count in the same time slice is checked. When the concurrency occupancy count exceeds the concurrency limit, it is determined to be a concurrency conflict.

[0047] Output a collaborative control instruction set. The task allocation results, path results, spatiotemporal reservation results, and communication and supplementary evidence dependency results are uniformly encapsulated to generate a collaborative control instruction set. This set includes subsets of robot motion instructions, payload action instructions, re-observation and verification instructions, communication relay and evidence upload instructions, and an execution sequence table. Each instruction is bound to a session identifier, event window number, stage marker, trigger reason code, target area or target device, success criteria, completion time limit, failure reason code, and remedial action. A satisfaction evaluation value is also recorded, enabling the command end to reproduce the basis for task allocation, path selection, and relay or supplementary evidence generation within the event window context, and to traceably verify the triggering reasons for dependent edges and remedial actions.

[0048] Table 1, showing the collaborative task satisfaction evaluation data, records key indicators such as the type of different collaborative tasks, the executing robot, the target area, satisfaction level, and priority. This data is used to quantify the degree of compliance and priority ranking of robot collaborative task execution. For example, Task ID TASK-001: Task type is supplementary verification and re-observation; assigned robot ID is ROBOT-003; target area is channel A-102; satisfaction evaluation value is 0.89; execution priority is 1; compliance is "yes," indicating that the task's execution effect meets the collaborative task requirements. Similarly, Task ID TASK-002: Task type is control effectiveness verification; assigned robot ID is ROBOT-001; target area is access control B-005; satisfaction evaluation value is 0.89; execution priority is 1; compliance is "yes," indicating that the task's execution effect meets the collaborative task standards. Task ID TASK-003: Task type is evacuation guidance assistance; assigned robot ID is ROBOT-002; target area is the west wing of the station hall; satisfaction evaluation value is 0.84; execution priority is 2; whether it meets the standard is yes, indicating that the execution effect of this task meets the collaborative task requirements. Task ID TASK-004: Task type is communication relay deployment; assigned robot ID is ROBOT-004; target area is deep area C-008; satisfaction evaluation value is 0.78; execution priority is 2; whether it meets the standard is yes, indicating that the execution effect of this task meets the collaborative task indicators. Task ID TASK-005: Task type is key area coverage; assigned robot ID is ROBOT-003; target area is the transfer passage; satisfaction evaluation value is 0.86; execution priority is 3; whether it meets the standard is yes, indicating that the execution effect of this task meets the collaborative task requirements. Task ID is TASK-006; task type is suspected risk source location; assigned robot ID is ROBOT-001; target area is equipment room D-012; satisfaction evaluation value is 0.84; execution priority is 3; whether it meets the standard is yes, indicating that the execution effect of this task meets the collaborative task standard.

[0049] Table 1. Data Table of Collaborative Task Satisfaction Evaluation like Figure 3The distribution of collaborative task satisfaction scores and priority chart shows that TASK-001 and TASK-002 have relatively high satisfaction scores, both close to 0.90, belonging to priority 1 tasks. This indicates that these tasks have a high degree of completion during execution, are likely to receive more resource support, and perform well. The red dashed line in the chart represents the executable threshold. Only when a task's satisfaction evaluation value is higher than the executable threshold can the task be guaranteed to execute smoothly under resource and scheduling conditions. By combining priority and satisfaction evaluation values, the execution status of each task and the potential risks can be clearly seen. In collaborative task scheduling, it is necessary to closely monitor the priority of low-satisfaction tasks and adjust them in a timely manner to ensure overall execution efficiency.

[0050] This implementation plan significantly reduces task failures caused by bottleneck channel congestion and mutual blocking; and unifies task allocation, path selection, time and space reservation, communication relay dependence and supplementary certification dependence into a unified collaborative control instruction set and binds success conditions, time limits and failure reason codes, so that the command end can reproduce the scheduling basis and triggering reasons by window, thereby improving the executability, anti-conflict capability and full-process traceability of multi-robot collaborative handling.

[0051] Specifically, the process of executing the online replanning output collaborative control instruction set is as follows: During the execution of the collaborative control instruction set, incremental updates of emergency response data frames, status snapshot data frames, and evidence graph snapshots are continuously received, and the satisfaction evaluation value of the set of tasks that have not yet been completed is recalculated in each scheduling cycle; the online satisfiability view includes: task identifier, currently assigned robot identifier, candidate path identifier, satisfiability score snapshot, residual value snapshot of each component, trigger reason code, and set of affected channel edges. For each incomplete task, read the current robot telemetry information, the current channel edge time slice reservation table, the current link indicators, the current blockade validity field, and the channel edge credibility field. Recalculate the robot's task execution satisfaction evaluation value. Anomaly handling rules include: when the link unreliability cost is less than zero, automatically generate a communication relay deployment subtask for the task, and establish an execution dependency edge where relay deployment is completed first, followed by execution of the original task. Simultaneously, write the relay coverage area and minimum link conditions onto the dependency edge; when the proof insufficiency cost is less than zero, automatically generate a supplementary proof re-observation subtask for the task, and establish an execution dependency edge where supplementary proof is completed first, followed by permission to enter the target area. Simultaneously, write the supplementary proof target object, supplementary proof modality, and evidence closure requirements onto the dependency edge; when the time consistency cost is less than zero, generate a communication relay deployment subtask for the task. Remedial actions include adjusting the execution order or reassigning robots. These actions include preemptively securing entry times at critical passage edges, lowering the priority of non-critical background tasks, and migrating tasks to robots with shorter expected completion times. When the cost of insufficient energy is less than zero, remedial actions include charging the task, replacing the robot, or shortening the task path. These actions include inserting a recharging docking point, breaking the task into sub-tasks that can be completed under existing energy constraints, or migrating the task to a robot with higher remaining energy. When the cost of unstable mapping and localization is less than zero, remedial actions include restricting the entry area or switching sensor combinations. These actions include replacing the target area with a nearby area where the localization conditions are more favorable, activating backup sensor combinations related to localization, and triggering relocalization and local map recovery processes.

[0052] When the exception handling rules are met, the unexecuted scheduled time slices are frozen and the corresponding scheduled records are revoked. The affected task subgraph is reconstructed and an updated collaborative control instruction set is generated. For each updated task, the robot and path combination with the highest satisfaction evaluation value is reselected from the candidate robot set and candidate path set, and the execution sequence table, communication relay dependency edge, and supplementary verification dependency edge are regenerated. The collaborative control instruction set is output, and the task identifiers before and after the update, snapshots of the satisfaction score values, channel edge time slice scheduled records, linkage review readback results, and supporting indexes are versioned and recorded to ensure that online replanning does not cover the historical execution context and can replay and reproduce the triggering conditions, affected scope, alternative combinations, and satisfaction change trajectory of each replanning according to the event window number.

[0053] After the replanning results are issued, the new task contract record, execution dependency edge set, and reservation table change record are written into the execution annotation node of the emergency response evidence graph and bound to the same event window number and stage marker.

[0054] like Figure 4 The real-time change graph of task satisfaction scores shown illustrates significant fluctuations in the satisfaction scores of various tasks across different scheduling cycles. Task satisfaction trends: Task satisfaction scores fluctuate across different scheduling cycles. The satisfaction scores of different tasks change over time; some tasks' scores tend to stabilize, while others exhibit large fluctuations in certain cycles. Relative changes between tasks: Satisfaction scores show different trends among different tasks. For example, Task-01 and Task-02 are relatively stable in the first few cycles, but experience significant fluctuations at certain replanning points, while Task-03 and Task-05 are relatively stable. The changes in task satisfaction across different scheduling cycles and the impact of key replanning points on task execution status can be clearly observed. This is of great significance for optimizing scheduling strategies and improving task execution efficiency.

[0055] In this implementation plan, by maintaining the channel time slice reservation table on the edge side and performing reservation conflict detection, the channel edge occupancy is shifted from post-event conflict handling to pre-event constraint verification. This ensures that concurrent occupancy within the same time slice is strictly controlled by the concurrency limit and safety interval constraints, reducing scheduling failures and repeated path recalculations caused by bottleneck channel congestion and mutual blocking. It also enables the command end to reproduce the scheduling basis and triggering reasons in the context of the event window, realizing the executable, verifiable and traceable collaborative handling process.

[0056] Specifically, the process of compiling the collaborative control instruction set into a linkage contract set is as follows: Input the collaborative control instruction set, and under the same session ID, event window number, and stage marker context, compile each instruction into a linkage contract set; the linkage contract set includes: a subset of device linkage contracts and a subset of robot action contracts; the subset of device linkage contracts is used for access control, screen display, broadcasting, fire protection, and safety facility control; the subset of robot action contracts is used for motion, dwell, load actions, re-observation, and evidence uploading; each linkage contract includes: contract ID, idempotent key, target object ID, action semantics, action parameters, set of preconditions for entry, expected status word, completion time limit, set of readback fields, set of receipt requirements, evidence obligation level, set of failure reason codes, set of rollback actions, required permission domain, trigger reason code, event window number, and stage marker.

[0057] For each linkage contract, pre-permission verification and executability verification are performed, and a contract executability mark is generated. Pre-permission verification includes: device identity and certificate fingerprint consistency verification, token validity verification, authorization domain coverage verification, and rejection reason code extraction. Executability verification includes: device online status verification, link indicators meeting the minimum communication condition set verification, target channel edge control validity field verification, and robot health status meeting the entry condition set verification. When any verification fails, the contract is marked as unexecutable and a failure reason code is output. At the same time, the failure reason code is written to the linkage execution annotation frame.

[0058] For verified linkage contracts, a closed-loop execution of issuance and receipt is performed: In the issuance phase, action commands are issued to the target device or robot according to the contract ID and idempotent key, and the issuance timestamp, target interface identifier, and link indicator snapshot are recorded. In the receipt phase, a receipt from the target end is received within the completion time limit. The receipt includes the receipt type, receipt reason code, target end execution stage marker, and target end self-check fields. When the target end lacks receipt capabilities, the contract is forcibly bound to status readback and verification closure requirements, using status snapshots and on-site verification instead of receipts. In the readback phase, one or more status readbacks are performed on the device linkage contract, the readback field set is extracted, and the data is processed according to the unified... A dictionary encoding mapping is used to obtain the read-back fields; the robot telemetry and payload action result fields are read from the robot action contract to form the robot execution state; in the consistency closed-loop stage, the read-back fields are compared with the expected state words for consistency, and the consistency judgment result and consistency failure reason code are output; when there are cases where the receipt is successful but the read-back is inconsistent, the read-back is consistent but the supporting evidence is missing, and the receipt is missing and the read-back fails, the contract is marked as pending supplementary certification or pending rollback, and the exception handling rules are triggered; the exception handling rules include: rereading, retrying the issuance, switching the backup linkage object, executing the rollback action, inserting a supplementary certification and re-observation task, or inserting a communication relay deployment task.

[0059] The execution process is uniformly encapsulated into linked execution annotation frames and output. The linked execution annotation frame includes: contract ID, idempotent key, target object ID, action semantics and parameters, pre-verification result, failure reason code, distribution record, receipt record, readback field, consistency judgment result, rollback action execution record, link indicator snapshot, event window number, stage marker and trigger reason code. The linked execution annotation frame is used to explain "why execution is allowed, what stage the execution has reached, whether the readback is consistent, and what reason triggers remediation or rollback" within the same event window context.

[0060] In this implementation plan, a three-way closed-loop consistency check of receipt, readback, and corroboration is used to classify complex anomalies and trigger retry, rollback, replacement object switching, supplementary evidence re-observation, or relay insertion actions, thereby reducing state drift and misjudgment in scenarios such as link jitter, device offline, and permission failure. The entire process is encapsulated as a linkage execution annotation frame writeback evidence diagram, enabling the command end to reproduce each linkage within the event window, thereby improving the executability, verifiability, and traceability of linkage handling.

[0061] Specifically, the process of generating an execution proof package and performing evidence graph write-back to drive online replanning is as follows: Input the linkage execution annotation frame, state snapshot data frame, and evidence graph snapshot. Under the same session ID, event window number, and stage marker context, generate an execution proof package for each linkage contract. The execution proof package includes: the original linkage contract text, pre-verification record, distribution record, receipt record, readback field, state snapshot index aligned with the readback time, fixed-end keyframe index or robot near-field evidence fragment index aligned with the readback time, link indicator snapshot, failure reason code, and remedial action record. The fixed-end keyframe index and robot near-field evidence fragment index are used to locate the observable evidence location of the action on site.

[0062] Versioned archiving of execution proof packages is implemented: version keys for proof packages are generated based on event window number, contract ID, and idempotent key, prohibiting the overwriting of historical versions; when the same contract is executed multiple times due to retries, rollbacks, or replacement of linked objects, multiple versions of proof packages are retained; a version chain of retries, rollbacks, and replacement objects is constructed in the evidence graph based on version causal relationships, and the target state transitions in the state snapshot are deambiguously checked to avoid state drift caused by retries being misjudged as effective or ineffective; the failure reason code, consistency judgment result, and remedial action corresponding to each version are recorded and used for replaying and reproducing "when it was triggered, the triggering basis, the remedial action taken, and whether it is consistent after the remediation". The failure reason code and consistency judgment result in the version chain are mapped to replanning constraints and candidate linked object screening conditions, serving as inputs for path replanning and replacement linked object selection, to improve the reachability and consistency of linked handling in scenarios of link jitter, object offline, or permission failure.

[0063] Write the execution proof package back to the exposed evidence graph: Add execution annotation nodes and contract-related edges to the evidence graph, and bind the execution annotation nodes to the corresponding state nodes and channel edge resource nodes. When the execution annotation indicates that the blockade configuration readback is consistent and the corroboration is closed, update the channel edge blockade validity field to valid; when the execution annotation indicates that the readback is inconsistent, the receipt reason code indicates rejection, or the device is offline, update the channel edge blockade validity field to unprovable blockade, and write it into the reason code index and corroboration index; when the execution annotation indicates that supplementary proof is needed, update the channel edge blockade validity field in the same value set for the supplementary proof to be supplemented, and generate a supplementary proof re-observation task node and dependent edges to write back to the collaborative task graph.

[0064] In this implementation plan, by versioning and archiving the execution proof package and constructing a version chain of retry, rollback, and replacement objects, the target state transitions of multiple executions of the same contract are deambiguously checked. This avoids the state drift caused by the intertwining of retries and rollbacks being misjudged as effective or ineffective. Furthermore, the failure reason code and consistency judgment result are transformed into replanning constraints and candidate object screening conditions, improving the quality of online replanning in scenarios of link jitter, device offline, and permission failure. This also enhances the executability, verifiability, and full-process traceability of emergency response coordination.

[0065] Specifically, the process of constructing a closed-loop verification element set and outputting a closed-loop verification annotation frame is as follows: Figure 5 The flowchart shown illustrates the closed-loop verifiable computation and evidence graph write-back process. Inputting the execution proof package set, the state snapshot data frame set, and the emergency response evidence graph snapshot, under the same session ID, event window number, and stage marker context, it performs unified verification and traceable encapsulation of the deliverable evidence elements, delivered evidence elements, execution dependency satisfaction, version evolution, and timing alignment within the event window. This generates a closed-loop verification annotation frame and writes it back to the emergency response evidence graph. For each linkage contract and robot action contract within the event window, a closed-loop obligation directory is expanded, forming a closed-loop obligation element set. These elements include: contract original text index, pre-verification record index, distribution record index, receipt record index, read-back field index, state snapshot index, supporting fragment index, link indicator snapshot index, failure reason code index, rollback action record index, and remedial action record index. For contracts where the target end lacks receipt capabilities, the receipt record index is replaced from the obligation elements with the state read-back index and supporting closure index, ensuring consistency between the obligation elements and the contract capability description and preventing undeliverable obligations.

[0066] Extract locatable and versioned archived element references from the execution proof package set to form a delivered element set; locatable means the element contains a traceable index key, and versioned archive means the element contains a version key and can be located to a specific version entity; when multiple versions of the same element exist, all versions are retained and the version link relationship is recorded in the set elements; extract the execution dependency edge set from the state snapshot data frame set, the dependency edges include: first supplementary proof then entry, first relay then deep zone entry, first review then blockade, first clear bottleneck then diversion, etc.; perform causal verification on each dependency edge to generate a dependency violation set; add the dependency edge to the dependency violation set if any of the following conditions are met: the preceding contract does not have a completion mark and the subsequent contract has been issued; the completion timestamp of the preceding contract is later than the start timestamp of the subsequent contract; the preceding contract is marked as unexecutable or pending rollback, but the subsequent contract is still executed; the preceding contract requires consistent readback and corroboration closure as completion conditions, but the execution proof package lacks the corresponding element.

[0067] The number of proof package versions is counted for each linked contract set within the event window, and the causal relationship between versions is extracted to form a version evolution. When the same contract generates multiple proof packages due to retry, rollback, or replacement of linked objects, the version link relationship is written into the version evolution link, and the timing alignment verification record is constructed and the alignment deviation is calculated. The record set includes: each issuance record, each receipt record, each status readback record, the status snapshot index aligned with the readback time, and the fixed end keyframe index or robot near-field evidence fragment index aligned with the readback time. For each record, the correction sorting timestamp and edge reception timestamp are read, the absolute deviation is calculated, and the median is taken to obtain the median delay difference of the event window. At the same time, the duration of the event window is read for the alignment deviation normalization description. The total penalty is calculated by adding the penalty values ​​for missing evidence closure, execution causality violations, version drift, and timing alignment deviations. The effective value is obtained by subtracting the total penalty from the absolute value of the closed-loop verification dimension set. The closed-loop verifiable value is then obtained by dividing the effective value by the absolute value of the closed-loop verification dimension set. The specific calculation method for the closed-loop verifiable value is as follows: ; In the formula, This represents a closed-loop verifiable value, used to describe whether the event window execution, evidence, and write-back chain possesses a closed-loop nature that is replayable and auditable; This represents the set of dimensions for closed-loop verification, which is generated through fixed dimension enumeration and is used to specify the minimum set of dimensions to cover closed-loop verification. The penalty value for missing evidence closure is obtained by taking the set difference between the set of elements of the closure obligation and the set of delivered elements and normalizing it according to the size of the obligation. It is used to quantify whether the closure elements of the proof package are missing. This represents the penalty value for causal violation, which is obtained by normalizing the size of the dependency violation set and the size of the dependency edge set, and is used to quantify whether the dependency order has been violated. The version drift penalty value is obtained by summing the logarithmically normalized sums of the number of contract proof package versions, and is used to quantify the degree of version splitting caused by retries, rollbacks, and replacements. The time alignment deviation penalty value is obtained by normalizing the median alignment deviation and the duration of the event window. It is used to quantify whether the evidence index and the readback time are on the same time base.

[0068] The closed-loop verifiable value and the alignment deviation of the version evolution link are uniformly encapsulated into a closed-loop verification annotation frame and output. The closed-loop verification annotation frame includes: session identifier, event window number, stage mark, closed-loop verifiable value, four types of penalty item values, missing element index set, violation dependency edge index set, version link index set, alignment deviation statistics and trigger reason code. The closed-loop verification annotation frame is written into the emergency response evidence graph as an execution annotation node, and the association edge is established with the contract node, channel edge resource node and linkage status node.

[0069] In this implementation plan, by statistically analyzing and normalizing the alignment deviations of the corrected sorting timestamps of the issuance, receipt, and readback of evidence with the supporting index, the impact of link jitter and alignment errors on evidence closure can be quantified. Writing the closed-loop verifiable values ​​and key index set back to the emergency response evidence map allows for rapid window-based location and triggers tasks such as task completion, rollback, retries, and replanning input updates, thereby improving the verifiability, reproducibility, and traceability of the entire emergency response linkage process.

[0070] Specifically, the process of triggering online replanning is as follows: Under the same session ID, event window number, and stage marker context, corresponding actions are generated based on the closed-loop verification annotation frame. These actions include executable completion tasks, rollback actions, retry convergence actions, and alignment repair actions. The actions and tasks are then written back to the collaborative task graph and the emergency response evidence graph to drive online replanning. A closed-loop completion condition set is generated for the event window. This set includes: the list of missing elements for closure obligations is empty, the list of dependency violations is empty, the version evolution meets the idempotent convergence condition, and the alignment deviation meets the replayable alignment condition. Based on the verifiable closed-loop value and the closed-loop completion condition set, a closed-loop status marker is output. The value set of the closed-loop status marker is limited to: closed, pending completion, pending rollback, pending convergence, and pending alignment repair. The closed-loop status marker is used as a unified closed-loop status source field in the evidence graph and task graph to avoid misjudgments of successful execution but incomplete closure.

[0071] Based on closed-loop verification annotation frames, a closed-loop completion task is generated: when the missing feature index set is not empty, a completion task node set is generated by grouping the missing features by feature type. For missing status readback field indexes, a status rereadback task is generated, and the readback field set and the maximum number of readbacks are written into the task contract; for missing supporting evidence fragment indexes, a supplementary evidence re-observation task is generated, and the supplementary evidence target object, supplementary evidence modality, and evidence closure requirements are written into the task contract; for missing link indicator snapshot indexes or upload record indexes, evidence upload and retransmission tasks are generated, and the target link condition set is written into the task contract; and a feature completion association edge is established between each completion task and the completed feature index, so that the completion result can be updated in reverse.

[0072] It generates rollback and sequence repair actions; when the set of violation dependency edge indices is not empty, it generates a set of causal repair actions for each violation dependency edge. If the violation is that the preceding order is not completed but the subsequent order has been executed, it generates a rollback action for the subsequent order contract and records the rollback reason code. At the same time, it generates an execution dependency edge that re-executes the preceding order and then executes the subsequent order. If the violation is that the preceding order is not executable or needs to be rolled back but the subsequent order is still executed, it generates an alternative linkage object selection action or cancellation action for the subsequent order contract and writes the non-executable reason code into the closed-loop repair annotation. If the violation is that the preceding order requires consistent readback and the supporting evidence is closed but the evidence is missing, it maps the violation to a completion task and establishes an execution dependency edge that completes the task first and then restores the dependency. It also writes the repair action into the rollback action set and exception handling rules of the linkage contract, so that the execution layer can implement the contract mechanism.

[0073] Based on the version evolution link, generate idempotent convergence and substitution strategies; when the violation dependency edge index set indicates that there are multiple versions of the same contract and repeated switching between versions, generate a convergence task set, requiring that the same idempotent key be reused and prohibiting the generation of new idempotent key branches to generate idempotent retry convergence tasks; when a target object version repeatedly fails and the failure reason code points to the same reason, select a backup linkage object and write the substitution reason code to generate a substitution linkage object selection task; require that each new version must reference the failure reason code and remedial action record of the previous version, prohibit the generation of version causal chain closure tasks for versions without a source; and establish version convergence association edges between convergence tasks and corresponding contract nodes, so that version evolution is transformed from a divergent record into an interpretable chain.

[0074] The closed-loop verification annotation frames are written back to the task graph and evidence graph, triggering online replanning: all repair tasks and actions are merged into a closed-loop repair task set, and the closed-loop repair task nodes and dependencies are written to the collaborative task graph, establishing dependencies of first completing then restoring, first converging then retrying, and first relaying then uploading; simultaneously, repair actions are written to the linkage contract set and synchronized to the execution annotation frames, ensuring that each remedy and rollback is clearly recorded; closed-loop repair annotations are written back to the evidence graph as execution annotation nodes, binding missing elements, violation dependency edges, and version indexes to the same event window number, ensuring that the specific execution of each repair action can be traced during post-event review. The repair task set and triggering reasons are written into the input of online replanning, ensuring that these closed-loop repair tasks participate in task allocation and path selection as mandatory preceding tasks during replanning. When the closed-loop repair task is completed or the rollback action takes effect, a new closed-loop verification record is recalculated and generated; all closed-loop verification records retain versions to avoid overwriting historical records. In this way, the review process can fully demonstrate the trajectory of changes in closed-loop verifiable values, the convergence process of the missing list, and the elimination process of dependency violations.

[0075] This implementation plan can directly quantify the impact of link jitter, out-of-order and latency fluctuations on evidence index matching and window evidence closure; and write back the closed-loop verifiable value, missing element index set, dependency violation edge index set, version link index set and alignment deviation statistics to the emergency response evidence graph, enabling the rapid location of missing items, violation points and deviations within the event window, thereby automatically triggering completion tasks, rollback and retry handling and replanning input updates, improving the verifiability, reproducibility and traceability of the entire emergency response linkage process.

[0076] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0077] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robots, characterized in that, include: The multi-terminal data acquisition module is used to collect various types of emergency response datasets and perform unified time base alignment, quality labeling and normalization on the various types of emergency response datasets to form emergency response acquisition data frames. The evidence graph fusion module is used to construct evidence itemsets based on emergency response data frames, perform consistency constraint fusion on the evidence itemsets to generate an emergency response evidence graph, and output a re-observation suggestion set based on the emergency response evidence graph; The risk-constrained collaborative planning module is used to construct a collaborative task graph based on a set of situational objects, allocate robot tasks, generate a collaborative control instruction set, and execute online replanning to output the collaborative control instruction set. The linkage execution and rollback closed-loop module is used to compile the collaborative control instruction set into a linkage contract set, generate an execution proof package and execute the evidence graph write-back to drive online replanning; The evidence closure and audit playback module is used to construct a closed-loop verification element set, output closed-loop verification annotation frames, and trigger online replanning.

2. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of collecting multiple types of emergency response datasets and performing unified time base alignment, quality labeling, and normalization on these datasets to form emergency response data frames is as follows: Multi-source sensing devices and embodied robots collaboratively collect various types of emergency response datasets. Within the same emergency response session, these datasets are classified, labeled, and prioritized. Based on the event windows and emergency response stage marker datasets within these datasets, a unified time base is used from the edge acquisition gateway to perform timestamp alignment on each record, resulting in a processed multi-type emergency response dataset. Each acquisition record is encapsulated using a unified data structure to construct an emergency response acquisition data frame, and a state snapshot data frame is constructed simultaneously. The collected multi-type emergency response datasets are then organized and cached using a unified data frame format, queue management, and frame dropping strategy. Finally, the emergency response acquisition data frames undergo normalization processing with a unified dictionary encoding mapping.

3. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of constructing an evidence itemset based on emergency response data frames and performing consistency constraint fusion on the evidence itemset to generate an emergency response evidence map is as follows: Input the sequence of data frames collected for emergency response, construct an evidence item set under the same session and event window numbering context, and encapsulate the evidence item set with a unified evidence structure to construct the emergency response evidence item structure; Within the event window, evidence items are aligned and clustered based on the corrected sorting timestamp. Evidence items from different modalities within the same time slice and the same area are aggregated into candidate evidence clusters using temporal and spatial neighborhood gating. Consistency constraint edges are established between the candidate evidence clusters and the status snapshot evidence items of access control, screen display, broadcast and fire linkage target equipment to construct an emergency response evidence graph. Multiply the result of each readback's determination of whether it equals the desired state by the weight of this readback and sum them to obtain the weighted sum of achieved readbacks; multiply the result of each readback's determination of whether it does not equal the desired state by the weight of this readback and sum them to obtain the weighted sum of contradictory readbacks; multiply the achieved readback contribution weight by the weighted sum of achieved readbacks, multiply the contradictory readback penalty weight by the weighted sum of contradictory readbacks, and add the bias parameter to obtain the provable term; The support probability is converted into a log-probability value, multiplied by the corroboration weight, and summed to obtain the corroboration weighted evidence sum. The multi-source corroboration contribution weight is multiplied by the corroboration weighted evidence sum as the corroboration item. The effective delay is divided by the action timeout limit to obtain the delay ratio. The delay effective penalty weight is multiplied by the delay ratio to obtain the delay penalty item. The comprehensive penalty weight is multiplied by the conflict comprehensive penalty item to obtain the comprehensive penalty item. The provable item, corroboration item, delay penalty item, and comprehensive penalty item are input into the mapping function to obtain the proof confidence value. The proof confidence value is written as the state node confidence attribute and constraint edge confidence attribute into the emergency response evidence graph snapshot, and the conflict cause code and evidence graph snapshot are output.

4. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of outputting a re-observation suggestion set based on the emergency response evidence map is as follows: Input an evidence map snapshot, generate a situational object set under the event window number and stage marker context, use the proof confidence value of each linked state node in the emergency response evidence map as the evaluation index of the linkage effectiveness credibility view, and bind the proof confidence value with the topology region node set and the channel edge set, determine the associated linked state node set for each channel edge, and use the minimum proof confidence value in the set as the edge credibility value of the channel edge; perform a blockade effectiveness judgment and situation update for each channel edge.

5. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of constructing a cooperative task graph based on the situational object set and generating a cooperative control instruction set for robot task allocation is as follows: Input a set of situational objects, construct a collaborative task graph under the same session ID, event window number and stage marker context, generate a task contract record for each task node, and perform multi-robot execution allocation and path generation based on the collaborative task graph: generate a set of candidate paths for each robot and each task, and perform constraint pruning and satisfiability evaluation on the set of candidate paths to form a feasible candidate set; The time consistency cost is multiplied by the time dimension weight coefficient, the link unreliability cost is multiplied by the communication dimension weight coefficient, the energy insufficiency cost is multiplied by the energy dimension weight coefficient, the mapping and positioning instability cost is multiplied by the mapping and positioning dimension weight coefficient, and the proof insufficiency cost is multiplied by the provable dimension weight coefficient. All five products are then added together to obtain the comprehensive cost. Finally, the comprehensive cost is gated using a path containment gating term to obtain the satisfaction evaluation value. The satisfaction evaluation value is used as the basis for task allocation and sorting: for each task, the combination that maximizes the satisfaction evaluation value is selected from all robots and feasible candidate paths as the task execution combination; the channel is maintained on the edge side, and when candidate paths and execution order are generated, each channel edge is written into the time slice reservation table through action, and conflict detection is performed before writing; Output a set of coordinated control instructions.

6. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of executing the online replanning output cooperative control instruction set is as follows: During the execution of the collaborative control instruction set, it continuously receives incremental updates of emergency response data frames, status snapshot data frames, and evidence map snapshots, and recalculates the satisfaction evaluation value for the set of tasks that have not yet been completed in each scheduling cycle. For each incomplete task, read the current robot telemetry information, the current channel edge time slice reservation table, the current link index, the current blockade validity field, and the channel edge credibility field. Recalculate the robot's task execution satisfaction evaluation value. When the abnormal handling rules are met, freeze the unexecuted reserved time slices and cancel the corresponding reservation records. Reconstruct the affected task subgraph and generate an updated collaborative control instruction set. For each updated task, reselect the robot and path combination with the highest satisfaction evaluation value from the candidate robot set and candidate path set, and regenerate the execution order table, communication relay dependency edge, and supplementary certification dependency edge. Output the collaborative control instruction set.

7. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of compiling the collaborative control instruction set into a linkage contract set is as follows: Input the collaborative control instruction set, and compile each instruction into a set of linkage contracts under the same session ID, event window number, and stage marker context. The set of linkage contracts includes a subset of device linkage contracts and a subset of robot action contracts. Perform pre-verification of permissions and executability verification on each linkage contract, and generate a contract executability flag. When any verification fails, mark the contract as unexecutable and output the failure reason code, and write the failure reason code into the linkage execution annotation frame. For linkage contracts that pass the verification, execute the issuance and acknowledgment closed loop: in the issuance phase, according to the contract... The ID and idempotent key send action commands to the target device or robot, and record the sending timestamp, target interface identifier, and link indicator snapshot. During the acknowledgment phase, the acknowledgment from the target end is received within the completion time limit. When the target end does not have the acknowledgment capability, the contract is forcibly bound to the status readback and evidence closure requirements, and the status snapshot and on-site evidence are used to replace the acknowledgment. When there are cases where the acknowledgment is successful but the readback is inconsistent, the readback is consistent but the evidence is missing, or the acknowledgment is missing and the readback fails, the contract is marked as pending supplementary evidence or pending rollback, and the execution process is uniformly encapsulated into a linkage execution annotation frame and output.

8. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of generating the execution proof package and performing evidence graph write-back to drive online replanning is as follows: Input the linked execution annotation frame, state snapshot data frame, and evidence graph snapshot. Under the same session ID, event window number, and stage marker context, generate an execution proof package for each linked contract. Perform versioned archiving on the execution proof package: generate a proof package version key by event window number, contract ID, and idempotent key, and prohibit overwriting historical versions. When the same contract is executed multiple times due to retry, rollback, or replacement of linked objects, retain multiple version proof packages. Based on the version causal relationship, construct the version chain of retry, rollback, and replacement objects in the evidence graph, and perform deambiguation verification on the target state transition in the state snapshot to avoid the state drift caused by retry being misjudged as effective or ineffective. Record the failure reason code, consistency judgment result, and remedial action corresponding to each version into the ledger, and write the execution proof package back to the protruding evidence graph: add execution annotation nodes and contract association edges in the evidence graph, and bind the execution annotation nodes to the corresponding state nodes and channel edge resource nodes.

9. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of constructing a closed-loop verification element set and outputting a closed-loop verification annotation frame is as follows: Input the execution proof package set, the state snapshot data frame set, and the emergency response evidence graph snapshot. Under the same session ID, event window number, and stage marker context, uniformly verify and traceably encapsulate the deliverable evidence elements, delivered evidence elements, execution dependency satisfaction, version evolution, and timing alignment within the event window, generate a closed-loop verification annotation frame, and write it back to the emergency response evidence graph. For each linked contract set within the event window, the number of proof package versions is counted, and the causal relationships between versions are extracted to form a version evolution. When the same contract generates multiple proof packages due to retries, rollbacks, or replacement of linked objects, the version link relationship is written into the version evolution link, and the timing alignment verification record is constructed and the alignment deviation is calculated. For each record, the corrected sorting timestamp and the edge reception timestamp are read, the absolute deviation is calculated, and the median is taken to obtain the median delay difference of the event window. At the same time, the duration of the event window is read, and the penalty values ​​for missing evidence closure, execution causal violation, version drift, and timing alignment deviation are added together to obtain the total penalty. The effective quantity is obtained by subtracting the total penalty from the absolute value of the closed-loop verification dimension set. The closed-loop verifiable value is obtained by dividing the effective quantity by the absolute value of the closed-loop verification dimension set. The alignment deviation between the closed-loop verifiable value and the version evolution link is uniformly encapsulated into a closed-loop verification annotation frame and output; the closed-loop verification annotation frame is written into the emergency response evidence graph as an execution annotation node, and the association edge is established with the contract node, channel edge resource node, and linkage status node.

10. The counter-terrorism and emergency response collaborative control system based on the fusion of multi-source perception and embodied robot as described in claim 1, characterized in that: The specific process of triggering online replanning is as follows: Under the same session ID, event window number, and stage marker context, corresponding handling actions are generated based on the closed-loop verification annotation frame. The handling actions include executable completion tasks, rollback actions, retry convergence actions, and alignment repair actions. The actions and tasks are written back to the collaborative task graph and the emergency response evidence graph to drive online replanning. A closed-loop completion condition set is generated for the event window, and a closed-loop status marker is output based on the closed-loop verifiable value and the closed-loop completion condition set. A closed-loop completion task is generated based on the closed-loop verification annotation frame. When the missing element index set is not empty, a completion task node set is generated by grouping the missing elements by element type. For missing status readback field indexes, a status rereadback task is generated. For missing supporting evidence fragment indexes, a supplementary evidence re-observation task is generated. For missing link indicator snapshot indexes or upload record indexes, an evidence upload and retransmission task is generated and written to the target link condition set. It also generates rollback and sequence repair actions; When the set of violation dependency edge indices is not empty, a set of causal repair actions is generated for each violation dependency edge, and an idempotent convergence and replacement strategy is generated based on the version evolution link. The closed-loop verification annotation frame is written back to the task graph and evidence graph, and online replanning is triggered: all repair tasks and actions are merged into a set of closed-loop repair tasks, and the closed-loop repair task nodes and dependencies are written into the collaborative task graph. The repair actions are written into the linkage contract set and synchronized to the execution annotation frame. When the closed-loop repair task is completed or the rollback action takes effect, a new closed-loop verification record is recalculated and generated. All closed-loop verification records retain the version.

Images