A Method and System for Tunnel Operation, Maintenance, Inspection and Emergency Response Based on Offline Intelligent Agents

Abstract

This application provides a method and system for tunnel operation and maintenance inspection and emergency response based on offline intelligent agents, relating to the field of tunnel operation and maintenance. The method includes: deploying offline intelligent agents in edge computing devices at the tunnel site, configuring a task scheduling engine, a lightweight recognition model, a local knowledge base, and a cache database to achieve autonomous inspection and emergency response under conditions of no network or weak network. The offline intelligent agent receives multi-source sensing data, generates inspection tasks and paths, uses a lightweight model to identify abnormal events such as cracks, leaks, and smoke, performs risk classification based on local standards and historical cases, and automatically generates standardized inspection conclusions and operation lists. During the on-site handling process, a local evidence chain is formed using events as indexes. After network connection is restored, the evidence is uploaded to the central platform according to risk priority, and the model and knowledge base are updated synchronously. This invention improves the intelligence and closed-loop capability of tunnel operation and maintenance in a network-free environment, and enhances the real-time performance and reliability of inspection and emergency response.

Description

Technical Field

[0001] This application relates to the field of tunnel operation and maintenance, and in particular to a method and system for tunnel operation and maintenance inspection and emergency response based on offline intelligent agents. Background Technology

[0002] As a crucial component of transportation infrastructure, tunnels operate in complex environments and are susceptible to various operational and maintenance issues, including surrounding rock deformation, groundwater seepage, vehicle loads, temperature and humidity fluctuations, equipment aging, and unforeseen accidents. These issues can lead to problems such as cracks, leaks, lining spalling, water accumulation, smoke, lighting malfunctions, abnormal ventilation, and fire equipment failure. Current tunnel maintenance primarily relies on manual inspections, centralized platform monitoring, and online system-assisted assessments. While these methods can facilitate data collection, defect identification, and work order processing in typical networked environments, communication links are often unstable in remote mountainous tunnels, long tunnels, deeply buried underground sections, and disaster emergency sites. This results in difficulties with real-time cloud connectivity, delayed data transmission, and the inability of the central platform to respond promptly.

[0003] In actual operation and maintenance, when tunnels experience leakage expansion, smoke alarms, rising water levels, structural anomalies, or equipment failures, on-site personnel typically need to rely on experience to consult specifications, emergency plans, and historical cases before assessing the risk level and formulating response measures. This approach suffers from drawbacks such as low efficiency, significant reliance on experience, inconsistent emergency procedures, and a disconnect between inspection findings and response execution. Especially under conditions of no network or weak network connectivity, traditional cloud-based large-scale models, online knowledge bases, and remote expert systems struggle to function effectively, resulting in on-site inspection terminals only being able to collect data and unable to independently complete defect identification, risk classification, response step generation, and result documentation.

[0004] Furthermore, existing tunnel operation and maintenance systems mostly adopt an online architecture of "central platform - field terminal," with core models, knowledge bases, and handling rules centrally deployed in the cloud or on a central server. When the field network is interrupted, the system can usually only cache data and cannot form a complete intelligent judgment chain locally. Although some edge recognition devices have image detection capabilities, they are mostly limited to single defect identification and lack linkage with operation and maintenance specifications, emergency plans, historical cases, and traffic organization schemes, making it difficult to support closed-loop on-site handling.

[0005] Therefore, it is necessary to propose a tunnel operation and maintenance inspection and emergency response method and system that can operate independently in the absence of network or weak network conditions. The system should encapsulate the capabilities of inspection task planning, defect identification, risk assessment, handling suggestions, emergency process invocation, result recording and synchronous updates after network connection into a local offline intelligent agent, so as to realize the localization, intelligence and closed loop of on-site inspection and emergency response.

[0006] To address the aforementioned issues, a method and system for tunnel operation, maintenance, inspection, and emergency response based on offline intelligent agents are now designed. Summary of the Invention

[0007] The purpose of this invention is to provide a tunnel operation and maintenance inspection and emergency response method and system based on offline intelligent agents to solve the problems of unstable network, inability to connect remote tunnels to the cloud in real time, reliance on experience for manual handling in emergency situations, and disconnect between inspection identification and handling processes in existing tunnel operation and maintenance systems.

[0008] The above-mentioned objective of this application is achieved through the following technical solution: S1: Deploy an offline intelligent agent in the edge computing device at the tunnel site. The offline intelligent agent is equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. S2: Receive and preprocess multi-source sensing data of tunnel operation and maintenance through offline intelligent agents to obtain local inspection datasets; S3: Based on the local inspection dataset, calculate the priority of each inspection segment and generate an inspection task list in descending order of priority; calculate the local executable inspection path of the inspection robot; the inspection robot collects inspection images based on the local executable inspection path and sends them to the local cache database. S4: Retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. Calculate the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combine them into an abnormal event record. S5: Based on abnormal event records, determine the defect type, defect size, and location of the crack and compare them with the standard thresholds to obtain a hazard score and a development score; obtain the risk level by combining the hazard score and the development score. S6: Based on the risk level and the type of abnormal event, match the corresponding handling template from the local knowledge base, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form a manually selected operation list; S7: Based on the checklist results, the inspection images, risk levels, inspection conclusion texts, and manually selected actual operations are stored in sequence according to time, forming a local evidence chain indexed by the event number, and uploaded to the central operation and maintenance platform in order of risk level from high to low.

[0009] Optionally, step S1 includes: Initialize and detect the computing power, available memory, available storage space, input / output interfaces, and current network status of the edge computing device to determine the resource conditions of the edge computing device; Based on the resource conditions of the edge computing device, a suitable lightweight recognition model is selected from the candidate model library; The lightweight identification models include: crack identification model, leakage identification model, smoke detection model, water accumulation identification model, lining anomaly identification model, and equipment failure judgment model; Edge computing devices include: inspection robots, mobile inspection terminals, fixed camera equipment, infrared thermal imaging equipment, smoke sensors, water level sensors, temperature and humidity sensors, lighting systems, ventilation systems, fire protection systems, drainage equipment, and traffic monitoring equipment; Establish a local knowledge base, and incorporate tunnel operation and maintenance specifications, emergency plans, disease knowledge, equipment handling manuals, and historical cases into the local knowledge base; The inspection task planning, model invocation, knowledge retrieval, rule reasoning, emergency process invocation, and log generation are encapsulated into a local action set of the offline intelligent agent and written into the local knowledge base; Establish a local cache database to store inspection data, identification results, risk levels, handling suggestions, manual confirmation information, and on-site evidence under conditions of no network, weak network, or network outage.

[0010] Optionally, step S2 includes: Multi-source sensing data includes: inspection images, inspection videos, infrared thermal images, smoke concentration, water level, temperature and humidity, illuminance, wind speed, ventilation equipment status, lighting equipment status, drainage equipment status, fire-fighting equipment status, power supply and distribution equipment status, historical inspection records, maintenance work orders, historical damage records, and equipment ledgers. Preprocessing includes: establishing a unified index for multi-source sensing data according to tunnel number, left / right or up / down direction, tunnel mileage marker, lane location, structural part, equipment number, and acquisition time; performing sharpness filtering and distortion correction on each frame of image data in the multi-source sensing data; performing unit conversion and timestamp alignment on each group of sensor data in the multi-source sensing data; and evaluating the data quality of the multi-source sensing data. If the data quality evaluation is lower than a preset threshold, re-acquisition is performed. The preprocessed image data and sensor data are stored in a local cache database according to the acquisition time and tunnel mileage marker, forming a local inspection dataset.

[0011] Optionally, step S3 includes: The tunnel is divided into multiple inspection objects, each of which includes: tunnel section, mileage range, structural parts or equipment objects, historical defects, environmental influencing factors and preset inspection cycle. The priority of each inspection section is determined based on the severity of historical disease records, the degree of abnormality in the last inspection, the trend of disease development, current environmental disturbances, the degree of traffic impact, and the importance of equipment. An inspection task list is generated based on priority. The inspection task list includes: inspection section, inspection object, inspection content, equipment to be called, data collection method, data collection accuracy, abnormal triggering conditions, and local recording requirements. Based on the inspection section, the current location of the inspection robot, traffic conditions, remaining power, and priority, a locally executable inspection path is generated. When traffic is obstructed, the equipment power is insufficient, or there is a sudden abnormality on site, the locally executable inspection path is locally replanned.

[0012] Optionally, step S4 includes: The inspection images are extracted in batches from the local inspection dataset, scaled to the input size required by the lightweight recognition model, and then fed into the model to perform forward inference. Extract the bounding box coordinates and defect category probability of the defect region from the feature map output by the lightweight recognition model; The actual mileage location of the defect area in the tunnel is calculated by back-calculating the bounding box coordinates. Read the maximum width value of the crack or the area of ​​the leaking pixels from the segmentation results output by the lightweight recognition model; The defect category probability, actual mileage location, maximum width value, and pixel area are combined into an abnormal event record; The specific process of the lightweight recognition model performing forward inference includes: organizing the scaled inspection image into a four-dimensional tensor, wherein the dimensions of the four-dimensional tensor are batch size, image height, image width and number of channels, respectively. The model inference interface is called to input the four-dimensional tensor into the acceleration chip to perform matrix multiplication and addition operations. Three result tensors are obtained from the output: bounding box position tensor, defect category probability tensor, and segmentation mask tensor. The bounding box coordinates and defect category probabilities are obtained through the bounding box position tensor and the defect category probability tensor. The segmentation result is obtained through the segmentation mask tensor. The specific process of calculating the actual mileage location of the defect area in the tunnel based on the bounding box coordinates includes: Obtain the mileage marker corresponding to the inspection image frame. and image width Let the x-coordinate of the center point of the bounding box be... The actual mileage location of the defect. According to the formula Calculation, where This represents the mileage interval value corresponding to each pixel in the image. The specific process for reading the maximum width value of the crack includes: Extract the skeleton lines of the crack region from the segmentation results output by the lightweight recognition model, calculate the distance between the two edges of each crack point by point along the normal direction of the skeleton lines, and take the maximum value of the distance as the maximum width of the crack; if the maximum width of the crack exceeds the warning width threshold stored in the local knowledge base, add a width over-limit label to the abnormal event record.

[0013] Optionally, step S5 includes: Based on the abnormal event record, determine the defect type, defect size and occurrence location in this abnormal event record, and retrieve the specification threshold that matches the defect type and defect size from the local knowledge base; The defect size is compared with the specification threshold, and a risk score is assigned based on the comparison result; Find the defect size of the same location in the last inspection from the local knowledge base, and calculate the rate of change of defect size between the current abnormal event record and the last abnormal event record as the development score; The risk score and the developmental score are weighted and added together to obtain a comprehensive risk score. The risk level is determined based on the range of values ​​that the comprehensive risk score falls into. The specific process for calculating the rate of change of size between the current abnormal event record and the previous abnormal event record includes: Retrieve the previous abnormal event record with the same mileage station number and the same defect type from the local knowledge base; Extract the defect size from the previous anomaly event record. Let the defect size identified in this abnormal event record be... Then the rate of change According to the formula Calculation, where To prevent the smallest constant from having a denominator of zero; if If the development rate exceeds the threshold stored in the local knowledge base, the development rate score of this abnormal event record will be set to the highest level.

[0014] Optionally, step S6 includes: By using a local lightweight model, a video event detection model, a sensor anomaly judgment model, and equipment status recognition rules, cracks, leaks, smoke, water accumulation, lining anomalies, and electromechanical equipment failures are identified to obtain the types of abnormal events. Based on the risk level and the type of abnormal event, the corresponding handling template is matched from the local knowledge base to generate a standardized inspection conclusion text, and the pre-set operation steps in the handling template are listed one by one in order to form a manually selected operation list. The specific process of generating a standardized inspection conclusion text includes: Retrieves the conclusion template corresponding to the abnormal event type from the local knowledge base. The conclusion template contains multiple placeholders, including: location placeholder, type placeholder, size placeholder, risk level placeholder, and recommendation placeholder. Enter the actual mileage marker in the location placeholder, the defect category name in the type placeholder, the defect size value and unit in the size placeholder, the risk level name in the risk level placeholder, and the defect size in the suggestion placeholder. After piecing them together, you will get the complete inspection conclusion text.

[0015] Optionally, step S7 includes: The offline intelligent agent detects the network connection status in real time. When it detects that the network has been restored and the bandwidth meets the conditions, it reads the local evidence chain that has not yet been uploaded from the local cache database. Local evidence chains are uploaded to the central operation and maintenance platform in descending order of risk level. After the upload is completed, wait for the platform to return confirmation information. If a model update file is received from the platform, the parameters of the lightweight recognition model are updated using the model update file.

[0016] A tunnel operation and maintenance inspection and emergency response system based on offline intelligent agents, the system comprising: The system deployment module is used to deploy offline intelligent agents in edge computing devices at the tunnel site. The offline intelligent agents are equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. The data acquisition module is used to receive multi-source sensing data of tunnel operation and maintenance through offline intelligent agents and preprocess it to obtain local inspection datasets; The data processing module is used to calculate the priority of each inspection segment based on the local inspection dataset, generate an inspection task list in descending order of priority, calculate the locally executable inspection path of the inspection robot, and collect inspection images based on the locally executable inspection path and send them to the local cache database. The abnormal event recording module is used to retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. It calculates the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combines them into an abnormal event record. The risk level assessment module is used to determine the defect type, defect size, and location of cracks based on abnormal event records, and compare them with standard thresholds to obtain a hazard score and a development score; the risk level is obtained by combining the hazard score and the development score. The operation list building module is used to match the corresponding handling template from the local knowledge base according to the risk level and abnormal event type, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form an operation list for manual selection. The local evidence chain construction module is used to connect and store inspection images, risk levels, inspection conclusion texts, and manually selected actual operations in chronological order based on the checklist results on the operation list, forming a local evidence chain indexed by the event number, and then uploading it to the central operation and maintenance platform in descending order of risk level.

[0017] The beneficial effects of the technical solution provided in this application are: 1. This invention encapsulates inspection task planning, defect identification, risk assessment, handling suggestion generation, and handling result recording into a local offline intelligent agent, enabling the tunnel site to independently complete inspections and emergency auxiliary decision-making even under conditions of no network, weak network, or network outage, avoiding the problem of abnormal events being unable to be analyzed, judged, or handled in a timely manner due to communication interruptions.

[0018] 2. This invention deploys local knowledge bases, emergency plan bases, operation and maintenance specification bases, and local knowledge bases in edge devices, inspection robots, and mobile terminals, enabling on-site personnel to obtain standard references, similar cases, and handling procedures without having to access the central platform in real time. This reduces the reliance on personal experience in emergency response and improves the consistency and standardization of on-site handling.

[0019] 3. This invention can perform local offline identification of various events such as cracks, leaks, smoke, water accumulation, lining anomalies and electromechanical equipment failures. It also combines images, videos, sensors, equipment status and historical records to perform multi-source evidence fusion, which improves the reliability of tunnel operation and maintenance anomaly event identification and reduces false alarms and missed alarms caused by single sensor alarms or single image recognition.

[0020] 4. This invention establishes a risk classification mechanism based on defect scale, development trend, spatial location, historical defects, traffic impact, and equipment linkage status. It can further transform the anomaly identification results into risk levels such as general concern, key tracking, on-site handling, and emergency response, so that inspection findings can be directly linked to subsequent handling processes, solving the problem of the disconnect between "discovering problems" and "handling problems" in traditional operation and maintenance.

[0021] 5. This invention automatically generates inspection conclusions, handling steps, personnel division of labor suggestions, equipment deployment suggestions, temporary traffic organization suggestions, and reporting texts based on risk level and event type, enabling on-site personnel to carry out handling according to the step-by-step checklist. It is especially suitable for sudden scenarios such as smoke, water accumulation, falling blocks, serious leakage, and equipment failure, improving emergency response efficiency and on-site handling closed-loop capability.

[0022] 6. This invention records inspection data, identification results, risk assessment, handling suggestions, manual confirmation, actual handling, and result feedback through a local log and evidence chain module. After network connection is restored, it completes data synchronization, central review, model update, knowledge base update, and strategy update with the central platform, forming a continuous optimization mechanism of "offline autonomy - network synchronization - central review - strategy iteration", which improves the traceability, reliability, and intelligence level of tunnel operation and maintenance management. Attached Figure Description

[0023] The present application will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a flowchart illustrating the overall process of the tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents provided in this embodiment of the invention. Figure 2 This is a comparison chart of inference latency of the offline recognition model provided in this embodiment of the invention on different edge devices; Figure 3 This is a comparison chart of anomaly identification accuracy before and after multi-source evidence fusion provided in an embodiment of the present invention; Figure 4 This is a statistical distribution chart of abnormal events with different risk levels provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the priority and synchronization order of locally cached data during network outages, provided in an embodiment of the present invention. Figure 6 A statistical chart illustrating the offline autonomous and network synchronous closed-loop operation effect provided in this embodiment of the invention. Detailed Implementation

[0024] To provide a clearer understanding of the technical features, objectives, and effects of this application, the specific embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0025] The embodiments of this application provide a method for tunnel operation and maintenance inspection and emergency response based on offline intelligent agents.

[0026] Please refer to Figure 1 , Figure 1 This is a flowchart of a tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents, as described in an embodiment of this application, including: S1: Deploy an offline intelligent agent in the edge computing device at the tunnel site. The offline intelligent agent is equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. S2: Receive and preprocess multi-source sensing data of tunnel operation and maintenance through offline intelligent agents to obtain local inspection datasets; S3: Based on the local inspection dataset, calculate the priority of each inspection segment and generate an inspection task list in descending order of priority; calculate the local executable inspection path of the inspection robot; the inspection robot collects inspection images based on the local executable inspection path and sends them to the local cache database. S4: Retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. Calculate the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combine them into an abnormal event record. S5: Based on abnormal event records, determine the defect type, defect size, and location of the crack and compare them with the standard thresholds to obtain a hazard score and a development score; obtain the risk level by combining the hazard score and the development score. S6: Based on the risk level and the type of abnormal event, match the corresponding handling template from the local knowledge base, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form a manually selected operation list; S7: Based on the checklist results, the inspection images, risk levels, inspection conclusion texts, and manually selected actual operations are stored in sequence according to time, forming a local evidence chain indexed by the event number, and uploaded to the central operation and maintenance platform in order of risk level from high to low.

[0027] Step S1 includes: Initialize and detect the computing power, available memory, available storage space, input / output interfaces, and current network status of the edge computing device to determine the resource conditions of the edge computing device; Based on the resource conditions of edge computing devices, suitable lightweight recognition models are selected from the candidate model library. Lightweight recognition models include: crack recognition model, leakage recognition model, smoke detection model, water accumulation recognition model, lining anomaly recognition model, and equipment fault judgment model. Edge computing devices include: inspection robots, mobile inspection terminals, fixed camera equipment, infrared thermal imaging equipment, smoke sensors, water level sensors, temperature and humidity sensors, lighting systems, ventilation systems, fire protection systems, drainage equipment, and traffic monitoring equipment. Establish a local knowledge base, and incorporate tunnel operation and maintenance specifications, emergency plans, disease knowledge, equipment handling manuals, and historical cases into the local knowledge base; The inspection task planning, model invocation, knowledge retrieval, rule reasoning, emergency process invocation, and log generation are encapsulated into a local action set of the offline intelligent agent and written into the local knowledge base; Establish a local cache database to store inspection data, identification results, risk levels, handling suggestions, manual confirmation information, and on-site evidence under conditions of no network, weak network, or network outage.

[0028] Step S2 includes: Multi-source sensing data includes: inspection images, inspection videos, infrared thermal images, smoke concentration, water level, temperature and humidity, illuminance, wind speed, ventilation equipment status, lighting equipment status, drainage equipment status, fire-fighting equipment status, power supply and distribution equipment status, historical inspection records, maintenance work orders, historical damage records, and equipment ledgers. Preprocessing includes: establishing a unified index for multi-source sensing data according to tunnel number, left / right or up / down direction, tunnel mileage marker, lane location, structural part, equipment number, and acquisition time; performing sharpness filtering and distortion correction on each frame of image data in the multi-source sensing data; performing unit conversion and timestamp alignment on each group of sensor data in the multi-source sensing data; and evaluating the data quality of the multi-source sensing data. If the data quality evaluation is lower than a preset threshold, re-acquisition is performed. The preprocessed image data and sensor data are stored in a local cache database according to the acquisition time and tunnel mileage marker, forming a local inspection dataset.

[0029] Step S3 includes: The tunnel is divided into multiple inspection objects, each of which includes: tunnel section, mileage range, structural parts or equipment objects, historical defects, environmental influencing factors and preset inspection cycle. The priority of each inspection section is determined based on the severity of historical disease records, the degree of abnormality in the last inspection, the trend of disease development, current environmental disturbances, the degree of traffic impact, and the importance of equipment. An inspection task list is generated based on priority. The inspection task list includes: inspection section, inspection object, inspection content, equipment to be called, data collection method, data collection accuracy, abnormal triggering conditions, and local recording requirements. Based on the inspection task location, the current location of the inspection robot, the access conditions, the remaining power, and the priority, a local executable inspection path is generated. When there is obstruction, insufficient power of the equipment, or sudden abnormality on site, the local executable inspection path is partially replanned.

[0030] Step S4 includes: The inspection images are extracted in batches from the local inspection dataset, scaled to the input size required by the lightweight recognition model, and then fed into the model to perform forward inference. Extract the bounding box coordinates and defect category probability of the defect region from the feature map output by the lightweight recognition model; The actual mileage location of the defect area in the tunnel is calculated by back-calculating the bounding box coordinates. Read the maximum width value of the crack or the area of ​​the leaking pixels from the segmentation results output by the lightweight recognition model; The defect category probability, actual mileage location, maximum width value, and pixel area are combined into an abnormal event record; The specific process of forward inference performed by the lightweight recognition model includes: organizing the scaled inspection image into a four-dimensional tensor, where the dimensions of the four-dimensional tensor are batch size, image height, image width, and number of channels, respectively; calling the model inference interface to input the four-dimensional tensor into the acceleration chip to perform matrix multiplication and addition operations; obtaining three result tensors from the output end, namely the bounding box position tensor, the defect category probability tensor, and the segmentation mask tensor; obtaining the bounding box coordinates and defect category probabilities through the bounding box position tensor and the defect category probability tensor; and obtaining the segmentation result through the segmentation mask tensor. The specific process of calculating the actual mileage location of the defect area in the tunnel based on the bounding box coordinates includes: Obtain the mileage marker corresponding to the inspection image frame. and image width Let the x-coordinate of the center point of the bounding box be... The actual mileage location of the defect. According to the formula Calculation, where This represents the mileage interval value corresponding to each pixel in the image. The specific process for reading the maximum width value of the crack includes: Extract the skeleton lines of the crack region from the segmentation results output by the lightweight recognition model, calculate the distance between the two edges of each crack point by point along the normal direction of the skeleton lines, and take the maximum value of the distance as the maximum width of the crack; if the maximum width of the crack exceeds the warning width threshold stored in the local knowledge base, add a width over-limit label to the abnormal event record.

[0031] Step S5 includes: Based on the abnormal event record, determine the defect type, defect size and occurrence location in this abnormal event record, and retrieve the specification threshold that matches the defect type and defect size from the local knowledge base; The defect size is compared with the specification threshold, and a risk score is assigned based on the comparison result; Find the defect size of the same location in the last inspection from the local knowledge base, and calculate the rate of change of defect size between the current abnormal event record and the last abnormal event record as the development score; The risk score and the developmental score are weighted and added together to obtain a comprehensive risk score. The risk level is determined based on the range of values ​​that the comprehensive risk score falls into. The specific process for calculating the rate of change of size between the current abnormal event record and the previous abnormal event record includes: Retrieve the previous abnormal event record with the same mileage station number and the same defect type from the local knowledge base; Extract the defect size from the previous anomaly event record. Let the defect size identified in this abnormal event record be... Then the rate of change According to the formula Calculation, where To prevent the smallest constant from having a denominator of zero; if If the development rate exceeds the threshold stored in the local knowledge base, the development rate score of this abnormal event record will be set to the highest level.

[0032] Step S6 includes: By using a local lightweight model, a video event detection model, a sensor anomaly judgment model, and equipment status recognition rules, cracks, leaks, smoke, water accumulation, lining anomalies, and electromechanical equipment failures are identified to obtain the types of abnormal events. Based on the risk level and the type of abnormal event, the corresponding handling template is matched from the local knowledge base to generate a standardized inspection conclusion text, and the pre-set operation steps in the handling template are listed one by one in order to form a manually selected operation list. The specific process of generating a standardized inspection conclusion text includes: Retrieves the conclusion template corresponding to the abnormal event type from the local knowledge base. The conclusion template contains multiple placeholders, including: location placeholder, type placeholder, size placeholder, risk level placeholder, and recommendation placeholder. Enter the actual mileage marker in the location placeholder, the defect category name in the type placeholder, the defect size value and unit in the size placeholder, the risk level name in the risk level placeholder, and the text description of the handling operation list in the suggestion placeholder. After piecing them together, you will get the complete inspection conclusion text.

[0033] Step S7 includes: The offline intelligent agent detects the network connection status in real time. When it detects that the network has been restored and the bandwidth meets the conditions, it reads the local evidence chain that has not yet been uploaded from the local cache database. Local evidence chains are uploaded to the central operation and maintenance platform in descending order of risk level. After the upload is completed, wait for the platform to return confirmation information. If a model update file is received from the platform, the parameters of the lightweight recognition model are updated using the model update file.

[0034] A tunnel operation and maintenance inspection and emergency response system based on offline intelligent agents, the system comprising: The system deployment module is used to deploy offline intelligent agents in edge computing devices at the tunnel site. The offline intelligent agents are equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. The data acquisition module is used to receive multi-source sensing data of tunnel operation and maintenance through offline intelligent agents and preprocess it to obtain local inspection datasets; The data processing module is used to calculate the priority of each inspection segment based on the local inspection dataset, generate an inspection task list in descending order of priority, calculate the locally executable inspection path of the inspection robot, and collect inspection images based on the locally executable inspection path and send them to the local cache database. The abnormal event recording module is used to retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. It calculates the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combines them into an abnormal event record. The risk level assessment module is used to determine the defect type, defect size, and location of cracks based on abnormal event records, and compare them with standard thresholds to obtain a hazard score and a development score; the risk level is obtained by combining the hazard score and the development score. The operation list building module is used to match the corresponding handling template from the local knowledge base according to the risk level and abnormal event type, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form an operation list for manual selection. The local evidence chain construction module is used to connect and store inspection images, risk levels, inspection conclusion texts, and manually selected actual operations in chronological order based on the checklist results on the operation list, forming a local evidence chain indexed by the event number, and then uploading it to the central operation and maintenance platform in descending order of risk level.

[0035] This application provides another embodiment as follows: A1: Building a local offline intelligent agent runtime environment: In A1, a local offline intelligent agent operating environment is built on edge computing devices, inspection robots, mobile inspection terminals, or portable emergency response terminals at the tunnel site. This allows functions such as inspection, identification, judgment, handling, and recording to be completed independently under conditions of no network, weak network, or network outage. This operating environment includes at least a local task scheduling engine, an offline intelligent agent kernel, a lightweight multimodal recognition model, a local knowledge base, an emergency plan library, an operation and maintenance specification library, a rule reasoning engine, a data cache database, a log management unit, a synchronization update unit, and an operation status monitoring unit.

[0036] Before deployment, the local offline intelligent agent operating environment first performs initialization testing on the computing resources, storage resources, sensor access capabilities, and communication status of the field edge devices to form a set of device capability parameters:

[0037] in, Represents the set of capabilities of edge devices. Indicates local computing power. Indicates the available memory capacity. Indicates available storage space. Indicates the current network bandwidth or network availability status. This represents the device's input / output interface capabilities. This set is used to determine whether the edge device meets the conditions for offline intelligent agent operation, and accordingly to determine the model loading scale, knowledge base indexing range, and caching strategy.

[0038] In terms of model deployment, the system selects the appropriate lightweight identification model based on the available equipment resources at the tunnel site. The model library includes models for crack identification, leakage identification, smoke detection, water accumulation identification, lining anomaly identification, and equipment fault diagnosis.

[0039] The crack recognition model adopts a structure of "image normalization layer - lightweight convolution feature extraction layer - slender target enhancement layer - pixel segmentation layer - skeleton extraction and width calculation layer" to extract linear dark patterns, crack edges and penetration morphology on the lining surface, and output the crack segmentation area, crack length and maximum width value.

[0040] The leakage identification model adopts a structure of "image enhancement layer - color texture fusion layer - multi-scale region segmentation layer - water stain boundary correction layer - area calculation layer" to identify wet spots, water stains, leakage extension boundaries and leakage area on the lining surface.

[0041] The smoke detection model adopts a structure of "keyframe extraction layer - inter-frame change analysis layer - lightweight temporal feature fusion layer - smoke region discrimination layer - concentration level output layer" to identify smoke diffusion, visibility reduction and continuous smoke changes in fixed camera equipment or inspection videos.

[0042] The water accumulation identification model adopts a structure of "road surface area extraction layer - reflective texture identification layer - water accumulation area segmentation layer - water level sensing verification layer - water accumulation level output layer" to identify the water accumulation range of road surfaces, drainage ditches or low-lying sections, and correct the water accumulation level by combining water level sensor data.

[0043] The lining anomaly identification model adopts a structure of "lining area positioning layer - local defect feature extraction layer - multi-category anomaly discrimination layer - geometric parameter output layer" to identify anomalies such as lining spalling, blockage, hollow signs, surface damage and local deformation.

[0044] The equipment fault diagnosis model adopts a structure of "equipment status coding layer - operating parameter timing analysis layer - alarm code matching layer - fault type discrimination layer - fault level output layer" to determine the switching status, operating current, alarm code and fault duration of lighting, ventilation, fire protection, drainage, power supply and distribution and traffic monitoring equipment.

[0045] The calling relationship of the above model in the offline intelligent agent can be expressed in words as follows: After preprocessing, the on-site images, videos, sensor data and equipment status data are input into the corresponding lightweight recognition model according to the event type. The model outputs the defect category, abnormal location, geometric parameters, confidence level and fault level, and combines them to form an abnormal event record.

[0046] The system selects a local model based on model accuracy, inference latency, and resource consumption. The selection criteria can be expressed as follows:

[0047] in, This indicates the selected local model. Represents the set of candidate models. Indicates the model's recognition accuracy. This represents the latency of a single inference iteration of the model. This indicates the model's resource consumption. and These represent the maximum allowed inference latency and the maximum resource consumption, respectively. These are the weighting coefficients. This method enables offline intelligent agents to maintain both recognition accuracy and real-time response capabilities even on low-computing-power edge devices.

[0048] In terms of knowledge resource deployment, tunnel operation and maintenance specifications, disease treatment rules, emergency plans, equipment operation manuals, historical inspection records, and typical cases are pre-written into the local knowledge base. The tunnel operation and maintenance specifications include inspection cycles, inspection items, structural component classification, defect judgment standards, risk classification thresholds, and reporting requirements; defect handling rules include triggering conditions, handling levels, review requirements, and handling steps for events such as cracks, leaks, water accumulation, smoke, lining spalling, rockfall, and electromechanical equipment failures; emergency plans include response procedures, personnel assignments, equipment deployment, and temporary traffic organization requirements for scenarios such as smoke alarms, severe water accumulation, lining rockfall, sudden leaks, abnormal ventilation, fire equipment failures, and traffic obstruction; equipment operation manuals include equipment numbers, operating status, alarm codes, fault types, start-up and shutdown procedures, and safety precautions for lighting, ventilation, fire protection, drainage, power supply and distribution, and traffic monitoring equipment; historical inspection records include inspection time, mileage marker, structural component, defect type, defect size, risk level, handling measures, and review results; and typical cases include the location, development process, handling plan, handling effect, recurrence, and status of related equipment for similar defect events.

[0049] The knowledge base is organized using three types of data: structured rules, text retrieval indexes, and case tags. Structured rules store directly calculable and judgmentable data fields, including defect type, applicable location, size threshold, risk level, handling action, review conditions, and reporting conditions. The text retrieval index stores segmented texts of standard provisions, emergency plans, operating instructions, and handling records, along with their retrieval features, enabling offline agents to perform local searches based on event type, mileage location, structural location, and keywords. Case tags label historical cases with tunnel numbers, mileage markers, defect types, defect parameters, risk levels, handling measures, handling results, and recurrence status, allowing current abnormal events to be matched with similar historical cases. Each local knowledge record can be represented as:

[0050] in, Indicates the first One local knowledge record; It represents specific objects, including cracks, leaks, water accumulation, smoke, lining spalling, lighting equipment, ventilation equipment, drainage equipment, fire-fighting equipment, and traffic monitoring equipment; Indicates the event type or defect type, including structural defects, environmental anomalies, and electromechanical equipment failures; This indicates the corresponding rule basis, including the standard threshold, risk classification conditions, emergency triggering conditions, and handling procedures; This indicates local search features extracted from regulatory provisions, handling instructions, or historical case texts; This indicates the corresponding emergency plan or response procedure; Indicates the historical case number associated with this knowledge record; This indicates the applicable conditions of the knowledge record, including the applicable tunnel type, applicable structural location, applicable risk level, and applicable equipment status.

[0051] In terms of agent kernel construction, inspection task planning, model invocation, knowledge retrieval, risk assessment, disposal suggestion generation, and log recording are encapsulated into a set of basic actions for the local agent, and scheduled through a local state machine. The running state of the offline agent at any given time can be represented as:

[0052] in, Indicates time The operational status of the intelligent agent. This indicates the current inspection task queue. This indicates the collected field data. Indicates identified anomalous events. This indicates the result of the risk assessment. This indicates the local log status. The system uses this status set to determine the next action to take, such as continuing data collection, invoking the recognition model, retrieving the knowledge base, generating disposal suggestions, or writing disposal records.

[0053] Regarding offline caching, the system establishes a local cache database to hierarchically store inspection data, identification results, risk levels, handling suggestions, manual confirmation information, and on-site evidence. To ensure that important events are saved and synchronized first, the system generates priorities based on event risk level, data time, and event type:

[0054] in, Indicates the first The priority of each cached record Indicates the risk level weight. Indicates the weight of data timeliness. Indicates the historical correlation weight of events. This is a weighting factor. Data with higher risk levels, more recent occurrence times, and stronger correlations with historical diseases have higher priority and will be uploaded to the central platform first after network connectivity is restored.

[0055] Through the above deployment, step A1 establishes a locally operable offline intelligent agent environment. This environment is not merely a simple data cache or edge detection program, but rather integrates task scheduling, model inference, knowledge retrieval, rule judgment, emergency process invocation, and result tracking into a local closed-loop operating mechanism. When the tunnel network is unavailable, the system can still rely on local computing and knowledge resources to complete inspections and emergency responses; once the network is restored, the synchronization update unit completes data backhaul, log verification, model updates, and incremental updates of the knowledge base, thereby ensuring consistency between on-site offline decision-making and central platform management.

[0056] A2: Access to multi-source sensing data for tunnel operation and maintenance: In A2, after completing the construction of the local offline intelligent agent operating environment, the system establishes a multi-source perception data access mechanism for tunnel operation and maintenance scenarios. This mechanism integrates inspection robots, mobile inspection terminals, fixed camera equipment, infrared thermal imaging equipment, smoke sensors, water level sensors, temperature and humidity sensors, lighting systems, ventilation systems, fire protection systems, drainage equipment, traffic monitoring equipment, and historical operation and maintenance data into the local edge devices. The access objects include both real-time collected data and locally pre-set historical inspection records, maintenance work orders, historical defect records, equipment ledgers, emergency response records, and structural component coding tables.

[0057] To ensure that data from different sources can be uniformly accessed by the offline intelligent agent, the system first uniformly encodes the collected multi-source sensing data to form tunnel operation and maintenance field data objects. Each type of access data can be represented as:

[0058] in, Indicates the first Similar to on-site data, Indicates the device from which the data originates. Indicates the collection time. Indicates the spatial location or mileage marker of the tunnel. Represents data type, Represents the original data content. This data object indicates the data quality status. Through this data object, images, videos, sensor sequences, device status, and manual records can enter a unified data processing chain, avoiding inconsistencies in data formats across different systems that could lead to difficulties in subsequent identification and judgment.

[0059] In terms of time processing, the system performs timestamp correction on data collected by inspection robots, mobile terminals, fixed sensors, and electromechanical equipment. For data with inconsistent sampling frequencies from different devices, different upload delays, or data written in batches after network outages, the system uses a local clock reference for time rearrangement, ensuring that images, videos, sensor data, and device statuses corresponding to the same abnormal event can be correlated within the same time window. The time-corrected data time can be represented as:

[0060] in, This indicates the corrected acquisition time. Indicates the original data collection time. Indicates the device from which the data originates. The corresponding local time offset. This processing reduces event misjudgments caused by asynchronous acquisition from multiple devices, such as the inconsistency between the smoke sensor alarm time and the video smoke recognition time.

[0061] In terms of spatial processing, the system maps different data uniformly to the tunnel operation and management coordinate system. For fixed equipment, the tunnel number, tunnel type, lane, mileage marker, and structural location are directly bound to the equipment's installation location. For inspection robots and mobile terminals, the data collection location is determined by combining odometer readings, inertial navigation, visual positioning, QR code identification, or manually input information. The spatial mapping result can be represented as:

[0062] in, Indicates the first Spatial index of data, Indicates the tunnel number. Indicates the direction of the tunnel, whether it is left or right, or up or down. Indicates the mileage marker. Indicates the location of a lane or maintenance driveway. This spatial index represents structural or equipment components such as lining, sidewalls, arches, pavements, drainage ditches, and electromechanical equipment. Through this index, the system can pinpoint cracks, leaks, water accumulation, smoke, and equipment malfunctions to specific tunnel sections and component locations, providing a basis for subsequent risk assessment and mitigation recommendations.

[0063] Regarding data format standardization, the system performs resolution correction, distortion correction, and brightness normalization on image data; extracts keyframes and segments event segments on video data; performs unit conversion, outlier removal, and sliding window resampling on sensor data; standardizes device status data for switch status, operating current, alarm codes, and fault codes; and extracts keywords and labels events on manual inspection text. The processed data is no longer stored in the original device format but is instead compiled into a unified inspection data package that can be accessed by offline agents.

[0064] For continuous sensor data, the system constructs a local state sequence according to a fixed time window for subsequent anomaly identification and risk assessment:

[0065] in, Indicates time The corresponding sensor time window, This represents the sensor observation value at the current moment. This indicates the window length. This method is suitable for scenarios such as continuously increasing smoke concentration, rapid rise in water level, abnormal changes in temperature and humidity, and fluctuations in the operating status of ventilation equipment, and can avoid accidental false alarms caused by judging based on single-point data.

[0066] In terms of data quality verification, the system performs integrity, validity, consistency, and reliability checks on the collected data. For cases such as blurry images, missing video frames, prolonged periods of unchanged sensor data, missing device status, and abnormal positioning information, the system automatically labels the data quality level and reduces the weight of that data or triggers re-collection during subsequent identification and inference processes. Data quality evaluation can be expressed as:

[0067] in, Indicates the first Quality score of each data point Indicates data integrity. Indicates numerical validity. Indicates the degree of alignment between time and space. Indicates the reliability of the source equipment. For weighting coefficients. When When the data falls below a preset threshold, the system marks the data as low-reliability data and prompts the inspection robot or on-site personnel to collect additional data, verify the data, or confirm it manually.

[0068] In terms of multi-source data association, the system uses "time window—spatial location—event type" as the main framework, combining image, video, sensor, and equipment status data within the same segment and time period into candidate event data packages. For example, if a water level sensor shows an increase, a camera detects water accumulation on the road, and a drainage pump malfunctions simultaneously near K2+300, the system associates these three types of data as a "water accumulation anomaly candidate event." Similarly, if smoke concentration increases, video visibility decreases, and ventilation equipment fails to start, the system associates this as a "smoke anomaly candidate event." The candidate event data package includes the event number, data source, collection time, spatial location, associated evidence, quality score, and the status to be identified.

[0069] Through the above processing, step A2 forms a standardized local data foundation for offline intelligent agents. This step is not a simple data collection, but rather transforms data from multiple devices, formats, frequencies, and locations into inspection data packages with temporal consistency, spatial locationability, quality evaluability, and event correlation, laying the foundation for subsequent offline defect identification, risk classification judgment, emergency response suggestion generation, and data synchronization after network restoration.

[0070] A3: Generate offline inspection tasks and locally executable inspection paths: In A3, after completing the construction of the local offline intelligent agent operating environment and the access of multi-source sensing data, the system generates offline inspection tasks and inspection paths that can be executed under conditions of no network, weak network, or network outage, based on tunnel basic information, historical disease records, equipment operating status, last inspection results, current environmental status, and preset inspection cycle.

[0071] Before generating a task, the system first establishes a list of tunnel inspection targets, organizing the tunnel into sections according to mileage markers, structural components, equipment types, and risk areas. Each inspection target can be represented as:

[0072] in, Indicates the first Each inspection target, Indicates the tunnel or section number. Indicates the range of mileage markers. Indicates structural components or equipment objects. Indicates the historical state of disease. Indicates current environmental influencing factors. This indicates the preset inspection cycle. Through this object-oriented representation, the system can incorporate arches, side walls, roads, drainage ditches, fire-fighting equipment, ventilation equipment, lighting equipment, monitoring equipment, and other components into a unified inspection task system.

[0073] Regarding the determination of inspection priorities, the offline intelligent agent comprehensively considers the severity of historical defects, the degree of anomaly in the last inspection, the trend of defect development, current environmental disturbances, the degree of traffic impact, and the importance of equipment, assigning dynamic priorities to different inspection objects. The priority calculation can be expressed as:

[0074] in, Indicates the first Inspection priority for each inspection target Indicates the weight of historical diseases. This indicates the weight of any anomalies detected during the last inspection. Indicates the weight of the disease development trend. This indicates the weights of environmental disturbances such as rainfall, temperature and humidity, and traffic load. Indicates the importance weight of structural components or equipment. This represents the weighting coefficient. The higher the priority, the more likely the system is to include the object in the current round of key inspection tasks and increase the collection frequency or recognition accuracy requirements.

[0075] Regarding task list generation, the system automatically generates an offline inspection task list set based on the priority of the inspection section and local device resources. The inspection task list must include at least the inspection section, inspection object, inspection content, called device, data collection method, data collection accuracy, anomaly triggering conditions, and local recording requirements. A single inspection task list is represented as follows:

[0076] in, Indicates the first One inspection task Indicates the corresponding inspection object. Indicates the type of inspection action. Indicates the sampling frequency or sampling interval. Indicates the inspection equipment being called. Indicates the threshold for triggering an anomaly. This indicates the requirements for task recording. Inspection actions include image acquisition, video inspection, thermal imaging detection, sensor reading, equipment status reading, manual verification, and re-photographing of key sections.

[0077] In terms of path planning, the system generates a locally executable inspection path based on the inspection task location, the current location of the inspection robot, traffic conditions, task priority, and remaining battery power. Path planning does not rely on real-time calculations from a central platform; instead, it is completed on the edge device based on local tunnel alignment, mileage markers, and robot movement constraints. For the inspection robot, the path objective is to reduce repetitive travel and unnecessary stops while prioritizing key tasks. This optimization objective can be expressed as:

[0078] in, Indicates the distance traveled between adjacent inspection task points. Indicates the first The estimated execution time for each task Indicates task priority. and This is an adjustment factor. The goal is to ensure that the path takes into account both travel distance and execution time, while also prioritizing the coverage of high-risk sections.

[0079] In offline mode, the inspection path also needs to consider situations such as task interruption, obstructed passage, insufficient equipment power, and sudden on-site anomalies. While generating the initial path, the system constructs backup task sequences and a local replanning mechanism. When the inspection robot cannot reach a certain section, or the mobile terminal indicates restricted passage, the offline agent reorders the remaining tasks according to priority, adjusts the inspection path, and marks incomplete tasks as pending inspection. For manual inspection terminals, the system generates a checklist according to mileage order and risk priority, prompting inspection personnel to complete, confirm, and record each item.

[0080] Regarding task accuracy configuration, the system automatically adjusts the data acquisition requirements based on the risk level of the inspected object. For general sections, the system uses a conventional acquisition frequency and standard resolution; for sections with historical cracks, long-term leaks, repeated water accumulation, or frequent equipment failures, the system increases image resolution, increases acquisition angle, shortens sensor sampling interval, and requires additional on-site verification. For objects that may cause safety incidents, such as smoke, water accumulation, or falling debris, the system sets immediate trigger conditions; once the acquired data exceeds a threshold, it jumps to the anomaly identification and risk assessment process.

[0081] During the inspection process, the offline intelligent agent continuously receives on-site data and task completion status, and adjusts the task queue according to real-time conditions. For example, when a new crack is found in a section, the system will automatically add supplementary shooting tasks for the adjacent mileage range before and after that section; when an abnormality is detected in the drainage equipment, the system will add joint inspection tasks for drainage ditches, collection wells, and low-lying road sections; when the mobile terminal manually enters "increased local seepage", the system will add tasks for infrared image acquisition, water stain range shooting, and historical case comparison.

[0082] Through the above processing, step A3 establishes an inspection task and path generation mechanism for offline operation conditions. This step does not simply involve inspections according to fixed cycles or routes, but rather dynamically determines the inspection content and execution sequence based on historical defects, current status, equipment resources, and on-site risks. This enables the offline agent to proactively organize the inspection process when the network is unavailable, and provides targeted on-site data for subsequent defect identification, risk classification, and emergency response.

[0083] A4: Perform offline identification of tunnel defects and abnormal events: In step A4, after generating offline inspection tasks and paths, the system, based on the task list and on-site data collection requirements formed in step A3, invokes the local lightweight model, sensor anomaly detection model, and rule inference engine to perform offline identification of tunnel structural defects, environmental anomalies, and electromechanical equipment malfunctions. This step is completed independently by the local offline agent under conditions of no network, weak network, or network outage, without relying on real-time calculations from the central platform. The identification results directly enter the subsequent risk classification and emergency response process.

[0084] Regarding the identification targets, the system can identify at least cracks, leaks, water accumulation, smoke, lining spalling, falling pieces, signs of hollowness, road surface anomalies, lighting malfunctions, ventilation anomalies, fire-fighting equipment anomalies, drainage equipment anomalies, and monitoring equipment malfunctions. For structural defects, the system focuses on outputting the defect type, spatial location, geometric dimensions, development characteristics, and confidence level; for environmental anomalies, the system focuses on outputting the anomaly intensity, duration, trend of change, and scope of impact; for electromechanical equipment malfunctions, the system focuses on outputting the equipment number, fault type, alarm status, operating parameters, and linkage effects.

[0085] In image and video recognition, the offline agent invokes the corresponding local image recognition model based on the inspection task type. For lining images collected by the inspection robot or mobile terminal, the system first performs image sharpness screening, distortion correction, brightness normalization, and region of interest extraction, then inputs the images into the local recognition model to obtain candidate defect regions. The model output can be represented as:

[0086] in, Indicates the first One defect candidate result, Indicates the defect category, This represents the defect bounding box or segmented region. This indicates the confidence level of the model in identifying the problem. This represents the geometric parameters of the defect. These parameters include crack length, crack width, leakage area, water accumulation range, spalling area, and coordinates of abnormal locations. For slender targets such as cracks, the system prioritizes extracting skeleton lines and width features from the segmentation results; for planar targets such as leaks, water accumulation, and spalling, the system extracts area, boundary expansion direction, and grayscale or color variation features.

[0087] In video event detection, the system extracts keyframes and compares consecutive frames from inspection videos or videos from fixed cameras to identify dynamic events such as smoke diffusion, water accumulation, foreign object intrusion, personnel lingering, abnormal vehicle parking, and decreased visibility. For video events, the system not only determines whether a single frame is abnormal, but also judges whether the event is continuing to develop based on the changing trend of abnormal areas in consecutive frames. The rate of change of dynamic events can be expressed as:

[0088] in, Indicates the rate of change of the abnormal event area. This indicates the area or scope of the abnormal region at the current moment. This indicates the area or scope of the abnormal region within the previous time window. This indicates a time interval. When the rate of change in a smoke-filled area, waterlogged area, or low-visibility area exceeds a preset threshold, the system marks the event as a continuously evolving anomaly and increases the weight of subsequent risk assessments.

[0089] In terms of sensor anomaly detection, the system performs local anomaly assessments on data such as smoke concentration, water level, temperature and humidity, wind speed, illuminance, current, voltage, equipment operating status, and alarm codes. For continuous sensor data, the system combines current values, rate of change, and short-term fluctuation amplitude to determine if anomalies exist; for status-based data, the system determines if faults exist based on equipment on / off status, alarm codes, and operating logic. Sensor anomaly deviation can be expressed as:

[0090] in, Indicates the degree of abnormal deviation of the current sensor data. Indicates the current observation value. Indicates the local reference base value. Indicates the scale of fluctuation in the reference data. This represents a minimal constant to prevent the denominator from being zero. When When the set threshold is exceeded and the duration of the abnormality meets the preset conditions, the system recognizes that the sensor has an abnormal event, rather than using a single fluctuation as the basis for alarm.

[0091] In terms of multi-source evidence fusion, the system correlates and confirms image recognition results, video detection results, sensor anomaly results, device status results, and manually input information to avoid false alarms from a single data source. For example, if only a suspected water stain appears in an image, the system can identify it as a candidate leakage event; if there is simultaneously increased humidity, historical leakage records, and an expansion of the water stain area at the same location, the system confirms it as an abnormal leakage event. The fusion confidence level can be expressed as:

[0092] in, This represents the fusion confidence level of an anomalous event. Indicates the first The confidence level or probability of anomaly detection for the source of similar evidence. This indicates the reliability weight of the source of the evidence. This indicates the amount of evidence involved in the fusion. This method enables the joint judgment of images, videos, sensors, and historical records, improving the reliability of offline recognition results.

[0093] In terms of event merging, the system combines multiple candidate results into a single anomalous event based on temporal proximity, spatial proximity, and consistency of event type. For example, when multiple consecutive images of the same section identify the same crack, the system merges them into a single crack event, retaining the maximum width, cumulative length, and highest confidence level. Similarly, when a water level sensor malfunction, video water accumulation detection, and drainage pump failure occur simultaneously in the same low-lying section, the system merges them into a single water accumulation-linked event. The merged anomalous event record includes the event number, event type, location, associated data, defect parameters, duration, confidence level, and pending determination status.

[0094] Regarding defect parameter extraction, for crack events, the system outputs information such as crack length, width, direction, distribution density, and whether it is continuous; for leakage events, it outputs leakage area, water stain boundary, degree of wetness, and whether it is accompanied by cracks; for water accumulation events, it outputs the location, range, depth estimate of water accumulation, and the associated status of drainage equipment; for smoke events, it outputs smoke concentration level, changes in visibility, and the operating status of ventilation equipment; for electromechanical equipment failures, it outputs equipment number, fault code, duration of abnormality, and associated impact range. These parameters serve as important inputs for subsequent risk grading, rather than simply outputting a conclusion of "whether there is an abnormality."

[0095] For offline identification result verification, the system performs confidence level screening and manual review triggering on the identification results. When the defect confidence level is high and multi-source evidence is consistent, the system directly enters the risk grading process; when the identification confidence level is in the middle range, or the image quality is low, the sensor status is abnormal, or the positioning information is incomplete, the system marks the event as "requires review" and issues a supplementary data collection task to the inspection robot or mobile terminal, including re-shooting, adjusting the angle, moving closer for inspection, increasing the sensor reading frequency, or requiring on-site personnel for manual confirmation. This can reduce false alarms, missed alarms, and erroneous judgments caused by low-quality data in offline mode.

[0096] Through the above processing, step A4 achieves localized, offline, and multi-source fusion identification of tunnel operation and maintenance anomalies. This step is not a single image detection or single-point sensor alarm, but rather integrates structural defect identification, environmental anomaly detection, equipment status judgment, historical information association, and on-site verification mechanisms into an offline intelligent agent identification chain. This enables the system to generate relatively complete anomaly event identification results even when the network is unavailable, providing a reliable basis for subsequent risk level determination, emergency plan invocation, and handling recommendations.

[0097] A5: Risk classification assessment based on local knowledge base: In step A5, after completing the offline identification of tunnel defects and abnormal events, the system inputs the abnormal event records, defect parameters, multi-source evidence, spatial location, historical defect status, and equipment operating status output from step A4 into the local offline agent. The offline agent then calls upon the local operation and maintenance specification library, defect knowledge base, emergency plan library, local knowledge base, and rule reasoning engine to perform risk classification judgment on the abnormal events. This step is completed independently under conditions of no network, weak network, or network outage, without relying on real-time review by the central platform. Its purpose is to further transform "identifying anomalies" into "clarifying the risk level, judgment basis, and subsequent handling trigger conditions."

[0098] Before risk classification, the system first constructs anomaly event risk assessment objects. Each anomaly event is no longer simply represented by a defect category, but rather forms a comprehensive assessment object that includes structural location, defect size, development status, environmental conditions, equipment associations, and historical evolution information. This object can be represented as:

[0099] in, Indicates the first An abnormal event. Indicates the event category, Indicates the location where the event occurred. Indicates the geometric or strength parameters of the defect. Indicates the duration or trend of an event. Indicates the correlation status of multi-source evidence. This indicates historical records of disease or treatment. This indicates the operating status of the relevant equipment. Through this object, the system can avoid relying solely on a single defect identification result for risk assessment, instead incorporating both the on-site status and historical information into the offline reasoning process.

[0100] In terms of knowledge matching, the offline intelligent agent retrieves corresponding regulatory clauses, operation and maintenance standards, disease treatment rules, emergency plans, and historical cases from the local knowledge base based on the type and location of the abnormal event. For crack events, the system focuses on matching rules such as crack width, length, development rate, whether it is accompanied by leakage, and the location of the lining; for leakage events, it focuses on matching rules such as leakage area, water volume changes, whether it affects electrical equipment, and whether it occurs in critical parts of the arch or sidewall; for water accumulation events, it focuses on matching water depth, range, growth rate, drainage equipment status, and traffic impact range; for smoke events, it focuses on matching smoke concentration, visibility, ventilation equipment status, vehicle congestion, and fire alarm status; for electromechanical equipment failures, it focuses on matching equipment type, fault code, redundant equipment status, and impact on traffic safety.

[0101] To ensure the interpretability of risk assessments, the system generates knowledge matching results for each anomaly event:

[0102] in, Indicates an abnormal event The corresponding knowledge matching results This indicates the matched operation and maintenance rules or specifications. This indicates the corresponding emergency response plan procedure. This indicates entries related to disease and pest knowledge. This indicates similar historical cases. The matching result serves as the basis for risk level determination and is simultaneously recorded in subsequent inspection conclusions and reports for easy review by operations and maintenance personnel.

[0103] In terms of risk scoring, the system comprehensively evaluates the hazard, development potential, impact, and controllability of abnormal events. Hazard reflects the severity of the defect or abnormality itself; development potential reflects whether the event has a tendency to escalate; impact potential reflects the scope of its influence on structural safety, vehicle safety, and equipment operation; and controllability reflects whether rapid response conditions are available on-site. The comprehensive risk score can be expressed as:

[0104] in, Indicates the first A comprehensive risk score for each abnormal event. Indicates the risk level of the event. Indicates the developmental rating of the event. Indicates the impact score of the event. Indicates the controllability score of the event. This is a weighting coefficient. The more dangerous the event, the faster it develops, the wider its impact, and the lower its on-site controllability, the higher the overall risk score.

[0105] The event hazard score can be determined based on the size of the defect or the intensity of the anomaly. For example, a crack event can be assessed by considering crack width, length, and location sensitivity; a leakage event by considering leakage area and water volume level; a water accumulation event by considering water depth and the range of lanes covered; a smoke event by considering smoke concentration and the degree of visibility reduction; and an equipment failure event by considering equipment importance and failure duration. The event progression score is determined based on the magnitude of change between the current event and historical records, the growth trend of continuous monitoring data, and whether multi-source evidence indicates an abnormal expansion.

[0106] Regarding thresholds and rule triggers, the system compares the comprehensive risk score with locally preset risk classification thresholds to obtain the initial risk level:

[0107] in, Indicates the risk level of abnormal events. Indicates general concern. This indicates that we will be closely monitoring this matter. Indicates on-site handling, Indicates emergency response. These represent the threshold values ​​for different risk levels. These thresholds can be pre-configured based on tunnel type, operation and management requirements, historical defects, and local emergency rules, and can be updated by the central platform after network connectivity is restored.

[0108] Regarding rule correction, the system does not rely solely on comprehensive scores for mechanical classification; instead, it sets mandatory escalation rules and manual review rules. For events that directly affect driving safety or personnel safety, such as abnormal smoke, rapid water accumulation, lining collapse, severe leakage, fire protection system malfunction, ventilation system failure, and power supply / distribution anomalies, even if the comprehensive score has not yet reached the highest level, as long as the mandatory conditions in the local emergency plan are triggered, the system will immediately escalate the risk level to on-site handling or emergency response. The mandatory escalation rule can be expressed as:

[0109] in, This indicates the risk level after the rule revision. This indicates the initial risk level obtained from the comprehensive score. This indicates the lowest risk level triggered by the mandatory rule. This mechanism prevents high-risk events from being underestimated due to missing data or insufficient model confidence.

[0110] In terms of historical correlation judgment, the system compares the current abnormal event with the historical records of the same mileage, the same structural part, or the same equipment object to determine whether there are repeated occurrences, continuous expansions, or recurrences after treatment. For example, if leakage occurs multiple times at the same sidewall location and the leakage area increases with each occurrence, the system classifies it as a complex defect with developmental characteristics; if the same drainage pump fails multiple times and occurs simultaneously with water accumulation events, the system classifies it as a coupled event of equipment failure and environmental risk; if the width of the same crack continues to increase and is accompanied by water seepage, the system upgrades it from a general structural defect to a key tracking or on-site treatment target.

[0111] In terms of multi-event linkage judgment, the offline intelligent agent also identifies the combined risks between different abnormal events. A single minor leak may only be of general concern, but if crack expansion, increased humidity, and water stains near electrical equipment occur simultaneously, the system will raise the risk level. A single lighting failure may be a common equipment failure, but if it occurs on a curved section, in the middle of a long tunnel, or in an area with reduced visibility due to smoke, it may have a greater impact on driving safety and require a higher level of response. The system determines whether there are linkage risks through event combination rules and incorporates the linkage relationship into the risk judgment criteria.

[0112] Regarding the output of risk classification results, the system generates a risk classification record for each abnormal event. This record includes the event number, event type, location of occurrence, defect parameters, comprehensive risk score, risk level, triggering rules, knowledge matching basis, historical correlation information, whether manual review is required, and whether the emergency response process has commenced. Level 1 general concern events are recommended by the system to be included in routine inspection records and continuously monitored; for For key tracking events, the system generates review plans and recommendations for enhanced inspections; For level-one on-site incidents, the system triggers the on-site handling procedure and requires recording the handling results; In the event of a Level II emergency response, the system directly invokes the local emergency plan and generates reporting content and temporary traffic organization suggestions.

[0113] When confidence levels are insufficient, the system will not directly output a certainty level, but instead generate a "provisional risk level + verification requirements". For example, if the image quality is low but there is suspected lining spalling, the system can provisionally designate it as a key area for tracking and require the inspection robot to take close-up re-shots; if the smoke sensor is malfunctioning but video evidence is insufficient, the system can require on-site personnel to confirm visibility and ventilation status; if equipment fault codes exist but the operating current is normal, the system can prompt for a second reading of the equipment status. Through this mechanism, the relationship between automatic judgment and manual confirmation can be balanced under offline conditions.

[0114] Through the above processing, step A5 transforms the "anomaly identification result" into "risk level and judgment basis." This step does not simply trigger an alarm based on a threshold, but rather performs local risk reasoning by comprehensively considering the defect scale, development trend, spatial location, historical records, equipment linkage, standard rules, and emergency plans. This allows the offline intelligent agent to generate interpretable, traceable, and actionable risk classification results even when the network is unavailable, providing direct evidence for subsequent inspection conclusion generation, emergency procedure invocation, and on-site handling recommendations.

[0115] A6: Generate inspection conclusions and emergency response recommendations: In step A6, after completing the risk classification assessment of abnormal events, the system automatically generates inspection conclusions and emergency response suggestions from the local offline agent based on the risk level, judgment criteria, event type, location, defect parameters, historical correlation information, and on-site equipment status output in step A5. The core of this step is to further transform the "risk assessment results" into a list of actions that on-site personnel can directly execute, record, report, and trace, enabling the offline agent to support the formation of a standardized closed-loop response at the tunnel operation and maintenance site even under conditions of no network, weak network, or network outage.

[0116] Before generating inspection conclusions, the system first constructs the input object for handling decisions. This object consists of the abnormal event identification results, risk classification results, knowledge matching results, and available on-site resources, and can be represented as:

[0117] in, Indicates the first Input objects for handling abnormal events and decision-making. Represents the exception event object, Indicates the risk level. This indicates the matching results from the local knowledge base. This indicates that resources are available on-site. This indicates the on-site constraints. On-site available resources include inspection personnel, inspection robots, drainage equipment, ventilation equipment, lighting equipment, fire-fighting equipment, warning signs, traffic diversion facilities, and maintenance tools; on-site constraints include communication status, traffic flow, tunnel section location, equipment availability, personnel arrival time, and safe operating conditions.

[0118] Regarding the generation of inspection conclusions, the system generates standardized conclusion texts based on event type and risk level. Inspection conclusions include at least the event name, location, source of identification, key parameters, risk level, judgment criteria, and recommended course of action. For example, for a crack-related leakage event, the system generates conclusions including the mileage of the crack, structural location, crack length, maximum width, leakage area, changes compared to historical records, and risk level; for an abnormal water accumulation event, the conclusions include the water accumulation section, water accumulation range, water level change trend, drainage equipment operating status, and traffic impact range; for an abnormal smoke event, the conclusions include the location of the smoke, changes in sensor concentration, changes in video visibility, ventilation equipment status, and whether an emergency response has been triggered.

[0119] Regarding the selection of disposal strategies, the system extracts candidate disposal solutions from the local knowledge base and the operation and maintenance specification library, and filters them based on on-site resource constraints. The set of candidate disposal solutions can be represented as:

[0120] in, Indicates the first A set of candidate handling solutions for each abnormal event. Indicates the first One candidate disposal plan, Candidate solutions may include on-site verification, increased patrols, setting up warning signs, restricting traffic, closing lanes, activating drainage equipment, turning on the ventilation system, switching to backup equipment, notifying maintenance units, organizing special inspections, implementing temporary repairs, activating emergency plans, and reporting to the central platform.

[0121] To ensure the proposed solutions are suitable for on-site conditions, the system evaluates the suitability of candidate solutions. The suitability evaluation comprehensively considers the effectiveness of the solution, execution timeliness, resource availability, on-site safety, and impact on traffic flow. The solution score can be expressed as:

[0122] in, Indicates candidate disposal plan Overall score This indicates the effectiveness of the solution in handling the current abnormal event. Indicates the timeliness of the plan's implementation. Indicates the degree to which on-site resources are met. Indicates on-site operational safety. Indicates the degree of impact on traffic operation or normal maintenance. , where is the weighting coefficient. The system prioritizes solutions with higher overall scores that also meet safety constraints as recommended actions.

[0123] Regarding the generation of response recommendations, the system creates a tiered response list based on different risk levels. For Level I general concern events, the system generates recommendations for record entry, routine tracking, and follow-up inspections. For Level II key tracking events, the system generates recommendations for increased inspection frequency, on-site verification, change monitoring, and maintenance plans. For Level III on-site response events, the system generates requirements for on-site warnings, equipment deployment, temporary measures, personnel arrival, and feedback on response results. For Level IV emergency response events, the system directly invokes the local emergency plan, generating emergency response steps, personnel assignment recommendations, equipment linkage instructions, traffic organization recommendations, and reporting texts.

[0124] For structural defects, the recommended handling focuses on verification, continuous monitoring, specialized testing, and repair and reinforcement. For example, when cracks widen and are accompanied by leakage, the system recommends taking photos of the entire crack on-site, measuring the crack width, marking the crack endpoints, inspecting adjacent lining sections, and, if necessary, arranging specialized testing and incorporating it into the maintenance plan. When there is a high risk of lining spalling or falling off, the system recommends setting up a safety warning zone, restricting personnel access, inspecting adjacent areas for hollowing or loosening, and notifying the maintenance unit for on-site handling.

[0125] For environmental anomalies, the response recommendations focus on quickly controlling the source of risk and ensuring traffic safety. For example, when water accumulation reaches the on-site response level, the system recommends checking the status of drainage ditches, sump pits, and drainage pumps, activating backup drainage equipment, setting up warning signs ahead of the waterlogged area, and restricting vehicle traffic or guiding vehicles to change lanes if necessary. When smoke anomalies reach the emergency response level, the system recommends immediately identifying the source of the smoke, activating the ventilation system, coordinating broadcasts to remind vehicles to slow down or move away, notifying on-duty personnel to rush to the scene, and proposing temporary lane closures or tunnel closures based on visibility and traffic conditions.

[0126] For incidents involving electromechanical equipment failures, the handling recommendations focus on equipment switching, fault isolation, and coordinated support. For example, when lighting equipment failure occurs in the middle of a long tunnel or on a curved section, the system recommends activating backup or mobile lighting equipment, setting up warning signs, and arranging equipment maintenance. When ventilation equipment failure and abnormal smoke occur simultaneously, the system escalates a single equipment failure to a coordinated risk event, recommending priority checks on ventilation control cabinets, backup fans, and power supply status. When drainage equipment failure and abnormal water accumulation occur simultaneously, the system recommends activating backup drainage equipment and simultaneously checking for drainage ditch blockages and pump operation status. Regarding the generation of temporary traffic organization recommendations, the system generates suitable traffic organization plans for on-site implementation based on risk level, abnormal location, impact range, lane occupancy, and tunnel traffic conditions. Traffic organization recommendations include setting up warning signs, speed limits, lane guidance, single-lane passage, temporary lane closures, diversion prompts, and tunnel entrance control. For high-risk events, the system prioritizes personnel and vehicle safety, outputting traffic organization recommendations simultaneously with emergency response steps to avoid addressing only the fault itself while neglecting traffic risks.

[0127] To facilitate on-site personnel execution, the system converts the proposed actions into a step-by-step checklist. Each checklist includes at least an action number, the target object, the action content, the action conditions, the expected result, and the recording requirements. The checklist can be represented as follows:

[0128] in, Indicates the first A list of handling procedures for each abnormal event. Indicates the first Specific handling steps, For emergency response events, the operation list is generated in the order of "on-site confirmation - safety alert - equipment linkage - traffic organization - information reporting - continuous monitoring - result feedback"; for key tracking events, the operation list is generated in the order of "review and collection - parameter recording - historical comparison - tracking plan - maintenance suggestions".

[0129] Regarding the generation of reported content, the system automatically generates standardized reported text based on local templates. The reported content includes the tunnel name, event number, time of occurrence, location of occurrence, event type, source of identification, risk level, key evidence, measures taken, recommended support items, and follow-up handling requirements.

[0130] The event type specifies whether the anomaly is a structural defect, environmental anomaly, electromechanical equipment failure, or traffic safety incident. Specific examples include cracks, leaks, water accumulation, smoke, lining spalling, falling pieces, lighting failures, ventilation anomalies, drainage equipment failures, and fire equipment anomalies. The source of identification describes the data or method used to discover the anomaly, including image recognition from inspection robots, video recognition from fixed cameras, smoke sensor alarms, water level sensor alarms, equipment status monitoring, manual confirmation via mobile terminals, or joint judgment using multi-source data. Key evidence records crucial materials supporting the risk assessment, including on-site images, video clips, sensor values, equipment alarm codes, defect dimensions, mileage of occurrence, and historical inspection records. Compare photos of the results and handling process; measures already taken to record temporary handling actions completed by on-site personnel, including setting up warning signs, closing or restricting access, activating ventilation equipment, activating drainage equipment, switching to backup equipment, on-site verification, taking photos for evidence, and notifying maintenance personnel; suggested support items to explain the support still needed on-site from the central platform, maintenance unit, emergency team, or professional testing unit, including remote verification, dispatching personnel to the site, allocating maintenance equipment, arranging special testing, activating emergency plans, or coordinating traffic organization; follow-up handling requirements to clarify the follow-up arrangements for the incident, including time-limited re-inspection, increased inspection frequency, continuous monitoring, defect retesting, closed-loop maintenance, uploading handling results, and recording recurrence.

[0131] Since the system may be offline, the reported text is first stored in a local cache database. Once the network is restored, the synchronization unit uploads it to the central platform according to event priority. For emergency response events, even if the network is not restored, the system will generate a concise version on the local terminal that can be verbally reported by on-site personnel via telephone, intercom, or other means to ensure that critical events can be transmitted in a timely manner.

[0132] Regarding manual verification and correction, the system allows on-site personnel to verify, supplement, or correct inspection conclusions and handling suggestions. Manual verification includes confirming the accuracy of the information, whether the issue has been addressed, whether escalation is needed, whether additional photos or video evidence is required, and whether support from the central platform is required. If the manual correction result differs from the offline agent's suggestion, the system retains both the original suggestion and the manual correction, writing both to the local log for subsequent model updates and rule optimization. This mechanism avoids offline agents providing incompletely applicable suggestions under special on-site conditions, while ensuring the traceability of the handling process.

[0133] Regarding the output format of handling suggestions, the system adapts to the type of terminal used. For inspection robots, the system outputs supplementary sampling tasks, key re-photograph locations, and anomaly marker information; for mobile inspection terminals, the system outputs textual inspection conclusions, operation lists, and manual confirmation entry points; for edge control terminals, the system outputs device linkage suggestions, event lists, and synchronization status; and for emergency response terminals, the system outputs simplified emergency procedures, traffic organization prompts, and reporting templates. Through multi-terminal adaptation, the same abnormal event can be handled collaboratively by different on-site roles.

[0134] Through the above processing, step A6 transforms the "risk level" into an "executable response plan." This step does not simply issue an alarm prompt, but rather automatically generates inspection conclusions, tiered response steps, temporary traffic organization suggestions, reporting texts, and manual confirmation requirements by combining local regulations, emergency plans, historical cases, on-site resources, and traffic constraints. This enables on-site personnel to complete emergency response according to standardized procedures even when the network is unavailable, and provides a complete basis for subsequent log recording, data synchronization, and strategy updates.

[0135] A7: Record the on-site handling process and results: In A7, after the system generates inspection conclusions and emergency response suggestions, the local offline intelligent agent records the entire process of on-site inspection findings, risk assessment results, response suggestions, manual confirmation opinions, actual response measures, and response results, forming a traceable, verifiable, and synchronizeable local log and evidence chain. The core of this step is to solve the problems in traditional tunnel operation and maintenance such as "discovery is recorded, but the response is not closed-loop," "manual response process is difficult to trace," and "data is easily missed when the network is offline." This enables the offline intelligent agent not only to assist in judgment and suggestions but also to completely record the on-site response process.

[0136] In terms of log object construction, the system establishes on-site handling records based on abnormal events as the basic unit. Each abnormal event, from identification, classification, suggestion, confirmation to handling completion, corresponds to a unique event number. An event log object can be represented as:

[0137] in, Indicates the first A local log object for each exception event. Indicates the event number. Indicates the time when the event occurred. Indicates the spatial location of the event. Indicates the event type, Indicates the risk level. This indicates the system-generated handling suggestions. This indicates that the information has been manually confirmed or corrected. Indicates the actual handling measures, This log object indicates the handling result. Through this log object, the system can bind the anomaly identification result with the actual handling process, avoiding the separation between inspection data, handling suggestions, and final results.

[0138] Regarding the recorded content, the system must record at least the following information: inspection task number, tunnel number, left / right tunnel or up / down direction, mileage marker, structural component or equipment number, abnormal event type, identified data source, defect parameters, risk level, judgment basis, handling suggestions, on-site personnel confirmation, actual handling steps, handling start time, handling completion time, handling personnel, on-site photos, video clips, sensor readings, equipment linkage status, and follow-up requirements. For emergency response events, the system also records traffic organization measures, equipment deployment status, reported content, on-site verification results, and whether the emergency status has been lifted.

[0139] Regarding the organization of the evidence chain, the system binds images, videos, sensor data, device status, human input, and agent reasoning results according to the same event number, forming a chain record of "data source—identification result—risk assessment—disposal suggestion—human confirmation—actual disposal—result feedback". The evidence chain can be represented as:

[0140] in, This represents the raw or pre-processed field data. This indicates the result of defect identification or anomaly detection. This indicates the risk classification results. Indicates the proposed handling, This indicates that the information needs to be confirmed manually. Indicates the actual handling measures, This indicates the outcome of the action. Through this chain structure, subsequent operation and maintenance personnel can trace which on-site data, which rules were followed, and which manual operations were used to arrive at a particular outcome.

[0141] Regarding on-site execution records, the system transforms the step-by-step operation list generated in step A6 into an execution record that can be checked, supplemented, and has evidence uploaded. After each operation is completed, on-site personnel can confirm it on a mobile terminal or edge terminal and upload on-site photos, short videos, text descriptions, or equipment readings. For example, for water accumulation anomalies, the system records whether drainage ditches have been inspected, drainage pumps have been started, warning signs have been set up, and the scope of water accumulation has been verified; for smoke anomalies, the system records whether the smoke location has been confirmed, the ventilation system has been activated, on-duty personnel have been notified, and traffic control measures have been implemented; for structural defects, the system records whether photos have been retaken, dimensions have been measured, markers have been set, and the issue has been included in subsequent maintenance plans.

[0142] In terms of handling status management, the system classifies each abnormal event into different handling statuses based on the on-site execution situation, including "Identified but not confirmed," "Confirmed and awaiting handling," "In progress," "Handled but awaiting review," "Completed," "Requires reporting," and "Requires tracking." The handling status transitions can be represented as follows:

[0143] in, Indicates the time of the event The status of handling This indicates the actions that have been performed so far. This indicates that the information has been manually confirmed or corrected. This indicates the updated processing status. Through the status transition mechanism, the system can determine whether an event has completed its closed loop, whether further processing is still needed, and whether it needs to be reported to the central platform first after connecting to the network.

[0144] For local storage, the system writes event logs, evidence files, and handling statuses to a local cache database. For text records, the system uses structured fields for storage; for large files such as images and videos, the system uses a file index bound to event numbers for storage; and for sensor sequences, the system stores them in slices according to event time windows. This ensures efficient local queries while avoiding the impact on terminal speed caused by directly embedding large amounts of data into logs.

[0145] Regarding network outage protection, the system sets local cache identifiers for all unsynchronized events and determines storage priorities based on risk level, event time, and handling status. For emergency responses, on-site handling, and events with incomplete closure, the system sets them as high-priority records, disallowing them from being overwritten by regular inspection caches. For events of general concern and those already handled, the system can compress or delay synchronization depending on storage space availability. If edge device storage space is insufficient, the system prioritizes retaining high-risk event logs, handling conclusions, key evidence, and manually confirmed information; low-risk video clips can be compressed and stored.

[0146] Regarding log integrity verification, the system performs field integrity checks on event logs to determine whether event number, time, location, risk level, handling suggestions, actual operations, and result status are missing. Log integrity scoring can be expressed as:

[0147] in, Indicates the first Completeness score of each event log. This indicates the number of key fields that have been filled in or automatically generated. This indicates the total number of key fields required for this type of event. When the completeness score is lower than the preset requirement, the system prompts on-site personnel to supplement photos, fill in the handling results, confirm the equipment status, or supplement manual explanations to avoid creating incomplete maintenance records.

[0148] Regarding feedback, the system automatically generates a closed-loop conclusion based on the on-site handling results. The closed-loop conclusion includes whether the anomaly has been resolved, whether further tracking is needed, whether specialized testing is required, whether repair and reinforcement are necessary, whether reporting to the central platform is required, and whether the inspection cycle needs adjustment. For events that have been handled, the system updates their status to "Completed" or "Completed pending tracking"; for events where the risk has not been completely eliminated, the system includes them in the subsequent inspection task queue and increases the priority of that section or equipment in the inspection task generation step A3.

[0149] Regarding manual correction records, the system fully retains the original judgment results of the offline agent and the correction opinions of on-site personnel. For example, if the system classifies a leakage event as a priority for monitoring, but on-site personnel confirm that the leakage volume has significantly increased and request escalation of treatment, the system simultaneously records the original risk level, the manual escalation opinion, the reason for the escalation, and on-site evidence. If the system identifies a suspected crack, but on-site personnel confirm it is a stain or construction mark, the system records the manual rejection result and corresponding photos. The above-mentioned manual correction information is uploaded to the central platform after networking and can be used for subsequent rule optimization and model retraining.

[0150] Regarding security record keeping, the system adds timestamps, device serial numbers, operator identifiers, and version numbers to key records to ensure clear log sources and traceable processes. For emergency response events, the system also records the time of each status change, each manual confirmation, and each handling operation, forming an event timeline. The event timeline includes the time of anomaly discovery, identification completion, risk classification, handling suggestion generation, manual confirmation, handling start time, handling completion time, and network synchronization restoration time, facilitating subsequent review of emergency response efficiency.

[0151] For local querying and display, the system establishes an index based on tunnel number, mileage marker, event type, risk level, handling status, and time range, enabling on-site personnel to query historical defects, events in adjacent sections, similar equipment failures, and unresolved issues even offline. For example, when inspection personnel enter a historical leakage section, the mobile terminal can automatically retrieve the section's historical records, previous handling results, and current inspection requirements; when equipment malfunctions again, the system can display the equipment's historical maintenance records and the most recent handling measures.

[0152] Through the above processing, step A7 establishes a site handling record and evidence chain management mechanism for offline operation and maintenance scenarios. This step does not simply save inspection results, but integrates anomaly identification, risk assessment, handling suggestions, on-site execution, manual correction, result feedback, and follow-up into a unified local log system. This ensures that tunnel operation and maintenance can still achieve process recording, handling evidence, result traceability, and synchronization after network restoration even under network outage conditions. This provides a complete data foundation for central platform review, model updates, responsibility tracking, and operation and maintenance management optimization.

[0153] A8: After restoring network connectivity, complete data synchronization and policy updates: In A8, once the network is restored by the on-site edge devices, inspection robots, mobile inspection terminals, or emergency response terminals, the system switches from local offline operation to network collaborative operation. It uploads inspection data, anomaly identification results, risk classification records, handling suggestions, manual confirmation opinions, on-site handling logs, and evidence chain data generated during the network outage to the central operation and maintenance platform. It also receives model parameters, knowledge base entries, emergency plan rules, and inspection strategy update packages from the central platform. The core of this step is resolving the issues of data consistency, policy consistency, and version consistency between the offline intelligent agent and the central platform, ensuring that on-site offline handling results can be integrated into a unified operation and maintenance management closed loop.

[0154] In terms of network recovery detection, the system periodically monitors network connectivity, bandwidth, latency, and packet loss using communication status monitoring units in edge devices. When the network status meets synchronization conditions, the system does not immediately upload all cached data in an unordered manner. Instead, it first enters a synchronization preparation state, performing integrity checks, priority sorting, and version comparisons on the local cached data. The network status can be represented as:

[0155] in, Indicates time The network status, Indicates the currently available bandwidth. Indicates network transmission delay. Indicates packet loss rate. Indicates the network stability status. When Higher than the minimum synchronization bandwidth Below the allowable delay Below the packet loss threshold and When the system is in a stable state, it initiates the network synchronization process; if the network only recovers briefly or is not stable enough, it prioritizes uploading high-risk event summaries and key logs.

[0156] Regarding data synchronization filtering, the system categorizes data to be synchronized based on the local logs, evidence chains, and handling status generated in step A7. High-priority data includes emergency response events, on-site handling events, events not yet closed, manually corrected events, equipment linkage anomaly events, and events involving traffic organization; medium-priority data includes key tracking events, historical disease recurrence events, and events requiring subsequent review; low-priority data includes events of general concern, routine inspection records, and completed inspection data without anomalies. The system forms synchronization queues according to risk level, handling status, data integrity, and event time to ensure that critical events are prioritized for transmission back to the central platform.

[0157] A synchronization queue can be represented as:

[0158] in, This represents the log queue to be synchronized. This represents the i-th local event log entry. Indicates risk priority. Indicates the priority of the handling status. Indicates log integrity priority. This indicates the time the event occurred. The system sorts events according to the principles of high risk, incomplete loop, high integrity, and recent occurrence time to avoid bandwidth consumption due to a large amount of low-risk data uploading during the initial network recovery phase, which could affect the transmission of emergency events.

[0159] Regarding data synchronization, the system categorizes data generated during network outages into five types for uploading: structured logs, unstructured evidence files, model inference results, manual correction records, and equipment status records. Structured logs include event number, time, location, risk level, handling status, and handling result; unstructured evidence files include images, videos, audio, on-site photos, and supplementary materials; model inference results include identification type, confidence level, defect parameters, and risk judgment basis; manual correction records include on-site personnel confirmation opinions, reasons for correction, and supplementary evidence; and equipment status records include sensor readings, electromechanical equipment operating status, linkage execution status, and fault codes.

[0160] During synchronization, the system adopts a "summary first, evidence later, result verification" approach. For high-risk events, an event summary, risk level, handling status, and abbreviated key evidence files are uploaded first, enabling the central platform to quickly grasp the on-site situation. Then, complete images, videos, sensor sequences, and handling process records are uploaded. Finally, the central platform returns confirmation and verification results. In the event of a network interruption, the system records uploaded data segments and synchronization breakpoints, resuming uploads once the network is restored to avoid duplicate transmissions or data loss.

[0161] Regarding the central platform's review, after receiving local offline data, the central platform reviews the event logs, handling results, and manual correction information. The review includes assessing the reasonableness of the risk level, whether the handling recommendations comply with regulations, whether the on-site handling was closed-loop, the completeness of the evidence chain, whether additional specialized testing is needed, whether it needs to be included in the maintenance plan, and whether subsequent inspection strategies need adjustment. The central platform can confirm, correct, or upgrade the initial judgment results of the offline intelligent agent and return the review conclusions to the on-site edge devices.

[0162] The results of the center's review can be expressed as follows:

[0163] in, Indicates the first The central review results of each event Indicates the risk level after review. This indicates the processing status after review. This indicates the requirements for subsequent processing. This indicates an update command generated by the central platform. If the central platform's review level is higher than the local offline judgment level, the system marks the event as requiring key review; if the central platform confirms that the handling has been completed, the system updates the local event status to synchronized and closed-loop.

[0164] Regarding strategy updates, the central platform incrementally updates the knowledge base, rule base, model base, and task templates of the local offline intelligent agent based on returned data, manual correction records, review results, and newly added operational experience. Updates include adding disease cases, revising risk thresholds, supplementing emergency response procedures, adjusting inspection priority weights, updating model parameters, replacing failed knowledge entries, and optimizing reporting templates. Update packages are not required to be distributed in full each time; instead, they are updated incrementally in the form of version numbers and difference packages to reduce data transmission pressure in weak network environments.

[0165] The local version update relationship can be represented as:

[0166] in, This indicates the updated local policy version. This indicates the local policy version before the update. This indicates an incremental update package issued by the central platform. An incremental update package must include at least the update type, scope of application, version number, release date, checksum, and rollback flag. Before installing the update package, the system performs an integrity check to ensure that the updated content is not corrupted and is compatible with the current device type, model version, and knowledge base version.

[0167] Regarding knowledge base updates, the system reconstructs local indexes for newly added standard clauses, operation and maintenance rules, emergency plans, equipment handling manuals, and historical cases. For structured rules, the system updates rule numbers, applicable conditions, trigger thresholds, and handling procedures; for text-based materials, the system performs local vectorization and index updates; for historical cases, the system re-labels them based on event type, risk level, handling measures, and outcome status. After the update is complete, the offline agent can access the latest knowledge resources during the next offline operation.

[0168] Regarding model updates, the system receives lightweight recognition model parameters or model files from the central platform and performs version replacements based on the computing power and storage conditions of edge devices. For devices with high computing power, such as inspection robots, higher-precision image or video recognition models can be updated; for resource-constrained devices, such as mobile terminals, compressed lightweight models can be updated. After the model update is completed, the system retains the previous version model as a rollback backup. If the new model fails to load, has excessively high inference latency, or produces abnormal recognition results during local self-checks, it automatically reverts to the previous stable version.

[0169] Regarding conflict handling, if there are inconsistencies between local offline judgment results, manual correction opinions, and central platform review opinions, the system does not directly overwrite the original records. Instead, it retains multiple versions of the judgment results and uses the central platform's review result as the subsequent management status. Simultaneously, it records the discrepancies as rule optimization samples. For example, if a local agent classifies a leakage event as a priority for tracking, on-site personnel believe on-site handling is necessary, and the central platform confirms after review that it should be escalated to on-site handling, the system retains all three types of judgment records and uses this event as a local risk classification rule correction sample for subsequent optimization.

[0170] Regarding synchronization completion confirmation, the system generates a synchronization status identifier for each event record, including not synchronized, synchronizing, uploaded, pending review, reviewed, closed loop, and synchronization failed. For data that fails to synchronize, the system records the reason for the failure, including network interruption, file corruption, version incompatibility, verification failure, or rejection by the central platform, and automatically adds it to the next round of synchronization queue. For events that have completed central review and confirmed closure, the system updates the local status to synchronized and closed loop, while retaining the local evidence index and the central platform receipt number.

[0171] Regarding subsequent inspection strategy adjustments, the system modifies the inspection task generation mechanism in A3 based on the review opinions and updated strategies returned by the central platform. For example, if a tunnel section experiences repeated leaks and the central platform confirms a developing trend, the system increases the inspection priority of that section, shortens the inspection cycle, and adds requirements for image re-taking and water stain range recording; if a certain type of equipment malfunctions frequently, the system increases the inspection frequency of that equipment and adds equipment operation status reading tasks; if a certain type of false alarm is confirmed by the central platform in large numbers, the system adjusts the local recognition threshold or adds manual review conditions.

[0172] Regarding security and access control, the system performs permission verification on uploaded data and distributed update packages. Field edge devices are only permitted to exchange data with the authorized central platform, and model, knowledge base, and rule update packages distributed by the central platform must include version signatures and verification information. For policy updates involving emergency response, traffic organization, and equipment linkage, the system requires higher-level management commands to prevent unauthorized policy modifications from affecting tunnel operational safety.

[0173] Through the above processing, step A8 achieves closed-loop collaboration between the offline agent and the central platform. This step is not a simple data upload, but a complete mechanism including network recovery detection, synchronization priority sorting, breakpoint resumption, central review, log closed-loop confirmation, knowledge base update, model update, rule update, and inspection strategy adjustment. Through this mechanism, the system ensures both the independence of on-site handling under no-network or weak-network conditions and the ability of the central platform to grasp the on-site situation, review the handling results, and update local agent strategies after network restoration, thus forming a continuous optimization closed loop of "offline autonomy—network synchronization—central review—strategy update—re-offline operation".

[0174] Figure 2 A comparison chart of inference latency of offline recognition models on different edge devices; Figure 3 This is a comparison chart of anomaly identification accuracy before and after multi-source evidence fusion; Figure 4 Statistical distribution chart of abnormal events at different risk levels; Figure 5 This diagram illustrates the priority and synchronization order of locally cached data during a network outage. Figure 6 A statistical chart showing the effect of offline autonomy and network synchronization closed-loop operation.

[0175] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure.

[0176] This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for tunnel operation and maintenance inspection and emergency response based on offline intelligent agents, characterized in that, The method includes the following steps: S1: Deploy an offline intelligent agent in the edge computing device at the tunnel site. The offline intelligent agent is equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. S2: Receive and preprocess multi-source sensing data of tunnel operation and maintenance through offline intelligent agents to obtain local inspection datasets; S3: Based on the local inspection dataset, calculate the priority of each inspection section and generate an inspection task list in descending order of priority. Calculate the locally executable inspection path for the inspection robot; The inspection robot collects inspection images based on a locally executable inspection path and sends them to a local cache database. S4: Retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. Calculate the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combine them into an abnormal event record. S5: Based on abnormal event records, determine the defect type, defect size, and location of the crack and compare them with the standard thresholds to obtain a hazard score and a development score; obtain the risk level by combining the hazard score and the development score. S6: Based on the risk level and the type of abnormal event, match the corresponding handling template from the local knowledge base, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form a manually selected operation list; S7: Based on the checklist results, the inspection images, risk levels, inspection conclusion texts, and manually selected actual operations are stored in sequence according to time, forming a local evidence chain indexed by the event number, and uploaded to the central operation and maintenance platform in order of risk level from high to low.

2. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 1, characterized in that, Step S1 includes: Initialize and detect the computing power, available memory, available storage space, input / output interfaces, and current network status of the edge computing device to determine the resource conditions of the edge computing device; Based on the resource conditions of the edge computing device, a suitable lightweight recognition model is selected from the candidate model library; The lightweight identification models include: crack identification model, leakage identification model, smoke detection model, water accumulation identification model, lining anomaly identification model, and equipment failure judgment model; Edge computing devices include: inspection robots, mobile inspection terminals, fixed camera equipment, infrared thermal imaging equipment, smoke sensors, water level sensors, temperature and humidity sensors, lighting systems, ventilation systems, fire protection systems, drainage equipment, and traffic monitoring equipment; Establish a local knowledge base, and incorporate tunnel operation and maintenance specifications, emergency plans, disease knowledge, equipment handling manuals, and historical cases into the local knowledge base; The inspection task planning, model invocation, knowledge retrieval, rule reasoning, emergency process invocation, and log generation are encapsulated into a local action set of the offline intelligent agent and written into the local knowledge base; Establish a local cache database to store inspection data, identification results, risk levels, handling suggestions, manual confirmation information, and on-site evidence under conditions of no network, weak network, or network outage.

3. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 2, characterized in that, Step S2 includes: Multi-source sensing data includes: inspection images, inspection videos, infrared thermal images, smoke concentration, water level, temperature and humidity, illuminance, wind speed, ventilation equipment status, lighting equipment status, drainage equipment status, fire-fighting equipment status, power supply and distribution equipment status, historical inspection records, maintenance work orders, historical damage records, and equipment ledgers. Preprocessing includes: establishing a unified index for multi-source sensing data according to tunnel number, left / right or up / down direction, tunnel mileage marker, lane location, structural part, equipment number, and acquisition time; performing sharpness filtering and distortion correction on each frame of image data in the multi-source sensing data; performing unit conversion and timestamp alignment on each group of sensor data in the multi-source sensing data; and evaluating the data quality of the multi-source sensing data. If the data quality evaluation is lower than a preset threshold, re-acquisition is performed. The preprocessed image data and sensor data are stored in a local cache database according to the acquisition time and tunnel mileage marker, forming a local inspection dataset.

4. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 3, characterized in that, Step S3 includes: The tunnel is divided into multiple inspection objects, each of which includes: tunnel section, mileage range, structural parts or equipment objects, historical defects, environmental influencing factors and preset inspection cycle. The priority of each inspection section is determined based on the severity of historical disease records, the degree of abnormality in the last inspection, the trend of disease development, current environmental disturbances, the degree of traffic impact, and the importance of equipment. An inspection task list is generated based on priority. The inspection task list includes: inspection section, inspection object, inspection content, equipment to be called, data collection method, data collection accuracy, abnormal triggering conditions, and local recording requirements. Based on the inspection section, the current location of the inspection robot, traffic conditions, remaining power, and priority, a locally executable inspection path is generated. When traffic is obstructed, the equipment power is insufficient, or there is a sudden abnormality on site, the locally executable inspection path is locally replanned.

5. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 4, characterized in that, Step S4 includes: The inspection images are extracted in batches from the local inspection dataset, scaled to the input size required by the lightweight recognition model, and then fed into the model to perform forward inference. Extract the bounding box coordinates and defect category probability of the defect region from the feature map output by the lightweight recognition model; The actual mileage location of the defect area in the tunnel is calculated by back-calculating the bounding box coordinates. Read the maximum width value of the crack or the area of ​​the leaking pixels from the segmentation results output by the lightweight recognition model; The defect category probability, actual mileage location, maximum width value, and pixel area are combined into an abnormal event record; The specific process of the lightweight recognition model performing forward inference includes: organizing the scaled inspection image into a four-dimensional tensor, wherein the dimensions of the four-dimensional tensor are batch size, image height, image width and number of channels, respectively. The model inference interface is called to input the four-dimensional tensor into the acceleration chip to perform matrix multiplication and addition operations. Three result tensors are obtained from the output: bounding box position tensor, defect category probability tensor, and segmentation mask tensor. The bounding box coordinates and defect category probabilities are obtained through the bounding box position tensor and the defect category probability tensor. The segmentation result is obtained through the segmentation mask tensor. The specific process of calculating the actual mileage location of the defect area in the tunnel based on the bounding box coordinates includes: Obtain the mileage marker corresponding to the inspection image frame. and image width Let the x-coordinate of the center point of the bounding box be... The actual mileage location of the defect. According to the formula Calculation, where This represents the mileage interval value corresponding to each pixel in the image. The specific process for reading the maximum width value of the crack includes: Extract the skeleton lines of the crack region from the segmentation results output by the lightweight recognition model, calculate the distance between the two edges of each crack point by point along the normal direction of the skeleton lines, and take the maximum value of the distance as the maximum width of the crack; if the maximum width of the crack exceeds the warning width threshold stored in the local knowledge base, add a width over-limit label to the abnormal event record.

6. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 1, characterized in that, Step S5 includes: Based on the abnormal event record, determine the defect type, defect size and occurrence location in this abnormal event record, and retrieve the specification threshold that matches the defect type and defect size from the local knowledge base; The defect size is compared with the specification threshold, and a risk score is assigned based on the comparison result; Find the defect size of the same location in the last inspection from the local knowledge base, and calculate the rate of change of defect size between the current abnormal event record and the last abnormal event record as the development score; The risk score and the developmental score are weighted and added together to obtain a comprehensive risk score. The risk level is determined based on the range of values ​​that the comprehensive risk score falls into. The specific process for calculating the rate of change of size between the current abnormal event record and the previous abnormal event record includes: Retrieve the previous abnormal event record with the same mileage station number and the same defect type from the local knowledge base; Extract the defect size from the previous anomaly event record. Let the defect size identified in this abnormal event record be... Then the rate of change According to the formula Calculation, where To prevent the smallest constant from having a denominator of zero; if If the development rate exceeds the threshold stored in the local knowledge base, the development rate score of this abnormal event record will be set to the highest level.

7. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 1, characterized in that, Step S6 includes: By using a local lightweight model, a video event detection model, a sensor anomaly judgment model, and equipment status recognition rules, cracks, leaks, smoke, water accumulation, lining anomalies, and electromechanical equipment failures are identified to obtain the types of abnormal events. Based on the risk level and the type of abnormal event, the corresponding handling template is matched from the local knowledge base to generate a standardized inspection conclusion text, and the pre-set operation steps in the handling template are listed one by one in order to form a manually selected operation list. The specific process of generating a standardized inspection conclusion text includes: Retrieves the conclusion template corresponding to the abnormal event type from the local knowledge base. The conclusion template contains multiple placeholders, including: location placeholder, type placeholder, size placeholder, risk level placeholder, and recommendation placeholder. Enter the actual mileage marker in the location placeholder, the defect category name in the type placeholder, the defect size value and unit in the size placeholder, the risk level name in the risk level placeholder, and the defect size in the suggestion placeholder. After piecing them together, you will get the complete inspection conclusion text.

8. The tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in claim 1, characterized in that, Step S7 includes: The offline intelligent agent detects the network connection status in real time. When it detects that the network has been restored and the bandwidth meets the conditions, it reads the local evidence chain that has not yet been uploaded from the local cache database. Local evidence chains are uploaded to the central operation and maintenance platform in descending order of risk level. After the upload is completed, wait for the platform to return confirmation information. If a model update file is received from the platform, the parameters of the lightweight recognition model are updated using the model update file.

9. A tunnel operation and maintenance inspection and emergency response system based on offline intelligent agents, used to implement the tunnel operation and maintenance inspection and emergency response method based on offline intelligent agents as described in any one of claims 1-8, characterized in that, The system includes: The system deployment module is used to deploy offline intelligent agents in edge computing devices at the tunnel site. The offline intelligent agents are equipped with a task scheduling engine, a lightweight recognition model, a local knowledge base, and a local cache database. The data acquisition module is used to receive multi-source sensing data of tunnel operation and maintenance through offline intelligent agents and preprocess it to obtain local inspection datasets; The data processing module is used to calculate the priority of each inspection segment based on the local inspection dataset, generate an inspection task list in descending order of priority, calculate the locally executable inspection path of the inspection robot, and collect inspection images based on the locally executable inspection path and send them to the local cache database. The abnormal event recording module is used to retrieve inspection images from the local cache database in batches and input them into the lightweight recognition model. It calculates the actual mileage location of the defect area, the probability of the defect category, the maximum width of the crack, and the pixel area of ​​the leakage, and combines them into an abnormal event record. The risk level assessment module is used to determine the defect type, defect size, and location of cracks based on abnormal event records, and compare them with standard thresholds to obtain a hazard score and a development score; the risk level is obtained by combining the hazard score and the development score. The operation list building module is used to match the corresponding handling template from the local knowledge base according to the risk level and abnormal event type, generate a standardized inspection conclusion text, and list the pre-set operation steps in the handling template in order to form an operation list for manual selection. The local evidence chain construction module is used to connect and store inspection images, risk levels, inspection conclusion texts, and manually selected actual operations in chronological order based on the checklist results on the operation list, forming a local evidence chain indexed by the event number, and then uploading it to the central operation and maintenance platform in descending order of risk level.

Images