Rail transit emergency disposal preplan systematization review and dynamic optimization method and device
By collecting and analyzing multi-source data, a closed-loop mechanism for emergency response plans for rail transit was constructed, which solved the problem of insufficient matching between the response strategies of the plans and real-time scenarios in the existing system, and realized the dynamic optimization of the plans and personalized emergency response.
Patent Information
- Application Number
- CN202611145533.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-30
- Publication Date
- 2026-11-03
AI Technical Summary
The existing rail transit emergency management system lacks a dynamic adjustment mechanism driven by multi-source data, resulting in insufficient matching between the emergency response strategy and the real-time scenario. The retrospective analysis has not established a complete closed loop, making it impossible to accurately identify differences in station characteristics and making it difficult to achieve collaborative optimization decisions across levels and disciplines.
By collecting and structuring multi-source data, a review record library is built to locate deviation periods and extract high-frequency co-occurrence features. Combined with multi-dimensional feature profiles and scenario-plan matching models, a set of candidate plans adapted to site characteristics is generated, and the plans are optimized and automatically updated.
It enables dynamic adjustment and precise adaptation of contingency plans, accurately identifies deviations in events, generates personalized emergency plans, and improves the accuracy of emergency response and the rationality of resource allocation.
Smart Images

Figure CN123031973A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of rail transit emergency management, specifically to a systematic review and dynamic optimization method for rail transit emergency response plans. Background Technology
[0002] In the field of rail transit emergency management, existing technologies have proposed various solutions to address the needs of emergency response. Chinese patent application CN117022409A (publication date: November 2023) discloses an urban rail transit emergency drill management platform. This platform manages drill equipment, scenario plans, and organizational processes through digital means, achieving full-process digitalization of emergency drills. While this platform improves the standardization of drills, its plan generation is still based on a pre-set, fixed scenario library, lacking the ability to adapt in real-time to dynamically changing personnel configurations, equipment conditions, environmental characteristics, and management features (i.e., "human-machine-environment-management" characteristics) in actual operation.
[0003] Chinese patent application CN119863132A (publication date: April 2025) proposes an emergency command system based on minimum critical tasks, which achieves tiered response by constructing a task item database and a risk perception system. However, its contingency plan optimization relies heavily on historical data matching and lacks a closed-loop review mechanism for execution deviations, resulting in contingency plan updates lagging behind actual needs.
[0004] The research paper "Research on Key Technologies of Digital Emergency Response Plan for Rail Transit Operation" (No. 3, 2024, Modern Information Technology) points out that although the existing digital emergency response plan system has achieved process visualization, it is insufficient in terms of root cause localization and feature profiling, making it difficult to accurately identify the causes of differentiated problems under different station environments.
[0005] The common problems with the above-mentioned technical solutions are: the lack of a dynamic adjustment mechanism driven by multi-source data in contingency plan optimization leads to insufficient matching between response strategies and real-time scenarios; the retrospective analysis mostly stays at the level of result evaluation and fails to establish a complete closed loop from deviation location to parameter optimization; and the use of static parameters for site feature characterization cannot reflect the real-time interactive impact of personnel, equipment, and the environment. When faced with the chain reaction of emergencies in large-scale networked operations, existing systems struggle to achieve cross-level and cross-professional collaborative optimization decisions. Summary of the Invention
[0006] To address the problems in the existing technology, this application provides a systematic review and dynamic optimization method for rail transit emergency response plans. It can realize a complete data link from deviation location to parameter optimization of the plan through a closed-loop review mechanism driven by multi-source data.
[0007] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a systematic review and dynamic optimization method for rail transit emergency response plans, including: collecting command and dispatch records, equipment operating status, environmental passenger flow parameters, and personnel operation feedback from station monitoring equipment, sensors, and emergency terminals; cleaning and aligning structured and unstructured data along the timeline to construct a review record library containing command action sequences, equipment response logs, passenger flow spatiotemporal distribution, and personnel operation trajectories; comparing the standard time nodes of the plan with the actual execution timestamps based on the review record library to locate the time difference, spatiotemporally associating personnel operation logs with passenger flow heatmaps, and extracting high-frequency co-occurrences through association rule mining. The system identifies the root causes of deviations and constructs a multi-dimensional feature profile of the site based on its static attributes, including personnel configuration, equipment conditions, environmental parameters, and management structure. The root causes and the multi-dimensional feature profile are then input into a scenario-plan matching model to generate a set of candidate plans adapted to the site's characteristics. Based on the candidate plan set and the root causes of deviations, optimization entries are generated by matching them according to a preset rule family. These optimization entries are then pushed to an approval node. Upon confirmation, the system synchronizes the updates to the corresponding site's plan response process and resource allocation parameters. The updated plan-driven instructions and resource scheduling are then implemented the next time a similar event is triggered.
[0008] Furthermore, it also includes: collecting command and dispatch recordings through the station service system and mobile terminal voice intercom interface, extracting key command words and corresponding timestamps through voice-to-text conversion; collecting gate obstruction rate logs through the automatic ticketing system; collecting broadcast trigger records through the broadcasting system; collecting equipment alarm logs through the integrated monitoring system; collecting real-time images through the video monitoring system, identifying passenger flow density through edge computing nodes to generate a passenger flow heat map, and converging the parameters collected by environmental sensors with the passenger flow heat map according to a preset collection cycle to form a structured feature vector.
[0009] Furthermore, it also includes: performing keyword matching verification on the collected voice text to remove invalid instruction fragments; parsing the equipment logs according to preset field templates to extract event types, timestamps, and equipment identifiers; performing outlier detection on the passenger flow heat map data and marking missing raster areas; aligning the cleaned data according to the time axis and writing it into the review record library with the station code as the primary key and the event occurrence time as the sorting key. The review record library is stored in four index partitions: instruction action sequence, equipment response log, passenger flow spatiotemporal distribution, and personnel operation trajectory.
[0010] Furthermore, it also includes: comparing the standard time nodes of the contingency plan in the review record library with the actual execution timestamps item by item to calculate the deviation, selecting the time period when the deviation exceeds the preset threshold condition as the deviation period, and spatially associating the personnel operation log entries within the deviation period with the passenger flow heat map grid of the corresponding time window; using an association rule mining algorithm to scan frequent itemsets of the associated operation-passenger flow data to extract the co-occurrence patterns of operation actions and passenger flow changes, and outputting the co-occurrence patterns whose support and confidence both exceed the preset threshold as the root causes of the deviation.
[0011] Furthermore, it also includes: extracting static attributes from the site's basic database, including the proportion of junior station staff in personnel characteristics, physical parameters of transfer channels and signal coverage area of handheld terminals in equipment characteristics, spatial parameters of channels and passenger flow conflict characteristics in environmental characteristics, and the number of inter-party linkages and standard time consumption of process nodes in management characteristics; dynamically adjusting the evaluation weights according to the current values of each feature in the static attributes, substituting the instance data in the review record library into the weight-adjusted multi-dimensional feature profile model to calculate the scores of each dimension and output the site feature vector.
[0012] Furthermore, it also includes: concatenating the category encoding of the root cause of the deviation with the site feature vector to form a matching input vector; calculating the fitness score for each candidate plan in the plan library using a pre-trained gradient boosting tree model; generating a preliminary plan selection list based on the fitness score in descending order; searching for the Pareto front solution set using a non-dominated sorting genetic algorithm with the fitness score, resource consumption, and response time as multiple objectives; and selecting a predetermined number of plans with the highest comprehensive ranking from the Pareto front solution set to form the candidate plan set.
[0013] Furthermore, it also includes: classifying the root causes of deviations into corresponding strategy matching types according to a preset decision tree; retrieving the optimization template associated with the type from the contingency plan strategy library and filling the variable fields of the template with site-specific parameters in the site feature vector to generate contingency plan optimization entries; pushing the contingency plan optimization entries to the contingency plan administrator terminal; after manual review and confirmation, synchronously deploying the updated contingency plan to the site emergency response terminal through the version control system; and automatically loading the updated contingency plan to drive the issuance of instructions when the next similar event is triggered.
[0014] Secondly, this application provides a systematic review and dynamic optimization device for rail transit emergency response plans, comprising: a multi-source data acquisition and structuring module, used to collect command and dispatch records, equipment operating status, environmental passenger flow parameters, and personnel operation feedback from station monitoring equipment, sensors, and emergency terminals, and to clean and align structured and unstructured data along the timeline to construct a review record library; a deviation location and root cause analysis module, used to locate deviation periods by comparing the standard time nodes of the plan with the actual execution timestamps based on the review record library, to spatiotemporally correlate personnel operation logs with passenger flow heatmaps, and to extract high-frequency co-occurrence features through association rule mining to determine the root cause of the deviation; and a multi-dimensional feature profile construction module, used to construct a multi-dimensional feature profile of the station based on the station's static attributes of personnel configuration, equipment conditions, environmental parameters, and management structure, and to analyze the deviations and root causes of the deviations. The system generates a set of candidate contingency plans adapted to the site characteristics by inputting the root causes of deviations and the site's multi-dimensional feature profile into the scenario-contingency plan matching model. The scenario-contingency plan adaptive matching module concatenates the category encoding of the root causes of deviations with the site feature vector to form a matching input vector, calculates the fit score using a pre-trained gradient boosting tree model, and selects a set of candidate contingency plans from the Pareto front solution set using a multi-objective optimization algorithm. The contingency plan optimization item generation and deployment module categorizes the root causes of deviations into strategy matching types according to a preset decision tree, retrieves optimization templates from the contingency plan strategy library, fills in site-specific parameters to generate contingency plan optimization items, and synchronously deploys them to the site's emergency response terminal after manual review and confirmation. The contingency plan dynamic loading and execution module automatically loads the updated contingency plan when the next similar event is triggered to drive instruction issuance and resource scheduling.
[0015] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the systematic review and dynamic optimization method for the rail transit emergency response plan.
[0016] Fourthly, this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the described method for systematic review and dynamic optimization of the rail transit emergency response plan system.
[0017] Fifthly, this application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the described method for systematic review and dynamic optimization of the rail transit emergency response plan system.
[0018] As can be seen from the above technical solutions, this application provides a systematic review and dynamic optimization method for rail transit emergency response plans. By constructing an "execution-review-optimization" closed-loop mechanism, it achieves dynamic adjustment and precise adaptation of the plan; through multi-source data integration and root cause analysis algorithms, it can accurately locate deviation links in the event process; through a human-machine-environment-management multi-dimensional feature profiling system, it can perform fine-grained characterization of station features, solving the problem of incompatibility between traditional plans and stations; through a scenario-plan adaptive matching algorithm, it can generate personalized emergency plans while considering different station characteristics; and through an artificial intelligence-based intelligent optimization decision-making mechanism, it can dynamically adjust the plan parameters according to the review analysis results and differences in station characteristics, achieving the accuracy of emergency response and the rationality of resource allocation. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.
[0020] Figure 1 This is a flowchart illustrating the systematic review and dynamic optimization method for rail transit emergency response plans in this application embodiment; Figure 2 This is a schematic diagram of the root cause analysis algorithm execution flow in the embodiments of this application; Figure 3 This is a schematic diagram of the execution flow of the scenario-plan matching algorithm in the embodiments of this application; Figure 4 This is a schematic diagram of the architecture of the multi-dimensional feature profiling system in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of the rail transit emergency response plan system review and dynamic optimization device in the embodiments of this application. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.
[0022] To systematically review and dynamically optimize emergency response plans for rail transit, this application provides an embodiment of a method for systematically reviewing and dynamically optimizing rail transit emergency response plans. This embodiment uses a scenario of sudden large-scale passenger congestion at a transfer station during a holiday as an example. This transfer station is a two-line transfer station, with a transfer passage length of 82 meters, a width of 2.1 meters, and a turning radius of 5 meters. See [link to relevant documentation] Figure 1 The method includes the following specific contents: Step S101: Collect command and dispatch records, equipment operating status, environmental passenger flow parameters and personnel operation feedback from site monitoring equipment, sensors and emergency terminals.
[0023] This step automatically initiates the data acquisition process after the contingency plan is completed. The acquisition pipeline pulls raw data in parallel from the following five types of data sources.
[0024] The station management system and mobile terminal provide command and dispatch recording files via a voice intercom interface. The audio stream is in mono format with a 16 kHz sampling rate. After processing by the speech-to-text module, key command words and corresponding timestamps are extracted. The command words are a sequence of operation command texts such as "start response", "close gate", and "guide passenger flow". The timestamp is the millisecond-level timestamp of the moment the instruction was issued. The automatic fare collection system outputs gate obstruction rate logs at a granularity of one minute. The data structure includes the gate number, time window start time, total number of people passing through the time window, number of obstructions, and obstruction rate fields. The obstruction rate is the ratio of the number of obstructions to the total number of people passing through.
[0025] The broadcast system outputs broadcast trigger records, each record containing the broadcast area identifier, broadcast content template number, trigger time, and playback duration. The integrated monitoring system exports device alarm logs categorized by preset alarm levels. Alarm log fields include device type, device identifier, alarm code, alarm level, and trigger timestamp.
[0026] The video surveillance system sends real-time footage to the edge computing nodes at a rate of 15 frames per second. These edge computing nodes are deployed in the site's communication room and utilize NVIDIA Orin NX edge computing modules, running target detection algorithms to identify pedestrian density in each frame.
[0027] The algorithm takes the pixel matrix of the input frame image (1920 pixels wide, 1080 pixels high, 3-channel red-green-blue order) and outputs the coordinates and confidence of each detection box through the feature extraction network. It maps the center point of the detection box to the preset channel grid coordinate system, counts the number of people in each grid, and generates a passenger flow heat map every 30 seconds.
[0028] The heat map is stored as a two-dimensional floating-point matrix, with rows and columns corresponding to grid coordinates, and element values taken as the head count within that grid. Environmental sensors include temperature and humidity sensors and carbon dioxide concentration sensors, reporting environmental parameter readings at 30-second intervals.
[0029] Step S102: Clean the structured and unstructured data and align them along the timeline to build a retrospective record library containing instruction action sequences, equipment response logs, passenger flow spatiotemporal distribution, and personnel operation trajectories.
[0030] Following the raw data collected in step S101, this step performs data cleaning and structuring processing. Keyword matching verification is performed on the speech-to-text output command word sequence. The command words are compared with the preset command word library. Command fragments with a matching degree lower than 0.7 are marked as invalid and removed, and the removal record is recorded in the data quality log.
[0031] The device logs are parsed according to the preset field templates, and the event type code, timestamp string and device identifier string are extracted using regular expressions. The timestamp string is converted into a unified timestamp data structure after formatting and validation. Records that fail validation are marked with a format exception label.
[0032] Outlier detection is performed on passenger flow heatmap data. The detection rules include: a single grid cell is marked as an outlier grid cell when the number of people exceeds the historical average for the same period by more than 3 standard deviations; a grid cell is marked as a missing grid cell when the value of a certain grid cell is always zero for 3 consecutive collection periods while the value of adjacent grid cells is non-zero.
[0033] Abnormal and missing raster records are written to the Raster Abnormality List field in the Data Quality Log. For rasters marked as abnormal, the weighted average of the values of adjacent rasters is used as the fill value, with the weight decaying by distance and a decay coefficient of 0.5.
[0034] The cleaned data is aligned along the timeline, with the alignment benchmark being the unified time of each data source's timestamp after calibration using the network time protocol. The data is written to the retrospective record database using the site code as the primary key and the event occurrence time as the sort key.
[0035] The retrospective record library is organized and stored using four types of index partitions: the instruction action sequence index area stores key instruction word sequences and timestamps; the device response log index area stores alarm and operating status logs of each device; and the passenger flow spatiotemporal distribution index area stores passenger flow heat maps and their raster metadata. The personnel operation trajectory index area stores personnel operation logs and handheld terminal interaction records. Foreign key relationships are established between different areas using event identifiers and timestamps.
[0036] Step S201: Based on the review record database, compare the standard time node of the contingency plan with the actual execution timestamp to locate the deviation period, and then spatially correlate the personnel operation log with the passenger flow heat map and extract high-frequency co-occurrence features through association rule mining to determine the root cause of the deviation.
[0037] This step uses the retrospective record library built in step S102 as the input data source. See also Figure 2 The standard time nodes for each operation step predefined in the contingency plan file are extracted one by one and compared with the actual execution timestamps in the instruction action sequence index area of the review record library.
[0038] The comparison method is as follows: for each plan step, the actual execution record is matched with the step number as the key, and the difference between the actual execution time and the standard time is calculated as the deviation. The deviation is a signed floating-point number in seconds. A positive value indicates execution lag, and a negative value indicates execution advance.
[0039] The time period during which the deviation exceeds a preset threshold is marked as the deviation period. The preset threshold is set as follows: the 95th percentile of the deviation of each step in three similar events in the history of the site is taken as the upper limit, and the 5th percentile is taken as the lower limit. Steps exceeding this range are marked as deviation items.
[0040] For each deviation period, extract the personnel operation log entries for that period, including the operator identifier, operation action type code, operation trigger time, and operation completion time; Simultaneously, extract the passenger flow heat map grid data for the corresponding time window, map the spatial coordinates of personnel operations (based on the positioning coordinates recorded by the handheld terminal) to the passenger flow heat map grid coordinate system, and associate the operation log entries with the passenger flow grid based on the nearest neighbor principle of spatial coordinates.
[0041] After association, operation-passenger flow data pairs are formed. Each data pair includes the operation action type, operator level, operation time, passenger flow density value of the associated grid, and passenger flow density change rate.
[0042] The frequent itemsets of the operation-passenger flow data pairs were scanned using an association rule mining algorithm. The minimum support threshold for frequent itemsets was set to 0.1, and the minimum confidence threshold was set to 0.6. Both thresholds were determined by taking the highest F1 value from the statistical analysis of historical treatment cases.
[0043] Co-occurrence patterns whose support and confidence both exceed the preset threshold, such as the co-occurrence combination of "the junior station staff's operation time is greater than 20 seconds and the corresponding grid passenger flow density increase rate is greater than 15% per second", are output as the root cause of the deviation after manual review and confirmation.
[0044] The deviation root cause data structure includes root cause category coding, associated operation type, associated personnel level, associated passenger flow characteristics, and confidence score fields.
[0045] Step S202: Construct a multi-dimensional feature profile of the site based on the site's static attributes, including personnel configuration, equipment conditions, environmental parameters, and management structure.
[0046] Following the root causes of deviations identified in step S201, this step loads static site attributes from the site's basic database to construct a feature profile. See also... Figure 4 .
[0047] The staffing data comes from the scheduling system. The statistics of job level distribution, average years of service and the proportion of junior station staff are extracted from the on-duty personnel in the current period. The proportion of junior station staff is the ratio of the number of junior positions to the total number of on-duty personnel, accurate to two decimal places.
[0048] The equipment condition data comes from the equipment management system. The physical parameters of the transfer channel (length, width, and turning radius, all in meters and rounded to one decimal place) and the signal coverage area of the handheld terminal (represented by the coordinate sequence of the vertices of the polygon in the area with a signal strength below -90 dB / mW) are extracted as features.
[0049] Environmental feature data comes from building information modeling and passenger flow analysis systems, and the spatial parameters of the passage (effective width of the passage, proportion of area occupied by fixed obstacles in the passage) and passenger flow collision characteristics (coordinates of the collision area, distribution of collision time period) are extracted.
[0050] The management feature data comes from the process management system, extracting the number of stakeholders (the total number of internal and external units involved in emergency response) and the standard time consumption of process nodes (the prescribed completion time of each standardized operation step, in minutes).
[0051] The evaluation weights are dynamically adjusted based on the current values of each feature in the static attributes. The adjustment mechanism takes the static attribute feature values as input and calculates the objective weights of the indicators in each dimension using the entropy weight method.
[0052] Specifically, when the proportion of junior station staff is detected to be greater than 30%, the weight of the response time sub-indicator in the personnel dimension is increased, so that the weight in the personnel dimension is adjusted from the initial 25% to the value automatically calculated based on the entropy value; when the effective width of the passage is less than 2.5 meters, the weight of the passenger flow guidance coverage sub-indicator in the environmental dimension is increased.
[0053] The magnitude of the weight adjustment is determined by the information entropy calculation result of the entropy weight method. The lower the information entropy, the greater the data difference of the indicator, and the higher the weight is assigned.
[0054] After weight adjustment, the instance data in the retrospective record library is substituted into the multidimensional feature profile model for scoring calculation. The model outputs a site feature vector, and each dimension of the vector takes a normalized score value between 0 and 1.
[0055] Feature vectors are stored as floating-point arrays, with dimensions representing personnel responsiveness score, equipment support capability score, environmental constraint score, and management collaboration score, respectively. Scoring results are written to the feature cache by site code, with a cache expiration time of 15 minutes, triggering a recalculation upon expiration.
[0056] Step S203: Input the root causes of the deviation and the multi-dimensional feature profile of the site into the scenario-plan matching model to generate a set of candidate plans adapted to the site features.
[0057] Following the root cause of the deviation output from step S201 and the site feature vector output from step S202, this step performs scenario-plan matching. (See also...) Figure 3 .
[0058] The category code of the deviation root cause (take the integer code value, such as equipment operation category, personnel configuration category, process connection category) is concatenated with the site feature vector to form a matching input vector. The first half of the vector is the feature dimension value, and the second half is the one-hot encoded representation of the root cause category code.
[0059] The matched input vector is fed into a pre-trained gradient boosting tree model. This model uses each candidate plan in the plan library as a classification label and uses the scene features and root cause labels of historical handling cases as training samples for supervised learning training.
[0060] The training data for the model consists of the following: each training sample is input by concatenating the site feature vector extracted from a historical event with the root cause category code, and the actual plan number used in the event is used as the label. The training adopts a log loss function and gradient boosting iterative strategy, with a learning rate of 0.1 and a tree depth limit of 6 layers.
[0061] After training, the gradient boosting tree model outputs a fit score for each candidate plan in the plan library. The score is a floating-point number between 0 and 1. The higher the score, the better the plan fits the current scenario-root cause combination.
[0062] Based on the suitability scores, a preliminary list of contingency plans is generated by sorting them in descending order. The length of the preliminary list is equal to the number of all candidate contingency plans in the contingency plan library.
[0063] The adaptation score, resource consumption, and response time are used as three optimization objectives to form a multi-objective optimization problem: resource consumption is the weighted sum of the number of personnel hours and equipment hours required to execute the plan, and response time is the sum of the standard time consumption of each step in the plan.
[0064] The non-dominated sorting genetic algorithm (NSGA-II) was used to perform multi-objective optimization search on the initial selection list. The population size was set to 50, the maximum number of generations was set to 100, the crossover probability was set to 0.9, and the mutation probability was set to 0.1.
[0065] The algorithm outputs a Pareto front solution set, from which the top 3 solutions in the comprehensive ranking are selected to form the candidate solution set. The candidate solution set is written into the memory cache in the form of a solution number list for reading in step S301.
[0066] Step S301: Based on the candidate plan set and the root cause of deviation, generate plan optimization entries according to a preset rule family, push the plan optimization entries to the review node, and after confirmation, synchronize them to the emergency plan system to update the plan response process and resource allocation parameters of the corresponding site.
[0067] This step reads the root causes of the deviation between the candidate plan set generated in step S203 and the output of step S201 as input.
[0068] The category encoding of the root cause of the deviation is input into a preset decision tree classifier. The decision tree uses the root cause category as the splitting attribute and the policy matching type as the leaf node label. The training data of the classifier is provided by a manually labeled policy matching case library.
[0069] The decision tree outputs the strategy matching type corresponding to the root cause of the deviation, including four types: equipment operation optimization, personnel configuration adjustment, process integration improvement, and composite optimization. The optimization template associated with this type is retrieved from the contingency plan strategy library.
[0070] The contingency plan strategy library is organized by strategy matching type. Each optimization template contains two parts: variable field placeholders and a fixed strategy description. The variable field placeholders are associated with site-specific parameter names. During population, the actual values of the corresponding parameters are extracted from the site feature vector and filled into the variable fields of the template.
[0071] For example, in the device operation optimization class template, the variable fields include shortcut key mapping key values and voice broadcast command text. The fill values are respectively the result of adding 1 to the maximum number of used key values in the site device configuration table and the preset guidance text in the site passenger flow management.
[0072] After the data is filled in, contingency plan optimization entries are generated. Each optimization entry includes an optimization item number, the corresponding contingency plan step number, a summary of the configuration before optimization, the configuration content after optimization, and a reason for the change. These optimization entries are then assembled into an approval message and pushed to the contingency plan administrator's terminal.
[0073] The contingency plan administrator terminal is a workstation deployed in the site control center. The review interface displays the configuration changes before and after optimization in a difference comparison view, and has two preset operation buttons: Confirm Effectiveness and Revert Modifications. After the contingency plan administrator performs manual confirmation, the status field of the review message is updated to "Confirmed".
[0074] Confirmed contingency plan optimization items are automatically synchronized to the emergency response plan system via the version control system, updating the contingency plan response process description files and resource allocation parameter configuration files for the corresponding sites. The contingency plan response process description files are stored in Extensible Markup Language (EXPLAIN) format, and the resource allocation parameter configuration files are stored in key-value pair format.
[0075] The synchronization operation adopts an incremental update strategy, replacing the changed paragraphs at the granularity of the plan step number. After the synchronization is completed, a consistency check is triggered. If the check fails, the version before synchronization is rolled back and the rollback event is registered in the operation log.
[0076] Step S302: When the same type of event is triggered again, issue instructions and schedule resources with the updated plan.
[0077] Following the plan synchronization update operation completed in step S301, this step realizes the automatic activation and execution of the updated plan.
[0078] The contingency plan system maintains an event type discriminator at the event trigger entry point. The event type discriminator takes the event type code carried in the event trigger signal as input and matches it with the corresponding contingency plan version record in the contingency plan library. When matching, the latest confirmed contingency plan with the latest version number is selected first.
[0079] Once the matched contingency plan version passes integrity verification (checking the existence of all referenced resource identifiers in the contingency plan file and whether the time constraints of each step meet the overall consistency requirement), it is loaded into the contingency plan execution engine in memory. The contingency plan execution engine drives the issuance of emergency response instructions using a step-by-step state machine model.
[0080] The state machine defines four states for each step: ready, in progress, completed, and exception. The steps are connected by a temporal dependency.
[0081] After the current step is completed, the engine determines the next activation step based on the step output code and preset transfer conditions. The instruction message for the next step is encapsulated according to the preset communication protocol and pushed to the corresponding execution terminal through the message queue telemetry transmission protocol. The terminal includes a handheld terminal, a broadcast controller, and a gate controller.
[0082] Each instruction message includes a step number, execution terminal identifier, instruction action code, instruction parameter list, and issuance timestamp fields. During execution, each terminal returns execution status data according to a preset reporting period. The status data includes terminal identifier, current step number, execution progress percentage, and error code fields.
[0083] The contingency plan execution engine continuously collects the execution status data and compares it with the contingency plan standard progress baseline. When the execution progress of any terminal lags behind the standard progress baseline by more than a preset threshold, the engine triggers resource scheduling adjustment and selects available resources from the alternative resource pool for supplementary scheduling.
[0084] The alternative resource pool is organized into a resource directory with resource type, resource location and current occupancy status as fields. When supplementing scheduling, the nearest available resource is selected in ascending order of spatial distance from the target site.
[0085] When an incident is resolved and a similar incident is triggered again, the contingency plan execution engine automatically loads the updated version of the contingency plan. The updated contingency plan parameters drive a new round of emergency response instructions and resource scheduling, forming a complete closed loop of "execution-review-optimization-re-execution".
[0086] New execution data generated during the process will be automatically imported into the debriefing record database, providing a data foundation for the next round of debriefing analysis.
[0087] To further illustrate the technical solution of this application, this application also provides an embodiment of an apparatus for implementing the systematic review and dynamic optimization method for the rail transit emergency response plan. See also... Figure 5 The device includes: a multi-source data acquisition and structuring module, used to collect command and dispatch records, equipment operating status, environmental passenger flow parameters, and personnel operation feedback from site monitoring equipment, sensors, and emergency terminals; cleans structured and unstructured data and aligns it along the timeline to build a review record library; a deviation location and root cause analysis module, used to locate deviation periods by comparing the standard time nodes of the plan with the actual execution timestamps based on the review record library; spatiotemporally correlates personnel operation logs with passenger flow heatmaps and extracts high-frequency co-occurrence features through association rule mining to determine the root cause of the deviation; and a multi-dimensional feature profile construction module, used to construct a multi-dimensional feature profile of the site based on the site's static attributes, including personnel configuration, equipment conditions, environmental parameters, and management structure; and inputs the root cause of the deviation and the multi-dimensional feature profile of the site into the system. The system includes: a scenario-plan matching model to generate a set of candidate plans adapted to site characteristics; a scenario-plan adaptive matching module to concatenate the category codes of the root causes of deviations with the site feature vectors to form a matching input vector, calculate the fit score using a pre-trained gradient boosting tree model, and select a set of candidate plans from the Pareto front solution set using a multi-objective optimization algorithm; a plan optimization item generation and deployment module to classify the root causes of deviations into policy matching types according to a preset decision tree, retrieve optimization templates from the plan policy library, fill in site-specific parameters to generate plan optimization items, and synchronously deploy them to the site emergency response terminal after manual review and confirmation; and a plan dynamic loading and execution module to automatically load the updated plan when the same type of event is triggered again to drive instruction issuance and resource scheduling.
[0088] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the systematic review and dynamic optimization method for the rail transit emergency response plan.
[0089] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the described method for systematic review and dynamic optimization of the rail transit emergency response plan.
[0090] This application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the aforementioned method for systematic review and dynamic optimization of rail transit emergency response plans.
[0091] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A systematic review and dynamic optimization method for rail transit emergency response plans, characterized in that, include: The system collects command and dispatch records, equipment operating status, environmental passenger flow parameters and personnel operation feedback from site monitoring equipment, sensors and emergency terminals. The structured and unstructured data are cleaned and aligned along the time axis to build a review record library that includes command action sequences, equipment response logs, passenger flow spatiotemporal distribution and personnel operation trajectories. Based on the review record database, the deviation period is located by comparing the standard time node of the contingency plan with the actual execution time stamp. The personnel operation log is spatiotemporally correlated with the passenger flow heat map, and high-frequency co-occurrence features are extracted through association rule mining to determine the root cause of the deviation. Based on the personnel configuration, equipment conditions, environmental parameters and management structure of the site's static attributes, a multi-dimensional feature profile of the site is constructed. The root cause of the deviation and the multi-dimensional feature profile of the site are input into the scenario-contingency plan matching model to generate a set of candidate contingency plans adapted to the site characteristics. Based on the candidate plan set and the root cause of the deviation, plan optimization entries are generated by matching according to a preset rule family. The plan optimization entries are pushed to the review node. After confirmation, they are synchronized to the emergency plan system to update the plan response process and resource allocation parameters of the corresponding site. When the same type of event is triggered again, the updated plan-driven instructions are issued and resources are scheduled.
2. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The collection of command and dispatch records, equipment operating status, environmental passenger flow parameters, and personnel operation feedback from site monitoring equipment, sensors, and emergency terminals includes: The system collects command and dispatch recordings through the station administration system and mobile terminal voice intercom interface, extracts key command words and corresponding timestamps through voice-to-text conversion, collects gate obstruction rate logs through the automatic ticketing system, collects broadcast trigger records through the broadcast system, and collects equipment alarm logs through the integrated monitoring system. The system collects real-time images through a video surveillance system, identifies pedestrian density through edge computing nodes, and generates a passenger flow heat map. The parameters collected by environmental sensors are then combined with the passenger flow heat map according to a preset collection cycle to form a structured feature vector.
3. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The process of cleaning structured and unstructured data and aligning it along the timeline to construct a review record library containing instruction action sequences, equipment response logs, passenger flow spatiotemporal distribution, and personnel operation trajectories includes: The system performs keyword matching and validation on the collected voice and text data to remove invalid instruction fragments; it parses and extracts event types, timestamps, and device identifiers from the device logs according to preset field templates; and it performs outlier detection and marks missing grid areas on the passenger flow heat map data. The cleaned data is aligned according to the timeline and written into the retrospective record library with the site code as the primary key and the event occurrence time as the sorting key. The retrospective record library is stored in four categories of index partitions: instruction action sequence, equipment response log, passenger flow spatiotemporal distribution, and personnel operation trajectory.
4. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The process of locating the deviation period by comparing the standard time node of the contingency plan with the actual execution timestamp based on the review record database, and determining the root cause of the deviation by spatiotemporally associating personnel operation logs with passenger flow heatmaps and extracting high-frequency co-occurrence features through association rule mining includes: The deviation is calculated by comparing the standard time nodes of the contingency plan in the review record library with the actual execution timestamps. The time period in which the deviation exceeds the preset threshold is marked as the deviation period. The personnel operation log entries in the deviation period are spatially correlated with the passenger flow heat map grid of the corresponding time window. The association rule mining algorithm is used to scan frequent itemsets of the associated operation-passenger flow data to extract co-occurrence patterns of operation actions and passenger flow changes. Co-occurrence patterns whose support and confidence both exceed the preset threshold are output as root causes of bias.
5. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The construction of a multi-dimensional feature profile of a site based on its static attributes, including personnel configuration, equipment conditions, environmental parameters, and management structure, includes: Static attributes were extracted from the site's basic database, including the proportion of junior station staff in personnel characteristics, physical parameters of transfer channels and signal coverage area of handheld terminals in equipment characteristics, spatial parameters of channels and passenger flow collision characteristics in environmental characteristics, and the number of inter-party collaboration and standard time consumption of process nodes in management characteristics. The evaluation weights are dynamically adjusted based on the current values of each feature in the static attributes. The instance data in the retrospective record library is substituted into the weight-adjusted multidimensional feature profile model to calculate the scores of each dimension and output the site feature vector.
6. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The step of inputting the root causes of the deviation and the multi-dimensional feature profile of the site into the scenario-plan matching model to generate a set of candidate plans adapted to the site features includes: The category encoding of the root cause of the deviation is concatenated with the site feature vector to form a matching input vector. A pre-trained gradient boosting tree model is used to calculate the fit score for each candidate plan in the plan library. The plan is then sorted in descending order based on the fit score to generate a preliminary list of plans. Using the fitness score, resource consumption, and response time as multiple objectives, a non-dominated sorting genetic algorithm is used to search for the Pareto front solution set. From the Pareto front solution set, a preset number of plans with the highest comprehensive ranking are selected to form the candidate plan set.
7. A systematic review and dynamic optimization method for rail transit emergency response plans as described in claim 1, characterized in that, The process of generating optimization entries by matching the candidate plan set with the root causes of deviation according to a preset rule family, pushing the optimization entries to the review node, and synchronizing them to the emergency plan system to update the corresponding site's plan response process and resource allocation parameters after confirmation includes: The root causes of deviations are classified into corresponding strategy matching types according to a preset decision tree. The optimization template associated with the type is retrieved from the contingency plan strategy library, and the variable fields of the template are filled with the site-specific parameters in the site feature vector to generate contingency plan optimization entries. The optimized contingency plan items are pushed to the contingency plan administrator terminal. After manual review and confirmation, the updated contingency plan is synchronously deployed to the site emergency response terminal through the version control system. When a similar event is triggered again, the updated contingency plan is automatically loaded to drive the issuance of instructions.
8. A systematic review and dynamic optimization device for rail transit emergency response plans, characterized in that, The device includes: a multi-source data acquisition and structuring module, used to collect command and dispatch records, equipment operating status, environmental passenger flow parameters, and personnel operation feedback from site monitoring equipment, sensors, and emergency terminals; and to clean and align structured and unstructured data along the timeline to build a review record library; a deviation location and root cause analysis module, used to locate deviation periods by comparing the standard time nodes of the contingency plan with the actual execution timestamps based on the review record library; to spatiotemporally correlate personnel operation logs with passenger flow heatmaps and extract high-frequency co-occurrence features through association rule mining to determine the root cause of the deviation; and a multi-dimensional feature profile construction module, used to construct a multi-dimensional feature profile of the site based on the site's static attributes, including personnel configuration, equipment conditions, environmental parameters, and management structure; and to input the root cause of the deviation and the multi-dimensional feature profile of the site into the system. The scenario-plan matching model generates a set of candidate plans adapted to the site characteristics; the scenario-plan adaptive matching module is used to concatenate the category encoding of the deviation root causes with the site feature vector to form a matching input vector, calculate the fitness score using a pre-trained gradient boosting tree model, and select the set of candidate plans from the Pareto front solution set through a multi-objective optimization algorithm; the plan optimization item generation and deployment module is used to classify the deviation root causes into strategy matching types according to a preset decision tree, retrieve optimization templates from the plan strategy library and fill in site-specific parameters to generate plan optimization items, and synchronously deploy them to the site emergency response terminal after manual review and confirmation; the plan dynamic loading and execution module is used to automatically load the updated plan when the next similar event is triggered to drive the issuance of instructions and resource scheduling.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the systematic review and dynamic optimization method for rail transit emergency response plans as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the systematic review and dynamic optimization method for rail transit emergency response plans as described in any one of claims 1 to 7.
Citation Information
Patent Citations
Urban rail transit emergency drill management platform
CN117022409A
Rail transit emergency command method and system based on minimum key task item
CN119863132A
