An offline data model-based cooperative subway vehicle base emergency safety dispatch management system

Abstract

The present application belongs to the technical field of urban rail transit emergency dispatching and offline data processing, and discloses a subway vehicle depot emergency safety dispatch management system based on offline data model cooperation, which comprises an offline data encapsulation and version checking module, a depot emergency knowledge graph construction module, a field state trusted calibration module, a safety constraint propagation and resource determination module, a multi-target emergency dispatch generation module, and a joint control order and traceability update module. The system encapsulates vehicle, track, turnout, signal machine, power supply section, maintenance task and post personnel data through unified resource coding, constructs a depot emergency knowledge graph, propagates safety constraints according to field state credibility and relationship type, generates a safety available resource set, determines a target dispatch scheme through constraint perception beam search and disturbance scene deduction, automatically forms joint control records and emergency orders, and realizes resource verification, dispatch calculation and record traceability under the condition of power failure and network interruption.

Description

Technical Field

[0001] This invention belongs to the field of urban rail transit emergency dispatch and offline data processing technology, specifically involving an emergency safety dispatch management system for subway vehicle depots based on offline data model collaboration. Background Technology

[0002] The metro depot is responsible for parking, maintenance, preparation, scheduling, marshalling, and receiving / departing of electric trains. Its dispatching and emergency response processes need to comprehensively consider the train maintenance release status, vehicle malfunction status, track occupancy status, switch positions, signal status, traction power supply sections, operating train schedules, emergency repair tasks, and personnel status. When the depot experiences a large-scale power outage, switch malfunction, vehicle malfunction, signal malfunction, abnormal track occupancy, or depot communication interruption, it is necessary to simultaneously determine available trains, available tracks, available routes, emergency repair personnel, emergency repair paths, and emergency repair protection zones while ensuring train operation safety, and to form a non-interfering train receiving / department dispatching plan and emergency repair response plan. Therefore, it is necessary to establish an emergency safety dispatching management system that can operate independently under the conditions of online system failure and local equipment failure.

[0003] Problems existing in the current technology: (1) The existing vehicle depot dispatch system mainly adopts the online centralized deployment method. The system operation depends on the server, communication network, integrated monitoring system and power supply monitoring system. Large-scale power outages can easily cause simultaneous interruption of data access, resource query, dispatch calculation and dispatch order generation. Switch failure, vehicle failure and signal failure can easily cause some equipment status to fail to be synchronized in time. The existing system lacks an offline data model that pre-encapsulates basic data, resource association, emergency repair personnel capabilities, emergency repair routes, safety protection zones, historical emergency cases, traffic safety rules and business templates. It is difficult to continue to complete the coordinated dispatch of vehicles, tracks, routes, emergency repair tasks and emergency personnel in the event of power outages, network interruptions and partial equipment failures.

[0004] (2) Existing offline emergency response mainly relies on paper ledgers, ordinary spreadsheets and manual communication. There is a lack of unified resource coding and associated topology between multiple data tables. It is impossible to identify contradictory information based on the credibility of the on-site status. It is also impossible to propagate the safety impact of power supply failure, track occupation, turnout lock-up, signal failure, vehicle non-release and changes in repair progress to related routes, train dispatching tasks and repair tasks. At the same time, there is a lack of mechanisms for screening excellent repair personnel, judging repair path conflicts and setting up repair protection zones. Problems such as train dispatching routes crossing repair areas, dispatching operations occupying repair channels, and mismatch between the professional capabilities of repair personnel and the type of fault are prone to occur. This results in long manual verification time, resource conflicts easily occur in candidate solutions, and it is difficult to quickly reconstruct dispatching plans and repair plans by combining emergency cases from previous years. Summary of the Invention

[0005] To address the issues that existing online dispatching systems cannot function properly after large-scale power outages, switch malfunctions, vehicle malfunctions, signal malfunctions, abnormal track occupancy, and communication interruptions at subway depots, and that manual emergency response suffers from slow resource status analysis, incomplete identification of associated safety risks, inaccurate matching of repair personnel, interference between dispatching and repair tasks, and difficulty in tracing business records, this invention provides a subway depot emergency safety dispatching management system based on offline data model collaboration.

[0006] This invention provides an emergency safety dispatch management system for subway vehicle depots based on offline data model collaboration, including an offline data encapsulation and version verification module, a depot emergency knowledge graph construction module, a field status reliability calibration module, a safety constraint propagation and resource determination module, a multi-target emergency dispatch generation module, and a joint control order and traceability update module.

[0007] The offline data encapsulation and version verification module acquires basic information of electric trains, operating schedules, track layouts, turnout locations, signal locations, traction power supply sections, vehicle fault records, maintenance plans, emergency repair tasks, emergency repair personnel capabilities, emergency repair equipment, emergency repair routes, emergency repair protection zones, and historical emergency cases from the metro vehicle depot. It forms an emergency data package according to the unified resource code and verifies the data version, field integrity, and model association integrity when the emergency data package is activated.

[0008] In some implementation schemes, emergency data packages include a basic data model, an emergency knowledge graph model, a field status model, a safety constraint model, a dispatch optimization model, and a business document model. These six types of offline data models establish a collaborative relationship through unified resource coding, unified status coding, unified time stamps, and unified task numbers. Historical emergency cases are written into the basic data model and the dispatch optimization model according to the fault type, fault location, affected resources, repair personnel, repair equipment, handling plan, handling duration, and handling results.

[0009] In some implementation schemes, the offline data encapsulation and version verification module includes a data import unit, an encoding unification unit, an offline encapsulation unit, a version verification unit, and a backup recovery unit. The offline encapsulation unit encapsulates basic data snapshots, entity node tables, relationship edge tables, security rule tables, historical emergency case tables, emergency repair personnel capability tables, emergency repair path tables, dispatch parameter tables, business document templates, and operation log templates into emergency data packages.

[0010] The depot emergency knowledge graph construction module sets electric passenger trains, tracks, switches, signals, traction power supply sections, train reception and dispatch tasks, emergency repair tasks, emergency repair personnel, emergency repair equipment, emergency repair routes, and emergency repair protection zones as entity nodes. It establishes relationship edges based on occupancy relationships, connection relationships, power supply relationships, fault relationships, release relationships, route relationships, conflict relationships, hostile relationships, prerequisite relationships, professional matching relationships, route accessibility relationships, protection and isolation relationships, dispatch relationships, and joint control relationships, generating a depot emergency knowledge graph that can run on offline terminals.

[0011] In some implementation schemes, the parking lot emergency knowledge graph construction module generates a relation index table based on the starting node code, relation type code, and ending node code, and generates an adjacency index based on the direct adjacent nodes and second-level adjacent nodes corresponding to the entity nodes. When the on-site status changes, only the calculation area corresponding to the target entity node and its adjacency relationship is updated, avoiding repeated traversal of all parking lot resources during fault handling.

[0012] The on-site status reliability calibration module receives the status of power supply section, track occupancy, turnout, signal, vehicle malfunction, train maintenance, emergency repair, train release, emergency repair personnel on-duty status, emergency repair equipment availability, and on-duty personnel status. Based on the status source, recording time, dual-post confirmation results, on-site emergency repair feedback, field integrity, and consistency of associated status, it calculates the on-site status reliability and adds data items with contradictory statuses and insufficient reliability to the list to be reviewed.

[0013] In some implementations, the field status trusted calibration module divides the resources corresponding to the field status into trusted resources, restricted resources, and resources to be verified. Resources to be verified do not participate in automatic dispatching and emergency repair task allocation, while restricted resources enter the subsequent safety constraint propagation process after completing manual verification.

[0014] In some implementation schemes, the field status credibility calibration module matches the current fault type, impact range, and resource status with historical emergency cases. Based on the actual handling results in the historical emergency cases, it calibrates the field status credibility, the degree of impact of safety rules, and the estimated repair time. The historical case matching results are then sent to the safety constraint propagation and resource determination module and the multi-target emergency dispatch generation module.

[0015] The safety constraint propagation and resource determination module loads the abnormal states corresponding to power outage sections, faulty switches, faulty signals, faulty vehicles, occupied tracks, trains not yet released, personnel not on duty, and obstructed repair paths into the depot emergency knowledge graph. First, it filters out unusable entity nodes based on hard safety conditions. Then, it performs iterative propagation of relation type perception based on the target entity node's own trustworthiness, the unavailability of adjacent entity nodes, relation edge types, and safety rule violation states to calculate the safety availability of electric trains, tracks, routes, train arrival and departure tasks, repair tasks, repair personnel, and repair paths.

[0016] In some implementation schemes, the safety constraint propagation and resource determination module ranks emergency repair personnel based on fault type, professional capabilities, historical success rate of handling, estimated arrival time, current workload, and continuous operation time. It selects personnel with high emergency repair suitability from those with corresponding professional capabilities and who are available for deployment, avoiding the determination of emergency repair personnel solely based on whether personnel are on duty.

[0017] In some implementations, the security constraint propagation and resource determination module configures different relationship type weights for power supply relationships, occupancy relationships, route relationships, conflict relationships, hostile relationships, fault relationships, professional matching relationships, path accessibility relationships, protection isolation relationships, and personnel relationships. It performs convergence judgment based on the degree of change between two adjacent propagation results and generates a set of safe and available resources, a set of restricted resources, and a set of prohibited resources based on security availability.

[0018] In some implementation schemes, the safety constraint propagation and resource determination module divides emergency resources into safety isolation resources, emergency repair and disposal resources, vehicle dispatching resources, and information control resources. It first locks the tracks, switches, routes, repair paths, and protection zones required for fault isolation and emergency repair protection, and then generates a set of vehicle dispatching resources from the remaining resources, so that the occupancy status of emergency repair and disposal resources can be propagated to the associated dispatching resources.

[0019] The multi-objective emergency dispatch generation module generates candidate resource combinations of train-track-route-personnel and fault object-repair personnel-repair equipment-repair path-repair protection zone based on the train reception task, train departure task, emergency repair task, task priority and safe available resource set. It also generates candidate resource combinations of fault object-repair personnel-repair equipment-repair path-repair protection zone through constraint perception bundle search to eliminate candidate schemes that have duplicate resource occupation, operation time conflict, simultaneous establishment of hostile routes, simultaneous establishment of mutually exclusive routes, unreserved trains participating in departure, train reception and departure routes crossing the repair protection zone, and dispatch operations blocking the repair path.

[0020] In some implementation plans, the multi-target emergency dispatch generation module sets up a repair protection zone based on the fault location and the scope of the repair operation. A safety buffer zone is reserved outside the repair protection zone. When there is spatial overlap between the vehicle pick-up and dispatch route and the repair protection zone, simultaneous execution is prohibited. When there is temporal overlap between the vehicle pick-up and dispatch route and the repair route, the dispatch time and the repair passage time are adjusted so that the repair task and the vehicle pick-up and dispatch task are spatially isolated or temporally staggered.

[0021] In some implementation schemes, the multi-objective emergency dispatch generation module calculates the impact of candidate vehicle pick-up and dispatch routes on the repair path. When a candidate vehicle pick-up and dispatch route occupies the repair vehicle lane, the repair equipment transport lane, and the personnel evacuation lane, the corresponding candidate scheme is marked as a prohibited scheme. When a candidate vehicle pick-up and dispatch route is close to the repair protection zone but has not entered the safety buffer zone, the corresponding candidate scheme is marked as a restricted scheme and on-site joint control conditions are added.

[0022] In some implementation schemes, the multi-objective emergency dispatch generation module establishes disturbance scenarios for power supply failure sections expanding, turnout manual locking, signal continuous failure, track temporary occupation, vehicle failure expansion, train release status cancellation, repair path obstruction, and key personnel exit. It then simulates the task delay, repair time, and re-dispatch requirements of candidate schemes under each disturbance scenario. Based on the operation delay, safety risk, resource conflict, repair interference, amount of manual intervention, and scenario disturbance loss, it selects the target dispatch scheme, backup dispatch scheme, target repair scheme, and backup repair scheme.

[0023] In some implementation schemes, the multi-objective emergency dispatch generation module matches the candidate repair schemes corresponding to the current fault with the handling schemes in historical emergency cases. It determines the reference order of cases based on the consistency of fault type, similarity of fault location, degree of overlap of affected resources, and historical handling efficiency, and uses the actual handling results to adjust the selection of repair personnel, configuration of repair equipment, repair route, and estimated repair time.

[0024] The joint control and dispatching order and traceability update module maps the target dispatch plan and target emergency repair plan to the train receiving dispatch and joint control page, the train departure dispatch and joint control page, the emergency repair task page, and the emergency dispatching order page. It generates train receiving and dispatching joint control records, vehicle dispatch joint control records, maintenance release notices, emergency repair orders, emergency dispatching orders, and emergency repair protection zone records. It also records the operator, the confirming personnel, the selected emergency repair personnel, the operation time, the content before modification, the content after modification, and the reason for modification.

[0025] In some implementation schemes, the joint control dispatch and traceability update module receives confirmation results submitted by the duty officer, the joint control officer, and the person in charge of emergency repair. When the two confirmation results for the dispatch task are consistent and the person in charge of emergency repair confirms that the dispatch plan will not affect the emergency repair operation, the dispatch task is updated to be allowed to be executed. When the confirmation results are inconsistent and the person in charge of emergency repair raises a path conflict, the dispatch task is updated to be suspended and the corresponding resource status is returned to the on-site status trusted calibration module for recalibration.

[0026] In some implementation plans, the joint control and dispatch order and traceability update module records the time of emergency repair order generation, the selection results of outstanding emergency repair personnel, the arrival time of emergency repair personnel, the time of emergency dispatch generation, the joint control process of vehicle reception and dispatch, the process of emergency repair plan adjustment, the actual time of emergency repair completion, the completion status of vehicle reception and dispatch tasks, and the efficiency of emergency response, forming an event chain that links dispatch tasks and emergency repair tasks.

[0027] In some implementation plans, after the emergency repair task is completed, the actual cause of the failure, the actual personnel used, the actual equipment used, the actual repair route, the adjustment of the protected area, the actual handling time, the number of shift adjustments and the handling results are written into the historical emergency case. When a similar failure occurs in the future, the updated historical emergency case will be used for on-site status calibration, safety availability assessment and emergency repair plan selection.

[0028] In some implementation schemes, the system runs on an offline terminal with independent power supply capability. The offline terminal is equipped with an offline table calculation environment, which includes the system main interface page, basic dictionary page, train maintenance and release page, on-site status entry page, train reception dispatch and joint control page, train departure dispatch and joint control page, emergency repair task page, emergency dispatch order page, model calculation page, and operation log page.

[0029] In some implementation schemes, the offline spreadsheet computing environment uses Excel office software. Each page establishes data associations through structured tables, data validation, cross-table indexing, conditional operations, conditional formatting, and protected calculated cells. Emergency data verification, historical case matching, security constraint propagation, emergency repair personnel screening, candidate solution calculation, business document generation, and operation log recording can be completed without calling external servers and external networks.

[0030] The beneficial effects of this invention are as follows: (1) By leveraging the offline collaborative relationships between the basic data model, emergency knowledge graph model, on-site status model, safety constraint model, dispatch optimization model, and business document model, the system can independently complete vehicle base resource verification, emergency dispatch, and business document generation even under conditions of large-scale power outages and network interruptions, thus solving the technical problem that the online dedicated dispatch system cannot continue to work after a power outage.

[0031] (2) The relationship between power supply sections, tracks, switches, signals, electric trains, maintenance tasks and train dispatching tasks is expressed through the emergency knowledge graph of the depot. The multi-level impact of abnormal states is calculated by using the safety constraints of relationship type perception. This enables the automatic identification of unavailable resources and associated risk tasks, solving the problem that manual item-by-item querying of ledgers makes it difficult to completely identify cross-resource safety risks.

[0032] (3) By constrained perception bundle search and multi-disturbance scenario deduction, target dispatch plan and backup dispatch plan are generated. A closed-loop record is formed by double post confirmation, joint control record, emergency dispatch order and operation log, so as to simultaneously improve the efficiency of emergency dispatch, the anti-disturbance capability of the plan and the completeness of operation traceability, and solve the problems of low efficiency of manual dispatch, high resource conflict rate and incomplete emergency response record. Attached Figure Description

[0033] Figure 1 This is a diagram illustrating the overall structure of the subway vehicle depot emergency safety dispatch management system of the present invention. Figure 2 This is a flowchart illustrating the emergency safety dispatch process of the present invention. Figure 3 This is a collaborative relationship diagram of the offline data model of the present invention. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention.

[0035] In the embodiments provided in this specification, data processing operations without specific technical specifications are implemented in accordance with the Urban Rail Transit Vehicle Depot Dispatch and Management Procedures, and offline terminals, power supplies, and storage media without specified models are all conventional products that can be obtained through legitimate channels.

[0036] The following embodiments use a large-scale power outage at the subway depot, with the integrated monitoring system, power supply monitoring system, dedicated dispatch system and depot communication network all simultaneously shut down as a special application scenario. The offline terminal uses a portable computer with an independent battery. An Excel spreadsheet calculation environment is pre-installed in the offline terminal and emergency data packets are stored. No data connection is established with an external server during the power outage.

[0037] The emergency data package in the following embodiments includes a basic data model, an emergency knowledge graph model, a field status model, a safety constraint model, a dispatch optimization model, and a business document model. These six types of offline data models establish a collaborative relationship through unified resource coding, unified status coding, unified time stamping, and unified task numbering.

[0038] The basic data model records the fixed attributes of electric trains, tracks, switches, signals, traction power supply sections, maintenance plans, operating train numbers, and personnel. The emergency knowledge graph model records the topological relationships and business dependencies between entities corresponding to the fixed attributes. The field status model records the manual verification results and status credibility after a power outage. The safety constraint model records the train operation safety conditions that must be met during the dispatching process. The dispatching optimization model generates train receiving and dispatching plans and train departure plans. The business document model generates joint control records, release notices, and emergency dispatch orders.

[0039] The Excel workbook contains the following pages: system main interface, basic dictionary, train maintenance and release, on-site status entry, train reception dispatch and control, train departure dispatch and control, emergency dispatch order, model calculation, and operation log. Each page uses structured tables, data validation, INDEX function, MATCH function, VLOOKUP function, SUMPRODUCT function, conditional formatting, and protected calculated cells to establish offline calculation relationships.

[0040] Example 1, see Figures 1-3 This invention provides an emergency safety dispatch management system for subway vehicle depots based on offline data model collaboration, including an offline data encapsulation and version verification module, a depot emergency knowledge graph construction module, a field status reliability calibration module, a safety constraint propagation and resource determination module, a multi-target emergency dispatch generation module, and a joint control and dispatch order and traceability update module. During normal power supply at the vehicle depot, the offline data encapsulation and version verification module acquires basic information of electric passenger trains, operating schedules, track layouts, turnout locations, signal locations, traction power supply sections, maintenance plans, and personnel information. It then forms emergency data packets according to the unified resource code and verifies the data version, field integrity, and model association integrity when the emergency data packets are activated. The depot emergency knowledge graph construction module sets electric passenger trains, tracks, switches, signals, traction power supply sections, maintenance tasks, train reception and dispatch tasks, and personnel as entity nodes. It establishes relationship edges based on occupancy relationships, connection relationships, power supply relationships, maintenance relationships, release relationships, route relationships, conflict relationships, pre-requisite relationships, dispatch relationships, and joint control relationships, generating a depot emergency knowledge graph that can run on offline terminals. The on-site status credibility calibration module receives the power supply section status, track occupancy status, turnout status, signal status, train maintenance status, and personnel on-duty status filled in by the on-site status entry page. Based on the status source, recording time, double-post confirmation results, field integrity, and consistency of related status, it generates the on-site status credibility and marks data items with contradictions. The safety constraint propagation and resource determination module loads the abnormal states corresponding to power outage sections, faulty equipment, occupied tracks, unreserved trains, and absent personnel into the depot emergency knowledge graph. Based on the safety impact direction of different relation edges, it performs constraint propagation with relation type perception to obtain the safety availability of each electric passenger train, track, route, and train arrival / departure task. The multi-objective emergency dispatch generation module filters out resource combinations that do not meet the hard safety conditions based on safety availability, generates multiple candidate dispatch schemes for receiving vehicles and dispatching vehicles through constraint perception bundle search, and selects the target dispatch scheme based on response time, risk exposure, resource conflicts, amount of manual intervention and scene disturbance loss. The joint control and dispatching order and traceability update module maps the target dispatching plan to the train receiving dispatching and joint control page, the train departure dispatching and joint control page, and the emergency dispatching order page. It automatically generates the corresponding train receiving and dispatching joint control records, maintenance release notices, and emergency dispatching orders, and writes the operator, confirming personnel, operation time, content before modification, content after modification, and reason for modification to the operation log page.

[0041] This system does not simply use Excel functions to perform field lookups. Instead, it establishes a collaborative processing chain between a basic data model, an emergency knowledge graph model, a field status model, a safety constraint model, a dispatch optimization model, and a business document model in an offline spreadsheet computing environment. When the field status changes, the safety constraints propagate along the power supply relationship, occupancy relationship, route relationship, and conflict relationship in the knowledge graph. The dispatch optimization model regenerates candidate solutions based on the propagation results, and the business document model updates the dispatch records and dispatch order content synchronously.

[0042] The emergency safety dispatch management method of this system specifically includes the following steps.

[0043] Step S1: The offline data encapsulation and version verification module reads the pre-stored emergency data packet and verifies the data version, resource code, field integrity, relationship edge integrity, and document template status. If the verification passes, proceed to step S2. If the verification fails, call the read-only backup emergency data packet for re-verification.

[0044] In step S2, the depot emergency knowledge graph construction module reads entity records and relationship records from the basic data model to construct a depot emergency knowledge graph connecting electric trains, tracks, switches, signals, traction power supply sections, maintenance tasks, train reception and dispatch tasks, and personnel in their posts.

[0045] In step S3, the on-site status credibility calibration module receives the on-site verification data, generates the on-site status credibility based on the status source, recording time, dual-position confirmation results, field integrity, and associated status consistency, and adds data items with insufficient credibility to the list to be reviewed.

[0046] In step S4, the on-duty personnel perform a second verification on the data items in the checklist. The on-site status credibility calibration module updates the on-site status model with the second verification results. Data items that have not completed the second verification remain in a restricted use state.

[0047] In step S5, the safety constraint propagation and resource determination module loads the abnormal status on site into the parking lot emergency knowledge graph, propagates the safety impacts of power supply failure, track occupancy, equipment lock-up, maintenance not allowed, and personnel absence along the relationship edges, and generates a set of safe and available resources.

[0048] Step S6: The multi-target emergency dispatch generation module generates candidate dispatch plans based on the vehicle reception task, vehicle departure task, task priority, and set of safe and available resources. It performs hard safety constraint verification, scenario disturbance simulation, and comprehensive target calculation, and outputs the target dispatch plan.

[0049] In step S7, the on-duty personnel and the joint control personnel conduct dual-post confirmation of the target dispatch plan. If the confirmation fails, the new on-site verification result is returned to step S3. If the confirmation passes, the joint control dispatch order and traceability update module generates a joint control record, a release notice and an emergency dispatch order.

[0050] Step S8: After power is restored, export the dispatch record, on-site status record, joint control record, emergency dispatch order and operation log, write the execution results into the emergency sample library and update the next version of the emergency data package.

[0051] Example 2: Based on all the above examples, the offline data encapsulation and version verification module specifically includes a data import unit, an encoding unification unit, an offline encapsulation unit, a version verification unit, and a backup recovery unit.

[0052] During normal operation of the vehicle depot, the data import unit exports basic data snapshots from the integrated monitoring system, power supply monitoring system, maintenance management system, and dedicated dispatch system. The basic data snapshots include vehicle number, vehicle type, train formation status, maintenance status, release status, track number, effective track length, track occupancy status, turnout number, turnout position, signal number, signal display status, power supply section code, section power supply status, operating train number, planned train reception time, planned train departure time, driver number, and joint control post number.

[0053] The unified coding unit establishes a unified resource code based on the resource category code, vehicle base code, and resource sequence code. Among them, the electric passenger train code consists of the vehicle category field and the car number field, the track code consists of the depot area field and the track number field, the power supply section code consists of the substation field and the feeder section field, and the train arrival and departure task code consists of the operation date field, the task category field, and the train number field.

[0054] The offline encapsulation unit encapsulates basic data snapshots, entity node tables, relationship edge tables, security rule tables, dispatch parameter tables, business document templates, and operation log templates into emergency data packages. The emergency data packages are stored simultaneously in the working directory of the offline terminal and in read-only removable storage media. The emergency data packages in the working directory are responsible for on-site data entry and calculation processing, while the emergency data packages in the read-only removable storage media are responsible for backup recovery in case of file corruption.

[0055] When the system starts, the version verification unit checks the emergency data packet version number, generation date, applicable vehicle base code, number of worksheets, number of required fields, number of entity nodes, number of relation edges, and template identifier in sequence. If any of the checked items is inconsistent with the registered value on the version registration page, the system main interface will display a version verification failure and lock the dispatch generation entry.

[0056] After version verification fails, the backup recovery unit reads the latest complete version from the read-only removable storage medium and saves the field status data after the failure to a temporary field status table. After the backup version is loaded, the temporary field status table is re-imported to avoid the loss of the verified field status during the file recovery process.

[0057] In this embodiment, the emergency data package is updated once every natural day. When track adjustments, turnout maintenance, train dispatching, and power supply section adjustments occur at the vehicle depot, incremental updates are performed immediately. Incremental updates only modify the entity node records and relation edge records that have changed, and retain the previous version.

[0058] Regarding the adjustment of offline data encapsulation parameters, the validity period of basic data in emergency data packets is controlled at 24 hours, the validity period of maintenance release status is controlled at 4 hours, the validity period of power supply section status is controlled at 30 minutes, and the validity period of on-duty personnel status is controlled at one shift. Data that exceeds the corresponding validity period will be automatically marked as pending review after emergency activation.

[0059] Example 3: Based on all the above examples, the parking lot emergency knowledge graph construction module specifically includes an entity node generation unit, a relationship edge generation unit, a topology index unit, an incremental update unit, and an abnormal relationship marking unit.

[0060] The entity node generation unit generates electric train nodes, track nodes, turnout nodes, signal nodes, traction power supply section nodes, maintenance task nodes, train reception and departure task nodes, and personnel nodes based on the unified resource code in the basic dictionary page. Each entity node is configured with node code, node category, fixed attributes, current status, status time, status source, confirmation personnel, and status credibility fields.

[0061] The relation edge generation unit establishes the occupancy relation edges between the electric train node and the track node, the connection relation edges between the track node and the turnout node, the route relation edges between the turnout node and the signal node, the power supply relation edges between the track node and the traction power supply section node, the maintenance relation edges between the electric train node and the maintenance task node, the dispatch relation edges between the electric train node and the train arrival and departure task node, the execution relation edges between the train arrival and departure task node and the on-duty personnel node, and the conflict relation edges between mutually exclusive routes.

[0062] The topology index unit generates a relation index table according to the start node code, relation type code, and end node code, and generates an adjacency index based on the direct adjacent nodes and second-level adjacent nodes corresponding to each node. When propagating security constraints, the adjacency index is read directly, and all basic data is not retraced at the power outage site, thereby reducing the computing load of offline terminals.

[0063] The incremental update unit receives the status change records output by the field status reliable calibration module, locates the target entity node according to the resource code, and only updates the calculation area corresponding to the target entity node and its adjacency relationship. The unaffected entity nodes retain the original calculation results, reducing the repeated calculations caused by frequent field corrections of track status and equipment status.

[0064] The abnormal relationship marking unit identifies, based on the safety rule table, the contradictions between the power supply section and the track power supply, the contradictions between the track occupancy status and the train parking status, the contradictions between the maintenance release status and the departure task, the contradictions between the turnout position and the route, and the contradictions between the personnel qualification and the work task, and marks the corresponding relationship edge as the blocking relationship edge.

[0065] In this embodiment, the parking lot emergency knowledge graph is stored in the form of a worksheet. Each row of the entity node table corresponds to an entity node, and each row of the relation edge table corresponds to a directed relation edge. The graph calculation does not depend on the network graph database. The offline terminal reads the adjacency index through the INDEX and MATCH functions and aggregates the security impacts corresponding to different relation types through the SUMPRODUCT function.

[0066] This embodiment is applied to a vehicle depot with 30 electric passenger trains, 36 parking tracks, 14 sets of key turnouts, 18 key signal machines and five traction power supply sections. The constructed depot emergency knowledge graph includes 125 entity nodes and 486 relation edges. After the emergency data package is started, the entity node table and adjacency index can be loaded within 12 seconds.

[0067] Regarding the adjustment of the emergency knowledge graph parameters in the depot, the power supply relationship, occupation relationship, route relationship and conflict relationship that directly affect the safety of train movement are set as strong constraints, and the personnel relationship, shift relationship and operation sequence relationship that affect the efficiency of task execution are set as scheduling constraints. When a strong constraint relationship is abnormal, the corresponding resource combination is directly blocked. When a scheduling constraint relationship is abnormal, the resource combination is retained and the scheduling cost of the candidate solution is increased.

[0068] Example 4: Based on all the above examples, the on-site status reliable calibration module specifically includes a status entry unit, a source classification unit, a time-effect decay unit, an association verification unit, a dual-position confirmation unit, and a checklist generation unit.

[0069] The status entry unit sets up status bars for power supply section, track occupancy, turnout, signal, train maintenance, train release, and on-duty personnel on the on-site status entry page. Each status bar uses preset drop-down options and prohibits on-duty personnel from entering undefined status text.

[0070] The source classification unit divides the status sources into five levels: system snapshot before power outage, paper maintenance record, dispatch telephone record, on-site single-person verification, and on-site dual-person verification. On-site dual-person verification has the highest basic credibility, while the credibility of the system snapshot before power outage gradually decreases according to the duration after the fault occurs.

[0071] The time-decrease unit adjusts the basic reliability based on the time difference between the status record time and the current dispatch calculation time. The power supply section status and track occupancy status are processed as short-cycle status, the maintenance release status is processed as medium-cycle status, and the train fixed attribute and track fixed attribute are processed as long-cycle status.

[0072] The correlation verification unit uses the depot emergency knowledge graph to check the physical consistency between status records. When a track is recorded as idle but there is still a train occupancy relationship on the corresponding track, the track occupancy status is marked as contradictory. When a train is recorded as not having completed maintenance but the departure task page records it as available for dispatch, the train release status is marked as contradictory.

[0073] The dual-position confirmation unit requires the duty officer and the joint control officer to enter the personnel number and confirm the key status. The key status includes the boundary of the power outage section, the position of the manually locked turnout, the occupied track, the maintenance of trains that have not been released, and the emergency train dispatch route. When the two confirmation results are consistent, the status credibility is improved. When the two confirmation results are inconsistent, the corresponding resource is prohibited from entering the safe and available resource set.

[0074] The unit generating the list to be reviewed sorts the data to be reviewed according to the credibility of the status and the level of safety impact. It prioritizes displaying the power supply sections, tracks, switches, signals and electric trains that are directly connected to the current train dispatching task, and displays the number of data to be reviewed and the corresponding resource codes on the main interface of the system.

[0075] In this embodiment, the credibility of the status verified by two on-site personnel and passing the association verification is set to 0.95, the credibility of the status verified by a single person on-site and passing the association verification is set to 0.80, the credibility of the status of paper records that have not expired is set to 0.75, the credibility of the status of system snapshots before power outages that have not expired is set to 0.70, and the credibility of data with contradictory associations is limited to below 0.40.

[0076] In this embodiment, resources with a status credibility of 0.85 are included in the trusted resource set, resources with a status credibility between 0.60 and 0.85 are included in the restricted resource set, and resources with a status credibility below 0.60 are included in the resource set to be reviewed. Resources in the resource set to be reviewed do not participate in automatic shift assignment.

[0077] Example 5: Based on all the above examples, the security constraint propagation and resource determination module specifically includes a hard constraint screening unit, a relation type weight configuration unit, a graph state propagation unit, a convergence determination unit, and a resource classification unit.

[0078] The hard constraint screening unit first executes deterministic safety rules. Tracks with confirmed power outages, tracks with unconfirmed occupancy, trains under maintenance that have not been released, switches with unconfirmed positions, signals with unconfirmed status, and work tasks with mismatched personnel qualifications are directly marked as unavailable. Hard constraint screening can prevent probability calculation results from covering the bottom line of train operation safety.

[0079] The graph state propagation unit performs relation type-aware iterative propagation on entity nodes that have passed the hard constraint screening. Unlike the processing method that judges resource availability based on only a single table field, the graph state propagation unit simultaneously considers the target node's own trust status, the unavailability of adjacent nodes, relation edge types, and security rule violation status, and calculates the node's security availability according to Formula 1:

[0080] In Formula 1, Let be the security availability of the i-th entity node after the (l+1)th propagation. The security availability value ranges from zero to one. The safe availability of adjacent entity nodes after the lth propagation; A logical mapping function that restricts the propagation result to the interval between zero and one; Basic bias coefficient; q_i is the adjustment coefficient for the state of the entity node itself; q_i is the field state reliability of the i-th entity node calculated by the field state reliability calibration module. It is the set of adjacent entity nodes that have a direct relationship edge with the i-th entity node; The relation type weight for the j-th entity node pointing to the i-th entity node; The relation type is the corresponding edge; K is the number of security rules; Let k be the influence coefficient of the k-th safety rule; This represents the violation status of the i-th entity node against the k-th security rule. It is set to zero if there is no violation and one if there is a violation.

[0081] The process of propagating security constraints specifically includes the following steps.

[0082] Step T1: Read the entity nodes that have passed the hard constraint screening and write the field status credibility into the initial security availability of each entity node.

[0083] Step T2: Based on the relationship type weight configuration unit, read the power supply relationship weight, occupancy relationship weight, route relationship weight, conflict relationship weight, maintenance relationship weight, and personnel relationship weight.

[0084] Step T3: Update the safety availability of each entity node according to Formula 1, and propagate the abnormal status of the power supply section node to the track node, route node, train node, and train reception / departure task node in sequence.

[0085] Step T4: Compare the changes in security availability obtained from two adjacent propagations. If the maximum change reaches the convergence condition, proceed to step T5. If the maximum change does not reach the convergence condition, return to step T3 to continue propagation.

[0086] Step T5: Divide the entity nodes into secure and available nodes, restricted-use nodes, and prohibited-use nodes according to their security availability, and generate a secure and available resource set based on the secure and available nodes.

[0087] Step T6: Receive the new status record sent by the field status trusted calibration module. If a new status record exists, update the corresponding entity node and return to step T1. If no new status record exists, send the set of safe and available resources to the multi-target emergency dispatch generation module.

[0088] In this embodiment, the weight of power supply relationship is set to 0.85, the weight of occupancy relationship is set to 0.95, the weight of route relationship is set to 0.90, the weight of conflict relationship is set to 1.00, the weight of maintenance relationship is set to 0.80, and the weight of personnel relationship is set to 0.65. Nodes with a safety availability of not less than 0.80 are classified as safe and available nodes, nodes with a safety availability between 0.60 and 0.80 are classified as restricted nodes, and nodes with a safety availability of less than 0.60 are classified as prohibited nodes.

[0089] The convergence determination unit compares the maximum change in security availability between two adjacent propagations with 0.01. If the maximum change in security availability is less than 0.01, propagation stops. When the number of iterations reaches twenty, propagation is forcibly stopped and the non-converged nodes are added to the list of nodes to be reviewed.

[0090] Regarding the adjustment of safety constraint propagation parameters, the weight of power supply relationship is controlled at 0.80 to 1.00, the weight of occupancy relationship is controlled at 0.90 to 1.00, the weight of route relationship is controlled at 0.85 to 1.00, the weight of maintenance relationship is controlled at 0.70 to 0.90, and the weight of personnel relationship is controlled at 0.50 to 0.75. Relationship types that directly affect the safety of train movement have a higher weight than personnel relationship, so as to avoid the weakening of safety constraints caused by power supply, track occupancy and route conflict by job allocation factors.

[0091] Example 6: Based on all the above examples, the multi-target emergency dispatch generation module specifically includes a task sorting unit, a candidate resource combination unit, a constraint perception bundle search unit, a scene disturbance inference unit, a comprehensive target calculation unit, and a target scheme output unit.

[0092] The task sequencing unit determines the task order based on the impact level of mainline operation, planned arrival and departure times, train passenger status, rescue task status, and subsequent route occupancy. Among them, rescue tasks and mainline first-shift follow-up tasks have high priority, and under the same priority, they are sorted according to the planned operation time.

[0093] The candidate resource combination unit selects electric trains, tracks, routes, and personnel from the set of safe and available resources to form a four-element candidate combination of train-track-route-personnel. Then, it checks the train maintenance and release conditions, track effective length conditions, power supply section availability conditions, route connectivity conditions, mutually exclusive route conflict conditions, and personnel qualification conditions in sequence.

[0094] The constraint perception bundle search unit uses the task ranking results as the search level. For each new train arrival / departure task, it retains a preset number of schemes with lower overall costs and deletes schemes that have issues such as duplicate resource occupation, time window conflicts, simultaneous establishment of mutually exclusive routes, and trains not yet released for departure. This narrows the search range of candidate schemes under the condition of limited computing power of offline terminals.

[0095] The scenario disturbance simulation unit replicates candidate dispatch schemes for five disturbance scenarios: expansion of power supply fault section, manual locking of turnout, temporary occupation of track, cancellation of train release status, and withdrawal of key personnel. It then re-executes safety constraint propagation and calculates the task delay and re-dispatch requirements of the candidate dispatch schemes under each disturbance scenario.

[0096] The integrated target calculation unit calculates the integrated scheduling cost of the candidate shift assignment schemes according to Formula 2:

[0097] In Formula 2, Candidate dispatching schemes The overall scheduling cost; M is the total number of train arrival and departure tasks; m is the sequence number of the train arrival and departure tasks; Normalized operation delay for the m-th vehicle pick-up and dispatch task in the candidate dispatch scheme; Normalized safety risks arising from the train nodes, track nodes, route nodes, and personnel nodes associated with the m-th train arrival and departure task; The resource conflict cost corresponding to the m-th vehicle pick-up and dispatch task; The number of manual reviews and adjustments required for the m-th vehicle arrival / departure task; A set of preset disturbance scenarios; The task completion rate loss of the candidate dispatch scheme in the s-th perturbation scenario compared to the undisturbed state; Weighting for task delays; Weighting for safety risks; As resource conflict weight; Weights are determined by human intervention. The scene perturbation weights.

[0098] The multi-target emergency dispatch generation process specifically includes the following steps: Step T1: Read the vehicle reception task, vehicle departure task, task priority, and set of available safe resources, and generate a task sequence according to the task priority and planned operation time.

[0099] Step T2 generates a candidate combination of train-track-route-personnel that meets the hard safety conditions for the first train arrival / departure task in the task sequence.

[0100] Step T3: Add the quaternary candidate combinations to the partial dispatch schemes, calculate the current scheduling cost of the partial dispatch schemes, and retain the twenty partial dispatch schemes with lower scheduling costs.

[0101] Step T4: Add the next pick-up and departure task according to the task sequence, delete some dispatch schemes with duplicate resource occupation and mutual exclusion route conflicts, and continue to retain the twenty dispatch schemes with lower scheduling costs until all pick-up and departure task combinations are completed.

[0102] Step T5: Perform five types of scenario disturbance simulations on the complete candidate dispatch schemes, and calculate the comprehensive scheduling cost according to Formula 2.

[0103] Step T6: Select the candidate dispatch scheme with the lowest overall scheduling cost and that passes all hard safety constraints as the target dispatch scheme, and output the second candidate dispatch scheme as a backup scheme in case the field status changes again.

[0104] In this embodiment, the weight of job delay is set to 0.20, the weight of safety risk is set to 0.35, the weight of resource conflict is set to 0.20, the weight of manual intervention is set to 0.10, and the weight of scene disturbance is set to 0.15. The weight of safety risk is higher than the weight of other individual items, so that when there is a conflict between emergency response efficiency and driving safety, the dispatch generation process will give priority to the candidate dispatch scheme with lower safety risk.

[0105] Regarding the adjustment of multi-target emergency dispatch parameters, the number of bundle search retentions is controlled between ten and thirty. When there are fewer than ten dispatch tasks, a ten-part dispatch scheme is adopted; when there are ten dispatch tasks, a twenty-part dispatch scheme is adopted; and when there are more than twenty dispatch tasks, a thirty-part dispatch scheme is adopted. The safety risk weight is controlled between 0.30 and 0.45, the scene disturbance weight is controlled between 0.10 and 0.20, and the operation delay weight is controlled between 0.15 and 0.30.

[0106] Example 7: Based on all the above examples, the joint control and dispatch order and traceability update module specifically includes a scheme mapping unit, a dual-position joint control unit, an emergency dispatch order generation unit, a change recording unit, a data export unit, and a sample update unit.

[0107] The scheme mapping unit writes the train number, train number, track, route, scheduled time, driver number, duty officer number, and control officer number into the receiving dispatch and control page and the departure dispatch and control page, respectively, based on the task number in the target dispatch scheme. The same field is read only from the data record corresponding to the unified resource code to avoid repeated filling in on multiple business pages.

[0108] Before each train reception and dispatch task is executed, the dual-position joint control unit displays the train number, target track, key turnout location, associated power supply section, and planned execution time. After the duty officer completes the initial confirmation, the joint control officer performs an independent confirmation. If the two confirmation results are consistent, the task status is updated to "allow execution"; if the two confirmation results are inconsistent, the task status is updated to "paused" and the system returns to the on-site status entry page.

[0109] The emergency dispatch order generation unit sets up dispatch order templates for electric passenger trains, train reception, test runs, diesel locomotives, and special emergency response. Based on the dispatch order category, it extracts the train number, car number, operating section, track, operating time, and precautions from the target dispatch plan to generate an emergency dispatch order with a dispatch order number, issuing personnel, reviewing personnel, and issuing time.

[0110] The change tracking unit records manual modifications to the target shift plan. When making manual modifications, the reason for modification must be selected from one of the following: change in on-site status, adjustment of emergency command, adjustment of personnel, and adjustment of equipment status. The field values ​​before modification, the field values ​​after modification, the operator, and the time of modification must be recorded.

[0111] After power is restored, the data export unit exports the field status table, safe and available resource table, target dispatch plan, backup dispatch plan, vehicle dispatch control record, maintenance release notice, emergency dispatch order and operation log into read-only archive files. The archive files are named according to the emergency event number and the date of handling.

[0112] The sample update unit reads the actual execution results after the emergency event ends, and writes the actual departure time, actual arrival time, new on-site faults, number of plan adjustments, number of joint control returns, and task completion status into the emergency sample library. Personnel with model maintenance permissions then update the relation type weights, task priorities, and disturbance scenario parameters under normal power supply conditions.

[0113] In this embodiment, the data before the power outage is not directly overwritten after power is restored. Emergency response records are first archived in an independent archive area and then written into the emergency sample library after being reviewed by the duty officer and safety management personnel. This avoids unconfirmed manual records from affecting the next version of the emergency data package.

[0114] Comparative Example 1: Comparative Example 1 uses a standard offline Excel dispatch table. The standard offline Excel dispatch table only sets up fields for train number, train number, track, maintenance status, and scheduled time. On-duty personnel use the VLOOKUP function to look up the corresponding data. It does not build a vehicle depot emergency knowledge graph, does not perform relation type-aware safety constraint propagation, and does not perform reliable calibration on the source of on-site status and the confirmation results of dual positions.

[0115] Compared to Example 1, which can open the basic dispatch table after a network interruption, when the status of the power supply section changes, the on-duty personnel can only check the affected tracks and trains one by one, making it difficult to identify the multi-level impact relationship between the power supply section, track, route, and train reception and dispatch tasks.

[0116] Comparative Example 2: Comparative Example 2 adopts a fixed-rule offline dispatch system. The fixed-rule offline dispatch system directly filters resources based on the train maintenance status, track occupancy status, and power supply section status, and arranges train arrival and departure tasks according to the planned time sequence. It does not distinguish the source and reliability of the on-site status, and does not disturb the execution scenario of the candidate dispatch scheme.

[0117] Comparative Example 2 can generate a shift dispatch plan when all status data is accurate, but when conflicts occur in the field records and the faulty section continues to expand, the fixed rules will not recalculate the safety impact based on the status of the associated nodes, and the generated candidate shift dispatch plan requires a lot of manual adjustment by the on-duty personnel.

[0118] Comparative Example 3: Comparative Example 3 uses paper-based basic ledgers and manual telephone communication to complete emergency dispatch. On-duty personnel check the train ledger, track occupancy board, maintenance release form and personnel schedule, and then manually compile the train reception and dispatch joint control record and emergency dispatch order.

[0119] Compared to the standard model, which does not rely on power supply and network, the lack of unified resource coding and automatic association mechanism among various ledgers makes it prone to errors such as train number transcription errors, duplicate track arrangements, omissions of dispatch order fields, and incomplete work records when train arrival and departure tasks occur in concentrated periods.

[0120] Experimental Example 1: This test case was conducted in an emergency drill environment at a subway depot to test Example 1 and Comparative Examples 1 to 3. The depot was equipped with 30 electric multiple unit trains, 36 parking tracks, 14 sets of key switches, 18 key signal machines, 5 traction power supply sections, and 12 personnel. The emergency tasks included 14 train departure tasks and 6 train reception tasks.

[0121] At the start of the test, the system simulated two adjacent traction power supply sections losing power, six tracks becoming unusable, the position of a set of turnouts needing confirmation, an electric passenger train undergoing maintenance and not being released, and a joint control personnel not being on duty. The integrated monitoring system, power supply monitoring system, dedicated dispatch system, and depot communication network simultaneously went out of operation, and each group used a portable terminal with an independent battery to complete the emergency dispatch.

[0122] Each group conducted 30 emergency dispatch tests, recording the generation time of the first executable dispatch plan, the completion time of all task dispatches, the resource conflict identification rate, the number of unsafe candidate combinations remaining, the document field error rate, and the record traceability completeness rate. The test results are shown in Table 1.

[0123] Table 1. Emergency Safety Dispatch Performance Test Results

[0124] As shown in Table 1, Example 1 establishes offline associations between power supply sections, tracks, routes, trains, tasks, and personnel through unified resource coding and a depot emergency knowledge graph. Abnormal conditions on site can propagate along the relationship edges to the affected resources, the resource conflict identification rate reaches 100.0%, and the number of unsafe candidate combinations remaining is zero.

[0125] The total shift completion time in Example 1 was 6.4 minutes, which is lower than that of Comparative Example 1 (19.7 minutes), Comparative Example 2 (12.6 minutes), and Comparative Example 3 (35.8 minutes). This indicates that offline data model collaboration, constraint propagation, and bundle search can reduce the time spent by on-duty personnel querying ledgers item by item and repeatedly verifying resources.

[0126] Experimental Example 2: In this test case, after generating the initial dispatch plan in Test Case 1, five types of disturbances were added: expansion of power supply fault section, manual locking of turnout, temporary occupation of track, cancellation of train release status, and withdrawal of key personnel. Twenty tests were performed for each type of disturbance, and the disturbance recognition rate, automatic reconstruction success rate, average re-dispatch time, and number of resource conflicts after the disturbance were recorded. The test results are shown in Table 2.

[0127] Table 2. Test results of dispatch scheme reconstruction under disturbance scenarios.

[0128] As shown in Table 2, after the on-site status changes, Example 1 can update the corresponding entity nodes and re-propagate the security constraints through the adjacency index. The dispatch optimization model can complete the partial reconstruction of the affected tasks without rereading all the basic ledgers. The automatic reconstruction success rate of the scheme reaches 96.0%, and the average re-dispatch time is shortened to 0.8 minutes.

[0129] Although Comparative Example 1 can query individual data through table functions, it lacks a multi-level propagation path composed of power supply relationships, occupancy relationships, route relationships, and conflict relationships. Therefore, it cannot automatically determine all affected tasks after the fault expands. Comparative Example 2 uses fixed rules to filter resources, but does not perform advance simulations of disturbance scenarios. The initial solution's adaptability to state changes is lower than that of Example 1. Comparative Example 3 relies on manual re-verification of all paper records, resulting in the longest reassignment time and the highest number of resource conflicts.

[0130] In summary, this invention ensures that basic data can be independently accessed during power outages through offline data encapsulation and version verification. It establishes connections between vehicle base physical resources, maintenance tasks, vehicle dispatching tasks, and personnel through a vehicle depot emergency knowledge graph. It distinguishes the reliability of data from different sources through on-site status reliability calibration. It identifies the multi-level impact of power supply failures and equipment anomalies through relation type-aware security constraint propagation. It generates emergency dispatch plans that balance safety, timeliness, and stability through constraint-aware bundle search and scenario disturbance inference. It forms a complete emergency response record closed loop through joint control and dispatch orders and traceability updates. This solves the technical problems of conventional dispatch systems being paralyzed by power outages, prone to errors in manual data matching, lack of security association verification in emergency dispatch plans, and difficulty in tracing work records.

[0131] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Any adjustments made by those skilled in the art to the data fields, relationship types, calculation parameters, and business document formats without departing from the technical concept of the present invention should fall within the scope of protection of the present invention.

Claims

1. A subway vehicle depot emergency safety dispatch management system based on offline data model collaboration, characterized in that, It includes an offline data encapsulation and version verification module, a parking lot emergency knowledge graph construction module, an on-site status reliable calibration module, a safety constraint propagation and resource determination module, a multi-target emergency dispatch generation module, and a joint control and dispatch order and traceability update module; The offline data encapsulation and version verification module acquires basic data from the subway vehicle base, forms emergency data packets according to the unified resource code, and verifies the data version, field integrity, and model association integrity. The vehicle depot emergency knowledge graph construction module generates entity nodes and relation edges based on emergency data packages, and establishes a vehicle depot emergency knowledge graph relating physical resources, maintenance tasks, vehicle reception and dispatch tasks, and personnel in the vehicle base. The on-site status credibility calibration module receives the on-site status of the vehicle base and calculates the on-site status credibility based on the status source, recording time, dual-post confirmation results, field integrity, and consistency of associated status. The safety constraint propagation and resource determination module loads the abnormal state of the site into the parking lot emergency knowledge graph. It performs iterative propagation based on the trust status of the entity node itself, the unavailability of adjacent entity nodes, the type of relation edges, and the state of safety rule violation. It calculates the safety availability of the entity node and generates a set of safe and available resources. The multi-objective emergency dispatch generation module generates candidate dispatch plans based on vehicle pick-up and drop-off tasks and a set of safe and available resources. It performs safety constraint verification and disturbance scenario simulation on the candidate dispatch plans and generates target dispatch plans based on operation delays, safety risks, resource conflicts, amount of manual intervention, and scenario disturbance losses. The joint control and dispatch order and traceability update module maps the target dispatch plan to the vehicle reception and dispatch joint control record, maintenance release notice and emergency dispatch order, and records the confirmation information, change information and execution information of the target dispatch plan.

2. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The offline data encapsulation and version verification module includes a data import unit, an encoding unification unit, an offline encapsulation unit, a version verification unit, and a backup recovery unit; The data import unit acquires basic information about electric passenger trains, including train schedules, track layout, turnout locations, signal locations, traction power supply sections, maintenance plans, and personnel information. The coding unit generates a unified resource code based on resource category, vehicle base, and resource sequence. The offline encapsulation unit encapsulates the basic data model, emergency knowledge graph model, on-site status model, safety constraint model, shift optimization model, and business document model into an emergency data package; The version verification unit compares the version number, generation date, applicable vehicle base code, number of fields, number of entity nodes, and number of relation edges of the emergency data packet with the version registration data; When the version verification fails, the backup recovery unit reads the backup emergency data packet and imports the temporary on-site status data into the backup emergency data packet.

3. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The parking lot emergency knowledge graph construction module includes an entity node generation unit, a relation edge generation unit, a topology index unit, an incremental update unit, and an abnormal relation marking unit; The entity node generation unit generates electric train nodes, track nodes, turnout nodes, signal nodes, traction power supply section nodes, maintenance task nodes, train reception and departure task nodes, and personnel nodes based on the unified resource code. The relationship edge generation unit establishes occupancy relationship edges, connection relationship edges, power supply relationship edges, maintenance relationship edges, release relationship edges, route relationship edges, conflict relationship edges, preceding relationship edges, dispatch relationship edges, and joint control relationship edges between entity nodes; The topology index unit generates a relation index based on the start node code, relation type code, and end node code, and generates an adjacency index based on the direct adjacent nodes and second-level adjacent nodes; The incremental update unit updates the target entity node and its adjacency relationship according to the resource code corresponding to the change in the field status; The abnormal relationship marking unit generates blocking relationship edges based on the state consistency between entity nodes.

4. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The on-site status reliable calibration module includes a status input unit, a source classification unit, a time-effect decay unit, an association verification unit, a dual-position confirmation unit, and a checklist generation unit. The status input unit receives the status of the power supply section, track occupancy, turnout status, signal status, train maintenance status, train release status, and personnel status. The source classification unit determines the status source level based on the system snapshot before the power outage, paper maintenance records, dispatch communication records, on-site single-person verification, and on-site dual-person verification; The time-decrease unit adjusts the status reliability based on the time difference between the status recording time and the current dispatch calculation time; The correlation verification unit identifies inconsistencies between on-site conditions based on the emergency knowledge graph of the parking lot. The dual-post confirmation unit compares the confirmation results submitted by the duty officer and the joint control officer respectively; The unit generating the list of data to be reviewed generates the order of the data to be reviewed based on the credibility of the status and the level of security impact.

5. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The security constraint propagation and resource determination module includes a hard constraint screening unit, a relation type weight configuration unit, a graph state propagation unit, a convergence determination unit, and a resource classification unit. The hard constraint screening unit generates unusable entity nodes based on power supply status, track occupancy status, train release status, turnout status, signal status, and personnel qualification status. The relationship type weight configuration unit configures the relationship type weights for power supply relationship, occupancy relationship, route relationship, conflict relationship, maintenance relationship and personnel relationship respectively; The graph state propagation unit iteratively updates the security availability of entity nodes based on the credibility of the entity node's current state, the security availability of adjacent entity nodes, the relation type weight, and the security rule violation state. The convergence determination unit generates a propagation stopping result based on the change in security availability between two adjacent iterations. The resource classification unit generates a set of secure and available resources, a set of restricted resources, and a set of prohibited resources based on security availability.

6. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The multi-target emergency dispatch generation module includes a task sorting unit, a candidate resource combination unit, a constraint perception bundle search unit, a scene disturbance inference unit, a comprehensive target calculation unit, and a target scheme output unit. The task sequencing unit generates a task sequence based on the impact level of mainline operation, planned arrival and departure times, train passenger status, rescue mission status, and subsequent route occupancy relationships. The candidate resource combination unit extracts electric trains, tracks, routes, and personnel from the set of safe and available resources to generate candidate resource combinations of train-track-route-personnel. The constraint perception bundle search unit adds train reception and departure tasks layer by layer according to the task sequence, and deletes some dispatch schemes that have duplicate resource occupation, operation time conflict, simultaneous establishment of mutually exclusive routes, and trains that have not been released to participate in the departure. The scenario disturbance simulation unit calculates the task completion rate loss of candidate dispatch schemes under the states of power supply failure section expansion, turnout manual locking, track temporary occupation, train release status cancellation and key personnel exit. The comprehensive target calculation unit generates a comprehensive scheduling cost for candidate dispatch schemes based on job delays, safety risks, resource conflicts, human intervention, and task completion rate losses. The target scheme output unit outputs the target dispatch scheme and the backup dispatch scheme based on the comprehensive scheduling cost.

7. The subway vehicle depot emergency safety dispatch management system according to claim 1, characterized in that, The joint control and dispatch order and traceability update module includes a scheme mapping unit, a dual-post joint control unit, an emergency dispatch order generation unit, a change recording unit, a data export unit, and a sample update unit. The scheme mapping unit writes the train number, train number, track, route, scheduled time, driver number, duty officer number, and control officer number into the train reception and dispatch records and the train departure and dispatch records according to the task number. The dual-position joint control unit receives confirmation results submitted by the duty officer and the joint control officer respectively, and generates an execution permission status and a pause status based on the two confirmation results; The emergency dispatch order generation unit generates an emergency dispatch order with a dispatch order number, issuing personnel, reviewing personnel, and issuance time based on the target dispatch plan and dispatch order template; The change tracking unit records the field values ​​before and after the modification, the operator, the time of modification, and the reason for modification for manual modifications to the target shift assignment plan. The data export unit generates emergency response archive files; The sample update unit updates the emergency sample database based on the actual execution results of the target dispatch plan.

8. The subway vehicle depot emergency safety dispatch management system according to any one of claims 1-7, characterized in that, The system operates on an offline terminal with independent power supply capability. The offline terminal is equipped with a main interface page, a basic dictionary page, a train maintenance and release page, a field status entry page, a train reception dispatch and joint control page, a train departure dispatch and joint control page, an emergency dispatch order page, a model calculation page, and an operation log page. Each page establishes cross-table data association through unified resource coding and unified task number. When the dual-position confirmation fails, the corresponding field status is returned to the field status reliable calibration module. After the field status is updated, the safety constraint propagation and target dispatch scheme generation are retried.

Images