Rail transit operation safety-oriented risk knowledge extraction method and system

Abstract

The application provides a risk knowledge extraction method and system for rail transit operation safety. The method comprises the following steps: performing term normalization, encoding mapping and time normalization processing on the obtained data to obtain standardized data; generating risk scenario fragments based on a risk ontology and a risk event pattern; performing joint extraction of entities, attributes, relationships and events based on the risk scenario fragments, and performing constraint checking to obtain candidate risk knowledge; performing time anchor point identification, space anchor point identification and rail transit topology mapping on the candidate risk knowledge to obtain spatio-temporal correlation knowledge units; performing evidence fusion and conflict resolution on the spatio-temporal correlation knowledge units corresponding to different data sources to generate risk knowledge fragments; assembling risk evolution chains based on the risk knowledge fragments, and outputting a rail transit operation safety risk knowledge extraction result. The application can improve the multi-source risk data extraction efficiency, enhance the risk knowledge correlation integrity, and improve the cross-source knowledge fusion consistency.

Description

Technical Field

[0001] This application relates to the field of rail transit technology, and in particular to a method and system for extracting risk knowledge for rail transit operation safety. Background Technology

[0002] As urban rail transit networks continue to expand, operational organization is becoming increasingly networked, denser, and more collaborative. The sources of operational safety risks have expanded from single equipment failures to complex risks resulting from the coupling of equipment status, passenger flow changes, environmental disturbances, operational activities, and management factors. To improve operational safety management, the industry is increasingly utilizing information such as accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, and monitoring data for risk identification, event analysis, and knowledge management. Existing technologies typically employ text parsing, entity recognition, relation extraction, or event extraction to extract risk-related information from unstructured text or structured records, or to organize and query risk knowledge by constructing knowledge bases and knowledge graphs.

[0003] However, most existing technologies process single data sources or single text types, making it difficult to uniformly extract structured, semi-structured, unstructured text data, and voice or image-converted data. Furthermore, existing technologies do not adequately consider temporal and spatial cues, object switching relationships, and event evolution relationships in rail transit operation safety scenarios, easily leading to fragmented extraction results and making it difficult to form complete risk knowledge corresponding to actual operational scenarios. In addition, the same risk fact from different data sources often presents different or even conflicting descriptions; existing technologies lack effective evidence fusion and conflict resolution mechanisms, resulting in poor consistency in extraction results and difficulty in supporting subsequent risk correlation analysis and evolution chain assembly. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a method and system for extracting risk knowledge for rail transit operation safety, in order to solve the problems of difficulty in uniformly extracting multi-source risk data, incomplete association of risk knowledge, and easy conflict of cross-source results in the prior art.

[0005] A first aspect of this application provides a method for extracting risk knowledge for rail transit operation safety, comprising: acquiring structured data, semi-structured data, unstructured text data, and speech or image conversion data related to rail transit operation safety; performing terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data; based on risk ontology and risk event patterns for rail transit operation safety, performing chapter boundary identification, time clue identification, spatial clue identification, and object switching identification on the standardized data to generate risk scene fragments; performing joint extraction of entities, attributes, relationships, and events based on the risk scene fragments, and performing constraint verification in conjunction with risk ontology and risk event patterns to obtain candidate risk knowledge; performing time anchor point identification, spatial anchor point identification, and rail transit topology mapping on the candidate risk knowledge to obtain spatiotemporally related knowledge units; performing evidence fusion and conflict resolution on the spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; assembling a risk evolution chain based on the risk knowledge fragments, and outputting the rail transit operation safety risk knowledge extraction results.

[0006] A second aspect of this application provides a risk knowledge extraction system for rail transit operation safety, comprising: an acquisition module for acquiring structured data, semi-structured data, unstructured text data, and voice or image conversion data related to rail transit operation safety, and performing terminology normalization, encoding mapping, and time normalization processing on the acquired data to obtain standardized data; an identification module for performing chapter boundary identification, time clue identification, spatial clue identification, and object switching identification on the standardized data based on risk ontology and risk event patterns for rail transit operation safety to generate risk scene fragments; an extraction module for performing joint extraction of entities, attributes, relationships, and events based on risk scene fragments, and performing constraint verification in conjunction with risk ontology and risk event patterns to obtain candidate risk knowledge; a mapping module for performing time anchor point identification, spatial anchor point identification, and rail transit topology mapping on the candidate risk knowledge to obtain spatiotemporally related knowledge units; a fusion module for performing evidence fusion and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; and an assembly module for assembling risk evolution chains based on risk knowledge fragments and outputting the rail transit operation safety risk knowledge extraction results.

[0007] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0008] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0009] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This application acquires structured, semi-structured, and unstructured text data related to rail transit operation safety, as well as voice or image conversion data. It then performs terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data. Based on risk ontology and risk event patterns for rail transit operation safety, it performs chapter boundary identification, time clue identification, spatial clue identification, and object switching identification on the standardized data to generate risk scene fragments. Based on these risk scene fragments, it performs joint extraction of entities, attributes, relationships, and events, and performs constraint verification in conjunction with risk ontology and risk event patterns to obtain candidate risk knowledge. It then performs time anchor point identification, spatial anchor point identification, and rail transit topology mapping on the candidate risk knowledge to obtain spatiotemporally related knowledge units. Finally, it performs evidence fusion and conflict resolution on the spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments. Based on these risk knowledge fragments, it assembles a risk evolution chain and outputs the rail transit operation safety risk knowledge extraction results. This application can improve the efficiency of multi-source risk data extraction, enhance the integrity of risk knowledge association, and improve the consistency of cross-source knowledge fusion. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating the risk knowledge extraction method for rail transit operation safety provided in an embodiment of this application. Figure 2 This is a schematic diagram of the structure of the risk knowledge extraction device for rail transit operation safety provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0013] In existing technologies, rail transit operation safety management typically relies on information such as accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, and monitoring data to conduct risk identification and event analysis. For this data, existing solutions usually employ methods such as text parsing, entity recognition, relation extraction, event extraction, or knowledge graph construction to extract risk-related knowledge from a single text type or data source, and then use the extracted results for knowledge organization, retrieval queries, or auxiliary analysis.

[0014] However, with the increasing complexity of rail transit operation scenarios, risk information is widely distributed across structured data, semi-structured data, unstructured text data, and voice or image-converted data. Significant differences exist between different data sources in terms of expression methods, temporal granularity, spatial granularity, and object reference methods. Most existing technologies lack a unified extraction mechanism for multi-source heterogeneous data and do not adequately consider temporal clues, spatial clues, object switching relationships, and event evolution relationships. This results in fragmented risk knowledge that is difficult to form a complete knowledge chain corresponding to actual operational scenarios. Furthermore, for differing descriptions of the same risk fact from different data sources, existing technologies typically lack effective evidence fusion and conflict resolution mechanisms, leading to poor consistency in cross-source extraction results.

[0015] Based on this, the technical problems to be solved by this application are: difficulty in uniformly extracting multi-source risk data, incomplete association of risk knowledge, and easy conflict of cross-source results.

[0016] To address the aforementioned technical issues, this application provides a method for extracting risk knowledge related to rail transit operation safety. The method first acquires structured, semi-structured, and unstructured text data, as well as speech or image conversion data, related to rail transit operation safety. It then performs terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data. Next, based on a pre-defined rail transit operation safety risk ontology and risk event patterns, it performs text boundary identification, time clue identification, spatial clue identification, and object switching identification on the standardized data to generate risk scenario fragments. Based on these, it performs joint extraction of entities, attributes, relationships, and events from the risk scenario fragments, and performs constraint verification in conjunction with the risk ontology and risk event patterns to obtain candidate risk knowledge. Further, it performs time anchor point identification, spatial anchor point identification, and rail transit topology mapping on the candidate risk knowledge to obtain spatiotemporally related knowledge units. It then performs evidence fusion and conflict resolution on the spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments. Finally, it assembles a risk evolution chain based on the risk knowledge fragments and outputs the rail transit operation safety risk knowledge extraction results.

[0017] Through the above technical solutions, this application can improve the efficiency of multi-source risk data extraction, enhance the integrity of risk knowledge association, and improve the consistency of cross-source knowledge fusion.

[0018] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0019] Figure 1 This is a flowchart illustrating the risk knowledge extraction method for rail transit operation safety provided in an embodiment of this application. Figure 1 As shown, the method may specifically include: S101: Acquire structured data, semi-structured data, unstructured text data, and voice or image conversion data related to rail transit operation safety, and perform terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data; S102, based on the risk ontology and risk event patterns for rail transit operation safety, performs chapter boundary identification, time clue identification, spatial clue identification and object switching identification on standardized data to generate risk scenario fragments; S103, based on risk scenario fragments, performs joint extraction of entities, attributes, relationships and events, and combines risk ontology and risk event patterns for constraint verification to obtain candidate risk knowledge; S104, perform time anchor point identification, spatial anchor point identification and rail transit topology mapping on candidate risk knowledge to obtain spatiotemporally related knowledge units; S105, perform evidence fusion and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; S106 assembles a risk evolution chain based on risk knowledge fragments and outputs the results of extracting knowledge about rail transit operation safety risks.

[0020] In some embodiments, terminology normalization, encoding mapping, and time normalization are performed on the acquired data to obtain standardized data, including: Obtain accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, monitoring data, and audio-visual data related to rail transit operation safety; According to the data organization form, the acquired data is subjected to structured parsing, semi-structured layout parsing, unstructured text parsing, and speech recognition or image text recognition to obtain the corresponding initial content units; Based on a pre-defined rail transit terminology system, object coding system, and data time benchmark, the initial content units are subjected to object identification association, terminology alias merging, field semantic alignment, and time expression unification to generate standardized data associated with data source identifiers.

[0021] Specifically, the standardized data generation process is used to uniformly organize rail transit operation safety-related data from different sources, in different formats, and with different representations, so that subsequent risk scenario fragment generation, joint extraction, and evidence fusion can be based on a consistent data representation. This process is not a simple aggregation of raw data, but rather focuses on four core information categories in rail transit operation safety scenarios: objects, events, time, and space. It performs categorized parsing, semantic normalization, and unified labeling processing on multi-source heterogeneous data.

[0022] In this embodiment, the rail transit terminology system refers to a pre-built set of terms and their corresponding relationships for rail transit operation safety scenarios, used to unify equipment names, operation names, risk status names, event description names, and spatial location names. This terminology system not only includes standard terms but also mappings between abbreviations, aliases, historical terms, and colloquial terms. For example, "upward platform screen door malfunction," "upward platform screen door anomaly," and "upward side platform screen door failure" can be grouped into unified target terms within the terminology system.

[0023] Data time base refers to a unified time reference system consisting of time formats, time zone rules, shift start and end rules, and relative time interpretation rules for various types of data. It is used to convert different forms of time descriptions such as "07:35", "during the morning rush hour", "before the first bus", and "5 minutes after a breakdown" into a comparable and sortable unified time representation.

[0024] An initial content unit refers to the smallest semantic processing unit formed after the original data has been parsed and categorized. It can be a structured field record, a table row record, paragraph text, sentence fragments, speech-to-text segments, image recognition text blocks, or a set of metadata associated with it.

[0025] In its implementation, this embodiment employs a categorized parsing approach to address the differences in accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, monitoring data, and audio / video data. For structured data such as monitoring data, equipment status tables, alarm records, and work order databases, the system prioritizes reading field names, field values, primary keys, timestamps, equipment codes, and site codes, and forms structured record units based on preset relationships between fields.

[0026] For semi-structured data such as regulatory documents, standardized checklists, and report templates with fixed heading levels, the focus is on performing layout parsing and hierarchy restoration to identify headings, chapters, entries, notes, and table blocks, so that the constraints, scope of application, implementing entities, and processing requirements in the document can be extracted into referable layout semantic units.

[0027] For unstructured text data such as accident reports, fault analysis descriptions, on-site records, and meeting minutes, text cleaning, paragraph segmentation, sentence group division, and domain terminology recognition are performed to form text content units that can be used for object recognition and event recognition.

[0028] For audio and video data such as dispatch recordings, station intercom recordings, video inspection footage, and monitoring clips with subtitles, speech recognition or image text recognition is performed first. Then, the recognition results are associated with the original timestamp, speaking turn, screen position, or video clip number to generate transcribed content units with time source information.

[0029] Furthermore, after the above-mentioned classification and parsing are completed, this embodiment further performs unified standardization processing on the obtained initial content units. Object identifier association is used to identify the lines, stations, sections, trains, equipment, positions, or work objects involved in the initial content units and map them to unified identifiers in the object coding system. For example, if a maintenance work order records "Elevator A at this station is out of service," and a fault record records "Elevator A at station is faulty," the system can associate the two with the same equipment object based on the station identifier, entrance / exit identifier, and equipment category.

[0030] In some examples, terminology aliasing is used to merge different terms from various sources into a unified terminology. For example, it groups "surge in passenger flow," "large instantaneous passenger flow," and "abnormally high concourse congestion" into the same category of passenger flow anomalies. Semantic alignment of fields is used to resolve inconsistencies in the meaning of the same field or different field names pointing to the same meaning in different data sources. For example, it aligns occurrence time, alarm time, reporting time, and recording time into a unified time field, and aligns location, station, station location, and interval location into a unified spatial field. Unified time representation is achieved by converting absolute time, relative time, interval time, and operating period expressions into a unified standard time representation based on the data time base. When necessary, it can also combine train timetables, schedules, and dispatch calendars to convert operational time expressions such as morning peak hours, nighttime maintenance windows, and after the last train into corresponding time intervals.

[0031] The implementation process of this embodiment is illustrated below with a specific example. Taking an operational scenario where abnormal passenger flow occurs at a station on a certain line, accompanied by an alarm for abnormal platform screen doors, as an example, the data acquired by the system includes: an incident report stating, "At 18:12, there was significant passenger gathering on the station's up platform, and local congestion occurred at 18:15"; a dispatch log stating, "At 18:16, the station was notified to implement flow control measures"; a maintenance work order stating, "The No. 3 door of the up platform screen door is malfunctioning, and repair was reported at 18:14"; a set of monitoring data, including passenger flow density curves for the station hall and platform; and a recording of a station duty call, which identifies that "There is an abnormality in the up platform screen door, and the passenger flow is overwhelming; flow control should be implemented first." For the above data, the system first performs incident report text parsing, structured reading of the dispatch log, field extraction of the maintenance work order, field extraction of monitoring data, and voice recognition of the recorded speech, respectively, to obtain multiple initial content units.

[0032] Then, based on the rail transit professional terminology system, platform screen doors, platform gates, and door bodies were merged into a unified terminology, and flow control and flow restriction measures were merged into a unified handling terminology; based on the object coding system, the No. 3 door of the up platform and the No. 3 door body of the up platform screen door were associated as the same equipment object; based on the data time base, the relative occurrence order of "18:12", "18:14", "18:16" and the audio clips were uniformly organized onto the same time axis; at the same time, the up platform of the station in the accident report, the No. 3 door body of the up platform screen door in the work order, and the corresponding sensor area in the monitoring data were mapped to a unified spatial identifier.

[0033] After the above processing, the descriptions that were originally scattered in multiple documents were organized into standardized data with source identifiers, object identifiers, unified terminology, unified field semantics, and unified time format, providing a consistent data foundation for subsequent identification of risk scenario fragments and extraction of the correlation between passenger flow anomalies, equipment anomalies, and emergency response.

[0034] Through the above implementation methods, this embodiment can convert rail transit operation safety-related data from different sources, in different formats, and with different expression habits into a unified standardized data representation, reducing object confusion, terminological ambiguity, field mismatch, and time inconsistency in subsequent processing, improving the comparability and relevance between multi-source data, and providing a stable data foundation for risk scenario fragment generation, candidate risk knowledge extraction, and cross-source evidence fusion.

[0035] In some embodiments, based on the risk ontology and risk event patterns for rail transit operation safety, standardized data is subjected to chapter boundary identification, time clue identification, spatial clue identification, and object switching identification to generate risk scenario fragments, including: Based on risk ontology and risk event patterns, a set of scenario segmentation rules corresponding to risk object type, event stage type, spatiotemporal constraint type and context transition type is constructed. Based on the scene segmentation rule set, the standardized data is parsed for chapter structure and semantic unit division to determine the boundaries of candidate segments corresponding to the accident process, anomaly characterization, handling process, recovery status or management requirements. For candidate segment boundaries, combining temporal clues, spatial clues, risk object referential relationships, and event trigger word distribution, we can identify scene continuity relationships and scene switching relationships between adjacent semantic units; Based on the continuity and switching relationships of scenarios, candidate fragments pointing to the same set of risk objects, the same spatiotemporal range, or the same stage of event evolution are aggregated and recombined. Candidate fragments with object switching, spatiotemporal jumps, or changes in event stages are separated and segmented to generate risk scenario fragments.

[0036] Specifically, the risk scenario fragment generation process further organizes standardized data, after terminology normalization, encoding mapping, and time normalization, into scenario expression units that can correspond to a single set of risk objects, a single spatiotemporal range, or a single event evolution stage, so as to facilitate subsequent joint extraction of entities, attributes, relationships, and events. This process is not a mechanical segmentation of standardized data, but rather, based on the risk ontology and risk event patterns oriented towards rail transit operation safety, it performs structured segmentation and semantic reorganization of content such as accident course, anomaly representation, handling process, recovery status, and management requirements, so that the scenario boundary is consistent with the actual risk evolution boundary.

[0037] In this embodiment, the risk ontology refers to a pre-constructed knowledge object system and its set of relational constraints surrounding the rail transit operation safety scenario. It is used to define the core object categories, attribute categories, relationship categories, and event categories involved in risk knowledge. Specifically, the risk ontology may include object types such as lines, stations, sections, trains, equipment, positions, operational activities, passenger flow status, environmental status, abnormal status, risk events, handling actions, and recovery status, and specifies the possible associations between different object types. For example, equipment objects can establish a status relationship with abnormal statuses, station objects can establish a carrying capacity relationship with passenger flow statuses, and risk events can establish a response relationship with handling actions.

[0038] A risk event pattern refers to a pre-defined semantic template for the evolutionary structure of a risk event, used to constrain the unfolding order and phases of risk-related content within a data set. This risk event pattern may include one or more of the following phases: risk induction phase, anomaly characterization phase, event triggering phase, response phase, and recovery phase.

[0039] A scenario segmentation rule set refers to a set of segmentation rules established based on the risk ontology and risk event patterns, used to determine when the current scenario should continue and when a switch to a new scenario should occur. Context transition type refers to the transition category corresponding to changes in subject, space, time, or event stage in continuous text or records.

[0040] Scene continuity refers to the relationship where adjacent semantic units maintain continuity or can be connected in terms of risk object, time range, spatial range, or event stage. Scene switching refers to the relationship where adjacent semantic units undergo significant changes in the above dimensions, making them no longer suitable to be classified into the same risk scene segment.

[0041] In practical implementation, a scenario segmentation rule set is first constructed based on the risk ontology and risk event patterns. This rule set does not rely solely on fixed-length segmentation, but rather establishes multi-dimensional judgment rules around common object boundaries, spatiotemporal boundaries, and evolutionary boundaries in rail transit operation safety scenarios. Rules corresponding to risk object types are used to identify whether the semantic content revolves around equipment anomalies, passenger flow anomalies, operational anomalies, environmental anomalies, or a combination of events. For example, in standardized data, when "abnormality of platform screen door No. 3 on the upbound platform" consistently serves as the core object, adjacent semantic units are usually preferentially classified into the same candidate scenario; when subsequent semantic units shift to station hall passenger congestion or train delays in the section, a switching judgment at the object level is triggered.

[0042] The rules corresponding to the event stage type are used to identify whether the current semantic unit belongs to the accident process, anomaly representation, handling process, recovery state, or management requirement. For example, "the gate action lag occurred at 18:12" usually belongs to the anomaly representation stage, "notification to the station to take flow control measures at 18:16" usually belongs to the handling process stage, and "the gate resumes linkage control at 18:28" usually belongs to the recovery state stage. The rules corresponding to the spatiotemporal constraint type are used to identify whether adjacent semantic units are still in the same station, the same section, the same equipment area, and the same continuous time window. The rules corresponding to the context transition type are used to identify whether there are changes in the speaker, the event subject, the location, or the time jump in long accident reports or multi-source records.

[0043] Furthermore, based on the aforementioned scenario segmentation rule set, this embodiment performs text structure parsing and semantic unit division on standardized data. For document-type data such as accident reports, fault analysis reports, and safety inspection records, priority is given to identifying titles, chapters, clauses, paragraphs, lists, and tables to restore the document's text structure. Then, combined with descriptions in the text title such as the event process, on-site situation, cause analysis, emergency response, and rectification suggestions, the major semantic region to which the content belongs is determined. For sequence-type data such as scheduling logs, work order flow records, and monitoring records, preliminary grouping is performed based on record time, object code, event number, and operation number. Then, combined with the temporal sequence relationship between adjacent records, continuous semantic segments are formed.

[0044] After completing the text structure analysis, semantic unit segmentation is further performed on each section. A semantic unit is the smallest processing unit that can independently express a local semantic action, state, or constraint in the current scenario. It can be represented as a sentence, a series of consecutive sentences, a log entry, a work order entry, or a structured record block. For example, in an accident report, "significant passenger gathering on the upbound platform at 18:12" is one semantic unit, "abnormal operation of platform screen door No. 3 at 18:14" is another semantic unit, and "station initiation of flow control and passenger detour guidance at 18:16" is a third semantic unit. Through this processing, candidate segment boundaries corresponding to the accident process, abnormal characteristics, handling procedures, recovery status, or management requirements can be determined.

[0045] Furthermore, after obtaining the candidate segment boundaries, this embodiment further combines time clues, spatial clues, risk object referential relationships, and event trigger word distribution to identify scene continuity relationships and scene switching relationships between adjacent semantic units. Time clues are used to characterize whether semantic units are in the same continuous time period, which can be absolute times such as "18:12", "18:14", "18:16", or relative time expressions such as after the fault occurs, before the handling is completed, and after recovery.

[0046] Spatial cues are used to characterize whether semantic units refer to the same line, station, section, platform, or equipment functional area. Risk object referential relationships are used to characterize whether the object names appearing in different semantic units refer to the same object. For example, "upward platform door No. 3" in the previous semantic unit and "this door" in the subsequent semantic unit should be identified as the same equipment object. Event trigger word distribution is used to determine whether semantic units are unfolding around the same event process; for example, words such as "occurrence," "alarm," "repair," "handling," and "recovery" can reflect the direction of the event chain.

[0047] If adjacent semantic units are continuous in time, overlap or are adjacent in space, maintain consistency in objects, and the event trigger words show an evolutionary and progressive relationship, then the two are considered to have a scene continuity relationship; if adjacent semantic units show obvious breaks in objects, locations, time periods or event stages, then the two are considered to have a scene switching relationship.

[0048] In some examples, based on the identified scene continuity and scene switching relationships, this embodiment performs aggregation and recombination and separation segmentation on candidate fragments. For candidate fragments pointing to the same set of risk objects, the same spatiotemporal range, or the same stage of event evolution, aggregation and recombination are performed to organize multiple local semantic units into risk scene fragments that can express the complete local risk process. For example, in a station's up platform scene, although "significant passenger gathering," "abnormal operation of platform screen door No. 3," and "station implements flow control measures" come from accident reports, maintenance work orders, and scheduling logs respectively, they are aggregated into the same risk scene fragment because they point to the same station, the same platform area, adjacent time windows, and all revolve around the same abnormal event process.

[0049] For candidate segments involving object switching, spatiotemporal jumps, or changes in event stages, separation and segmentation are performed. For example, in the same incident report, the first half describes "abnormal passenger flow and flow restriction measures in the station hall," while the second half transitions to "speed reduction operation of trains in the section and the process of dispatch recovery." Although both are under the same overall incident background, they should be segmented into different risk scenario segments because the set of risk objects, spatial scope, and evolution stage have all changed significantly.

[0050] The implementation of this embodiment is illustrated below with specific examples. Taking a complex risk event that occurred during the evening peak of a holiday on a certain line as an example, the standardized data obtained by the system includes: "At 18:10, the passenger flow in the station hall continued to rise, and at 18:12, the passenger gathering on the up platform was obvious" in the accident report; "At 18:16, the station was notified to start the up line flow restriction, and at 18:18, the train entry interval was adjusted" in the dispatch log; "At 18:14, the No. 3 door of the up platform screen door was malfunctioning" in the maintenance work order; "From 18:11 to 18:17, the density of the platform area continued to rise" in the passenger flow monitoring data; and "The up platform screen door was malfunctioning, and passengers gathered at the escalator entrance. Flow control was implemented first" in the duty recording transcription.

[0051] In this embodiment, the system first identifies the types of objects involved, including stations, up-line platforms, platform screen door equipment, passenger flow, and dispatching actions, based on the risk ontology. Then, based on the risk event pattern, the system identifies the content as including anomaly representation stages and response stages. Subsequently, the system performs structural analysis on the chapter content in the incident report, identifying continuously rising passenger flow in the station hall and significant passenger gathering on the up-line platform as candidate segments for anomaly representation, initiating up-line flow control and adjusting train arrival intervals in the dispatching log as candidate segments for the response process, and identifying abnormal door movements in the maintenance work order as candidate segments for equipment anomalies.

[0052] Further analysis of temporal and spatial clues reveals that the aforementioned candidate segments are all concentrated within the time window of 18:10 to 18:18, and spatially they all revolve around the same station's upstream area. Combining object referencing relationships and the distribution of event trigger words, these segments collectively describe the localized operational risk process caused by the intertwining of abnormal passenger flow and platform screen door malfunctions. Therefore, the system aggregates these candidate segments into a single risk scenario segment. If, in the subsequent part of the same incident report, content such as "signal restored in the downstream section at 19:05, trains resumed normal tracking operation" appears, it should be segmented into a separate risk scenario segment because its time window and object set have changed, and should not be merged with the aforementioned platform passenger flow anomaly segment.

[0053] Through the above implementation methods, this embodiment, based on a risk ontology and risk event patterns for rail transit operation safety, performs chapter boundary recognition, time clue recognition, spatial clue recognition, and object switching recognition on standardized data. This allows long texts, multi-record, and multi-source mixed data to be organized into risk scenario fragments that match actual operational risk processes. This reduces contextual fragmentation caused by segmenting data into fixed-length segments or single sentences, improves object consistency, stage consistency, and scenario integrity in subsequent risk knowledge extraction processes, and provides a more accurate semantic input foundation for the joint extraction of entities, attributes, relationships, and events.

[0054] In some embodiments, joint extraction of entities, attributes, relationships, and events is performed based on risk scenario fragments, and constraint verification is performed in conjunction with risk ontology and risk event patterns to obtain candidate risk knowledge, including: Risk element trigger word identification, object reference parsing, and semantic role labeling are performed on risk scenario fragments to generate joint extraction inputs corresponding to entity candidates, attribute candidates, relationship candidates, and event candidates. Based on the preset joint extraction model, collaborative decoding under association constraints is performed on the joint extraction input to obtain the initial extraction results corresponding to the risk object, state representation, association relationship, event type and event participant role; Based on the risk ontology, type consistency verification, object pairing legality verification, and attribute attribution verification are performed on the initial extraction results to eliminate abnormal results that do not meet the ontology constraints; Based on the risk event pattern, the initial extraction results verified by ontology are subjected to event stage sequence verification, causal connection verification, and disposal chain integrity verification to obtain candidate risk knowledge that matches the semantics of risk evolution.

[0055] Specifically, the candidate risk knowledge generation process is used to further identify core objects, states, relationships, event types, and event participants in rail transit operation safety scenarios based on risk scenario fragments. The extraction results are then subject to dual constraints and verification through risk ontology and risk event patterns, ensuring that the output corresponds to the true semantics of risk evolution. This process does not perform entity recognition, relationship recognition, and event recognition separately, but rather performs joint extraction around the chain of objects, states, behaviors, and events within the same risk scenario fragment, thereby reducing semantic fragmentation and missing associations caused by single-task extraction.

[0056] In this embodiment, risk element trigger words refer to key descriptive units that can characterize the status of rail transit operation safety risks, event triggering, handling response, or recovery transfer, such as gathering, congestion, failure, anomaly, alarm, flow restriction, blockade, recovery, and lifting.

[0057] Object referencing resolution refers to the process of identifying different semantic units within a risk scenario segment that use different names, abbreviations, pronouns, or locational references to the same operational object, and associating them with a unified object identifier. For example, the No. 3 platform screen door, the door itself, and the corresponding platform screen door can all be resolved to the same equipment object in the same scenario.

[0058] Semantic role labeling refers to identifying the semantic functions undertaken by each object in an event, such as risk-bearing object, anomaly-occurring object, triggering object, handling execution object, affected object, and recovery object.

[0059] Joint extraction input refers to the structured semantic input formed by superimposing risk element trigger word positions, object reference chains, and semantic role prompts in a risk scenario fragment, which is used to provide a unified context for the joint extraction model.

[0060] The joint extraction model refers to a collaborative identification model configured for risk scenario fragments. It is used to simultaneously output entity candidates, attribute candidates, relationship candidates and event candidates in the same decoding process, and to jointly model the correlation constraints between different types of candidate results.

[0061] In practical implementation, the risk scenario segments are first subjected to risk element trigger word identification, object reference parsing, and semantic role labeling to generate joint extraction input. For risk element trigger word identification, this embodiment prioritizes the use of a preset rail transit operation safety trigger word lexicon and context judgment rules to identify key phrases that can indicate abnormal states, risk changes, response actions, and recovery results. For example, in the scenario segment "At 18:12, there was significant passenger gathering on the up-line platform; at 18:14, the No. 3 platform screen door malfunctioned; at 18:16, the station initiated flow control," "significant gathering" corresponds to the passenger flow abnormality trigger word, "malfunction" corresponds to the equipment abnormality trigger word, and "initiated flow control" corresponds to the handling action trigger word.

[0062] For object reference parsing, this embodiment combines the object encoding system, positional reference rules, and contextual common reference relationships to uniformly associate the names of objects in a scene segment. For example, "the shielded door No. 3" in the previous sentence and "the door" in the next sentence establish the same object mapping.

[0063] For semantic role labeling, this embodiment assigns different roles to objects in a scene segment based on a predefined set of roles in the risk event pattern. For example, in the scenario "the duty officer discovers passengers gathering on the up platform and reports to the dispatcher, who then instructs the station to implement flow control," the "duty officer" is the discovery role, the "up platform passengers" are the anomaly bearers role, the "dispatcher" is the instruction issuer role, and the "station" is the handling execution role. After the above processing, a joint extraction input containing text content, object reference chains, trigger word identifiers, and role prompts can be generated.

[0064] In some examples, the joint extraction model performs collaborative decoding under association constraints on the joint extraction input to obtain the initial extraction result. This joint extraction model can employ a model structure combining shared semantic encoding and multi-task decoding. The shared semantic encoding part is used to uniformly represent the contextual semantics, temporal connections, and object dependencies in risk scenario fragments; the multi-task decoding part outputs the risk object, state representation, association relationship, event type, and event participant roles respectively. Unlike the traditional sequential approach of first performing named entity recognition, then relation extraction, and then event extraction, this embodiment introduces mutual constraints between entities, attributes, relationships, and events within the same decoding process.

[0065] For example, when the model identifies "platform screen door No. 3" as a device object and "abnormal action" as a state representation, the confidence level of the "device-state" relationship can be increased simultaneously, and "platform screen door abnormal event" can be output as a possible event type. When the model identifies "initiating flow restriction" as a handling action, "station" can be identified as the executing role and "passenger gathering" as the triggering background state. This avoids the problem of relationship disconnect caused by separate extraction.

[0066] Furthermore, after obtaining the initial extraction results, this embodiment performs type consistency checks, object pairing legality checks, and attribute attribution checks based on the risk ontology, eliminating abnormal results that do not meet the ontology constraints. The type consistency check is used to determine whether the extracted object categories and status categories conform to the defined relationships in the risk ontology. For example, if an extraction result identifies "station hall" as a equipment object, it does not meet the object type definition and should be eliminated or corrected.

[0067] Object pairing validity verification determines whether a current relationship is permissible between two objects. For example, the risk ontology allows relationships such as "equipment object - status representation," "station object - passenger flow status," and "event object - response action," but not illegal pairings like "management system - equipment location." Attribute attribution verification determines whether a particular attribute should belong to the current object. For example, passenger flow density should belong to the concourse or platform area object, action lag should belong to the equipment object, and flow restriction level should belong to the response action or management response object. Through these ontology verifications, type mismatches, incorrect relationship connections, or incorrect attribute attribution results caused by model misidentification can be eliminated.

[0068] Furthermore, after verifying the risk ontology, this embodiment further performs event phase sequence verification, causal connection verification, and resolution chain integrity verification based on the risk event pattern. The event phase sequence verification is used to determine whether each event fragment in the extracted results meets the basic sequence of risk event evolution. For example, anomaly manifestation should typically occur first, followed by event triggering, then a response, and finally, a recovery state may occur.

[0069] If the extraction results show "return to normal" before "abnormality occurred," it indicates an anomaly in the sequence of events, requiring a reduction in its reliability or re-evaluation. Causal connection verification is used to determine whether a reasonable causal relationship exists between preceding and subsequent events. For example, passenger congestion may trigger flow control measures, and equipment malfunction may trigger repair requests or isolation operations; if the extraction results directly establish a causal relationship between "regulation revision" and "instant platform congestion," it does not conform to the causal logic of the current scenario.

[0070] The completeness check of the handling chain is used to determine whether the handling process in the scenario has the most basic response structure. For example, at least several key links should be retained in the process of "detecting an anomaly - reporting - issuing instructions - executing handling - feedback recovery". If the model only extracts the "handling action" without any corresponding triggering anomaly or object support, the result is usually not retained as a high-confidence candidate risk knowledge. After the above event pattern verification, candidate risk knowledge that matches the semantics of risk evolution is obtained.

[0071] The implementation of this embodiment is illustrated below with a specific example. Taking a risk scenario segment of a station's up-line platform experiencing abnormal passenger flow and accompanying platform screen door malfunction during a holiday evening rush hour as an example, the segment includes: "At 18:12, passenger gathering on the up-line platform became significant; at 18:14, platform screen door No. 3 experienced abnormal operation; station staff reported to dispatch; at 18:16, the station initiated flow control and arranged personnel to guide passengers; at 18:28, the door resumed linkage control." In this scenario, the system first identifies "significant gathering," "abnormal operation," "initiating flow control," and "resumption of linkage control" as risk element trigger words, and through object referencing parsing, identifies "platform screen door No. 3" and the "door" in "door resumed linkage control" as the same device object.

[0072] Subsequently, semantic role labeling identifies passengers on the up-line platform as the abnormal carrying objects, platform screen door No. 3 as the abnormal occurrence object, station staff as the reporting role, dispatchers as the instruction receiving role, and the station as the handling execution role. After collaborative decoding, the joint extraction model outputs the initial extraction results, including: risk objects: up-line platform, platform screen door No. 3, and station; state representation: obvious passenger gathering, abnormal actions, and restoration of linkage control; correlation relationships: "platform-passenger flow abnormality", "equipment-action abnormality", and "station-implementation of flow restriction"; event types: passenger flow abnormality event, equipment abnormality event, and handling response event; and event participating roles: "station staff-reporting role" and "station-execution role".

[0073] During the ontology verification phase, the system confirms that passenger gathering clearly belongs to the platform area object, abnormal actions belong to the equipment object, and initiating flow control belongs to the handling action, thus retaining the corresponding knowledge. If the model mistakenly identifies scheduling as an equipment object, it will be removed during type consistency verification. During the event pattern verification phase, the system further determines that the scenario follows the evolutionary sequence of "abnormal representation - handling response - recovery state," and that passenger gathering and equipment abnormality together constitute the triggering background, flow control and guidance constitute the handling chain, and recovery linkage control constitutes the recovery state. Therefore, a candidate risk knowledge set matching the scenario is finally generated.

[0074] For example, in a power supply anomaly scenario in a certain section, the risk scenario segment includes "at 07:45, the section power supply voltage fluctuation alarm is triggered; at 07:47, the dispatcher issues a speed limit command; at 08:02, maintenance confirms that the contact network power supply has returned to stability." When identifying trigger words, the system extracts "alarm trigger," "speed limit command," and "restoration to stability" as key trigger words; during object referencing, it maps the section power supply and contact network power supply to the same power supply object; and during semantic role labeling, it identifies the dispatcher as the control execution role and the maintenance worker as the restoration confirmation role.

[0075] After the joint extraction model outputs initial results such as power supply anomaly events, operation control events, and recovery confirmation events, the object types and relationship legitimacy are verified through the risk ontology, and the event pattern verification confirms that the scenario forms a complete "anomaly trigger - operation control - recovery confirmation" event chain, thus retaining the corresponding candidate risk knowledge. If another statement, "monthly training summary completed on the same day," is mistakenly included in the scenario, it will be removed during the ontology verification and event pattern verification stages because it neither conforms to the risk object relationship nor satisfies the event evolution chain order.

[0076] Through the above implementation methods, this embodiment performs risk element trigger word identification, object reference parsing, and semantic role labeling on risk scenario fragments, and performs joint extraction of entities, attributes, relationships, and events under association constraints. Combined with risk ontology and risk event patterns for dual verification, the extracted candidate risk knowledge can better fit the real object relationships and event evolution logic in rail transit operation safety scenarios, reduce the knowledge fragmentation, role missing, and relationship mismatch problems caused by single task extraction, and improve the semantic integrity and structural consistency of candidate risk knowledge.

[0077] In some embodiments, candidate risk knowledge is subjected to time anchor identification, spatial anchor identification, and rail transit topology mapping to obtain spatiotemporally related knowledge units, including: Identify the temporal representation, spatial representation, operational object identification, and event association description in the candidate risk knowledge, and generate temporal candidate anchor points, spatial candidate anchor points, and object location candidate results; Based on the preset operational timeline benchmark and time parsing rules, absolute time conversion, relative time alignment and time interval regularization are performed on the candidate time anchor points to determine the time anchor points corresponding to the candidate risk knowledge. Based on the preset line station system, section location system, equipment coding system and spatial reference rules, the station affiliation resolution, section direction resolution, equipment location resolution and spatial hierarchy association are performed on the spatial candidate anchor points and object positioning candidate results to determine the spatial anchor points corresponding to the candidate risk knowledge; Based on the rail transit topology model, candidate risk knowledge corresponding to time anchor points and spatial anchor points is mapped to the topological location corresponding to the line, station, section, equipment or functional area, generating spatiotemporal related knowledge units associated with time anchor points, spatial anchor points and topological locations.

[0078] Specifically, the spatiotemporal knowledge unit generation process further binds the candidate risk knowledge obtained in the previous step to specific temporal, spatial, and rail transit network topological locations. This transforms the candidate risk knowledge from merely semantic descriptions of objects, states, and events into structured knowledge units that correspond to specific lines, stations, sections, equipment, or functional areas. This facilitates subsequent cross-source evidence fusion, conflict resolution, and risk evolution chain assembly. The process unfolds across four levels: temporal representation parsing, spatial representation parsing, object location parsing, and topological mapping. Its core lies in unifying the mapping of candidate risk knowledge from different sources, with different granularities, and different representations onto the same operational spatiotemporal framework.

[0079] In this embodiment, the time candidate anchor point refers to the time description unit identified from the candidate risk knowledge that can characterize the time of occurrence, duration, sequence or operation phase of the event. It can be an absolute time such as "18:12" or "07:45", or a relative time or operation period such as "5 minutes after the fault occurred", "before the first bus", or "during the evening peak".

[0080] Spatial candidate anchor points refer to spatial description units identified from candidate risk knowledge that can characterize the location of a line, station, section, equipment area, or functional area, such as "Line 2 up platform", "People's Square Station concourse", "down section", "area where platform screen door No. 3 is located", "Exit A escalator entrance", etc.

[0081] Candidate results for object location refer to the results of inferring the location of an object based on the object identifier. For example, the equipment code can be used to infer that the equipment is located at a certain platform of a certain station on a certain line, and the job position can be used to infer the station duty area to which it belongs.

[0082] Operational timeline benchmarks refer to a unified time reference system pre-set for rail transit operation scenarios. It is used to convert, align, and sort data time from different sources. This benchmark may include standard clock time, operation calendar, shift start and end times, train timetable time, maintenance window time, and holiday operation periods.

[0083] A rail transit topology model is a hierarchical location model established based on the connection relationships between lines, stations, sections, platforms, entrances / exits, equipment, and functional areas. It is used to describe the topological adjacency, subordination, and location relationships between different spatial objects.

[0084] Spatiotemporal related knowledge units refer to candidate risk knowledge units that are simultaneously associated with time anchors, spatial anchors, and topological locations. They can serve as the basic granular units for subsequent cross-source knowledge alignment and evolution chain construction.

[0085] In practical implementation, the time representation, spatial representation, operational object identifier, and event association description in the candidate risk knowledge are first identified to generate time candidate anchors, spatial candidate anchors, and object location candidate results. For time representation identification, this embodiment not only extracts explicit time fields but also extracts relative time phrases and operational period phrases implicit in the event description.

[0086] For example, in the candidate risk knowledge items "significant passenger flow gathering on the up platform at 18:12", "station implements flow control 3 minutes after the fault", and "restoration completed before the last train", "18:12", "3 minutes after the fault", and "before the last train" are all retained as candidate time anchor points. For spatial representation recognition, this embodiment identifies station names, line names, section directions, equipment locations, and functional area descriptions, and processes abbreviated expressions, directional expressions, and local location expressions. For example, "up platform", "escalator entrance A", "contact network in the down section", and "near the security checkpoint in the station hall" can all be used as candidate spatial anchor points.

[0087] For candidate object location results, this embodiment combines the operational object identifier in the candidate risk knowledge and uses the object coding system to look up the object's location. For example, the equipment code of platform screen door No. 3 can be directly mapped to the door location of a certain platform in a certain station, and the code of a certain power supply equipment can be mapped to the location of a certain power supply segment in a certain section.

[0088] Furthermore, after identifying candidate time anchors, this embodiment performs absolute time conversion, relative time alignment, and time interval normalization on the candidate time anchors based on preset operational timeline benchmarks and time parsing rules to determine the time anchors corresponding to the candidate risk knowledge. For clearly given time expressions, they can be directly converted into a unified time format; for relative time expressions such as 5 minutes after the fault occurs, immediately after reporting, or before the first bus of the next day, conversion is required in conjunction with the benchmark event time, operational calendar, and shift information in the current risk scenario segment.

[0089] For example, if a platform screen door malfunction is known to have occurred at 18:14 in a given scenario, then the activation of flow control 3 minutes after the fault can be converted to 18:17. For operational phases such as evening peak hours, nighttime maintenance windows, and holiday closing times, a standard time interval is mapped based on the operational timeline. For example, the evening peak hours on a designated operational day are mapped to 17:30 to 19:30. For similar time descriptions from multiple sources, this embodiment can also perform time interval normalization processing, merging times differing within a preset threshold into the same time period for adaptation to subsequent cross-source evidence fusion.

[0090] Furthermore, after determining the time anchor point, this embodiment further performs station affiliation resolution, section direction resolution, equipment location resolution, and spatial hierarchy association on the spatial candidate anchor points and object positioning candidate results based on the preset line station system, section location system, equipment coding system, and spatial reference rules, in order to determine the spatial anchor point corresponding to the candidate risk knowledge. The line station system is used to describe each line, each station, and their up and down relationships; the section location system is used to describe the relationships between stations, section directions, and mileage segments; the equipment coding system is used to describe the correspondence between equipment and stations, sections, platforms, and functional areas; and the spatial reference rules are used to handle relative or abbreviated location expressions such as "this station," "upstream side," "near Exit A," and "south end of the station."

[0091] For example, when the candidate risk knowledge includes "abnormal operation of the No. 3 door of the up platform", the corresponding station and platform can be located first based on the equipment coding system, and then its spatial anchor point can be refined into "a certain line - a certain station - up platform - No. 3 door area" through spatial hierarchy association; when the candidate risk knowledge includes power supply fluctuation in the down section, the down section between two adjacent stations can be resolved based on the section location system; when the candidate risk knowledge only includes the escalator at Exit A of this station, the station can be resolved to the station identifier corresponding to the current scenario context through spatial reference rules.

[0092] Furthermore, after determining the spatial and temporal anchor points, this embodiment, based on the rail transit topology model, maps the candidate risk knowledge corresponding to the temporal and spatial anchor points to the topological locations corresponding to lines, stations, sections, equipment, or functional areas, generating spatiotemporally related knowledge units associated with the temporal anchor points, spatial anchor points, and topological locations. This topological mapping is not simply recording location names, but rather attaching candidate risk knowledge to topological nodes or topological levels that reflect the actual operational spatial connections.

[0093] For example, the candidate risk knowledge of significant passenger flow in the station hall can be mapped to the "line-station-station hall area" topology level; the abnormal operation of platform screen door No. 3 can be mapped to the "line-station-platform-equipment area" topology level; and the voltage fluctuation of the power supply in the section can be mapped to the "line-section-power supply segment" topology level. If a candidate risk knowledge involves multiple objects, such as escalator congestion at Exit A due to passenger flow in the up platform, this embodiment can retain multiple topological location references in the same spatiotemporal related knowledge unit and identify its primary and related locations for subsequent analysis of risk diffusion paths.

[0094] The implementation of this embodiment is illustrated below with a specific example. Taking a scenario where abnormal passenger flow and equipment malfunction occur coupled during the evening rush hour on a certain line at a certain station during a holiday as an example, the candidate risk knowledge obtained in the previous step includes: "significant passenger gathering on the up platform at 18:12", "abnormal operation of platform screen door No. 3 at 18:14", "station initiation of flow restriction at 18:16", and "resuming linkage control of the door at 18:28". The system first identifies the time expressions 18:12, 18:14, 18:16, and 18:28 from the above candidate risk knowledge and directly converts them into a unified time format; it identifies the spatial expressions up platform, platform screen door No. 3, and station, where the station is resolved to a specific station name through scenario context parsing; at the same time, it locates "platform screen door No. 3" to the equipment location of platform screen door No. 3 on the up platform of the station according to the equipment code.

[0095] Subsequently, the system maps the obvious passenger gathering on the up-line platform to the topological location of "a certain line - a certain station - up-line platform area", maps the abnormal operation of platform screen door No. 3 and the linkage control of door restoration to the topological location of "a certain line - a certain station - up-line platform - No. 3 door equipment area", and maps the station's initiation of flow restriction to the topological location of "a certain line - a certain station - platform and entry control area", and attaches corresponding time anchors to each, ultimately forming multiple spatiotemporally related knowledge units with a unified time axis and a unified spatial hierarchy. In this way, when performing cross-source evidence fusion, the system can clearly determine whether the platform passenger gathering in the incident report, the door abnormality in the work order, and the initiation of flow restriction in the scheduling log are within the same time window and the same topological area.

[0096] Furthermore, in certain implementation scenarios, candidate risk knowledge may simultaneously contain both relative time and relative spatial expressions. For example, a duty recording might state, "Two minutes after the fault, congestion began at Exit A of this station." In this case, this embodiment first converts the two minutes after the fault into an absolute time based on the known baseline event time in the same risk scenario segment. Then, based on the current station identifier in the context, it resolves the station as a specific station and maps Exit A of the escalator to the topological location of the station's entrance / exit functional area. In this way, even if the original statement does not directly provide complete standardized spatiotemporal information, it can be transformed into comparable and fusionable spatiotemporally related knowledge units under unified rules.

[0097] Through the above implementation methods, this embodiment can further transform candidate risk knowledge from semantic-level descriptions of objects, states, and events into spatiotemporally related knowledge units bound to specific time anchors, spatial anchors, and rail transit topological locations. This improves the alignability of candidate risk knowledge from different sources in both time and space dimensions, enhances the accuracy of subsequent cross-source evidence fusion, conflict identification, and risk evolution chain construction, and provides a stable spatiotemporal foundation for the correlation analysis and dynamic simulation of rail transit operational safety risks.

[0098] In some embodiments, evidence fusion and conflict resolution are performed on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments, including: Based on the risk object identifier, event type identifier, time anchor, spatial anchor and source identifier in the spatiotemporal related knowledge unit, a cross-source evidence association rule set is constructed; Based on the cross-source evidence association rule set, homogeneity deduplication, cross-source alignment and association clustering are performed on spatiotemporal related knowledge units corresponding to different data sources to generate evidence association sets corresponding to the same risk object, the same event process or the same evolution stage. For the evidence association set, evidence confidence aggregation is performed by combining the data source credibility level, spatiotemporal consistency, object consistency, event phase consistency and evidence support strength to obtain candidate fusion results; For conflicting knowledge in candidate fusion results, based on preset conflict discrimination rules, time conflicts, spatial conflicts, object conflicts, event sequence conflicts or attribute value conflicts are identified, and conflict resolution is performed according to source priority, topological constraint relationship and time constraint relationship. Based on the candidate fusion results after conflict resolution, risk knowledge fragments are generated that are associated with risk fact identifiers, evidence index sets, confidence identifiers, and version identifiers.

[0099] Specifically, the risk knowledge fragment generation process is used to further integrate spatiotemporally related knowledge units from different data sources that have already undergone time anchoring, spatial anchoring, and topological mapping. This allows descriptions of the same risk fact, the same event process, or the same evolutionary stage from multiple sources to be converged into a unified, traceable, and verifiable knowledge representation. This process does not simply splice together knowledge units from different sources; rather, it establishes cross-source evidence relationships around the risk object, event type, temporal location, spatial location, and source attributes. Based on this, it performs evidence aggregation, conflict identification, and conflict resolution to obtain risk knowledge fragments that can provide stable support for the subsequent assembly of the risk evolution chain.

[0100] In this embodiment, the cross-source evidence association rule set refers to a set of rules for determining whether different spatiotemporally related knowledge units can be regarded as the same risk fact. This rule set can be constructed around the consistency of risk object identification, event type consistency, temporal anchor proximity, spatial anchor proximity, topological location overlap, and data source relevance.

[0101] An evidence association set refers to a group of spatiotemporally related knowledge units that are determined to jointly describe the same risk object, the same event process, or the same evolutionary stage after being matched by cross-source evidence association rules.

[0102] Spatiotemporal consistency refers to the degree to which multiple spatiotemporally related knowledge units maintain overlap, proximity, or reasonable evolutionary connection at temporal and spatial anchor points. Object consistency refers to whether the risk objects pointed to by multiple knowledge units are the same object or the same set of objects. Event phase consistency refers to whether multiple knowledge units jointly correspond to the same event phase, such as the anomaly representation phase, the response phase, or the recovery phase.

[0103] In practical implementation, a cross-source evidence association rule set is first constructed based on the risk object identifier, event type identifier, time anchor, spatial anchor, and source identifier in the spatiotemporal related knowledge unit. For the risk object identifier, the focus is on determining whether spatiotemporal related knowledge units from different sources point to the same station, the same section, the same equipment, the same operational activity, or the same passenger flow area. For the event type identifier, the focus is on determining whether they belong to the same category, such as equipment abnormality event, passenger flow abnormality event, operation control event, handling response event, or recovery confirmation event.

[0104] For time anchor points, the focus is on determining whether they fall within the same time window, adjacent time windows, or meet a preset time deviation range. For spatial anchor points, the focus is on determining whether they fall within the same topological node, adjacent topological nodes, or the same spatial level. For example, significant passenger flow gathering, initiation of flow control, or abnormal gate operation within a 5-minute time window in the upstream platform area of ​​the same station can be included in the candidate scope for association. Source identifiers are used to distinguish whether the evidence comes from equipment monitoring, manual records, dispatch instructions, maintenance work orders, accident reports, or audio / video transcriptions, so that different weights can be assigned subsequently. Through the above rules, spatiotemporally related knowledge units from different sources that may jointly point to the same risk fact can be filtered out.

[0105] Furthermore, after constructing the cross-source evidence association rule set, this embodiment performs same-source deduplication, cross-source alignment, and association clustering on the spatiotemporal related knowledge units corresponding to different data sources to generate an evidence association set. Same-source deduplication is used to eliminate duplicate knowledge units formed within the same data source due to repeated collection, repeated reporting, or repeated transcription. For example, if a device monitoring system continuously reports three completely identical abnormal alarms, they can be consolidated into a single spatiotemporal related knowledge unit.

[0106] In some examples, cross-source alignment is used to map spatiotemporally related knowledge units from different sources that are semantically equivalent or highly relevant to the same candidate fact space. For example, the dispatch log showing uplink flow control initiated at 18:16, the duty recording showing flow control in advance, and the accident report showing station passenger flow control measures, although expressed differently, can be aligned to the same response fact if their objects, time, and space are basically consistent. Association clustering, on the other hand, is used to aggregate multiple aligned knowledge units into evidence association sets according to the same risk object, the same event process, or the same evolutionary stage. In this way, each evidence association set is no longer a single record, but a cluster of evidence that collectively supports a candidate risk fact.

[0107] For the generated evidence association set, this embodiment further combines data source trust level, spatiotemporal consistency, object consistency, event phase consistency, and evidence support strength to perform evidence confidence aggregation and obtain candidate fusion results. Specifically, a basic trust weight is first assigned according to the data source type. For example, original equipment monitoring alarms and formal dispatch commands usually have a higher basic trust level, while the basic trust level of on-site free description text and automatic speech-to-text can be relatively lower.

[0108] Then, the spatiotemporal consistency index is calculated based on the degree of consistency of each knowledge unit within the same evidence association set in time and space; the object consistency index is calculated based on whether their risk objects are completely consistent or whether they are in the same object set; the event stage consistency index is calculated based on whether they belong to the same evolution stage such as anomaly representation, handling response or recovery state; and the evidence support strength is calculated based on the number of independent sources supporting the candidate fact, the diversity of sources and the degree of mutual corroboration.

[0109] Based on this, the various indicators are comprehensively aggregated to obtain candidate fusion results. For example, if an equipment anomaly is recorded simultaneously by equipment alarms, maintenance work orders, and accident reports, and the time error of the three is within 2 minutes and the spatial location corresponds to the same equipment area, then the confidence of the anomaly can be significantly improved; if there is only one low-confidence transcription record describing the anomaly without other supporting sources, then its confidence is relatively low.

[0110] Furthermore, after obtaining the candidate fusion results, this embodiment performs conflict discrimination and conflict resolution on the conflicting knowledge within them. Conflicting knowledge refers to situations where, within the same candidate fusion result, knowledge units from different sources have inconsistencies, contradictions, or cannot be simultaneously established on key attributes. Preset conflict discrimination rules may include time conflicts, spatial conflicts, object conflicts, event sequence conflicts, and attribute value conflicts, etc. Time conflicts are used to identify whether the occurrence time or duration of the same risk fact in different sources exceeds a preset tolerance range. For example, if one source records "18:14 equipment malfunction" and another source records "18:40 no malfunction record before equipment recovery," and these two cannot be established in the same evolution process, then a time conflict is constituted. Spatial conflicts are used to identify whether the same candidate fact is described as occurring simultaneously in two incompatible spatial locations.

[0111] Object conflicts are used to identify whether different sources attribute the same abnormal state to different objects, such as one source assigning an abnormality to gate 3 while another source assigns it to gate 5. Event sequence conflicts are used to identify situations where the response action precedes the abnormality occurrence, or the recovery state precedes the response action, which do not conform to the evolutionary sequence. Attribute value conflicts are used to identify inconsistencies in the values ​​of key attributes such as passenger flow level, fault level, flow restriction level, and recovery time across different sources.

[0112] Furthermore, after identifying conflicting knowledge, this embodiment performs conflict resolution according to source priority, topological constraints, and time constraints. Source priority is used to prioritize the source with higher authority or stronger originality when multiple sources simultaneously provide mutually exclusive descriptions. For example, in equipment status facts, original equipment alarms may take precedence over manually recorded verbal records; in handling command facts, formal scheduling logs may take precedence over incident summary texts.

[0113] In some examples, topological constraints are used to determine whether a spatial description matches the object's location and scene scope based on the rail transit topology model. If a record incorrectly marks an upward platform door in the concourse area, the spatial description can be corrected or removed based on topological constraints. Temporal constraints are used to determine the rationality of sequential relationships based on operational timing and event patterns. For example, in cases where there are "flow control started at 18:16" and "significant passenger gathering at 18:12," if another source record states "flow control completed at 18:10," it can be judged as an abnormal record and downgraded due to inconsistency with the preceding and following timelines. For conflicting results that cannot be completely resolved but have a certain degree of credibility, this embodiment can adopt a version retention method, that is, save multiple versions simultaneously and record their source and applicable status through version identifiers for subsequent manual review or subsequent evidence supplementation.

[0114] Furthermore, after conflict resolution, this embodiment generates risk knowledge fragments associated with risk fact identifiers, evidence index sets, confidence identifiers, and version identifiers based on the candidate fusion results after conflict resolution. These risk knowledge fragments are not ordinary triples, but rather information units with a clear evidence source chain, fused confidence information, and version status. A risk knowledge fragment may include: the corresponding risk object or set of objects, the corresponding event type or relationship type, its unified time anchor, unified spatial anchor, topological location, evidence index set supporting the fact, the fused confidence identifier, and the current version identifier. Therefore, when assembling the risk evolution chain subsequently, not only the semantic content of the fragment can be utilized, but also its evidence support and credibility can be used to filter and sort the chain.

[0115] The implementation of this embodiment is illustrated below with specific examples. Taking a scenario of abnormal passenger flow on the up platform of a certain station accompanied by abnormal platform screen doors as an example, the spatiotemporal knowledge units obtained in the previous step include: "At 18:12, there was a significant gathering of passengers on the up platform" in the accident report; "At 18:16, the station started up-line flow control" in the dispatch log; "At 18:14, the No. 3 platform screen door on the up platform was malfunctioning" in the maintenance work order; "At 18:13, the door linkage failed to alarm" in the equipment alarm; and "Up-line platform screen door malfunction, control the flow first" in the duty recording transcription.

[0116] In a specific example, the system first constructs association rules based on risk object identifiers, event type identifiers, time anchors, and spatial anchors. It identifies that the five spatiotemporally related knowledge units are all located in the same station's upstream platform area, within an adjacent time window from 18:12 to 18:16, and jointly involve passenger flow anomalies, equipment anomalies, and response processes. Therefore, they are included in the same evidence association set. Subsequently, evidence confidence aggregation is performed on this set. Equipment alarms and dispatch logs have a high confidence level, followed by maintenance work orders and accident reports. Audio transcription has a low confidence level, but the audio transcription corroborates the "flow restriction" statement in the dispatch log, thus it can still be used as supplementary evidence.

[0117] After aggregation, candidate fusion results can be generated, including three main facts: abnormal passenger flow on the up-line platform, abnormal operation of platform screen door No. 3, and the station's activation of flow control response. If the incident report records the anomaly occurrence time as 18:12, while the maintenance work order records the repair request time as 18:14, then the two do not constitute a time conflict, but rather different records of the same abnormal fact at different stages. If another low-confidence text describes the fault location as "platform hall door," then because it does not match the topological location of the platform door corresponding to the equipment code, it can be determined as a spatial conflict and eliminated based on topological constraints. Finally, the system generates a risk knowledge fragment for "abnormal operation of platform screen door No. 3," which is associated with relevant evidence indexes from equipment alarms, maintenance work orders, and incident reports, and is supplemented with a fusion confidence flag and a current version flag.

[0118] Through the above implementation methods, this embodiment constructs a cross-source evidence association rule set based on risk object identifiers, event type identifiers, time anchors, spatial anchors, and source identifiers. It then performs homogeneous deduplication, cross-source alignment, association clustering, evidence confidence aggregation, and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources. This enables the integration of scattered descriptions of the same risk fact from multi-source heterogeneous data into unified, traceable risk knowledge fragments with credibility identifiers. Consequently, it reduces duplication, contradictions, and ambiguities among multi-source information, improving knowledge consistency and evidence reliability in the subsequent risk evolution chain assembly process.

[0119] In some embodiments, a risk evolution chain is assembled based on risk knowledge fragments, and the results of extracting knowledge about rail transit operation safety risks are output, including: Based on the risk object identifier, event type identifier, time anchor, spatial anchor, relationship type and disposal information in the risk knowledge fragments, a risk evolution assembly rule set is constructed; Based on the risk evolution assembly rule set, the preceding fragment identification, subsequent fragment identification and same-stage fragment merging are performed on risk knowledge fragments to determine the temporal connection relationship, causal connection relationship and disposal transmission relationship between fragments. Based on temporal, causal, and disposal transmission relationships, risk knowledge fragments corresponding to the same set of risk objects, the same event process, or the same spatiotemporal range are linked in a chain to generate a risk evolution chain corresponding to one or more stages in risk induction, state evolution, event triggering, impact diffusion, disposal response, and recovery state. For the risk evolution chain, the integrity check and inter-chain conflict check are performed by combining the evidence index set, confidence marker and version marker of the fragments in the chain to determine the target risk evolution chain; Based on the target risk evolution chain, knowledge extraction results of rail transit operation safety risks are generated, corresponding to the risk object, evolution stage, associated evidence, and target risk evolution chain identifier.

[0120] Specifically, the risk evolution chain assembly process is used to further link the risk knowledge fragments generated in the previous step according to time progression, causal relationships, and disposal transmission relationships. This organizes the scattered object state knowledge, event knowledge, and disposal knowledge into an evolutionary structure that reflects the occurrence, development, response, and recovery process of rail transit operation safety risks. This process does not simply arrange risk knowledge fragments chronologically, but rather identifies the predecessor, successor, and same-stage merging relationships between fragments based on the risk object set, event stage semantics, spatiotemporal continuity, and disposal transmission logic. This forms a risk evolution chain that can be used for subsequent risk analysis, case review, knowledge retrieval, and decision support, and further generates rail transit operation safety risk knowledge extraction results.

[0121] In this embodiment, the risk evolution assembly rule set refers to a set of rules established around whether risk knowledge fragments can constitute the same risk evolution process. This rule set includes, but is not limited to: object continuity rules, time connection rules, spatial connection rules, event phase advancement rules, causal triggering rules, and disposal transmission rules. Object continuity rules are used to determine whether multiple fragments revolve around the same equipment object, the same station area, the same interval object, or the same set of objects.

[0122] Temporal connection rules determine whether consecutive fragments are located within the same evolution window or have an acceptable temporal progression relationship. Spatial connection rules determine whether the spatial anchor points and topological locations corresponding to fragments are within the same spatial range, adjacent ranges, or on the same risk propagation path. Event phase progression rules constrain the connection order between stages such as risk induction, state evolution, event triggering, impact diffusion, response, and recovery. Causal triggering rules determine whether a previous fragment can serve as the inducing cause, triggering condition, or background state of a subsequent fragment. Response propagation rules determine whether a response action is triggered by a previous anomalous state and whether it affects the subsequent recovery state or impact convergence.

[0123] A precursor fragment is a fragment that precedes the current fragment in the evolutionary chain and has a temporal precedence, causal support, or triggering effect on the current fragment. A successor fragment is a fragment that follows the current fragment in the evolutionary chain and inherits the influence or response result of the current fragment. Simultaneous fragment merging refers to the merging of multiple fragments that are in the same event stage but are described by different sources or different object perspectives.

[0124] The target risk evolution chain refers to an evolution chain that represents the current risk process, determined after integrity verification and inter-chain conflict verification. The knowledge extraction result for rail transit operation safety risks refers to the structured output based on the target risk evolution chain, which includes the risk object, evolution stage, related evidence, and target risk evolution chain identifier.

[0125] In practical implementation, the risk evolution assembly rule set is first constructed based on the risk object identifier, event type identifier, time anchor, spatial anchor, relationship type, and handling information in the risk knowledge fragments. For the risk object identifier, the focus is on determining whether the fragment points to the same station, platform, equipment, line section, or passenger flow area. For the event type identifier, the focus is on determining whether the fragment belongs to the anomaly representation category, triggering event category, impact diffusion category, handling response category, or recovery confirmation category.

[0126] For temporal anchors, the focus is on determining the sequential order, persistent coverage relationships, and phase continuity relationships between fragments. For spatial anchors, the focus is on determining whether fragments are located on the same topological node, adjacent nodes, or topological paths with a clear propagation direction. For relationship types, the focus is on identifying whether the fragments represent state relationships, causal relationships, response relationships, recovery relationships, or influence relationships.

[0127] For handling information, it is used to identify whether a certain element contains handling actions such as flow restriction, speed reduction, blockade, repair reporting, isolation, guidance, and recovery confirmation, and to establish the transmission logic from anomaly to handling and from handling to recovery. For example, if one element indicates "significant passenger gathering on the up platform" and another element indicates "station initiates up line flow restriction", and the two are continuous in terms of object, space, and time, and the latter has the attribute of handling action, then a connection can be established through handling transmission rules; if one element indicates "abnormal operation of platform screen door No. 3" and another element indicates "door linkage control restored", then a connection can be established through event phase advancement rules and recovery rules.

[0128] Furthermore, after constructing the risk evolution assembly rule set, this embodiment uses this rule set to perform predecessor fragment identification, successor fragment identification, and same-stage fragment merging on risk knowledge fragments, determining the temporal connection relationship, causal connection relationship, and disposal transmission relationship between fragments. Predecessor fragment identification is mainly used to find fragments that precede the current fragment in time and have a supporting role for the current fragment in terms of object, space, or causality. For example, the predecessor fragment of a "start flow restriction" fragment could be a significant accumulation of passenger flow on the platform or a decrease in throughput capacity due to abnormal platform screen doors.

[0129] Successor fragment identification is mainly used to find fragments that are later in time than the current fragment and inherit the influence or response results of the current fragment. For example, the successor fragment of a "power supply anomaly alarm" fragment could be the dispatcher issuing a speed limit order or maintenance confirming the restoration of stability. Fragment merging within the same stage is used to unify and integrate descriptions from multiple sources and perspectives within the same stage. For example, in the anomaly characterization stage, obvious passenger gathering in the accident report, continuously increasing passenger flow density mapped from monitoring data, and escalator congestion in the audio transcription can be merged into composite anomaly fragments of the same stage; in the handling and response stage, the initiation of flow restriction in the dispatch log, the dispatch of additional guidance personnel in the on-site record, and the release of diversion prompts in the broadcast record can be merged into composite handling fragments of the same stage.

[0130] Through the above identification and merging, temporal connection relationships, causal connection relationships, and disposal transmission relationships can be formed among fragments. Among them, the temporal connection relationship is used to characterize the order of fragments on a unified timeline; the causal connection relationship is used to characterize whether a certain abnormal state induces another state, event, or impact; and the disposal transmission relationship is used to characterize whether a certain disposal action inherits the risk of the preceding sequence and affects the evolution of the subsequent state.

[0131] Furthermore, after determining the relationships between fragments, this embodiment, based on temporal, causal, and dispositional connections, links risk knowledge fragments corresponding to the same set of risk objects, the same event process, or the same spatiotemporal range in a chain, generating a risk evolution chain corresponding to one or more stages of risk induction, state evolution, event triggering, impact diffusion, disposition response, and recovery state. It should be noted that the risk evolution chain may not cover all stages in different real-world scenarios. For example, in some shorter-process scenarios, only a three-stage chain of "state evolution - disposition response - recovery state" may be formed; in some complex and compound risk scenarios, a complete chain of "risk induction - state evolution - event triggering - impact diffusion - disposition response - recovery state" may be formed.

[0132] This embodiment allows for the flexible assembly of one or more evolutionary chains based on the actual content of the fragments, without requiring all stages to exist. When connecting in a chain, a main chain is prioritized around the primary risk object or set of primary risk objects, and then related affected objects, related handling actions, or related diffusion objects are linked as branch chains. For example, in a scenario where abnormal passenger flow on a platform is coupled with abnormal platform screen door operation, passenger flow aggregation and abnormal door operation can be considered together as the triggering background for the main chain, and then the activation of flow restriction, the deployment of additional guidance personnel, and the linkage control for door restoration can be respectively connected to subsequent stages of the main chain; in a scenario of fluctuating power supply in a section, abnormal voltage fluctuation can be used as the starting fragment, and speed limit commands and power restoration confirmations can be used as subsequent main chain fragments.

[0133] Furthermore, after forming the risk evolution chain, this embodiment further performs integrity checks and inter-chain conflict checks on the risk evolution chain, combining the evidence index set, confidence marker, and version marker of the fragments within the chain, to determine the target risk evolution chain. The integrity check is mainly used to determine whether an evolution chain has at least a valid stage structure and supporting evidence conditions.

[0134] For example, if a chain contains only a single isolated "recovery state" fragment without any preceding anomaly or handling context, it is generally not retained as a target risk evolution chain. If a chain contains multiple stages, but the key fragments within the chain lack valid evidence indexes or have confidence levels below a preset threshold, then the chain can be marked as a supplementary chain or a candidate chain.

[0135] In some examples, inter-chain conflict verification is primarily used to determine whether there are object conflicts, temporal conflicts, spatial conflicts, or stage conflicts among multiple candidate evolution chains. For instance, if two chains both claim to represent an abnormal process of the same device within the same time window, but one chain is primarily based on "abnormal action - repair report - recovery," while the other chain is primarily based on "normal operation - recovery confirmation," and neither can be simultaneously established, then one of them should be selected as the target risk evolution chain based on the strength of evidence within the chain, source priority, and version status, while the other chain should be downgraded, retained as a historical version, or eliminated. For cases where there are local conflicts but overall compatibility, fragment replacement, stage merging, or version coexistence can be used to handle the situation.

[0136] Furthermore, after determining the target risk evolution chain, this embodiment generates rail transit operation safety risk knowledge extraction results corresponding to the risk object, evolution stage, associated evidence, and target risk evolution chain identifier based on the target risk evolution chain. These extraction results can be output in a structured record format, and their content may include: the corresponding main risk object or set of objects, stage identifiers contained in the evolution chain, key fragments corresponding to each stage, a set of evidence indexes associated with each fragment, and a target risk evolution chain identifier used to uniquely identify the evolution chain. When necessary, the time interval, spatial range, key handling actions, and recovery results of each stage within the chain can also be further output for subsequent knowledge graph storage, risk case retrieval, scenario simulation, and platform visualization.

[0137] The implementation of this embodiment is illustrated below with a specific example. Taking the scenario of abnormal passenger flow on the platform and abnormal operation of the platform screen door equipment during the evening peak of a certain station during a holiday as an example, the risk knowledge fragments generated in the previous step include: Fragment 1 "Significant passenger gathering on the up platform", with a time anchor point of 18:12, a spatial anchor point of the up platform area of ​​a certain station, and an event type of abnormal passenger flow; Fragment 2 "Abnormal operation of platform screen door No. 3", with a time anchor point of 18:14, a spatial anchor point of the same platform equipment area, and an event type of equipment abnormality; Fragment 3 "Station initiates up line flow restriction", with a time anchor point of 18:16, and an event type of handling response; Fragment 4 "Additional personnel to guide passengers to detour", with a time anchor point of 18:17, and an event type of handling response; Fragment 5 "Door body resumes linkage control", with a time anchor point of 18:28, and an event type of recovery state.

[0138] In a specific example, the system first determines that all the aforementioned fragments are located within the relevant range of the same station's upstream platform based on object continuity rules and spatial connection rules. Then, based on temporal connection rules and event phase advancement rules, it identifies fragment 1 and fragment 2 as precursor fragments, fragment 3 and fragment 4 as fragments handled in the same phase, and fragment 5 as a subsequent recovery fragment. Subsequently, the system merges fragment 1 and fragment 2 into a composite fragment for the anomaly representation phase, merges fragment 3 and fragment 4 into a composite fragment for the handling response phase, and assembles them into a risk evolution chain in the order of "anomaly representation - handling response - recovery state".

[0139] If accident reports and monitoring data support fragment one, equipment alarms and maintenance work orders support fragment two, and dispatch logs and audio transcriptions support fragments three and four, then the chain has high completeness and strong evidentiary support, and can be identified as the target risk evolution chain. The final output of rail transit operation safety risk knowledge extraction results includes: the main risk object is the set of objects related to the up-line platform and platform screen door No. 3 of a certain station; the evolution stages include the anomaly characterization stage, the handling and response stage, and the recovery stage; the associated evidence is the index set of corresponding accident reports, monitoring data, equipment alarms, maintenance work orders, and dispatch logs; and the target risk evolution chain identifier is the unique chain identifier of this chain.

[0140] For example, in a power supply anomaly scenario, risk knowledge fragments include abnormal fluctuations in the downlink power supply voltage, dispatching speed limit orders, train interval adjustments, and maintenance confirmation of power supply stabilization. Based on event phase progression rules, the system identifies abnormal voltage fluctuations as risk-inducing or state evolution phase fragments, speed limit orders and interval adjustments as response and impact control phase fragments, and power supply stabilization as a recovery state fragment. These are linked together to form an evolutionary chain of "state evolution - response - recovery state." If another chain exists that is supported only by low-reliability transcription records, and its recovery time significantly conflicts with the maintenance confirmation record, then in the inter-chain conflict verification, the main chain supported by dispatch logs, equipment monitoring, and maintenance records will be prioritized, and the low-reliability chain will be downgraded to a candidate version.

[0141] For example, in some scenarios, a single risk process can trigger a localized diffusion effect. Suppose that passenger congestion on a station platform further leads to escalator congestion at entrances and exits. The system can then, based on the main chain of "platform passenger congestion - initiation of flow control - passenger flow recovery to controllable levels," add escalator congestion and entrance / exit diversion broadcasts as branch chains for impact diffusion and diffusion management to the corresponding stages of the main chain. This generated target risk evolution chain not only reflects the evolution process of the main risk object but also expresses the propagation and suppression process of the risk in adjacent functional areas, providing a basis for subsequent risk diffusion analysis.

[0142] Through the above implementation methods, this embodiment constructs a risk evolution assembly rule set based on risk object identifiers, event type identifiers, time anchors, spatial anchors, relationship types, and handling information in risk knowledge fragments. It then performs predecessor fragment identification, successor fragment identification, same-stage fragment merging, chain connection, and chain integrity and inter-chain conflict verification on the risk knowledge fragments. This enables the organization of scattered risk knowledge fragments into risk evolution chains that conform to the semantics of rail transit operation safety scenarios, and further generates structured rail transit operation safety risk knowledge extraction results. Therefore, it enhances the overall expressive ability of the extraction results for the risk occurrence, handling, and recovery processes, improving the usability of subsequent knowledge graph storage, case analysis, and risk deduction.

[0143] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0144] Figure 2 This is a schematic diagram of the structure of a risk knowledge extraction system for rail transit operation safety provided in an embodiment of this application. Figure 2 As shown, the system includes: The acquisition module 201 is used to acquire structured data, semi-structured data, unstructured text data and voice or image conversion data related to rail transit operation safety, and to perform terminology normalization, encoding mapping and time normalization processing on the acquired data to obtain standardized data. The identification module 202 is used to identify chapter boundaries, time clues, spatial clues and object switching of standardized data based on the risk ontology and risk event patterns for rail transit operation safety, and generate risk scene fragments. The extraction module 203 is used to perform joint extraction of entities, attributes, relationships and events based on risk scenario fragments, and to perform constraint verification by combining risk ontology and risk event patterns to obtain candidate risk knowledge; The mapping module 204 is used to perform time anchor point identification, spatial anchor point identification and rail transit topology mapping on candidate risk knowledge to obtain spatiotemporally related knowledge units. The fusion module 205 is used to perform evidence fusion and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; Assembly module 206 is used to assemble a risk evolution chain based on risk knowledge fragments and output the results of extracting knowledge on rail transit operation safety risks.

[0145] In some embodiments, Figure 2 The acquisition module 201 acquires accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, monitoring data, and audio-visual data related to rail transit operation safety. It performs structured parsing, semi-structured format parsing, unstructured text parsing, and speech or image text recognition on the acquired data according to its organization format to obtain corresponding initial content units. Based on a preset rail transit professional terminology system, object coding system, and data time benchmark, it performs object identifier association, terminology alias merging, field semantic alignment, and time expression unification on the initial content units to generate standardized data associated with the data source identifier.

[0146] In some embodiments, Figure 2The identification module 202, based on risk ontology and risk event patterns, constructs a set of scene segmentation rules corresponding to risk object types, event stage types, spatiotemporal constraint types, and context transition types. Based on the scene segmentation rule set, it performs chapter structure parsing and semantic unit division on standardized data to determine the boundaries of candidate segments corresponding to accident course, anomaly representation, handling process, recovery status, or management requirements. For the candidate segment boundaries, it identifies the scene continuity relationship and scene switching relationship between adjacent semantic units by combining time clues, spatial clues, risk object referential relationships, and event trigger word distribution. Based on the scene continuity relationship and scene switching relationship, it aggregates and recombines candidate segments pointing to the same set of risk objects, the same spatiotemporal range, or the same event evolution stage, and separates and segments candidate segments with object switching, spatiotemporal jumps, or event stage changes to generate risk scene segments.

[0147] In some embodiments, Figure 2 The extraction module 203 performs risk element trigger word identification, object referencing parsing, and semantic role labeling on risk scenario fragments to generate joint extraction inputs corresponding to entity candidates, attribute candidates, relationship candidates, and event candidates. Based on a preset joint extraction model, it performs collaborative decoding under association constraints on the joint extraction inputs to obtain initial extraction results corresponding to risk objects, state representations, association relationships, event types, and event participating roles. Based on the risk ontology, it performs type consistency verification, object pairing legality verification, and attribute attribution verification on the initial extraction results, eliminating abnormal results that do not meet ontology constraints. Based on the risk event pattern, it performs event stage sequence verification, causal connection verification, and disposal chain integrity verification on the initial extraction results that have passed the ontology verification, to obtain candidate risk knowledge that matches the semantics of risk evolution.

[0148] In some embodiments, Figure 2 The mapping module 204 identifies the temporal expression, spatial expression, operational object identification, and event association description in the candidate risk knowledge, generating temporal candidate anchors, spatial candidate anchors, and object location candidate results. Based on preset operational time series benchmarks and time parsing rules, it performs absolute time conversion, relative time alignment, and time interval regularization on the temporal candidate anchors to determine the temporal anchors corresponding to the candidate risk knowledge. Based on preset line station system, section location system, equipment coding system, and spatial reference rules, it performs station affiliation parsing, section direction parsing, equipment location parsing, and spatial hierarchy association on the spatial candidate anchors and object location candidate results to determine the spatial anchors corresponding to the candidate risk knowledge. Based on the rail transit topology model, it maps the candidate risk knowledge corresponding to the temporal and spatial anchors to the topological locations corresponding to lines, stations, sections, equipment, or functional areas, generating spatiotemporal association knowledge units associated with the temporal anchors, spatial anchors, and topological locations.

[0149] In some embodiments, Figure 2 The fusion module 205 constructs a cross-source evidence association rule set based on the risk object identifier, event type identifier, time anchor, spatial anchor, and source identifier in the spatiotemporal related knowledge unit. Based on the cross-source evidence association rule set, it performs homogeneous deduplication, cross-source alignment, and association clustering on the spatiotemporal related knowledge units corresponding to different data sources, generating an evidence association set corresponding to the same risk object, the same event process, or the same evolutionary stage. For the evidence association set, it performs evidence confidence aggregation by combining the data source credibility level, spatiotemporal consistency, object consistency, event stage consistency, and evidence support strength to obtain candidate fusion results. For conflicting knowledge in the candidate fusion results, it identifies time conflicts, spatial conflicts, object conflicts, event sequence conflicts, or attribute value conflicts based on preset conflict discrimination rules, and performs conflict resolution according to source priority, topological constraint relationship, and time constraint relationship. Based on the candidate fusion results after conflict resolution, it generates risk knowledge fragments associated with risk fact identifiers, evidence index sets, confidence identifiers, and version identifiers.

[0150] In some embodiments, Figure 2 The assembly module 206 constructs a risk evolution assembly rule set based on the risk object identifier, event type identifier, time anchor, spatial anchor, relationship type, and disposal information in the risk knowledge fragments. Based on this rule set, it performs predecessor fragment identification, successor fragment identification, and merging of fragments at the same stage to determine the temporal, causal, and disposal transmission relationships between fragments. Based on these relationships, it chains risk knowledge fragments corresponding to the same risk object set, the same event process, or the same spatiotemporal range, generating risk evolution chains corresponding to one or more stages of risk induction, state evolution, event triggering, impact diffusion, disposal response, and recovery. For each risk evolution chain, it performs integrity checks and inter-chain conflict checks, combining the evidence index set, confidence marker, and version marker of the fragments within the chain, to determine the target risk evolution chain. Based on the target risk evolution chain, it generates rail transit operation safety risk knowledge extraction results corresponding to the risk object, evolution stage, associated evidence, and target risk evolution chain identifier.

[0151] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0152] Figure 3 This is a schematic diagram of the electronic device 3 provided in an embodiment of this application. Figure 3As shown, the electronic device 3 of this embodiment includes: a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various system embodiments described above.

[0153] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or different components.

[0154] The processor 301 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0155] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 3. The memory 302 can also include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device.

[0156] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0157] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which may be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0158] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for extracting risk knowledge for rail transit operation safety, characterized in that, include: The system acquires structured data, semi-structured data, unstructured text data, and voice or image conversion data related to rail transit operation safety, and performs terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data. Based on the risk ontology and risk event patterns for rail transit operation safety, the standardized data is subjected to chapter boundary identification, time clue identification, spatial clue identification, and object switching identification to generate risk scene fragments. The risk ontology refers to a pre-constructed knowledge object system and its set of relational constraints around rail transit operation safety scenarios, used to define the core object categories, attribute categories, relation categories, and event categories involved in risk knowledge. The risk event pattern refers to a pre-defined semantic template for the evolutionary structure of risk events, used to constrain the unfolding order and stage composition of risk-related content in a data segment. Based on the risk scenario fragments, joint extraction of entities, attributes, relationships, and events is performed, and constraint verification is performed in conjunction with the risk ontology and risk event patterns to obtain candidate risk knowledge; The candidate risk knowledge is subjected to time anchor point identification, spatial anchor point identification, and rail transit topology mapping to obtain spatiotemporally related knowledge units. Evidence fusion and conflict resolution are performed on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; Based on the aforementioned risk knowledge fragments, a risk evolution chain is assembled, and the results of extracting knowledge about rail transit operation safety risks are output. The step of performing evidence fusion and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments includes: Based on the risk object identifier, event type identifier, time anchor, spatial anchor and source identifier in the spatiotemporal related knowledge unit, a cross-source evidence association rule set is constructed; Based on the cross-source evidence association rule set, homogeneity deduplication, cross-source alignment and association clustering are performed on spatiotemporal related knowledge units corresponding to different data sources to generate evidence association sets corresponding to the same risk object, the same event process or the same evolution stage. For the aforementioned evidence association set, evidence confidence aggregation is performed by combining data source trust level, spatiotemporal consistency, object consistency, event phase consistency, and evidence support strength to obtain candidate fusion results; For conflicting knowledge in the candidate fusion results, based on preset conflict discrimination rules, time conflicts, spatial conflicts, object conflicts, event sequence conflicts, or attribute value conflicts are identified, and conflict resolution is performed according to source priority, topological constraint relationship, and time constraint relationship. Based on the candidate fusion results after conflict resolution, risk knowledge fragments are generated that are associated with risk fact identifiers, evidence index sets, confidence identifiers, and version identifiers.

2. The method according to claim 1, characterized in that, The process of performing terminology normalization, encoding mapping, and time normalization on the acquired data to obtain standardized data includes: Obtain accident reports, fault records, inspection records, dispatch logs, maintenance work orders, regulatory documents, monitoring data, and audio-visual data related to rail transit operation safety; According to the data organization form, the acquired data is subjected to structured parsing, semi-structured layout parsing, unstructured text parsing, and speech recognition or image text recognition to obtain the corresponding initial content units; Based on a pre-defined rail transit terminology system, object coding system, and data time benchmark, the initial content unit is subjected to object identification association, terminology alias merging, field semantic alignment, and time expression unification to generate standardized data associated with data source identifiers.

3. The method according to claim 1, characterized in that, Based on the risk ontology and risk event patterns for rail transit operation safety, the standardized data is subjected to chapter boundary identification, time clue identification, spatial clue identification, and object switching identification to generate risk scenario fragments, including: Based on the risk ontology and risk event patterns, a set of scenario segmentation rules corresponding to risk object type, event stage type, spatiotemporal constraint type and context transition type is constructed. Based on the scenario segmentation rule set, the standardized data is parsed for chapter structure and semantic unit division to determine the candidate segment boundaries corresponding to the accident process, anomaly characterization, handling process, recovery status or management requirements. Based on the candidate segment boundaries, and combining temporal clues, spatial clues, risk object referential relationships, and event trigger word distribution, the scene continuity relationship and scene switching relationship between adjacent semantic units are identified; Based on the scenario continuity relationship and scenario switching relationship, candidate segments pointing to the same set of risk objects, the same spatiotemporal range, or the same event evolution stage are aggregated and recombined. Candidate segments with object switching, spatiotemporal jumps, or event stage changes are separated and segmented to generate risk scenario segments.

4. The method according to claim 1, characterized in that, The process involves jointly extracting entities, attributes, relationships, and events based on the risk scenario fragments, and performing constraint verification in conjunction with the risk ontology and risk event patterns to obtain candidate risk knowledge, including: The risk scenario fragments are subjected to risk element trigger word identification, object reference parsing, and semantic role labeling to generate joint extraction inputs corresponding to entity candidates, attribute candidates, relationship candidates, and event candidates. Based on the preset joint extraction model, collaborative decoding under association constraints is performed on the joint extraction input to obtain the initial extraction results corresponding to the risk object, state representation, association relationship, event type and event participant role; Based on the risk ontology, type consistency verification, object pairing legality verification, and attribute attribution verification are performed on the initial extraction results to eliminate abnormal results that do not meet the ontology constraints; Based on the aforementioned risk event pattern, the initial extraction results verified by ontology are subjected to event stage sequence verification, causal connection verification, and resolution chain integrity verification to obtain candidate risk knowledge that matches the semantics of risk evolution.

5. The method according to claim 1, characterized in that, The process of identifying time anchor points, spatial anchor points, and mapping rail transit topology to the candidate risk knowledge yields spatiotemporally related knowledge units, including: The temporal representation, spatial representation, operational object identification, and event association description in the candidate risk knowledge are identified to generate temporal candidate anchor points, spatial candidate anchor points, and object location candidate results. Based on the preset operational timeline benchmark and time parsing rules, the candidate time anchors are subjected to absolute time conversion, relative time alignment and time interval regularization to determine the time anchors corresponding to the candidate risk knowledge. Based on the preset line station system, section location system, equipment coding system and spatial reference rules, the spatial candidate anchor points and object positioning candidate results are analyzed for station affiliation, section direction, equipment location and spatial hierarchy to determine the spatial anchor points corresponding to the candidate risk knowledge. Based on the rail transit topology model, the candidate risk knowledge corresponding to the time anchor point and spatial anchor point is mapped to the topological location corresponding to the line, station, section, equipment or functional area, generating spatiotemporal related knowledge units associated with the time anchor point, spatial anchor point and topological location.

6. The method according to claim 1, characterized in that, The assembly of the risk evolution chain based on the risk knowledge fragments and the output of the rail transit operation safety risk knowledge extraction results include: Based on the risk object identifier, event type identifier, time anchor, spatial anchor, relationship type, and handling information in the risk knowledge fragments, a risk evolution assembly rule set is constructed. Based on the risk evolution assembly rule set, the risk knowledge fragments are subjected to predecessor fragment identification, successor fragment identification and same-stage fragment merging to determine the temporal connection relationship, causal connection relationship and disposal transmission relationship between fragments. Based on the aforementioned temporal connection relationship, causal connection relationship, and disposal transmission relationship, risk knowledge fragments corresponding to the same set of risk objects, the same event process, or the same spatiotemporal range are linked in a chain to generate a risk evolution chain corresponding to one or more stages in risk induction, state evolution, event triggering, impact diffusion, disposal response, and recovery state. For the aforementioned risk evolution chain, based on the evidence index set, confidence marker, and version marker of the fragments within the chain, integrity verification and inter-chain conflict verification are performed to determine the target risk evolution chain; Based on the target risk evolution chain, knowledge extraction results of rail transit operation safety risks are generated, corresponding to the risk object, evolution stage, associated evidence, and target risk evolution chain identifier.

7. A risk knowledge extraction system for rail transit operation safety based on the method described in any one of claims 1 to 6, characterized in that, include: The acquisition module is used to acquire structured data, semi-structured data, unstructured text data, and voice or image conversion data related to rail transit operation safety, and to perform terminology normalization, encoding mapping, and time normalization processing on the acquired data to obtain standardized data. The identification module is used to perform chapter boundary identification, time clue identification, spatial clue identification and object switching identification on the standardized data based on the risk ontology and risk event patterns for rail transit operation safety, and generate risk scene fragments. The extraction module is used to perform joint extraction of entities, attributes, relationships and events based on the risk scenario fragments, and to perform constraint verification in combination with the risk ontology and risk event patterns to obtain candidate risk knowledge; The mapping module is used to perform time anchor point identification, spatial anchor point identification, and rail transit topology mapping on the candidate risk knowledge to obtain spatiotemporal related knowledge units. The fusion module is used to perform evidence fusion and conflict resolution on spatiotemporally related knowledge units corresponding to different data sources to generate risk knowledge fragments; The assembly module is used to assemble a risk evolution chain based on the risk knowledge fragments and output the results of extracting knowledge about rail transit operation safety risks.

8. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images