Recommended methods and systems for emergency response plans for urban rail transit dispatchers

Abstract

This invention provides a method for recommending emergency response plans for urban rail transit dispatchers, comprising: Step S1: Constructing an emergency response case knowledge graph and a dispatching procedure knowledge graph using unstructured records in the dispatching log; Step S2: Recognizing interactive speech using speech recognition technology, identifying entity information in the interactive speech when an emergency response is triggered, generating a search query, and searching within the emergency response case knowledge graph and the dispatching procedure knowledge graph; Step S3: Sorting the search results according to the search content; Step S4: Merging the extracted content from the emergency response case knowledge graph and the dispatching procedure knowledge graph. This emergency response plan recommendation method provides dispatchers with an efficient information retrieval tool, and the proposed solutions can provide reference and decision-making assistance, effectively reducing the workload of dispatchers.

Description

Technical Field

[0001] This invention relates to the field of emergency management for rail transit, and in particular to a method for recommending emergency response plans for urban rail transit dispatchers. Background Technology

[0002] Urban rail transit, as the preferred mode of transportation for short- and medium-distance travel, boasts advantages such as low fares and high punctuality. In recent years, continuous upgrades to facilities and equipment, along with improvements in operation and management, have effectively reduced the likelihood of operational problems. To further enhance emergency response capabilities, management departments have developed corresponding emergency plans based on different types of malfunctions. However, the descriptions of malfunction scenarios in these plans are not detailed enough, leading to difficulties in matching actual situations with existing plans. Furthermore, dispatchers struggle to quickly identify the causes of malfunctions or accurately predict the impact of corresponding actions, resulting in insufficient and comprehensive understanding of the entire incident handling process. Current emergency response methods hinder the accumulation of dispatching and handling knowledge and fail to meet the requirements for efficient emergency response.

[0003] Existing technology publication number CN202111637549.8 discloses a fault handling auxiliary decision-making system and method based on knowledge graphs. The fault handling auxiliary decision-making system includes: a fault receiving module for receiving fault information from external sources; a retrieval module for retrieving fault handling solutions from a pre-constructed power information system fault knowledge graph based on the fault information; and a ranking module for ranking the retrieved fault handling solutions. This invention employs knowledge graph technology for fault handling auxiliary decision-making in power information systems. The power information system fault knowledge graph extracts, expresses, learns, organizes, and stores multi-dimensional data required for fault handling. When a fault is detected, intelligent retrieval and intelligent recommendations are performed in the power information system fault knowledge graph based on fault characteristics, providing relevant knowledge and fault handling solutions, and offering auxiliary reference for information dispatchers and operation and maintenance professionals.

[0004] However, this patent document struggles to unify retrieval information when dealing with excessive data; furthermore, it lacks voice input for retrieval, resulting in poor practicality. The BIO annotation format is widely used in entity recognition annotation. Compared to the BILSTM-CRF model, the BERT-BILSTM-CRF-based method incorporates a pre-trained model, fully considering contextual relationships and producing more reasonable character vectors. Compared to the BERT-BILSTM method, it adds constraints between adjacent labels, significantly reducing annotations that do not conform to the annotation rules. Summary of the Invention

[0005] Based on the shortcomings of existing technologies, the purpose of this invention is to provide a method for recommending emergency response plans for urban rail transit dispatchers. This method involves preprocessing unstructured urban rail transit dispatcher work procedures and dispatcher records for different fault events in dispatch logs, performing text preprocessing, named entity recognition, and relation extraction, and finally storing them in the Neo4j graph database as triples. When operational problems occur, the method uses the actual situation of the fault scenario as input to match the content in the knowledge graph, providing timely and accurate emergency response methods and possible consequences for different scenarios, facilitating dispatchers' overall control of the event handling process.

[0006] To achieve the above objectives, the present invention provides a method for recommending emergency response plans for urban rail transit dispatchers, comprising the following steps:

[0007] Step S1: Construct an emergency response case knowledge graph and a scheduling procedure knowledge graph using unstructured records in the scheduling log;

[0008] Step S2: Recognize interactive voice through speech recognition technology. When an emergency response is triggered, identify entity information in the interactive voice and generate a search statement for retrieval in the emergency response case knowledge graph and the dispatch procedure knowledge graph.

[0009] Step S3: Sort the retrieved content according to its relevance to the actual fault scenario to obtain the sorted search results;

[0010] Step S4: Merge the sorted content and display it to obtain the emergency response plan.

[0011] The emergency response plan includes fault handling methods, a complete process for handling fault phenomena, the impact of the event, and the event closure process. It provides a reference for emergency response measures and helps dispatchers understand the pattern of event evolution.

[0012] Preferably, step S1 includes:

[0013] Step S1.1: Obtain the unstructured record text from the scheduling log and define different entity categories;

[0014] Step S1.2: Preprocess all extracted unstructured record text to unify the text format, remove invalid text and duplicate information, and obtain the processed text;

[0015] Step S1.3: Annotate the processing text according to the specified entity category and in the BIO format;

[0016] Step S1.4: Using the Bert-BILSTM-CRF-based method, train the entity recognition model for the subway dispatch emergency response domain labeled in step S1.3, and use the trained recognition model to identify different entity information in the response text;

[0017] Step S1.5: Construct the relationships between the entities in steps S1.1-S1.4, i.e., directed edges;

[0018] Step S1.6: Import the extracted entity information and relationships between entities into the Neo4j graph database in the form of triples to complete the construction of the emergency response case knowledge graph;

[0019] Step S1.7: The extracted information includes fault and fault handling method information. Construct a scheduling procedure knowledge graph according to the above steps S1.1-S1.6.

[0020] Preferably, step S2 includes:

[0021] Step S2.1: In operation and production, dispatchers interact with employees in different positions through official telephones and walkie-talkies to generate voice data, and use voice recognition technology to generate voice text;

[0022] Among them, a noise reduction algorithm was added to the official telephones and walkie-talkies used by dispatchers to improve the quality of voice audio.

[0023] Step S2.2: Use the recognition model trained in step S1.4 to extract keywords from the text recognized by speech and identify the fault scenario;

[0024] Step S2.3: Generate query statements from the keywords and search for relevant emergency response content in the emergency response case knowledge graph and the dispatch procedure knowledge graph, respectively.

[0025] Preferably, step S1.1 includes:

[0026] The entity categories include: fault phenomenon, fault time, fault range, handling method, event impact and event closure status, and faulty train number;

[0027] The attributes of the fault phenomenon include: fault time, fault range, and fault train number.

[0028] Preferably, step S1.4 includes:

[0029] The recognition module includes a speech recognition module and a text keyword recognition module. The speech recognition module incorporates a dispatch interaction terminology database, which contains special terms for dispatch emergency response and special pronunciation rules.

[0030] Voiceprint recognition technology is added to the speech recognition module to identify the speaker's identity.

[0031] An emergency response plan recommendation system for urban rail transit dispatchers includes the following modules:

[0032] Module M1: Constructs an emergency response case knowledge graph and a scheduling procedure knowledge graph using unstructured records in the scheduling log;

[0033] Module M2: Recognizes interactive speech using speech recognition technology. When an emergency response is triggered, it identifies entity information in the interactive speech and generates a search statement, which is then searched in the emergency response case knowledge graph and the dispatch procedure knowledge graph.

[0034] Module M3: Sorts the retrieved content according to its relevance to the actual fault scenario, and obtains the sorted search results.

[0035] Module M4: Combines and displays the sorted content to present the emergency response plan;

[0036] The emergency response plan includes fault handling methods, a complete process for handling fault phenomena, the impact of the event, and the event closure process. It provides a reference for emergency response measures and helps dispatchers understand the pattern of event evolution.

[0037] Preferably, module M1 includes:

[0038] Module M1.1: Retrieves unstructured record text from the scheduling log and specifies different entity categories;

[0039] Module M1.2: Preprocesses all extracted unstructured record text to unify the text format, remove invalid text and duplicate information, and obtain the processed text;

[0040] Module M1.3: Annotates the processed text according to the specified entity category and in the BIO format;

[0041] Module M1.4: Using the Bert-BILSTM-CRF-based method, train the entity recognition model for the subway dispatch emergency response domain labeled in Module M1.3, and use the trained recognition model to identify different entity information in the response text;

[0042] Module M1.5: Constructs the relationships between entities in modules M1.1-S1.4, i.e., directed edges;

[0043] Module M1.6: Imports the extracted entity information and relationships between entities into the Neo4j graph database in the form of triples to complete the construction of the emergency response case knowledge graph;

[0044] Module M1.7: The extracted information includes fault and fault handling method information, and a scheduling procedure knowledge graph is constructed according to the above modules M1.1-S1.6.

[0045] Preferably, module M2 includes:

[0046] Module M2.1: In operation and production, dispatchers interact with employees in different positions through official telephones and walkie-talkies, generating voice data and using voice recognition technology to generate voice text;

[0047] Among them, a noise reduction algorithm was added to the official telephones and walkie-talkies used by dispatchers to improve the quality of voice audio.

[0048] Module M2.2: Uses the recognition model trained in Module M1.4 to extract keywords from the text recognized by speech and identify fault scenarios;

[0049] Module M2.3: Generates query statements from keywords and retrieves relevant emergency response content from the emergency response case knowledge graph and the dispatch procedure knowledge graph.

[0050] Preferably, module M1.1 includes:

[0051] The entity categories include: fault phenomenon, fault time, fault range, handling method, event impact and event closure status, and faulty train number;

[0052] The attributes of the fault phenomenon include: fault time, fault range, and fault train number.

[0053] Preferably, the module M1.4 includes:

[0054] The recognition module includes a speech recognition module and a text keyword recognition module. The speech recognition module incorporates a dispatch interaction terminology database, which contains special terms for dispatch emergency response and special pronunciation rules.

[0055] Voiceprint recognition technology is added to the speech recognition module to identify the speaker's identity.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] 1. This invention, through its emergency response plan recommendation method, can provide dispatchers with an efficient information retrieval tool, and the proposed solutions can provide dispatchers with reference and decision-making assistance, effectively reducing the workload of dispatchers;

[0058] 2. By introducing speech recognition technology, this invention can automatically generate search statements, effectively improving information retrieval efficiency;

[0059] 3. In the case recommendation stage, this invention can rank cases by calculating their similarity, allowing dispatchers to refer to them sequentially.

[0060] 4. This invention effectively improves the accuracy of speech recognition by introducing noise reduction algorithms, voiceprint recognition technology, and constructing a professional terminology database for scheduling interaction;

[0061] 5. This invention provides dispatchers with problem-solving approaches by integrating different contents from the knowledge graph of scheduling procedures and the knowledge graph of scheduling handling cases. Attached Figure Description

[0062] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0063] Figure 1 This is a structural diagram of the present invention.

[0064] Figure 2 A flowchart for providing an emergency response plan recommendation method for this invention patent;

[0065] Figure 3 The flowchart for constructing a knowledge graph of scheduling and handling cases and a knowledge graph of scheduling procedures for this invention patent;

[0066] Figure 4 This is the entity relationship diagram constructed for this invention patent. Detailed Implementation

[0067] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0068] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0069] like Figure 1 As shown, the present invention provides a technical solution: a recommended method for emergency response plans for urban rail transit dispatchers.

[0070] like Figure 3As shown, this paper constructs a knowledge graph for scheduling logs and a knowledge graph for operational scheduling procedures. The data preprocessing process mainly utilizes natural language processing technology to standardize text in different formats. This includes tasks such as removing duplicate text content, removing incomplete text content, standardizing punctuation formats, removing special characters, and adding relevant content at specified locations in the text.

[0071] The ontology construction process mainly adopted the seven-step principle, ultimately constructing four entity categories: train fault phenomenon, handling, event impact, and event closure. Among them, to better describe the scenario in which the fault phenomenon occurs, the train fault phenomenon handling entity has five entity attributes: equipment ownership unit, equipment type, time, train number, and train direction.

[0072] For different text data, the BIO text annotation format is adopted. This invention uses a Named Entity Recognition (NER) method based on BERT-BILSTM-CRF. Since the data format used in this paper is relatively fixed, and the relationships between different entities are also relatively fixed, this invention adopts a rule-based relationship extraction method.

[0073] In this context, BIO stands for B: begin, representing the beginning of an entity; I: inside, representing the internal content of an entity; and O: outside, representing the non-entity content.

[0074] BERT-BILSTM-CRF is a mature named entity recognition model. BERT is a pre-trained model whose main function is to convert characters into vectors. BILSTM is a bidirectional long short-term memory network whose main function is to learn features. CRF is a conditional random field whose main function is to consider the interdependencies of labels and improve the accuracy of labeling.

[0075] In emergency response and dispatch, the same emergency response measures may be used in different fault scenarios, but different results may occur in different scenarios, and the triples have different tree structures. Therefore, this invention does not perform knowledge fusion.

[0076] The extracted entities and entity relationships are stored in the Neo4j graph database in the form of triples to achieve a visual representation of the knowledge graph.

[0077] like Figure 2 As shown, this paper uses dispatcher interaction content to trigger a recommendation method. Speech recognition algorithms are incorporated into different interaction tools to recognize dispatcher interactions in real time. This invention incorporates a noise reduction algorithm during the interaction process, effectively improving audio quality. Simultaneously, this invention establishes a complete professional terminology database for urban rail transit dispatching; during recognition, words from this database are prioritized for output, improving the accuracy of speech recognition.

[0078] Subsequently, the trained NER model is used to extract key information from the speech text, and information such as fault scenarios and fault phenomena are identified. Then, corresponding information retrieval statements are generated with text keywords as input, the similarity of text information is calculated, and relevant emergency response information is retrieved from two knowledge graphs respectively.

[0079] The retrieved information is sorted according to the degree of similarity, and the information generated from the two knowledge graphs is merged and presented to the dispatcher to assist in decision-making.

[0080] This paper employs speech recognition to identify daily interactive voice recordings for dispatching. A specialized terminology database for dispatching interactions is constructed to effectively improve recognition accuracy. When the identified text contains trigger words for emergency response, entity recognition and intent recognition are performed to generate corresponding search statements for querying within a knowledge graph. Compared to manually inputting search statements, this method optimizes the query process, achieves connectivity between data, and enables seamless recommendation of emergency response methods by mining relevant information, significantly improving the system's retrieval efficiency.

[0081] This paper constructs a knowledge graph of dispatching and handling cases and a knowledge graph of dispatching procedures. The two graphs are integrated to recommend dispatching emergency responses. The procedure graph provides the rules for dispatching and handling, while the case handling knowledge graph provides the handling and can provide more information. The two complement each other and provide dispatchers with more new ideas for emergency response.

[0082] Step S1.5: A knowledge graph consists of nodes and directed edges; the relationships between entities are represented by directed edges. The entity relationship graph constructed in this paper is as follows: Figure 4 As shown.

[0083] The knowledge graph contains four types of entities: fault phenomenon, handling, event impact, and event closure. The fault phenomenon entity has several attributes: the unit to which the equipment belongs, the equipment type, the time, the train number, and the direction of train operation.

[0084] This paper utilizes a rule-based approach to extract textual relationships, performing entity relationship extraction on each case. The prerequisite for relationship extraction is the accurate identification of different entities within the case. Furthermore, steps s1.1-s1.4 are prerequisites for relationship extraction (s1.5).

[0085] The present invention also provides an emergency response plan recommendation system for urban rail transit dispatchers. The emergency response plan recommendation system for urban rail transit dispatchers can be implemented by executing the process steps of the emergency response plan recommendation method for urban rail transit dispatchers. That is, those skilled in the art can understand the emergency response plan recommendation method for urban rail transit dispatchers as a preferred implementation of the emergency response plan recommendation system for urban rail transit dispatchers.

[0086] An emergency response plan recommendation system for urban rail transit dispatchers includes the following modules: Module M1: Constructs an emergency response case knowledge graph and a dispatch procedure knowledge graph using unstructured records in the dispatch log; Module M2: Recognizes interactive speech using speech recognition technology. When an emergency response is triggered, it identifies entity information in the interactive speech and generates a search query, which is then searched in the emergency response case knowledge graph and the dispatch procedure knowledge graph; Module M3: Sorts the retrieved content according to its relevance to the actual fault scenario, resulting in sorted search content; Module M4: Merges and displays the sorted content to obtain the displayed emergency response plan. The emergency response plan includes fault handling methods, a complete process for handling fault phenomena, the impact of the event, and the event closure loop, providing a reference for emergency response measures while facilitating dispatchers' understanding of the event's evolution.

[0087] Specifically, module M1 includes: Module M1.1: Obtaining unstructured record text from the dispatch log and defining different entity categories; Module M1.2: Preprocessing all extracted unstructured record text to unify the text format, removing invalid text and duplicate information to obtain the disposal text; Module M1.3: Labeling the disposal text according to the defined entity categories in the BIO format; Module M1.4: Using a Bert-BILSTM-CRF-based method, training the entity recognition model for the subway dispatch emergency disposal domain labeled in module M1.3, and using the trained recognition model to identify different entity information in the disposal text; Module M1.5: Constructing the relationships between entities in modules M1.1-S1.4, i.e., directed edges; Module M1.6: Importing the extracted entity information and the relationships between entities into the Neo4j graph database in the form of triples to complete the construction of the emergency disposal case knowledge graph; Module M1.7: Extracting information including fault and fault handling method information, and constructing a dispatch procedure knowledge graph according to modules M1.1-S1.6 above.

[0088] Specifically, module M2 includes: Module M2.1: In operation and production, dispatchers interact with employees in different positions through official telephones and walkie-talkies, forming voice and text; among them, noise reduction algorithms are added to the official telephones and walkie-talkies used by dispatchers to improve the voice and audio quality; Module M2.2: Using the recognition model trained in module M1.4, keywords are extracted from the text recognized by the voice to identify fault scenarios; Module M2.3: The keywords are used to generate query statements, and relevant emergency handling content is retrieved in the emergency response case knowledge graph and the dispatch procedure knowledge graph respectively.

[0089] Specifically, module M1.1 includes: the entity categories include: fault phenomenon, fault time, fault range, handling method, event impact and event closure status, and faulty train number; wherein, the attributes of the fault phenomenon include: fault time, fault range, and faulty train number.

[0090] Specifically, module M1.4 includes: the recognition module includes: a speech recognition module and a text keyword recognition module. The speech recognition module incorporates a dispatch interaction terminology database, which contains special terms for dispatch emergency response and special pronunciation rules; the speech recognition module incorporates voiceprint recognition technology to identify the speaker's identity.

[0091] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0092] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for recommending emergency response plans for urban rail transit dispatchers, characterized in that, Includes the following steps: Step S1: Construct an emergency response case knowledge graph and a scheduling procedure knowledge graph using unstructured records in the scheduling log; Step S2: Recognize interactive voice through speech recognition technology. When an emergency response is triggered, identify entity information in the interactive voice and generate a search statement for retrieval in the emergency response case knowledge graph and the dispatch procedure knowledge graph. Step S3: Sort the retrieved content according to its relevance to the actual fault scenario to obtain the sorted search results; Step S4: Merge the sorted content and display it to obtain the emergency response plan. In the emergency response plan, the dispatch procedure knowledge graph contains the operational requirements under the fault scenario, and the handling case knowledge graph includes fault handling methods, the complete process of handling fault phenomena, the impact of the event, and the event closure situation. It provides a reference for emergency response measures and helps dispatchers to grasp the pattern of event evolution.

2. The method for recommending emergency response plans for urban rail transit dispatch as described in claim 1, characterized in that, Step S1 includes: Step S1.1: Obtain the unstructured record text from the scheduling log and define different entity categories; Step S1.2: Preprocess all extracted unstructured record text to unify the text format, remove invalid text and duplicate information, and obtain the processed text; Step S1.3: Annotate the processing text according to the specified entity category and in the BIO format; Step S1.4: Using the Bert-BILSTM-CRF-based method, train the entity recognition model for the subway dispatch emergency response domain labeled in step S1.3, and use the trained recognition model to identify different entity information in the response text; Step S1.5: Construct the relationships between the entities in steps S1.1-S1.4, i.e., directed edges; Step S1.6: Import the extracted entity information and relationships between entities into the Neo4j graph database in the form of triples to complete the construction of the emergency response case knowledge graph; Step S1.7: The extracted information includes fault and fault handling method information. Construct a scheduling procedure knowledge graph according to the above steps S1.1-S1.

6.

3. The method for recommending emergency response plans for urban rail transit dispatch as described in claim 2, characterized in that, Step S2 includes: Step S2.1: In operation and production, dispatchers interact with employees in different positions through official telephones and walkie-talkies to generate voice data, and use voice recognition technology to generate voice text; Among them, a noise reduction algorithm was added to the official telephones and walkie-talkies used by dispatchers to improve the quality of voice audio. Step S2.2: Use the recognition model trained in step S1.4 to extract keywords from the text recognized by speech and identify the fault scenario; Step S2.3: Generate query statements from the keywords and search for relevant emergency response content in the emergency response case knowledge graph and the dispatch procedure knowledge graph respectively.

4. The method for recommending emergency response plans for urban rail transit dispatch as described in claim 2, characterized in that, Step S1.1 includes: The entity categories include: fault phenomenon, fault time, fault range, handling method, event impact and event closure status, and faulty train number; The attributes of the fault phenomenon include: fault time, fault range, and fault train number.

5. The method for recommending emergency response plans for urban rail transit dispatch as described in claim 2, characterized in that, Step S1.4 includes: The recognition module includes a speech recognition module and a text keyword recognition module. The speech recognition module incorporates a dispatch interaction terminology database, which contains special terms for dispatch emergency response and special pronunciation rules. Voiceprint recognition technology is added to the speech recognition module to identify the speaker's identity.

6. A system for recommending emergency response plans for urban rail transit dispatchers, characterized in that, Includes the following modules: Module M1: Constructs an emergency response case knowledge graph and a scheduling procedure knowledge graph using unstructured records in the scheduling log; Module M2: Recognizes interactive speech using speech recognition technology. When an emergency response is triggered, it identifies entity information in the interactive speech and generates a search statement, which is then searched in the emergency response case knowledge graph and the dispatch procedure knowledge graph. Module M3: Sorts the retrieved content according to its relevance to the actual fault scenario, and obtains the sorted search results. Module M4: Combines and displays the sorted content to present the emergency response plan; The emergency response plan includes fault handling methods, a complete process for handling fault phenomena, the impact of the event, and the event closure process. It provides a reference for emergency response measures and helps dispatchers understand the pattern of event evolution.

7. The urban rail transit dispatching emergency response plan recommendation system as described in claim 6, characterized in that, Module M1 includes: Module M1.1: Retrieves unstructured record text from the scheduling log and specifies different entity categories; Module M1.2: Preprocesses all extracted unstructured record text to unify the text format, remove invalid text and duplicate information, and obtain the processed text; Module M1.3: Annotates the processed text according to the specified entity category and in the BIO format; Module M1.4: Using the Bert-BILSTM-CRF-based method, train the entity recognition model for the subway dispatch emergency response domain labeled in Module M1.3, and use the trained recognition model to identify different entity information in the response text; Module M1.5: Constructs the relationships between entities in modules M1.1-S1.4, i.e., directed edges; Module M1.6: Imports the extracted entity information and relationships between entities into the Neo4j graph database in the form of triples to complete the construction of the emergency response case knowledge graph; Module M1.7: The extracted information includes fault and fault handling method information, and a scheduling procedure knowledge graph is constructed according to the above modules M1.1-S1.

6.

8. The urban rail transit dispatching emergency response plan recommendation system as described in claim 7, characterized in that, Module M2 includes: Module M2.1: In operation and production, dispatchers interact with employees in different positions through official telephones and walkie-talkies, generating voice data and using voice recognition technology to generate voice text; Among them, a noise reduction algorithm was added to the official telephones and walkie-talkies used by dispatchers to improve the quality of voice audio. Module M2.2: Uses the recognition model trained in Module M1.4 to extract keywords from the text recognized by speech and identify fault scenarios; Module M2.3: Generates query statements from keywords and retrieves relevant emergency response content from the emergency response case knowledge graph and the dispatch procedure knowledge graph.

9. The urban rail transit dispatching emergency response plan recommendation system as described in claim 7, characterized in that, Module M1.1 includes: The entity categories include: fault phenomenon, fault time, fault range, handling method, event impact and event closure status, and faulty train number; The attributes of the fault phenomenon include: fault time, fault range, and fault train number.

10. The urban rail transit dispatching emergency response plan recommendation system as described in claim 7, characterized in that, The module M1.4 includes: The recognition module includes a speech recognition module and a text keyword recognition module. The speech recognition module incorporates a dispatch interaction terminology database, which contains special terms for dispatch emergency response and special pronunciation rules. Voiceprint recognition technology is added to the speech recognition module to identify the speaker's identity.

Images