Fault emergency treatment question and answer and report generation method, system, device and medium

Abstract

The application provides a fault emergency treatment question and answer and report generation method, system, device and medium, including the following steps: receiving a running fault event input, constructing an event state vector; constructing an event chain graph; based on the event chain graph, risk sorting is performed on the current state, necessary verification items and candidate treatment branches are generated; for the candidate treatment branches that meet the trigger conditions, step-level treatment cards are generated; the question and answer interface is rendered according to the preset information priority; receiving the on-site feedback corresponding to the step-level treatment card, updating the event state vector and the event chain graph by using the on-site feedback; associating the step-level treatment card, the on-site feedback, the data source, the timestamp, the artificial revision record and the rule verification result into a field-level evidence chain, and automatically generating an emergency treatment report based on the field-level evidence chain. The application makes the primary risk, necessary verification and prohibited items to be presented in priority in the emergency stage, and can dynamically adjust the subsequent question and answer content according to the on-site feedback.

Description

Technical Field

[0001] This invention belongs to the field of intelligent operation and maintenance technology for rail transit, and in particular relates to a method, system, equipment and medium for generating emergency response questions and reports for faults. Background Technology

[0002] During rail transit operation, when equipment such as vehicles, power supply, signaling, and communication malfunctions, on-site personnel must complete fault confirmation, risk identification, regulation review, and handling procedures within a very short time. However, actual operation and maintenance information is scattered across multiple heterogeneous systems such as fault management systems, equipment monitoring systems, maintenance records, dispatch logs, and regulatory knowledge bases. On-site personnel often need to manually search across systems and rely on personal experience to integrate information, resulting in low handling efficiency and a high risk of errors.

[0003] Existing intelligent question-and-answer or report generation tools mostly use static templates, simply listing vehicle information, historical records, regulations, etc. This approach has the following technical defects: (1) It cannot distinguish the urgency of information. In fault scenarios, a large amount of background information interferes with the operator's ability to quickly identify the primary risk; (2) It lacks a state constraint mechanism. The system is difficult to dynamically adjust subsequent suggestions based on on-site feedback. When verification is not completed or the risk is high, it may still output immature definitive conclusions, which poses a safety hazard; (3) The handling process is separated from the report generation, resulting in repeated data entry afterward. Moreover, there is a lack of traceable connection between the handling steps and the data source and regulatory basis, which is not conducive to review and auditing. Summary of the Invention

[0004] This invention aims to address the following problems in existing intelligent Q&A and report template generation technologies for rail transit operation and maintenance: First, fixed templates cannot highlight the most critical verifications, prohibitions, and the first action at the current stage of an operational fault; second, there is a lack of state transitions and conditional constraints between fault information, on-site feedback, and subsequent suggestions; third, there is a lack of accessible correspondence between action steps and regulations, equipment locations, human-machine interfaces, or simulation resources; fourth, on-site handling records cannot be automatically converted into report fields with evidence chains; and fifth, template extensions for general operation and maintenance scenarios typically lack reusable core mechanisms derived from emergency scenarios.

[0005] To achieve the above-mentioned objectives, this invention provides a method for generating emergency response questions and reports, comprising the following steps: Step 1: Receive operational failure event input, extract and complete event elements, and construct an event state vector containing six state dimensions: failure status, on-site verification status, risk level, handling stage, data confidence level, and input completeness. Step 2: Based on the event state vector, retrieve related objects in the fault code-equipment object-rules and regulations-disposal resource mapping library, and construct an event chain diagram consisting of state nodes, verification nodes, action nodes, expected state nodes, and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints, and state transition rules. Step 3: Based on the event chain diagram, sort the current state by risk and generate necessary verification items and candidate disposal branches; when the risk level corresponding to the current state is higher than the preset threshold, or the triggering condition of the candidate disposal branch is not met, generate a verification card, a reporting card or a waiting instruction card, and prohibit the generation of deterministic recovery conclusions corresponding to the failure to meet the triggering conditions. Step 4: For candidate handling branches that meet the triggering conditions, generate step-level handling cards; each step-level handling card should include at least the execution role, triggering premise, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index and visual resource index; Step 5: Render the Q&A interface according to the preset information priority, place the current risk, necessary verification, prohibited items and the first step-level handling card in the emergency execution area, place the subsequent step-level handling cards in the step-by-step handling area, and place non-real-time information in the information area that can be expanded as needed. Step 6: Receive on-site feedback corresponding to the step-level handling card, update the event state vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next state; Step 7: Associate the step-level handling card, on-site feedback, data source, timestamp, manual revision record, and rule verification result into a field-level evidence chain, and automatically generate an emergency response report based on the field-level evidence chain. The emergency response report shall include at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and a list of cited evidence.

[0006] Furthermore, in step 1, the operational failure event input includes at least one of the following: fault code, vehicle identification, carriage or equipment location, train number or operational task, occurrence time, operational location, operational status, on-site description, and handling feedback.

[0007] Furthermore, in step 2, the fault code-equipment object-regulation clause-disposal resource mapping library includes at least the correspondence between fault codes and system components, the correspondence between system components and inspection items, the correspondence between inspection items and regulations or emergency plans, and the correspondence between inspection items and human-machine interface diagrams, simulation pages, graphic operation manuals, or video resources.

[0008] Furthermore, in step 2, the verification node includes at least one of the following: on-site phenomenon confirmation node, equipment status confirmation node, and regulatory applicability confirmation node; the upgrade node includes a node that initiates a confirmation request to the dispatching and command personnel, professional and technical personnel, or authorized review personnel; and the state transition rule at least defines the preconditions, feedback conditions, and prohibition conditions required for the current node to enter the action node.

[0009] Furthermore, in step 4, the step-level handling card is dynamically generated based on the authorized scope of the execution role, the device location, the current operating status, and the risk level; when the execution role does not have the corresponding operating authority, the handling resources are lacking, or the on-site risk has not been eliminated, the corresponding step-level handling card is replaced with a reporting card or a waiting instruction card.

[0010] Furthermore, in step 4, the visual resource index is used to call up human-machine interface diagrams, equipment part diagrams, simulation interaction pages, work instruction pages, or historical disposal case fragments that match the operation object and operation content, and to display resource entry points or resource identifiers in the step-level disposal card.

[0011] Furthermore, in step 5, the priority of the preset information is determined by the operating status, risk level, and input completeness. When the user only inputs the fault code or the description of the equipment abnormality, the system outputs a brief Q&A result containing the fault meaning, necessary supplementary information, and initial verification items. When the user inputs the vehicle, location, operating status, and on-site feedback, the system outputs a complete Q&A result including a step-by-step handling card, relevant history, and a draft report.

[0012] Furthermore, the information area that expands on demand includes at least the vehicle's basic configuration, operation information, maintenance history, historical cases, principle explanations, and regulatory basis.

[0013] Furthermore, in step 7, in the field-level evidence chain, each factual field is associated with at least one original business field, original data record, or knowledge entry, and each advisory field is associated with at least one corresponding event chain node, triggering condition, rule clause, or historical case. When a factual field lacks a traceable source, or an advisory field lacks a rule basis, the system marks the field as pending confirmation and prevents it from being output as the final report conclusion.

[0014] Furthermore, in step 7, the emergency response report is automatically filled in by on-site feedback. The automatic filling includes at least filling in the generation order and feedback timestamp of the step-level response card into the response process field, filling in the expected phenomena that are met or not met into the response result field, filling in the upgrade card or waiting instruction card into the risk control field, and filling in the visual resource index and rule basis into the attachment or reference field.

[0015] Furthermore, it also includes: after the emergency response report is approved, the event state vector, event chain diagram, step-level handling card, on-site feedback and field-level evidence chain are written into the case library; when generating similar fault handling results in the future, the case library is searched according to vehicle model, component, fault code, operating status and closed-loop reliability, and only cases that meet the preset similarity and reliability thresholds are output as reference information.

[0016] This invention also provides a fault emergency response question and answer and report generation system, comprising: The fault event input and status construction module is used to receive operational fault event inputs, extract and complete event elements, and construct an event status vector containing six status dimensions: fault status, on-site verification status, risk level, handling stage, data confidence, and input completeness. The event chain construction and handling judgment module is used to retrieve related objects in the fault code-equipment object-rule clause-handling resource mapping library according to the event state vector, and construct an event chain diagram composed of state nodes, verification nodes, action nodes, expected state nodes, and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints, and state transition rules; and is used to sort the current state by risk based on the event chain diagram, generate necessary verification items and candidate handling branches; when the risk level corresponding to the current state is higher than a preset threshold, or the triggering condition of the candidate handling branch is not met, a verification card, a reporting card, or a waiting instruction card is generated, and the generation of deterministic recovery conclusions corresponding to the failure to meet the triggering conditions is prohibited; The step-level handling card generation module is used to generate step-level handling cards for candidate handling branches that meet the triggering conditions. Each step-level handling card includes at least the execution role, triggering premise, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index and visual resource index. The phased question-and-answer interaction module is used to render the question-and-answer interface according to the preset information priority, placing the current risk, necessary verification, prohibited items and the first step-level handling card in the emergency execution area, the subsequent step-level handling cards in the step-by-step handling area, and non-real-time information in the information area that can be expanded as needed; and is used to receive on-site feedback corresponding to the step-level handling cards. The status feedback and update module is used to update the event status vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next status; The evidence association and report generation module is used to associate the step-level handling cards, on-site feedback, data sources, timestamps, manual revision records, and rule verification results into a field-level evidence chain, and automatically generate an emergency response report based on the field-level evidence chain. The emergency response report includes at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and cited evidence.

[0017] Furthermore, it also includes a risk constraint and permission management module, which, when the interception conditions are triggered, limits the system output to verification prompts, risk prompts, reporting requests, pending authorization, supplementary information requests, or manual confirmation tasks, and does not output unverified definitive handling conclusions; the interception conditions include at least one of the following: the on-site verification status is unknown, there is an anomaly in the linkage of multiple systems, the fault level exceeds the preset level, the required regulations and clauses are not found, the handling card lacks key prerequisites, the authorization level of the execution role is insufficient, or the credibility of the data source is lower than the threshold.

[0018] An electronic device includes: one or more processors; and a storage device for storing one or more programs; wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the method described above.

[0019] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0020] Compared with the prior art, the present invention has the following significant advantages: Compared with the technology of generating text directly according to a fixed template, the present invention drives information output with event status and risk constraints, so that the primary risks, necessary verifications and prohibited items are presented in priority during the emergency stage, which is suitable for the time sensitivity requirements of the operation failure site. This invention organizes fault symptoms, verification conditions, operating steps, expected phenomena, and escalation paths into a constrained state transition structure through fault code-equipment object-rules and regulations-disposal resources mapping and event chain diagrams, which can dynamically adjust the subsequent Q&A content based on on-site feedback; This invention establishes an index relationship between human-machine interface diagrams, simulation resources, part diagrams, and work instructions and step-level processing cards, enabling different roles to quickly obtain corresponding auxiliary resources around the current operation object, avoiding the provision of only abstract text instructions; This invention directly fills the report field with the step cards, feedback, timestamps, rule basis, and raw data from the question-and-answer process, realizing "recording as soon as handling, and documenting as soon as recording", reducing the problems of repeated post-event organization and inconsistency between report content and actual process; This invention sets up a high-risk and unmet premise interception mechanism, and transforms conclusions without reliable evidence into verification, reporting or manual confirmation tasks, which can reduce the risk of general language models generating inappropriate deterministic suggestions in security-sensitive scenarios; This invention takes the state vector, event chain, step-level handling card and evidence chain accumulated in emergency response scenarios as its core. It can be extended to scenarios such as maintenance, review and quality analysis by replacing the trigger conditions and field configuration of business templates, thereby improving the system's reusability. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the overall process of phased intelligent question answering and report generation for emergency response to operational failures in this invention. Figure 2 This is a flowchart illustrating the event chain construction and step-level processing card generation process of this invention. Figure 3 This is a diagram showing the linkage structure between information priority and report fields in the emergency Q&A interface of this invention; Figure 4 This is a diagram showing the transferable structure of the present invention from an emergency fault handling template to a general operation and maintenance template. Detailed Implementation

[0022] To better understand the purpose, structure, and function of this invention, the following detailed description, in conjunction with the accompanying drawings, provides a method, system, device, and medium for generating emergency response questions and reports based on fault conditions.

[0023] This invention prioritizes emergency response to operational failures as its primary application scenario. Instead of generating reports directly according to fixed chapters, the system integrates user input, real-time business data, and knowledge base content into an event state vector. This process of organizing and mapping user input, real-time business data, and knowledge base content into an event state vector is called state representation. The event state vector is used to represent six state dimensions: failure state, on-site verification state, risk level, handling stage, data confidence level, and input completeness.

[0024] The system constructs an event chain diagram based on fault codes, equipment objects, applicable vehicle models or equipment types, operating status, regulations and clauses, and visualization resources. As a result, the system outputs not a fixed text that is detached from the on-site situation, but a dynamic handling path that can change with on-site feedback.

[0025] When generating the interface, the system employs a phased information priority mechanism. The emergency execution area prioritizes displaying risk levels, necessary verifications, prohibited items, and the first step-level handling card; the step-by-step handling area sequentially displays subsequent actions that meet the preconditions; non-real-time information such as vehicle basic configuration, operation information, maintenance history, historical cases, principle explanations, and the full text of regulations are displayed in the information area that is expanded as needed. This mechanism can prevent complete report-type content from occupying operational attention in the early stages.

[0026] Each step-level action card is stored as a structured data object, with its business content fields corresponding one-to-one with the aforementioned step-level action card fields. These include the execution role, triggering prerequisites, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry point, basis index, and visual resource index. The triggering prerequisites, expected phenomenon, basis index, and visual resource index can use single or aggregate values ​​as needed, and the feedback entry point can be configured with one or more feedback options. Card identifier, current node identifier, generation time, and verification status are only additional management fields required for system storage, process positioning, and verification, and are not part of the aforementioned business content fields. The visual resource index can point to a human-machine interface diagram, part diagram, simulation interaction page, graphic work instructions, or video resource matching the current action. After the user submits step feedback, the system updates the event state vector and event chain branches, and automatically generates the next step-level action card or upgrade card.

[0027] For high-risk situations, incomplete on-site verification, insufficient regulatory basis, mismatched execution role permissions, or unavailable resources, the system will not output a definitive recovery conclusion, but instead output verification, reporting, pending instructions, or manual confirmation content. For factual fields, the system requires at least one source of original data or knowledge; for suggestion fields, the system requires association with corresponding event chain nodes, triggering conditions, and regulatory or case basis to form a field-level evidence chain.

[0028] The system directly maps step-by-step handling cards and their on-site feedback to report template fields. As a result, the event overview, handling process, risk control, analysis conclusions, database recommendations, cited evidence, and attachment index are all automatically populated from the actual Q&A and feedback process. After the emergency response case is reviewed and closed-loop, it can be used as a reliable case asset, and can be cited in subsequent searches for similar faults when a similarity threshold is met.

[0029] After completing the application of emergency response scenarios for operational failures, the system abstracts status representation, event chain construction, handling card generation, feedback update, evidence association, and report generation into a reusable core engine. For scenarios such as inbound maintenance, outbound review, quality notification, recurring failure analysis, and special rectification, the system can achieve the migration and expansion from dedicated emergency templates to general operation and maintenance templates by replacing the trigger conditions, status nodes, handling card fields, information priorities, and report sections in the scenario configuration (template profile).

[0030] The method for generating emergency response questions and reports includes the following steps: The system receives operational failure event inputs, which include at least one of the following: fault code, vehicle identification, carriage or equipment location, train number or operation task, occurrence time, operation location, operation status, on-site description, and handling feedback. Through semantic parsing components and business data query components, the system extracts and completes event elements to construct an event state vector containing six state dimensions: fault status, on-site verification status, risk level, handling stage, data confidence, and input completeness.

[0031] Among the six status dimensions, fault status corresponds to fault code and its validity mark; on-site verification status corresponds to whether on-site verification has been completed; risk level corresponds to fault level and whether there is a linkage alarm; handling stage corresponds to operation or work status; data confidence corresponds to data source credibility mark; and input completeness corresponds to input field missing mark.

[0032] Based on the event state vector, related objects are retrieved in the fault code-equipment object-rules and regulations-disposal resource mapping library to construct an event chain diagram consisting of state nodes, verification nodes, action nodes, expected state nodes, and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints, and state transition rules.

[0033] The fault code-equipment-regulation-disposal resource mapping library should at least include the correspondence between fault codes and system components, the correspondence between system components and inspection items, the correspondence between inspection items and regulations or emergency plans, and the correspondence between inspection items and human-machine interface diagrams, simulation pages, graphic and textual work instructions, or video resources.

[0034] The verification nodes in the event chain diagram include at least one of the following: on-site phenomenon confirmation nodes, equipment status confirmation nodes, and regulatory applicability confirmation nodes. The escalation nodes include nodes that initiate confirmation requests to dispatchers, technical personnel, or authorized reviewers. The state transition rules at least define the preconditions, feedback conditions, and prohibition conditions required for the current node to enter the action node.

[0035] Based on the event chain diagram, the current state is ranked by risk, and necessary verification items and candidate disposal branches are generated. When the risk level corresponding to the current state is higher than the preset threshold, or the triggering conditions of the candidate disposal branch are not met, a verification card, a reporting card or a waiting instruction card is generated, and the generation of deterministic recovery conclusions corresponding to the failure to meet the triggering conditions is prohibited.

[0036] For candidate action branches that meet the triggering conditions, generate step-level action cards; each step-level action card includes at least the execution role, triggering prerequisite, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index, and visual resource index.

[0037] The step-level handling card is dynamically generated based on the authorized scope of the executing role, the location of the equipment, the current operating status, and the risk level. When the executing role does not have the corresponding operating authority, the handling resources are lacking, or the on-site risk has not been eliminated, the corresponding step-level handling card will be replaced with a reporting card or a waiting instruction card.

[0038] The visual resource index is used to call up human-machine interface diagrams, equipment part diagrams, simulation interaction pages, work instruction pages or historical case fragments that match the operation object and operation content, and displays the resource entry or resource identifier in the step-level operation card.

[0039] The question-and-answer interface is rendered according to the preset information priority. The current risk, necessary verification, prohibited items and the first step-level handling card are placed in the emergency execution area, the subsequent step-level handling cards are placed in the step-by-step handling area, and the vehicle basic configuration, operation information, maintenance history, historical cases, principle explanation and regulatory basis are placed in the information area that is expanded as needed.

[0040] The priority of preset information is determined by the operating status, risk level, and completeness of input. When the user only enters the fault code or the description of the equipment abnormality, the system outputs a brief Q&A result that includes the meaning of the fault, necessary supplementary information, and initial verification items. When the user enters the vehicle, location, operating status, and on-site feedback, the system outputs a complete Q&A result that includes a step-by-step handling card, relevant history, and a draft report.

[0041] Receive on-site feedback corresponding to the step-level handling card, update the event state vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next state.

[0042] The step-level handling cards, on-site feedback, data sources, timestamps, manual revision records, and rule verification results are linked into a field-level evidence chain. An emergency response report is automatically generated based on the field-level evidence chain. The emergency response report includes at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and cited evidence.

[0043] In the field-level evidence chain, each factual field is associated with at least one original business field, original data record, or knowledge entry, and each advisory field is associated with at least one corresponding event chain node, triggering condition, rule clause, or historical case. When a factual field lacks a traceable source, or an advisory field lacks a rule basis, the system marks the field as pending confirmation and prevents it from being output as the final report conclusion.

[0044] Emergency response reports are automatically filled in by on-site feedback. Automatic filling includes at least filling in the generation order and feedback timestamp of the step-level response cards in the response process field, filling in the expected phenomena that were met or not met in the response result field, filling in the escalation card or waiting instruction card in the risk control field, and filling in the visual resource index and rule basis in the attachment or reference field.

[0045] After the emergency response report is approved, the event status vector, event chain diagram, step-level handling card, on-site feedback, and field-level evidence chain are written into the case library. When generating similar fault handling results in the future, the case library is searched based on vehicle model, component, fault code, operating status, and closed-loop reliability, and only cases that meet the preset similarity and reliability thresholds are output as reference information. The status representation, event chain constraint, handling card generation, feedback update, evidence association, and report generation are used as reusable core engines. For scenarios such as inbound inspection, outbound review, quality notification, recurring fault analysis, or special rectification, the corresponding scenario trigger conditions, status nodes, handling card fields, and report chapters are replaced to generate a general operation and maintenance template.

[0046] Example 1: Overall Process.

[0047] like Figure 1 As shown, this embodiment is geared towards emergency response scenarios for rail transit operation failures. It completes the handling of operation failure events in three stages: event input and status construction, event chain and handling judgment, and question and answer feedback and report generation. It also forms a recyclable and updatable handling process through on-site feedback.

[0048] The system first enters the event input and status construction phase. It receives operational fault event inputs, which may include one or more of the following: fault code, vehicle identifier, location of the carriage or equipment, train number or operational task, occurrence time, operational location, operational status, on-site description, and handling feedback. The system processes, identifies, and supplements the received event information as necessary, and then proceeds accordingly. Figure 1 The "Event State Construction" node shown on the right side of the first stage forms an event state vector. The event state vector is used to represent six state dimensions: fault state, on-site verification state, risk level, handling stage, data confidence, and input completeness, providing a foundation for subsequent event chain construction and handling judgment.

[0049] After completion Figure 1After the "Event State Construction" node is processed and an event state vector is formed, the system enters the event chain and handling judgment stage. The system constructs an event chain based on the current event state, organizing the state facts, matters to be verified, action nodes, expected states, and escalation nodes according to the event development relationship, using the current node as the starting point for judgment. Subsequently, the system comprehensively considers the risk level, on-site verification results, action prerequisites, and prohibition conditions to perform risk judgment and branch determination. The "subsequent handling branches" referred to in this paper include action branches entered when conditions are met, and verification, reporting, or waiting branches entered when conditions are not met, the risk level is high, or further confirmation is required. This stage corresponds to... Figure 2 The "Premise and Risk Judgment" node; the risk constraint is the constraint mechanism adopted for this judgment.

[0050] when Figure 2 When the judgment result of the "Prerequisite and Risk Assessment" shown is satisfied, the system enters the step-level processing generation stage, forming... Figure 2 The "step-level processing card" shown is... Figure 1 The output of the "Step-Level Handling Generation" is shown. When the judgment result is not met, the system enters the verification, reporting, or waiting process. Verification is used to supplement unconfirmed on-site facts; reporting is a specific form of escalation handling, used to initiate a confirmation request to dispatching personnel, technical personnel, or authorized reviewers; waiting is used to pause the entry into the action branch when authorization, on-site conditions, or other triggering conditions are not yet met. The above process corresponds to... Figure 2 The "Verification / Upgrade Waiting Card" branch does not generate definitive disposal conclusions corresponding to unmet conditions.

[0051] Step-level handling cards, verification cards, reporting cards, or waiting instruction cards all enter the Q&A feedback and report generation stage as the generation results of the current branch. The system first displays a phased Q&A, showing the user information and handling content corresponding to the current event status based on the current handling stage, so that the content that needs to be executed or confirmed and subsequent auxiliary information are presented step by step according to the handling process.

[0052] After users complete the corresponding operations or verifications according to the content displayed in the phased Q&A, the system receives on-site feedback and executes the on-site feedback and status update. On-site feedback reflects the execution status of the current step, changes in the on-site status, and whether the conditions for continued handling are met. The system updates the current event status based on the on-site feedback and determines the subsequent process accordingly. When the on-site feedback indicates that the event still needs to be handled, the system returns the updated event status to the risk assessment and branch determination stage for updating and reassessing. Based on the new assessment result, it generates subsequent step-level handling content, or enters the corresponding verification, reporting, or waiting process, thus forming a closed-loop handling process based on continuously updated on-site feedback.

[0053] When on-site feedback indicates that the current event has met the conditions for termination, the system moves from the on-site feedback and status update phase to the evidence association and automatic report generation phase. The system associates event information, step-by-step handling details, on-site feedback, relevant data sources, time information, and the basis for the handling process, ensuring that the relevant content in the report corresponds to the actual handling process. Based on this, an emergency response report is automatically generated. The generated emergency response report records the event overview, handling process, handling results, analysis conclusions, follow-up handling recommendations, and relevant cited evidence.

[0054] Therefore, this embodiment forms an overall process of "operational failure event input—event status construction—event chain construction—risk assessment and branch determination—step-level handling generation or verification, reporting, and waiting—phased Q&A display—on-site feedback and status update—evidence association and automatic report generation." The on-site feedback and status update can either proceed to the report generation stage after the handling is completed, or return to the risk assessment and branch determination stage for reassessment when further handling is needed. This allows the emergency handling process for operational failures to continuously adjust according to changes in the on-site status, ultimately generating an emergency handling report corresponding to the actual handling process.

[0055] Example 2: Event chain construction and step-level handling card.

[0056] like Figure 2 As shown, the event chain diagram starts with the fault code-equipment object mapping, mapping fault codes to relevant systems, components, applicable vehicle models, or equipment types. It then uses rule and knowledge mapping to obtain contingency plan clauses, inspection items, prohibited items, historical cases, and resource indexes. Based on this information, the system constructs a graph structure where status nodes describe known facts, verification nodes describe on-site facts requiring confirmation, action nodes describe constrained operational tasks, expected status nodes describe observable results after the operation, and escalation nodes describe situations requiring confirmation from professionals, dispatchers, or authorized reviewers.

[0057] Each action node must store at least the following: 1. Triggering prerequisites, such as completion of a site verification, equipment being in an inspection-permitted state, or necessary authorization being obtained; 2. The object of operation, such as a carriage, equipment cabinet, control interface, or specific component; 3. The operation content; 4. Prohibited items; 5. The executing role and execution time limit; 6. Expected phenomena and feedback entry points; 7. The basis index and visual resource index. If the triggering prerequisites of an action node are not met, the action branch will not be entered.

[0058] When the current status is high-risk or necessary verification has not yet been completed, the event chain remains at the verification node or escalation node, without proceeding to the action node. Upon receiving verification feedback, the system updates the on-site verification status and risk level. Only when necessary verification is completed, the risk level is not higher than a preset threshold, and the action prerequisites are met, is the current node moved to the action branch and a step-level handling card generated; otherwise, a verification card, a reporting card, or a waiting instruction card is generated. The reporting card is a specific implementation of the escalation card, therefore... Figure 2 The “Verification / Upgrade Waiting Card” in the document corresponds to the verification, reporting, or waiting branch in Implementation Example 1.

[0059] The system can configure step-level handling cards as structured data objects, such as: {Execution Role, Triggering Prerequisite, Operation Object, Operation Content, Prohibited Items, Execution Time Limit, Expected Phenomenon, Feedback Entry Point, Basis Index, Visual Resource Index, Card Identifier, Current Node Identifier, Generation Time, Verification Status}. The first ten items correspond one-to-one with the fields of the step-level handling card, while the last four are additional management fields. The Triggering Prerequisite, Expected Phenomenon, Basis Index, and Visual Resource Index can store one or more values, and the Feedback Entry Point can configure one or more feedback options. The Basis Index can be associated with fault code tables, emergency plans, technical regulations, maintenance manuals, or historical cases that have been reviewed and closed-loop. The Visual Resource Index can be associated with human-machine interface diagrams, part diagrams, simulation pages, or graphic descriptions.

[0060] When on-site feedback indicates that the expected phenomenon has not occurred, new linked alarms have been detected, the risk level has increased, or the action cannot be executed, the event chain diagram switches to the abnormal branch or the escalation branch. This mechanism allows the system to change the next task based on feedback, rather than repeatedly outputting the same fixed suggestion.

[0061] Example 3: The phased Q&A interface and report fields are linked.

[0062] like Figure 3 As shown, the system divides the output into an emergency execution area, a step-by-step handling area, an information area that can be expanded as needed, and a handling record-report field linkage area. The emergency execution area is displayed first when the user initiates a Q&A or risk level update for the first time. The content includes the current risk level, the on-site phenomena that must be confirmed immediately, prohibited items, and the first step-level handling card; this area avoids displaying a large amount of static history information.

[0063] The step-by-step handling area displays subsequent cards according to the current branch of the event chain. After each user feedback, the system marks the current card as completed, incomplete, abnormal, or pending confirmation, and refreshes the next card based on the feedback. For queries that only input fault codes, the system can only display the fault meaning, necessary supplementary fields, and the initial verification card; for queries that input complete event elements such as vehicle, operating status, and on-site feedback, the system then expands the maintenance history, historical cases, and complete report drafts related to the vehicle and operating task.

[0064] The system dynamically adjusts the display hierarchy of the above areas based on the granularity of user queries, the completeness of input, the stage of handling, and the risk level. When there are few input fields, the draft report only generates fields with reliable sources and marks missing fields as to be supplemented or confirmed. As users supplement information or provide on-site feedback, the system expands the corresponding information areas level by level and updates the filled, confirmed, and inapplicable status of the report fields in sync, so that the scope of the interface display corresponds to the completeness of the report fields.

[0065] The information area that can be expanded on demand can include at least the vehicle's basic configuration, operation information, maintenance history, equipment health status, historical cases, system principles, and regulatory basis. The system anonymizes or hides sensitive fields such as personnel information, contact information, precise location, and internal links based on user roles and access permissions.

[0066] The information area that expands on demand is collapsed by default during the initial Q&A and emergency response phases, retaining only the area identifier, summary, or expansion entry. When a user actively queries, the current step requires access to corresponding resources, or the risk status is reduced to the point where viewing auxiliary information is permitted, the system expands the corresponding content according to access permissions. Collapsing only changes the interface display and does not delete the already acquired data or its evidence index.

[0067] The handling record—report field linkage area stores the generation time, confirmation time, feedback content, corresponding event chain node, data source, rule basis, and manual revision information for each card. When a report is generated, the system maps these records to fields such as "Event Overview," "Handling Process," "Risk Control," "Analysis Conclusion," "Follow-up Recommendations," "Cited Basis," and "Attachment Index." For factual fields lacking evidence sources or recommendation fields lacking rule basis, the system automatically marks them as pending confirmation.

[0068] Example 4: High-risk constraints, permissions, and chain of evidence.

[0069] In a preferred embodiment, the risk constraint module uses rule thresholds and semantic recognition results to jointly determine whether deterministic recommendations need to be intercepted. Interception conditions include, but are not limited to: the on-site verification status is unknown, there are multiple system linkage anomalies, the fault level exceeds the preset level, the required regulations and clauses are not found, the handling card lacks key prerequisites, the authorization level of the execution role is insufficient, or the credibility of the data source is lower than the threshold.

[0070] After an interception is triggered, the content generated by the system is limited to verification prompts, risk warnings, reporting requests, requests for authorization, requests for supplementary information, or manual confirmation tasks. Unverified hypothetical judgments will not be output as handling conclusions. For example, the system may prompt for confirmation of relevant on-site phenomena, confirmation of whether there are related alarms, requests for authorization, or requests for remote confirmation from professionals, but will not output conclusions such as "operation can be resumed" or "fault has been resolved" when the conditions are not met.

[0071] The field-level evidence chain is recorded using metadata such as field identifiers, source systems or knowledge entries, collection time, original values, cleaned values, associated event chain nodes, calculation rules, model versions, verification results, and manual revision records. For factual information in the report, such as numerical values, times, vehicle identifiers, and fault codes, the system verifies them through field matching and time logic checks. For recommendations, cause analyses, and back-to-database measures, the system checks whether they are associated with regulatory clauses, event chain nodes, or trusted historical cases.

[0072] The system sets access controls for different roles. The execution role can view necessary content and resource entry points related to the current action; the review role can view the complete evidence chain and version differences; and the management role can view anonymized and aggregated case studies and statistical results. This permission mechanism is not based on specific organizations, job titles, or personal information and can be applied to the business architecture of different rail transit operating organizations.

[0073] Example 5: Extension from dedicated emergency templates to general operation and maintenance templates.

[0074] like Figure 4 As shown, this invention is not limited to generating emergency response reports for operational failures. The reusable core engine for emergency response scenarios includes state representation, event chain construction, response card generation, feedback updates, evidence association, and report generation.

[0075] Figure 4The scenario configuration shown is implemented using a template profile. The template profile includes at least a scenario identifier, a set of trigger conditions, an input field structure, a status node type, a disposal card field or type, information priority, chart generation rules, report chapter mapping, permission rules, and archiving rules. The reusable core engine reads the scenario configuration (template profile) to determine the initial node of the event chain, available branches, card structure, interface display hierarchy, and report field mapping. When switching maintenance scenarios, migration is completed by replacing or adjusting the corresponding configurations, without changing the fundamental logic of event chain construction, evidence association, and feedback processing.

[0076] For inbound maintenance scenarios, the trigger conditions can be replaced with inbound tasks, travel mileage, items to be inspected, and fault history; the status nodes can be replaced with maintenance preparation, work execution, test confirmation, and quality release nodes; the step-level handling cards can be replaced with maintenance task cards, tool cards, material cards, and test cards; and the report chapters can be replaced with inbound overview, maintenance items, problems found, test results, and pending items.

[0077] For outbound review scenarios, the triggering conditions can be replaced with outbound application, key test results, and release conditions; the status nodes can be replaced with test completion, defect closure, authorization confirmation, and release status; and the report sections can be replaced with outbound verification, anomaly closure, release conclusion, and risk warning. For quality notification or recurring failure analysis scenarios, the status nodes can be replaced with statistical caliber confirmation, sample screening, trend analysis, cause summarization, and improvement measure tracking nodes.

[0078] The aforementioned extension only changes the triggering conditions, field structure, status nodes, disposal card types, information priorities, chart rules, and report sections in the scenario configuration (template profile), while retaining the core processing logic of status representation, event chain construction, disposal card generation, feedback updates, evidence association, and report generation. The migrated templates automatically backfill step feedback, node status changes, and review records into the corresponding scenario's report fields based on the new report section mapping. Therefore, this invention, while highlighting the current application value of emergency response, can form a universal template system that can be extended to multiple types of rail transit operation and maintenance tasks.

[0079] Example 6: Report output, review and case reuse.

[0080] The report generation module can output approved content as web pages, platform forms, editable documents, or archiveable files. Output objects include the report text, structured fields, action card records, cited evidence, charts, attachment indexes, and field-level evidence chains. The system supports automatic synchronization, post-approval synchronization, scheduled synchronization, or manual synchronization to the operations and maintenance management platform, archive system, knowledge base, or message notification system.

[0081] After each review, the system generates a unique archive identifier for the event and saves the card version, feedback record, rule verification result, and manual revision record as auditable data. If subsequent similar events meet the similarity thresholds for vehicle model or equipment type, component, fault code, operating status, and event chain structure, the system can reference historical cases that have been reviewed and closed-loop, and clearly state in the Q&A and reports that they are used as reference information rather than current event facts.

[0082] Example 7: Fault Emergency Response Q&A and Report Generation System.

[0083] This invention also provides a fault emergency response question and answer and report generation system, comprising: The fault event input and status construction module is used to receive operational fault event inputs, extract and complete event elements, and construct an event status vector containing six status dimensions: fault status, on-site verification status, risk level, handling stage, data confidence, and input completeness. The event chain construction and handling judgment module is used to retrieve related objects in the fault code-equipment object-rule clause-handling resource mapping library according to the event state vector, and construct an event chain diagram composed of state nodes, verification nodes, action nodes, expected state nodes, and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints, and state transition rules; and is used to sort the current state by risk based on the event chain diagram, generate necessary verification items and candidate handling branches; when the risk level corresponding to the current state is higher than a preset threshold, or the triggering condition of the candidate handling branch is not met, a verification card, a reporting card, or a waiting instruction card is generated, and the generation of deterministic recovery conclusions corresponding to the failure to meet the triggering conditions is prohibited; The step-level handling card generation module is used to generate step-level handling cards for candidate handling branches that meet the triggering conditions. Each step-level handling card includes at least the execution role, triggering premise, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index and visual resource index. The phased question-and-answer interaction module is used to render the question-and-answer interface according to the preset information priority, placing the current risk, necessary verification, prohibited items and the first step-level handling card in the emergency execution area, the subsequent step-level handling cards in the step-by-step handling area, and non-real-time information in the information area that can be expanded as needed; and is used to receive on-site feedback corresponding to the step-level handling cards. The status feedback and update module is used to update the event status vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next status; The evidence association and report generation module is used to associate the step-level handling cards, on-site feedback, data sources, timestamps, manual revision records, and rule verification results into a field-level evidence chain, and automatically generate an emergency response report based on the field-level evidence chain. The emergency response report includes at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and cited evidence.

[0084] The system for automatically generating emergency response questions and reports for operational failures also includes a risk constraint and access control module, which limits the system output to verification prompts, risk warnings, reporting requests, pending authorization, requests for supplementary information, or manual confirmation tasks when interception conditions are triggered, and does not output unverified definitive handling conclusions; the interception conditions include at least one of the following: the on-site verification status is unknown, there is an anomaly in the linkage of multiple systems, the fault level exceeds the preset level, the required regulations and clauses are not found, the handling card lacks key prerequisites, the authorization level of the execution role is insufficient, or the credibility of the data source is lower than the threshold.

[0085] The present invention also provides an electronic device, comprising: one or more processors; and a storage device for storing one or more programs; wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method as described above.

[0086] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0087] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the present invention. For those skilled in the art, any equivalent substitutions or improvements made to the event state vector field, event chain node type, step-level handling card field, resource index format, report output format, and general template range without departing from the core idea of ​​the present invention should fall within the protection scope of the present invention.

Claims

1. A method for generating Q&A and reports for emergency fault handling, characterized in that, Includes the following steps: Step 1: Receive operational failure event input, extract and complete event elements, and construct an event state vector containing six state dimensions: failure status, on-site verification status, risk level, handling stage, data confidence level, and input completeness. Step 2: Based on the event state vector, retrieve related objects in the fault code-equipment object-rules and regulations-disposal resource mapping library, and construct an event chain diagram consisting of state nodes, verification nodes, action nodes, expected state nodes, and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints, and state transition rules. Step 3: Based on the event chain diagram, sort the current state by risk and generate necessary verification items and candidate disposal branches; When the risk level corresponding to the current state is higher than the preset threshold, or the triggering conditions of the candidate disposal branch are not met, a verification card, a reporting card, or a waiting instruction card is generated, and the generation of a deterministic recovery conclusion corresponding to the failure to meet the triggering conditions is prohibited. Step 4: For candidate handling branches that meet the triggering conditions, generate step-level handling cards; each step-level handling card should include at least the execution role, triggering premise, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index and visual resource index; Step 5: Render the Q&A interface according to the preset information priority, place the current risk, necessary verification, prohibited items and the first step-level handling card in the emergency execution area, place the subsequent step-level handling cards in the step-by-step handling area, and place non-real-time information in the information area that can be expanded as needed. Step 6: Receive on-site feedback corresponding to the step-level handling card, update the event state vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next state; Step 7: Associate the step-level handling card, on-site feedback, data source, timestamp, manual revision record, and rule verification result into a field-level evidence chain, and automatically generate an emergency response report based on the field-level evidence chain. The emergency response report shall include at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and a list of cited evidence.

2. The fault emergency response question and report generation method according to claim 1, characterized in that: In step 1, the operational failure event input includes at least one of the following: fault code, vehicle identification, carriage or equipment location, train number or operational task, occurrence time, operational location, operational status, on-site description, and handling feedback.

3. The fault emergency response question and report generation method according to claim 1, characterized in that, In step 2, the fault code-equipment object-regulation clause-disposal resource mapping library includes at least the correspondence between fault codes and system components, the correspondence between system components and inspection items, the correspondence between inspection items and regulations or emergency plans, and the correspondence between inspection items and human-machine interface diagrams, simulation pages, graphic operation manuals or video resources.

4. The fault emergency response question and report generation method according to claim 3, characterized in that, In step 2, the verification node includes at least one of the following: on-site phenomenon confirmation node, equipment status confirmation node, and regulatory applicability confirmation node. The upgrade node includes a node that initiates a confirmation request to the dispatching and command personnel, professional and technical personnel, or authorized review personnel. The state transition rule at least defines the preconditions, feedback conditions, and prohibition conditions required for the current node to enter the action node.

5. The fault emergency response question and report generation method according to claim 1, characterized in that, In step 4, the step-level handling card is dynamically generated based on the authorized scope of the execution role, the device location, the current operating status, and the risk level. When the execution role does not have the corresponding operation authority, the handling resources are missing, or the on-site risk has not been eliminated, the corresponding step-level handling card is replaced with a reporting card or a waiting instruction card.

6. The fault emergency response question and report generation method according to claim 5, characterized in that, In step 4, the visual resource index is used to call up human-machine interface diagrams, equipment part diagrams, simulation interaction pages, work instruction pages or historical disposal case fragments that match the operation object and operation content, and to display resource entry or resource identifiers in the step-level disposal card.

7. The fault emergency response question and report generation method according to claim 1, characterized in that, In step 5, the priority of the preset information is determined by the operating status, risk level, and input completeness. When the user only inputs the fault code or the description of the equipment abnormality, the system outputs a brief Q&A result that includes the fault meaning, necessary supplementary information, and initial verification items. When the user inputs the vehicle, location, operating status, and on-site feedback, the system outputs a complete Q&A result that includes a step-by-step handling card, relevant history, and a draft report.

8. The fault emergency response question and report generation method according to claim 7, characterized in that, The information area that can be expanded on demand includes at least the vehicle's basic configuration, operation information, maintenance history, historical cases, principle explanations, and regulatory basis.

9. The fault emergency response question and report generation method according to claim 1, characterized in that, In step 7, in the field-level evidence chain, each factual field is associated with at least one original business field, original data record, or knowledge entry, and each advisory field is associated with at least one corresponding event chain node, triggering condition, rule clause, or historical case. When a factual field lacks a traceable source, or an advisory field lacks a rule basis, the system marks the field as pending confirmation and prevents it from being output as the final report conclusion.

10. The fault emergency response question and report generation method according to claim 9, characterized in that, In step 7, the emergency response report is automatically filled in by on-site feedback. The automatic filling includes filling in the generation order and feedback timestamp of the step-level response card into the response process field, filling in the expected phenomena that are met or not met into the response result field, filling in the upgrade card or waiting instruction card into the risk control field, and filling in the visual resource index and rule basis into the attachment or reference field.

11. The fault emergency response question and report generation method according to any one of claims 1 to 10, characterized in that, Also includes: After the emergency response report is approved, the event status vector, event chain diagram, step-level response card, on-site feedback, and field-level evidence chain will be written into the case library. When generating similar fault handling results in the future, the case library is searched based on vehicle model, component, fault code, operating status and closed-loop reliability, and only cases that meet the preset similarity and reliability thresholds are output as reference information.

12. A fault emergency response question-and-answer and report generation system, characterized in that, include: The fault event input and status construction module is used to receive operational fault event inputs, extract and complete event elements, and construct an event status vector containing six status dimensions: fault status, on-site verification status, risk level, handling stage, data confidence, and input completeness. The event chain construction and handling judgment module is used to retrieve related objects in the fault code-equipment object-rule clause-handling resource mapping library according to the event state vector, and construct an event chain diagram consisting of state nodes, verification nodes, action nodes, expected state nodes and escalation nodes; adjacent nodes of the event chain diagram are connected by triggering conditions, risk constraints and state transition rules; It is also used to rank the current state by risk based on the event chain graph, and generate necessary verification items and candidate disposal branches; When the risk level corresponding to the current state is higher than the preset threshold, or the triggering conditions of the candidate disposal branch are not met, a verification card, a reporting card, or a waiting instruction card is generated, and the generation of a deterministic recovery conclusion corresponding to the failure to meet the triggering conditions is prohibited. The step-level handling card generation module is used to generate step-level handling cards for candidate handling branches that meet the triggering conditions. Each step-level handling card includes at least the execution role, triggering premise, operation object, operation content, prohibited items, execution time limit, expected phenomenon, feedback entry, basis index and visual resource index. The phased question-and-answer interaction module is used to render the question-and-answer interface according to the preset information priority, placing the current risk, necessary verification, prohibited items and the first step-level handling card in the emergency execution area, the subsequent step-level handling cards in the step-by-step handling area, and non-real-time information in the information area that can be expanded as needed; and is used to receive on-site feedback corresponding to the step-level handling cards. The status feedback and update module is used to update the event status vector and event chain diagram using the on-site feedback, and redetermine the step-level handling card, upgrade card or end card corresponding to the next status; The evidence association and report generation module is used to associate the step-level handling cards, on-site feedback, data sources, timestamps, manual revision records, and rule verification results into a field-level evidence chain, and automatically generate an emergency response report based on the field-level evidence chain. The emergency response report includes at least an event overview, handling process, analysis conclusions, follow-up handling suggestions, and cited evidence.

13. The fault emergency response question and report generation system according to claim 12, characterized in that, Also includes: The risk constraint and access control module is used to limit the system output to verification prompts, risk warnings, reporting requests, pending authorization, supplementary information requests, or manual confirmation tasks when interception conditions are triggered, and to prevent the output of unverified definitive handling conclusions. The interception conditions include at least one of the following: the on-site verification status is unknown, there is an anomaly in the linkage of multiple systems, the fault level exceeds the preset level, the required regulations and clauses are not found, the handling card lacks key prerequisites, the authorization level of the execution role is insufficient, or the credibility of the data source is lower than the threshold.

14. An electronic device, characterized in that, include: One or more processors; as well as Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1 to 11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 11.

Images