Rail transit one-ticket system multi-scene transfer identification and travel modeling method and system

Abstract

The invention discloses a rail transit one-ticket system multi-scene transfer identification and travel modeling method and system, and relates to the technical field of industrial internet platforms. The rail transit one-ticket-system multi-scene transfer identification and travel modeling method comprises the following steps: S1, collecting multiple types of rail transit basic data sets, and carrying out normalization processing and standardized packaging; s2, carrying out transfer candidate identification and type judgment, and generating a transfer event record set; s3, performing stroke path reconstruction, running fragment division and section data structure packaging; and S4, performing travel result state management, and constructing a settlement-oriented result output and audit account checking interface. According to the method, the one-ticket multi-scene transfer identification accuracy and the travel reconstruction precision in a scene in which multiple operation subjects and multiple pricing modes coexist are effectively improved, and the problems that automatic identification is difficult, section-level data are difficult to output to a settlement system and an industrial internet platform, and the result lacks version management and traceable recalculation capability are solved.

Description

Technical Field

[0001] This invention relates to the field of industrial internet platform technology, specifically to a method and system for identifying and modeling multiple transfer scenarios under a single-ticket system for rail transit. Background Technology

[0002] As urban rail transit networks evolve from single-line operation to cross-regional, multi-system, and multi-operator collaborative operation, the scope of one-ticket interoperability has expanded from a single line to multiple lines, multiple brands, and intercity lines. Multiple travel media such as card swiping, QR codes, and NFC are used in parallel. Settlement, clearing, and operational analysis increasingly rely on refined segment-level passenger flow data. Current technologies still focus on single entry and exit records, only retaining the origin and destination stations and simple ticket information. They lack unified modeling of multi-source ticketing data and automatic recognition capabilities for multi-scenario transfers. They also fail to construct segment data structures subdivided by line and station boundaries, making it difficult to meet the needs of trip reconstruction, segment-level clearing, and result audit recalculation in a one-ticket system scenario involving multiple operators.

[0003] For example, the invention patent with announcement number CN114092297B discloses a rail transit data processing method, apparatus, equipment, and storage medium, including: selecting at least one target station and determining multiple operating sections corresponding to the target station, wherein the starting station of the operating section is the target station, and the ending station is any station on a single path from the target station without transfer; for any operating section, traversing the rail transit data of the operating section in a preset time period to obtain the set of non-travel time periods of passengers in the operating section; performing data clustering on the set of non-travel time periods through unsupervised learning corresponding to the operating section to obtain the clustering result of the operating section; identifying abnormal data in the rail transit data that shows reverse travel behavior at the target station based on the clustering result; and sorting passenger flow based on the identification result of abnormal data.

[0004] For example, the invention patent with announcement number CN114971229B discloses a method for matching passenger flow and train numbers on rail transit lines based on card swiping and positioning data. This method includes: determining the direction of passenger travel sequences for single-line passengers without transfers based on passenger card swiping data and vehicle automatic positioning data; identifying possible train numbers for passengers entering and exiting the station by the difference between passenger card swiping time and subway operating time, and determining single-train and multi-train travel sequences based on the intersection of possible train numbers; classifying passenger entry and exit times into time categories using K-means clustering analysis, and revising the clustering results based on previous and subsequent train number derivations and single-train travel sequence information; and performing repeated clustering analysis on passenger flow on a single line until all passenger travel sequences are determined. This invention uses only rail transit card swiping data and operational data to complete the specific train number matching for passengers on a single line, is computationally convenient, and provides effective decision support for rail transit companies to reduce costs and increase efficiency in operation scheduling.

[0005] In the existing technology, the existing system only summarizes the simple journey based on the single entry and exit record, lacks the unified identification ability for same-station transfers, cross-station walking transfers and cross-system transfers, and has not built a segment data structure subdivided according to the line and station boundaries, making it difficult to support the single-ticket system clearing and result audit recalculation for multiple operators.

[0006] Therefore, in order to address the above issues, there is an urgent need for a method and system for recognizing and modeling multiple transfer scenarios under the single-ticket system for rail transit. Summary of the Invention

[0007] Technical problems to be solved

[0008] To address the shortcomings of existing technologies, this invention provides a method and system for multi-scenario transfer identification and trip modeling in rail transit with a single ticket system. This solves the problems of difficulty in automatic identification, output of segment-level data to settlement systems and industrial internet platforms, and lack of version management and traceable recalculation capabilities for the results.

[0009] Technical solution

[0010] To achieve the above objectives, this invention provides the following technical solution: a method and system for multi-scenario transfer recognition and trip modeling under a single-fare system for rail transit, comprising: S1, collecting multiple types of basic rail transit datasets and performing normalization and standardized encapsulation to form input data frames for single-fare trip modeling of rail transit; S2, performing transfer candidate recognition and type determination on multiple types of basic rail transit datasets based on topological constraints, generating a transfer event record set and forming an extended trip event sequence; S3, reconstructing the trip path and dividing the operation segments based on the extended trip event sequence, encapsulating the segment data structure, and generating a segment-level trip view; S4, managing the trip result status based on the segment-level trip view, and constructing a result output and audit reconciliation interface oriented towards settlement.

[0011] Furthermore, the specific process of collecting multiple types of basic rail transit datasets and performing normalization and standardized encapsulation is as follows: Multiple types of basic rail transit datasets are collected collaboratively through an access gateway. These datasets include: ticketing event datasets, equipment basic configuration datasets, line and station topology datasets, candidate trip sequence datasets, operating timetables, section access maps, interconnection and transfer relationship datasets, and modeling parameter and version information datasets. The collected datasets undergo unified format conversion and field standardization, aligning records from different sources in terms of field naming, time representation, and character encoding. Normalization is then performed using a minimum-maximum scaling method, linearly mapping to a unified interval. Discrete fields are assigned continuous integer indices using dictionary encoding, expanding into fixed-length vectors to obtain the processed multi-type basic rail transit datasets.

[0012] Furthermore, the specific process for constructing the input data frame for rail transit single-fare system travel modeling is as follows: The time axis of the processed multi-type rail transit basic datasets is unified using a time synchronization mechanism and access timestamps. On the data access gateway side, an access timestamp and acquisition node identifier are added to each ticketing event record, while simultaneously retaining the device's local time field sent by the front-end device. The gateway synchronizes with the upper-layer time service, recording the time deviation between the current node and the unified time reference. When the absolute value of the time difference between a record's device local time and the access timestamp is less than or equal to the clock drift tolerance threshold, both are considered the same event time and uniformly written as the record's analysis time. When the absolute value of the time difference is greater than the clock drift tolerance threshold, the access timestamp is used as the analysis time, and the time difference between the two is written in the deviation field for quality assessment. After completing field standardization and timestamps, the media identifier, event type, line number, station number, device number, analysis time, device local time, access timestamp, acquisition node identifier, and quality mark fields are stored in the same record. An ordered cache queue is maintained in the access gateway according to the media identifier and analysis time to construct the input data frame for rail transit single-fare system travel modeling.

[0013] Furthermore, the specific process of identifying and determining the type of transfer candidates based on topological constraints for multiple types of rail transit basic datasets is as follows: Input candidate trip sequence datasets, line and station topology datasets, interconnection and transfer relationship datasets, and modeling parameter and version information datasets. Traverse the candidate trip sequences sorted by a unified analysis time under the same medium identifier. Within the same waiting trip, scan the event sequence according to the unified analysis time. Form candidate transfer event pairs by pairing each exit event with its first subsequent arrival event. Filter and classify the candidate transfer event pairs based on time intervals and topological relationships: For each pair of exit and subsequent arrival events, the difference between the arrival and exit times is used as the transfer interval time. When the transfer interval time exceeds the maximum duration threshold for a single trip, the current candidate trip is considered complete; when the transfer interval time exceeds the maximum duration threshold for a single trip, the current candidate trip is considered complete. When the transfer interval is within the same-station transfer time window threshold, the candidate event pair is marked as a same-station transfer candidate; when the transfer interval is greater than the same-station transfer time window threshold but does not exceed the cross-station transfer time window threshold, the candidate event pair is marked as a cross-station walking transfer candidate; when the line or operating entity of the exit event is different from that of the entry event, the candidate event pair is marked as a cross-system transfer candidate; for multiple pairs of transfer candidate event pairs within the same waiting journey, conflict resolution and order constraints are performed based on dynamic programming for optimal path: according to the order of unified analysis time, the size of the transfer interval, and the topological relationship between stations, the candidate transfer event pairs are prioritized to form a transfer skeleton sequence; during the transfer event identification process, the ticket numbers of the entry and exit transactions need to be matched to form a complete entry and exit transaction. This ensures that the station and line affiliation of the gate where the entry event is located and the station and line affiliation of the gate where the exit event is located can be clearly marked in this complete transaction.

[0014] Furthermore, the specific process of generating a transfer event record set and forming an extended travel event sequence is as follows: Based on the transfer skeleton sequence, each confirmed transfer candidate pair is structurally encapsulated to generate a standardized transfer event record set, and each transfer event is marked with confidence and quality. During the transfer event encapsulation process, the matching degree of transfer interval time, spatial distance and configuration parameters is comprehensively evaluated to obtain a transfer confidence score and write it into the transfer event record. In the candidate travel sequence, the transfer events are merged with the original entry and exit events in chronological order using the unified analysis time as the sorting key to form an extended travel event sequence.

[0015] Furthermore, the specific process of reconstructing travel paths and dividing operational segments based on extended travel event sequences is as follows: Input the extended travel event sequence, sort the entry, exit, and transfer events within each travel number range according to a unified analysis time, using transfer events as the line switching boundary, and divide continuous operational segments on the time axis: Within each operational segment, read the line number, starting station number, and ending station number of the segment, retrieve the station sequence table and adjacent station accessibility relationships from the line and station topology data, and combine this with the operating timetable or interval accessibility map to sequentially search for the next directly reachable station from the starting station to the ending station, generating the actual station sequence; when multiple candidate paths exist in the topology, prioritize the path with the lowest total number of stations that aligns with the normal operating direction, marking detour paths or reverse boarding paths that do not conform to the path as abnormal and not writing them as normal operating segments; the single operational interval between two adjacent stations is used as the minimum operational granularity, and multiple minimum operational granularities are sequentially combined to form a line-based station path, forming an operational segment record.

[0016] Furthermore, the specific process of encapsulating the segment data structure and generating a segment-level travel view is as follows: Obtain the segment modeling parameters from the running segment records, line and station topology datasets, and modeling parameters and version information datasets. Within each running segment, segmentation is performed according to the station number order and segment modeling parameters to form a basic segment set. Attribute completion and data structure encapsulation are performed on the segmented basic segments to generate standardized segment records for each segment. The basic segments are then merged according to rules as needed to form a segment view. A segment list is organized using the travel ID as the primary key to construct a segment-level travel view, providing a unified data interface. The main travel table, segment detail table, and version configuration dataset are output.

[0017] Furthermore, the specific process of managing the status of trip results based on the segment-level trip view is as follows: Based on the trip master table, segment detail table, standardized transfer event record set, and version configuration dataset, result status fields and lifecycle management logic are introduced into the trip master table and segment detail table to perform phased control from generation, consumption to recalculation and disposal; Based on the trip master table, segment detail table, standardized transfer event record set, and version configuration dataset, result status fields and status transition rules are set in the trip master table and segment detail table to perform phased management of each trip result from generation, downstream system reading, triggering recalculation to marking disposal. When the trip modeling process is completed and successfully written to the trip master table and segment details table, the status automatically switches from "Pending Modeling" to "Modeling Completed". When the settlement system or industrial internet platform reads the trip results through the interface, the status switches to "Outputted" and records the last read time. When the route and station topology configuration, interconnection and transfer relationship configuration, or segment modeling parameter version changes and the change scope covers trips within a certain time interval, a recalculation task list is generated based on the version configuration dataset, using trip number, time interval, or version conditions as filtering conditions. The status of the corresponding record is switched from "Outputted" or "Modeling Completed" to "Pending Recalculation". For the old and new versions of the same trip number, the origin and destination stations, number of transfers, number of segments, segment mileage, and segment time interval fields are compared item by item. The parts with different field values ​​are registered as difference entries and marked with the reason for the difference. When it is confirmed that the new version result is the standard, the status of the old version record can be uniformly updated to "Discarded". It can only be queried by version number and modeling time when traceability is required.

[0018] Furthermore, the specific process of constructing the result output and audit reconciliation interface for settlement is as follows: For settlement, a result output interface with trip as the granularity is constructed to output trip structure and segment list information, and the settlement system completes ticket calculation and clearing under its own rules; For industrial internet platform and operation analysis system, an analysis interface is constructed to support the output of modeling results from the perspective of trip and segment. In terms of audit and reconciliation support, for each complete entry and exit trip record, the ticket number of the entry and exit gate is checked to see if they match, and reconciliation auxiliary interfaces and difference analysis capabilities are provided by trip and by aggregation dimension.

[0019] Furthermore, the second aspect of this invention provides a multi-scenario transfer recognition and journey modeling system for rail transit with a single fare system, applied to the method for multi-scenario transfer recognition and journey modeling for rail transit with a single fare system. The system includes: a basic topology data acquisition module, used to collect multiple types of basic rail transit datasets and perform normalization and standardized encapsulation to form input data frames for rail transit single-fare journey modeling; an equipment affiliation identification module, used to identify transfer candidates and determine types based on topological constraints in multiple types of basic rail transit datasets, generating a transfer event record set and forming an extended journey event sequence; a journey segmentation modeling module, used to reconstruct journey paths and divide running segments based on the extended journey event sequence, encapsulate segment data structures, and generate segment-level journey views; and a journey result management module, used to manage journey result status based on the segment-level journey view, and construct a result output and audit reconciliation interface oriented towards settlement.

[0020] Beneficial effects

[0021] The present invention has the following beneficial effects: (1) This invention introduces a scenario transfer recognition mechanism based on time window constraints and line and station topology constraints on candidate travel sequences to classify and determine same-station transfers, cross-station walking transfers and cross-system transfers. Combined with conflict resolution and confidence scoring, it solves the problem of difficulty in automatically distinguishing different types of transfers and the need for a lot of manual experience to make judgments, and improves the accuracy and stability of transfer recognition in multi-entity single-ticket scenarios.

[0022] (2) This invention introduces the topology configuration version number, the interconnection and transfer relationship configuration version number, the transfer identification parameter version number, and the section modeling parameter version number into the trip master table, the section detail table, and the transfer event table in a unified manner, and constructs a recalculation and comparison mechanism based on trip ID and version conditions. This enables the modeling results of the same batch of trips before and after parameter or configuration changes to be recalculated, aligned, and audited, which solves the problems of black box, untraceability, and unrecalculation of trip modeling rules, and provides a verifiable basis for parameter optimization and rule upgrade.

[0023] (3) This invention constructs a result output interface for the settlement system at the granularity of the trip, and constructs an analysis interface for the industrial Internet platform and operation analysis system at the granularity of the segment. The interface layer uniformly outputs the trip ID, segment sequence, time interval, mileage, transfer event summary and version information, so that the backend can directly use the segment-level data generated by this invention to complete the cost calculation and clearing under its own fare and clearing rules, avoiding repeated path parsing and secondary trip inference, and reducing integration complexity.

[0024] (4) This invention summarizes the line sections based on the section details table and compares them with the section statistics results of the external clearing system. The number of passes and statistical differences of each section are displayed in the graphical interface. This invention realizes the ability to perform fine reconciliation and difference location for line sections and sections, which is conducive to quickly discovering and investigating errors in travel modeling, errors in clearing rule configuration, or statistical anomalies in external systems.

[0025] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0026] Figure 1 This is a flowchart of the method for multi-scenario transfer recognition and trip modeling of rail transit with a single ticket system provided in an embodiment of the present invention; Figure 2 This is a framework diagram of a multi-scenario transfer recognition and journey modeling system for rail transit with a single ticket system provided in an embodiment of the present invention; Figure 3 This invention provides a schematic diagram of scene transfer recognition and transfer skeleton construction under the same medium in an embodiment of the present invention; Figure 4 A flowchart illustrating the segmentation and segment-level travel view construction provided in this embodiment of the invention; Figure 5 This is a schematic diagram illustrating the statistical analysis and reconciliation discrepancies of line sections based on the section detail table, provided as an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] Please see Figures 1-5 This invention provides a technical solution: a method and system for multi-scenario transfer recognition and trip modeling under a single-fare system for rail transit. In this first embodiment, the method includes: S1, collecting multiple types of basic rail transit datasets and performing normalization and standardized encapsulation to form input data frames for single-fare trip modeling; S2, performing transfer candidate recognition and type determination on multiple types of basic rail transit datasets based on topological constraints to generate a transfer event record set and form an extended trip event sequence; S3, reconstructing the trip path and dividing the operation segments based on the extended trip event sequence, encapsulating the segment data structure, and generating a segment-level trip view; S4, managing the trip result status based on the segment-level trip view, and constructing a result output and audit reconciliation interface oriented towards settlement.

[0029] Specifically, in the specific implementation of Example 1, the process of collecting multiple types of rail transit basic datasets and performing normalization and standardized encapsulation is as follows: Multiple types of rail transit basic datasets are collected collaboratively through an access gateway. These datasets include: ticketing event datasets, equipment basic configuration datasets, line and station topology datasets, candidate travel sequence datasets, operating timetables, section access maps, interconnection and transfer relationship datasets, and modeling parameter and version information datasets. The ticketing event datasets include: entry records, exit records, ticket supplement records, timeout processing records, and abnormal release records, which are original transaction logs uploaded in real-time or in batches by entry and exit gates, station ticketing servers, and the central ticketing clearing system deployed at each line and station, in the order of transaction occurrence. The equipment basic configuration datasets include: unique equipment number, equipment type, operating entity, line, station, and installation area within the station, which are periodically exported from the ticketing equipment management platform or asset management system or obtained through interface synchronization. The line and station topology datasets include: line number, line... The data includes: road name, route type, station number, station name, station sequence number on the route, distance between adjacent stations, and standard operating time. These are structured configuration data provided by the operation scheduling system or route planning system. The candidate trip sequence dataset includes: waiting trip number, medium identifier, event sequence number, unified analysis time, event type, equipment number, route number, station number, operating entity number, and event quality marker fields. These are obtained by identifying equipment affiliation, calculating unified analysis time, and performing semantic verification on standard ticketing event records. The interconnection and transfer relationship dataset includes: same-station transfer station identifiers, cross-station pedestrian transfer station group identifiers, cross-route transfer channel relationships, and corresponding station pairs. These are transfer relationship tables formed by configuring route construction data and operation plans. The modeling parameter and version information dataset includes: section modeling parameters, same-station transfer time window threshold, cross-station transfer time window threshold, maximum duration of a single trip, topology configuration version number, equipment configuration version number, and modeling rule version number. These are operating parameters uniformly maintained and distributed through the parameter configuration platform.

[0030] The collected basic rail transit datasets undergo unified format conversion and field standardization, aligning records from different sources in terms of field naming, time representation, and character encoding. Manufacturer-defined equipment and station codes in the basic equipment configuration data are converted to platform-unified equipment IDs and station IDs. Effective and expiration time fields are added to configuration records for the same equipment at different times. Line topology and station configuration data are grouped and validated according to line number and topology version, checking the continuity of station numbers and the integrity of inter-station relationships, removing discontinued lines and abandoned stations, and automatically generating new or adjusted line and station records. A new topology version number is generated, while the old version is retained to support historical route modeling. Normalization is performed using a minimum-maximum scaling method, linearly mapping to a unified interval. Discrete fields are assigned continuous integer indices using dictionary encoding, expanding into fixed-length vectors. Interchange relationship data is deduplicated and merged according to station number and line combination, unifying duplicated transfer relationships from multiple sources into a standardized transfer relationship table at the granularity of transfer stations or station groups. The modeling parameters and version information datasets are managed for validity periods, with each set of parameters configured with an effective and expiration time, resulting in processed multi-class rail transit basic datasets. In the organized modeling parameters and version information datasets, rule numbers and rule version numbers are configured for the generation logic of derived fields in the unified analysis time calculation rules, transfer candidate identification rules, and confidence scoring rules, respectively. These numbers and version numbers are then associated and stored with their corresponding effective and expiration times. When calculating the unified analysis time, generating event quality markers, and writing transfer confidence scores, the rule number and rule version number used are synchronously written into the record. This ensures that the unified analysis time field, event quality marker field, and confidence score field maintain a consistent source chain in terms of source data, calculation methods, and version management. This facilitates recalculation and traceability of results according to version after parameter or rule adjustments.

[0031] In this implementation plan, through unified data collection, standardization, and normalization, and by establishing clear rule version relationships for key fields such as unified analysis time, quality markers, and confidence scores, this embodiment eliminates coding differences and time caliber deviations between multiple systems, lines, and operating entities at the underlying data level. This improves the stability and interpretability of trip modeling results. Furthermore, after parameter or rule adjustments, it enables precise comparison of old and new results by version, achieving auditability and recalculation throughout the entire trip modeling process.

[0032] Specifically, in the implementation of Example 1, the specific process of constructing the input data frame for the rail transit single-ticket travel modeling is as follows: The time axis of the processed multi-type rail transit basic datasets is unified using a time synchronization mechanism and access time stamps, and all event times are uniformly converted to a standard time format in a unified time zone; an access timestamp and a collection node identifier are added to each ticketing event record on the data access gateway side, while simultaneously retaining the device local time field sent by the front-end device; the gateway synchronizes with the upper-layer time service, recording the time deviation between the current node and the unified time reference; when the absolute value of the time difference between the device local time and the access timestamp of a record is less than or equal to the clock drift tolerance threshold, the two are considered as the same event time and uniformly written as the analysis time of the record; when the absolute value of the time difference is greater than the clock drift tolerance threshold, the access timestamp is used as the analysis time, and the time difference between the two is written in the deviation field for quality assessment; for front-end devices that cannot obtain device time or have severe drift, a correction time interval is generated by estimating the access time and network round-trip delay.

[0033] After completing field standardization and time stamping, the media identifier, event type, line number, station number, equipment number, analysis time, equipment local time, access timestamp, acquisition node identifier, and quality mark fields are stored in the same record. An ordered cache queue is maintained in the access gateway according to the media identifier and analysis time to construct the input data frame for rail transit single-ticket travel modeling. The input data frame for rail transit single-fare travel modeling includes: frame number, data source type marker, ticketing event substructure, equipment basic information reference, line and station topology version reference, and modeling parameter configuration reference. The ticketing event substructure carries standard ticketing event fields and quality markers. The equipment basic information reference uses the equipment ID and effective time pointer to point to the corresponding record in the equipment basic configuration table. The line and station topology version reference records the topology version number used for this travel modeling and provides a quick access entry from the station ID to the line number and the relationship between adjacent stations. The modeling parameter configuration reference records the configuration numbers of the modeling parameters for same-station transfer time windows, cross-station transfer time windows, and travel timeout thresholds, ensuring that a consistent set of parameters is used when modeling the same batch of input data frames. Global acquisition queues ordered by time and local acquisition queues divided by media identifier or equipment identifier are maintained on edge acquisition nodes or central access gateways. A time-based rolling caching and expiration elimination strategy is implemented for input data frames, prioritizing the retention of the latest travel-related key events to prevent cache overflow.

[0034] In this implementation plan, by unifying the timeline, analyzing time priority rules, and recording clock drift deviations during the input phase of trip modeling, the waiting trip segmentation, transfer identification, and section modeling are all based on a unified time reference and clear version references. On the one hand, this ensures the consistency of data in time and topological semantics across devices, stations, and operating entities, reducing hidden errors caused by clock drift and configuration changes. On the other hand, it provides a foundation for subsequent replay, recalculation, and auditing of results, allowing for precise traceability to the input frame, configuration version, and time deviation.

[0035] Specifically, in another implementation of Example 1, the specific process of identifying and determining the transfer candidate based on topological constraints for multiple types of rail transit basic datasets is as follows: Input candidate travel sequence datasets, line and station topology datasets, interconnection and transfer relationship datasets, and modeling parameter and version information datasets. Traverse the candidate travel sequences sorted by unified analysis time under the same medium identifier. Perform joint determination of time window constraints and topological constraints between adjacent exit events and subsequent entry events to identify multiple scenario transfer candidate pairs and complete transfer type labeling. Within the same waiting area, the event sequence is scanned according to a unified analysis time. Each exit event and its immediately following arrival event are paired as candidate transfer events. These candidate transfer event pairs are then filtered and classified based on time intervals and topological relationships: For each pair of exit and arrival events, the difference between the arrival and exit times is used as the transfer interval. When the transfer interval exceeds the maximum duration threshold for a single trip, the current candidate trip is considered complete, and the subsequent arrival event is reclassified as a new candidate trip and no longer considered for this transfer. When the transfer interval is within the same-station transfer time window threshold, the station numbers of the exit and arrival events are read. If they are the same or marked as equipment combinations within the same physical station in the interconnected transfer relationship dataset, the candidate event pair is labeled as a same-station transfer. Candidate events are categorized as follows: When the transfer interval is greater than the same-station transfer time window threshold but not greater than the cross-station transfer time window threshold, the exit station and the entry station belong to the same transfer station group or are configured as a combination of stations with pedestrian transfer passages. The transfer interval is determined based on the distance between stations and walking time, and the candidate event pair is marked as a cross-station pedestrian transfer candidate. When the line or operating entity of the exit event is different from that of the entry event, and a cross-system transfer passage is configured between them in the interconnection transfer relationship dataset, the candidate event pair is marked as a cross-system transfer candidate. For candidate event pairs whose transfer interval is less than the minimum transfer time threshold, or greater than the cross-station transfer time window threshold, or whose exit and entry station combinations do not support transfers in either the topology data or the transfer relationship dataset, they are marked as non-transfer or abnormal candidates.

[0036] For multiple pairs of candidate transfer events within the same waiting area, conflict resolution and order constraints are applied to achieve optimal paths based on dynamic programming: Candidate transfer event pairs are prioritized according to the order of analysis time, transfer interval, and topological relationships between stations. When multiple candidate event pairs have the same time interval, if priority markers or main channel markers are configured for some station combinations in the interconnection transfer relationship dataset, then the station combinations with priority markers or main channel markers are selected as transfer events from the candidates with the same time interval. Other candidate event pairs that share outbound or inbound events are marked as conflict candidates and temporarily not adopted. The time interval and station span between two consecutive transfer candidates within the same waiting journey are checked. The station order changes on the line topology of each confirmed transfer event are checked one by one in chronological order. The station order number on the same line is required to remain unchanged or increase as the event progresses. It is not allowed for the station order number to decrease relative to the last station of the previous operating section. When it is detected that the introduction of a candidate transfer event will cause the entire path to be connected only by passing through a certain station and then returning to the station or returning to the station before the station, the path corresponding to the candidate transfer is determined to be a round-trip path or a backtracking path. The relevant candidate transfer events are uniformly marked as invalid and removed from the candidate set, retaining the transfer skeleton that forms a monotonic path. All confirmed same-station transfers, inter-station transfers, and inter-system transfers within each waiting area are sorted from morning to night according to a unified analysis time to form a transfer skeleton sequence.

[0037] During the transfer event identification process, the ticket numbers of inbound and outbound transactions need to be matched to form a complete inbound / outbound transaction. This ensures that the station and line affiliation of the gate for the inbound event and the gate affiliation of the outbound event can be clearly identified within this complete transaction. If there are ticket number mismatches or anomalies (such as multiple uses of the same ticket number for inbound and outbound or a lost ticket number), it is marked as an abnormal event and subject to review and processing.

[0038] During the processing of each entry and exit event, ticket numbers are checked to ensure that the ticket numbers for entry and exit gates are identical within the same ticketing transaction. If the ticket numbers match and the event time sequence is correct, the entry and exit gates are considered successfully paired, allowing the generation and identification of subsequent transfer events. If the ticket numbers do not match or the entry / exit times do not conform to the rules, an anomaly is recorded, and the event is marked as a candidate event requiring review or manual confirmation.

[0039] like Figure 3The diagram shown is a schematic diagram of scene transfer recognition and transfer skeleton construction under the same medium provided by the embodiment of this application. The upper part of the diagram shows the station topology and interconnection and transfer relationship of line A, line B and line C: line A includes station A1, station A2 and station A3 in sequence, line B includes station B1, station B2 and station B3 in sequence, and line C includes station C1 and station C2 in sequence. In the topology diagram, the transfer passage between station A2 and station B2 is marked as a same-station transfer passage, and the transfer passage between station B3 and station C1 is marked as a cross-station pedestrian transfer passage, which is used to indicate the physical transfer relationship between different lines. The lower half of the diagram shows the timeline event sequence under the same medium identifier, from left to right: at time t1, entering station A1 of line A; at time t2, exiting station A2 of line A; at time t3, entering station B2 of line B; at time t4, exiting station B3 of line B; at time t5, entering station C1 of line C; and at time t6, exiting station C2 of line C. On the timeline, the area between t2 and t3 is marked as a candidate passage for same-station transfer, corresponding to the A2-B2 transfer relationship in the topology; the area between t4 and t5 is marked as a candidate passage for cross-station pedestrian transfer, corresponding to the B3-C1 transfer relationship in the topology. By mapping outgoing events and subsequent arrival events on the timeline to the upper part of the line and station topology, and combining the configuration of same-station transfer channels and cross-station walking transfer channels, it is possible to identify A2 to B2 as a same-station transfer event and B3 to C1 as a cross-station walking transfer event. The two pairs of events t2-t3 and t4-t5 are identified as transfer nodes, forming the transfer skeleton sequence of this trip, which provides a foundation for trip path reconstruction and segment-level trip modeling based on the transfer skeleton.

[0040] Table 1 shows the corresponding extended trip event sequence table. The independent trips of the three passengers are distinguished by different ticket numbers. The trip chain and data description for each ticket number are as follows: The itinerary chain of ticket number P00125 (passenger 1): This passenger's itinerary contains two core events. The first is a transfer event (number T001) from 10:08:00 to 10:10:00, with the route from A to B and the station from A2 to B2. This is a same-station transfer, connecting the previous event E2 and the next event E3. The transfer interval is 2 minutes, the path length is 100 meters, and the confidence level is 2, indicating that the transfer is efficient and the data is reliable. The second is an exit event at 10:15:00, with the route B and the station B3. It is connected to the previous event E3 and the next event T2. It has no transfer attribute and the confidence level is 2, indicating that the exit data is accurate. This is a key node before the passenger's destination. The itinerary chain of ticket number P00126 (passenger 2): This passenger's itinerary starts with entering the station and consists of three events. The first event is the entry event at 09:30:00, on line D, at station D1, with no preceding events and followed by event E7, with a confidence level of 2, which is the initial record of the itinerary. The second event is the transfer event (number T003) from 09:38:00 to 09:40:00, from line D to E, at station D3 to E2, a transfer at the same station, connecting E7 and E8, with an interval of 2 minutes and a path of 120 meters, with a confidence level of 2, showing a clear transfer process. The third event is the exit event at 09:45:00, on line E, at station E4, followed by E8, with no subsequent events, with a confidence level of 2, completing a complete itinerary loop. The itinerary chain of ticket number P00127 (passenger 3): This passenger's itinerary also contains three events, and the transfer type is a passageway transfer, which differs from the first two passengers. The first event is the entry event at 11:10:00, line F, station F2, no preceding event, followed by E9, confidence level 2, which is the start of the itinerary; the second event is the transfer event (number T004) from 11:20:00 to 11:25:00, line F to G, station F5 to G3, which is a passageway transfer, connecting E9 and E10, with an interval of 5 minutes and a path of 300 meters. Because the passageway transfer distance is longer, the interval and path are both greater than the same-station transfer, and the data is consistent with the actual scenario, confidence level 2; the third event is the exit event at 11:32:00, line G, station G5, followed by E10, no subsequent event, confidence level 2, the itinerary record is complete.

[0041] Table 1 Extended Trip Event Sequence Table

[0042] This implementation scheme introduces a joint determination mechanism that combines time window constraints with line topology and interconnection / transfer relationships into candidate travel sequences. This mechanism reliably distinguishes same-station transfers, cross-station walking transfers, and cross-modal transfers from ordinary station entry / exit events within a single trip on the same medium, generating a clearly structured and sequentially stable transfer skeleton sequence. This improves the accuracy and consistency of scene transfer identification and provides a directly applicable foundation of transfer nodes for travel path reconstruction, segment division, and section-level travel modeling.

[0043] Specifically, in the specific implementation of Example 1, the process of generating a transfer event record set and forming an extended travel event sequence is as follows: Based on the transfer skeleton sequence, each confirmed transfer candidate pair is structurally encapsulated to generate a standardized transfer event record set. The standardized transfer event record set includes: transfer event number, waiting travel number, medium identifier, transfer type, starting line number, starting station number, target line number, target station number, unified analysis time for exiting the station, unified analysis time for entering the station, transfer interval time, estimated transfer path length, transfer direction indicator, and transfer event quality marker fields. The transfer type is used to distinguish between different categories of same-station transfer, cross-station walking transfer, and cross-system transfer. The estimated transfer path length is calculated based on the channel length, inter-station distance, or spatial relationship between station groups configured in the interconnected transfer relationship dataset, and is used to characterize the spatial scale traversed by the transfer. The transfer direction indicator records which line or which operator is transferring from to another line or another operator.

[0044] Each transfer event is assigned a confidence and quality rating. During the event encapsulation process, the matching degree between transfer interval time, spatial distance, and configuration parameters is comprehensively evaluated to obtain a transfer confidence score, which is then written into the transfer event record. Based on the distance of the transfer interval time relative to the same-station transfer time window threshold and the cross-station transfer time window threshold, it is determined whether the time feature falls within the middle sub-interval, upper limit, or lower limit of the transfer time interval. When the transfer interval time falls within the middle sub-interval, it is marked as meeting the time condition; when it falls within the sub-interval close to the upper or lower limit, it is marked as meeting the boundary time condition; when it exceeds the entire interval, it is marked as not meeting the time condition. Based on the comparison results of the transfer path length with the minimum and maximum transfer path lengths, the spatial feature is determined: when the transfer path length is less than the minimum transfer path length and the corresponding time interval is greater than the same-station or cross-station transfer time window threshold, or when the transfer path length is greater than the maximum transfer path length and the corresponding time interval is less than the same-station or cross-station transfer time window threshold, the transfer event is marked as a case of mismatch between spatial and temporal features.

[0045] After classifying time and spatial features, these three types of information—time features, spatial features, and conflict status—are uniformly transformed into numerical scoring indicators. Based on time features, the time score is scaled to a range of zero to one; based on spatial features, the spatial score is also scaled to a range of zero to one; based on conflict status, a conflict coefficient lower than one is assigned to transfer events that share exit or arrival events with other candidates in the waiting travel sequence. For the time score, spatial score, and conflict coefficient, time weights, spatial weights, and conflict penalty weights are configured in the modeling parameters and version information dataset. By selecting manually confirmed real transfer sets and non-transfer sets from historical travel samples, multiple sets of candidate weight parameters are tested. The accuracy of the confidence set, the recall of the boundary set, and the overall false positive rate under different parameters are compared. The set of weights that is close to the expected value in terms of comprehensive indicators is selected as the effective configuration for the current version, and the weight configuration number and version number are recorded in the modeling parameters and version information dataset.

[0046] In the specific scoring process, the weighted sum of the time score and the spatial score is used as the basic confidence value. A conflict coefficient is then used to attenuate the basic confidence value, resulting in a transfer confidence score. The score is then written into the confidence field of the transfer event record. For the transfer confidence score, when the transfer confidence score is not lower than the high threshold and both the time and spatial features are marked as meeting the conditions, the transfer event is marked as a high-confidence transfer. When the transfer confidence score is between the high and low thresholds, or when only one of the time or spatial features meets the conditions, the transfer event is marked as a transfer pending review. When the transfer confidence score is lower than the low threshold, or when neither the time nor spatial features meet the conditions, the transfer event is marked as a low-confidence transfer or an invalid transfer, and the specific reasons for not meeting the conditions are recorded in the quality label field.

[0047] In cases where multiple candidate pairs share the same exit or entry event in the waiting sequence, a conflict penalty is added to these candidates during confidence assessment to reduce their confidence. Considering both temporal rationality, spatial rationality, and conflict situation, a confidence level is assigned to each transfer event, and the confidence level is written into the confidence field of the transfer event record. At the same time, the quality tags distinguish between three categories: high-confidence transfers, transfers pending review, and low-confidence transfers.

[0048] In the candidate travel sequence, using the unified analysis time as the sorting key, transfer events are merged with the original arrival and departure events in chronological order to form an extended travel event sequence. Within this extended sequence, transfer events serve as natural dividing points, dividing continuously traveling sections on the same route into several segments. Each segment corresponds to a running segment without transfer interruptions, and the segment's start and end stations, start and end times, and the corresponding route are recorded. For transfer events with confidence scores between the upper and lower thresholds but not deemed invalid, these events are marked as backup boundaries and retained as candidate dividing points when updating the travel path skeleton. When writing to the travel event table and transfer event table, the topology configuration version number and modeling parameter configuration number used for this transfer identification are recorded simultaneously. After a version upgrade, transfer identification can be re-executed for a specific batch of trips, and the old and new results can be compared.

[0049] In this implementation plan, by quantifying, weighting, and managing the transfer time characteristics, spatial characteristics, and conflict status, the transfer judgment that originally relied on empirical rules is transformed into a calibrable and traceable confidence label. On the one hand, this significantly reduces the trip reconstruction errors caused by misjudgment and omission, and on the other hand, it provides a stable and consistent transfer event basis for segment-level modeling, settlement reconciliation, and result recalculation.

[0050] Specifically, in another implementation of Embodiment 1, the specific process of reconstructing the travel path and dividing the running segments based on the extended travel event sequence is as follows: Input the extended travel event sequence, sort the arrival events, departure events, and transfer events within each travel number range according to the unified analysis time, and use the transfer event as the line switching boundary to divide the continuous running segments on the time axis: For the same travel ID, arrange all events in the extended travel event sequence in ascending order according to the unified analysis time, take the first arrival event as the travel start point, read the line number and station number as the starting line and starting station of the current running segment; traverse the subsequent events sequentially along the time axis, and when an departure event is encountered and the adjacent event is a transfer. When an event occurs, the station number and unified analysis time of the departure event are used as the termination station and termination time of the current running segment. The target line number and target station number are read from the transfer event and used as the starting line and starting station of the next running segment. When there are no more subsequent transfer events and the last event is a departure event, the station number and unified analysis time of the departure event are used as the termination station and termination time of the final running segment. When there are events marked as abnormal by quality control within the trip (such as time sequence reversal, line missing, etc.), without changing the original event record, the abnormal point is used as a temporary segment boundary to divide an independent running segment and the source of the abnormality is recorded in the segment quality mark field.

[0051] Within each running segment, the segment's line number, starting station number, and ending station number are read. The station sequence table and adjacent station accessibility relationships for that line are retrieved from the line and station topology data. The sequence numbers of the starting and ending stations on the line are queried in the station base table, and the existence of continuous adjacent station connections is verified. When a continuous connection exists, starting from the starting station sequence number, the sequence numbers are enumerated sequentially up to the ending station sequence number. For each pair of adjacent stations (e.g., station i and station i+1), the corresponding inter-station distance and standard running time are read and added to the segment's station path list as the smallest running unit. When a breakpoint in the topology is detected between the starting and ending stations or when a detour via other lines is required for connection, the segment is marked as a topology-abnormal running segment. During path expansion, only the continuous station sequence on the topology is retained, and the range and reason for stations that cannot be fully expanded are recorded in the segment quality marker. For successfully expanded running segments, a line-based path representation is constructed for them, and the corresponding inter-station distance and standard running time are recorded for each station pair.

[0052] Combining the operation timetable or interval access map, the system sequentially searches for the next directly reachable station from the starting station to the ending station, generating an actual station sequence. When multiple candidate paths exist in the topology, the path with the lowest total number of stations and consistent with the normal operating direction is prioritized. Detour paths or reverse travel paths that do not conform to the established path are marked as abnormal and not included in the normal operation segment. A single operation interval between two adjacent stations is used as the smallest operation granularity. Multiple smallest operation granularities are sequentially combined to form a routed station path, creating an operation segment record. Each operation segment is assigned a unique segment number, which increments from 1 within the same trip ID. The operation segment record includes: trip ID, segment number, route number, starting station number, ending station number, starting station sequence number, ending station sequence number, segment start time, segment end time, ordered list of stations covered by the segment, total segment mileage, standard segment operation time, and segment quality flag field. In this implementation plan, by automatically reconstructing the routed operation path and dividing the operation into segments based on the extended travel event sequence, the entry, exit and transfer records that originally only existed discretely at the ticketing level are transformed into a temporally continuous and spatially traceable operation segment view. This not only accurately restores the actual travel range and station sequence of passengers on each line and promptly exposes anomalies such as detours, reverse travel and topology missing, but also provides a clearly structured and well-defined travel path foundation for segment division, mileage and time statistics and segment-based source tracing audit.

[0053] Specifically, in the specific implementation of Embodiment 1, the specific process of encapsulating the segment data structure and generating the segment-level travel view is as follows: Figure 4The diagram shows a flowchart of segment segmentation and segment-level travel view construction provided in this application embodiment. It obtains segment modeling parameters from the running segment records, line and station topology datasets, and modeling parameters and version information datasets. Within each running segment, segmentation is performed according to the station number order and segment modeling parameters to form a basic segment set. For a given running segment, starting from the first station in the ordered station list, the distance between stations and the number of stations are gradually accumulated, using adjacent station pairs as the smallest step unit. When the currently accumulated mileage value reaches or exceeds the minimum effective mileage threshold of the segment, and the accumulated number of stations reaches or exceeds the minimum number of stations threshold of the segment, the currently accumulated station range is defined as a basic segment, with the starting station being the current station. The first station of each round of accumulation is the first station, and the last station is the last station of this round of accumulation. The corresponding segment mileage is the accumulated mileage, and the standard running time of the segment is the standard running time of the accumulation. The starting and ending station sequence numbers of the segment within the fragment are recorded. After the division is completed, the above process continues from the next station as the starting point of a new round of accumulation until the station list of the entire running segment is traversed. When the number of stations or mileage remaining at the end of the segment is insufficient to form a basic segment that meets the minimum threshold, the end can be merged with the previous basic segment, provided that the mileage of the merged segment does not exceed the maximum merged mileage threshold of the segment and the number of stations after the merge does not exceed the maximum merged station threshold of the segment. Otherwise, the end is marked as a short interval and noted in the segment quality field.

[0054] The basic segments that have been segmented are augmented with attributes and their data structures are encapsulated to generate standardized segment records for each segment. The basic segments are then merged according to rules as needed to form a segment view. The standardized segment record includes: trip ID, segment number, segment number, route number, operating entity number, segment type, starting station number, ending station number, sequence number of starting station, sequence number of ending station, range of station sequence numbers covered by the segment, segment mileage, standard operating time, estimated actual operating time, start time, end time, and preceding transfer events. The system includes a route number, subsequent transfer event number, and section quality marker. The actual estimated running time of a section can be directly calculated based on the start and end times within the section. For intermediate stations lacking precise timestamps, time estimation can be performed by allocating time according to the standard running time ratio between stations, and the participation of time estimation should be noted in the section quality marker. When it is necessary to form granular business sections, several basic sections that are adjacent and have the same route number, the same section type, and meet the quality marker requirements can be sequentially merged according to the merging rules in the section modeling parameters to generate merged sections. At the same time, the merged section record retains the list of numbers and station ranges of the merged basic sections. The merging rules stipulate that merging is only allowed between basic segments whose segment mileage does not exceed the maximum merging mileage threshold, whose segment coverage does not exceed the maximum merging station threshold, and whose operating entities are the same and are located in the same fare zone or the same settlement unit. In practice, the basic segments are traversed from front to back in sequence based on their segment numbers. Basic segments that meet the above conditions and are consecutively adjacent on the timeline are attempted to be merged in turn. When encountering any situation such as changes in line number, changes in segment type, quality marking as abnormal, or exceeding the mileage and station limit after merging, the current merging chain is immediately terminated, the merged business segment is fixed, and a new merging chain is established from the next basic segment. This ensures that the segment merging result is uniquely determined by deterministic rules and traversal order.

[0055] The system organizes the segment list using the trip ID as the primary key, constructing a segment-level trip view to provide a unified data interface. Based on the reference maximum mileage and reference longest running time configured in the segment modeling parameters, the fields of each segment record are scaled proportionally. A main trip table is created in the database, using the trip ID as the primary key to record trip start and end times, origin and destination stations, total mileage, total number of stations, total number of segments, number of transfers, set of involved routes, set of involved operating entities, and a summary of the trip modeling rule version number. A segment detail table is created, using the trip ID and segment sequence number as a composite primary key to store all fields of standardized segment records, while adding route number, operating entity number, segment type, and time interval index fields, supporting queries from both trip and segment perspectives. Transfer event numbers and running segment sequences are retained in the segment records to enable mutual traceability between segment data and transfer events / running segments.

[0056] Output the trip master table, segment detail table, and version configuration dataset. The trip master table includes: trip ID, medium identifier, trip start time, trip end time, origin station number, destination station number, total mileage, total number of stations, total number of segments, number of transfers, set of involved routes, set of involved operating entities, trip modeling rule version number, route and station topology version number, interconnection and transfer relationship configuration version number, transfer identification parameter version number, segment modeling parameter version number, modeling time, and modeling node fields. The segment detail table includes: trip ID, segment number, sequence number of the associated running segment, number of the associated route, and number of associated operating entities. The configuration dataset includes the following fields: segment number, segment type, segment start station number, segment end station number, segment start station sequence number, segment end station sequence number, segment mileage, segment standard operating time, segment actual estimated operating time, segment start time, segment end time, preceding transfer event number, subsequent transfer event number, and segment quality marker. The version configuration dataset also includes: line and station topology configuration, interconnection and transfer relationship configuration, transfer identification parameter configuration, segment modeling parameter configuration, and historical version information. Each version records its effective date, reason for change, and scope of application.

[0057] This implementation scheme achieves a unified representation from scattered event records to a segment-level trip view by automatically dividing basic segments based on mileage and station thresholds, combined with unified segment merging rules and a dual-table structure for trips and segments. This ensures that each trip has clear route affiliation, station range, time interval, and version source at the segment level. The segment quality tagging and version configuration dataset enable traceability, recalculation, and comparability of the trip splitting process, reducing manual intervention costs and improving the reliability of segment-level business applications.

[0058] Specifically, in another implementation of Example 1, the specific process of managing the status of trip results based on the segment-level trip view is as follows: Based on the trip master table, segment detail table, standardized transfer event record set, and version configuration dataset, result status fields and lifecycle management logic are introduced into the trip master table and segment detail table to perform phased control from generation, consumption to recalculation and disposal; Based on the trip master table, segment detail table, standardized transfer event record set, and version configuration dataset, result status fields and status transition rules are set in the trip master table and segment detail table to perform phased management of each trip result from generation, downstream system reading, triggering recalculation to marking disposal. When the trip modeling process is completed and successfully written to the trip master table and segment details table, the status automatically switches from pending modeling to modeling completed. A segment result status field is set in the segment details table to mark whether the segment record is the current version, whether it needs to be recalculated, or whether it has been replaced by a new version. When the settlement system or industrial internet platform reads the trip results through the interface, the status is switched to output and the last read time is recorded. When the route and station topology configuration, interconnection and transfer relationship configuration, or segment modeling parameter version changes and the change scope covers trips within a certain time interval, a recalculation task list is generated based on the version configuration dataset, with trip number, time interval, or version condition as the filtering condition. The status of the corresponding record is switched from output or modeling completed to pending recalculation, and a version expiration quality mark is added to the corresponding segment details and transfer event record.

[0059] For trip results awaiting recalculation, the recalculation task queue sequentially re-executes transfer identification, trip path reconstruction, and segment modeling according to trip number or time order. The new trip master record, segment details, and transfer event records obtained from the new round of modeling are saved in parallel with the old version results under the same trip number. The corresponding topology version number, parameter version number, and modeling time are marked in the records respectively. During the dedicated difference comparison process, for the new and old versions of the same trip number, the origin and destination stations, number of transfers, number of segments, segment mileage, and segment time interval fields are compared item by item. The parts with different field values ​​are registered as difference entries and marked with the reason for the difference, which is used by auditors to compare the impact of the new and old rules on the trip results. When it is confirmed that the new version results shall prevail, the status of the old version records can be uniformly updated to obsolete, and queries can be made only when traceability is needed by version number and modeling time.

[0060] A recalculation task queue management mechanism based on trip ID, time interval, or version conditions is constructed. Modeling is re-executed under the new version configuration, and the old and new results are retained for difference analysis and auditing. When a configuration change in the version configuration dataset is centrally marked as requiring trip recalculation, trip IDs with a status of "to be recalculated" are filtered from the trip master table based on time interval, route, or operator filtering conditions and added to the recalculation task queue. A unique recalculation batch number is assigned to each batch of tasks. During recalculation, the original ticketing records and basic topology data are read according to the trip ID, and extended trip event sequences are regenerated under the new version configuration. The transfer event table and segment details table record the data. After recalculation, the newly generated results are compared with the old version results item by item in terms of trip ID and segment sequence number. Differences in the segment mileage, segment time, segment type, and transfer type fields are marked. The result status of the old results is set to obsolete or retained as a historical version. At the same time, a new result instance number is assigned to the new results, and the trip status is updated to the initial state of modeled and awaiting settlement or audited. The initiator, triggering reason, recalculation time, execution node, success or failure flags, and exception summary during the recalculation process are uniformly written into the audit log table to ensure that the recalculation process is traceable and explainable.

[0061] This implementation plan transforms trip modeling results into a tagged, recalculated, and comparable end-to-end management object by introducing result status fields, version information, and a recalculation task queue into the trip master table, segment detail table, and transfer event records. This ensures that each trip stage has a clear and traceable status record. After parameter or topology configuration adjustments, it allows for selective batch recalculation and difference verification of historical trips. This guarantees that the data provided to external parties is strictly consistent with the current configuration at any given time, and provides a traceable and interpretable result evolution chain for settlement verification, responsibility allocation, and rule evolution.

[0062] Specifically, in the implementation of Example 1, the specific process of constructing the settlement-oriented result output and audit reconciliation interface is as follows: A settlement-oriented result output interface with trip granularity is constructed, outputting trip structure and segment list information, and completing fare calculation and clearing under its own rules: The settlement interface uses the trip ID as the core identifier, and the minimum output field set includes: trip ID, medium identifier, trip start time, trip end time, origin station number, destination station number, set of involved lines, set of involved operating entities, total mileage, total number of stations, total number of segments, number of transfers, trip modeling rule version number, line and station topology version number, and a segment list sorted by segment number; Each segment in the segment list outputs at least the segment number, the line number, the operating entity number, the segment start station number, the segment end station number, the segment start time, the segment end time, the segment mileage, and the segment quality flag, to ensure that the complete trip structure can be restored without relying on other data tables, and fare calculation and clearing logic can be executed accordingly. The settlement interface supports filtering trip master table records based on time interval, route number, operator number, and trip result status conditions. For each trip that meets the conditions, it outputs the trip ID, medium identifier, trip start time, trip end time, origin station number, destination station number, set of involved routes, set of involved operators, total mileage, total number of stations, total number of segments, number of transfers, and the trip modeling rule version number and topology version number, along with a list of segments corresponding to the trip. The segment list is built based on the segment details table. Each segment record includes: segment sequence number, affiliated route number, affiliated operator number, segment type, segment origin station number, segment end station number, segment mileage, segment actual estimated running time, segment quality mark, and associated preceding and subsequent transfer event numbers. Based on this, it can calculate and clear fees internally according to fares and clearing rules.

[0063] An analysis interface is built for industrial internet platforms and operation analysis systems, supporting the output of modeling results from both trip and segment perspectives, providing a data foundation for passenger flow analysis, operational efficiency assessment, and simulation applications. From a trip perspective, the minimum output field set includes: trip ID, medium identifier, trip start time, trip end time, origin station number, destination station number, set of involved routes, set of involved operating entities, number of transfers, total mileage, total running time, and the trip modeling rule version number and route and station topology version number. Optional outputs include path fingerprints and transfer node sequences. From a segment perspective, the minimum output field set includes: trip ID, segment sequence number, associated route number, associated operating entity number, segment type, segment origin station number, segment end station number, segment mileage, estimated segment running time, segment start time, segment end time, segment quality flag, and the trip modeling rule version number and route and station topology version number. This allows users to uniformly rely on this set of fields to complete route cross-section statistics, operational efficiency assessment, and segment load analysis. In the trip-view interface, the caller can filter trip master table records based on time interval, route or operator, and trip result status conditions. The returned information includes a summary of the matching trip, the routes and operators involved, the number of transfers, and a summary of possible routes, such as a path fingerprint generated by station sequence encoding and a transfer node sequence. In the segment-view interface, the caller can filter segment detail table records based on route number, segment type, time interval, or operator number. The returned information includes a list of matching segments, including segment mileage, segment time, segment type, quality marker, and mileage and time characteristics, supporting route cross-section analysis, segment load assessment, and efficiency comparison. All interface outputs include the trip modeling rule version number and topology version number to explain the source of the results, facilitating data alignment and result comparison in multi-version environments.

[0064] In terms of auditing and reconciliation support, it provides reconciliation assistance interfaces and discrepancy analysis capabilities by trip and aggregation dimension. During the auditing and reconciliation process, for each complete entry and exit trip record, the ticket numbers at the entry and exit gates are checked for matching to ensure data consistency between entry and exit events. If a ticket number mismatch is found, it should be marked and the relevant error information should be output for auditors to verify. The minimum output field set of the auditing and reconciliation assistance interface includes: trip ID, medium identifier, trip start time, trip end time, trip modeling rule version number, line and station topology version number, interconnection and transfer relationship configuration version number, transfer identification parameter version number, segment modeling parameter version number, trip path structure summary, segment list summary (e.g., number of segments, total segment mileage, total segment time), transfer event list summary, and reconciliation discrepancy marker field. This allows auditors to complete the verification and discrepancy location of single trips or groups of trips with only the minimum field set. When further analysis is needed, the complete segment details and transfer event details can be traced back by trip ID and version number. For verification requirements at the trip-level granularity, when the settlement system or auditors provide a set of trip IDs and the costs or clearing results in the settlement system, the system returns the corresponding trip's path structure, segment list, transfer event set, and version information. This allows auditors to check whether transfer identification conforms to configuration rules, whether segment splitting meets minimum and maximum threshold constraints, and whether there are any abnormal detours or reverse routes. For verification requirements at the aggregation level, statistics are summarized based on the segment details table by route, segment type, and time granularity (e.g., by hour, by day), calculating indicators such as segment passage times, segment cumulative mileage, and segment cumulative time. These are then compared with statistical data provided by external systems. When the statistical results of a certain route or segment deviate from the set difference alarm threshold in the statistical configuration parameters within a specified time period, the route or segment is marked as a reconciliation anomaly, and the difference details and related trip ID list are output, providing clues for further investigation. Conditions, thresholds, execution times, and discovered anomalies during the reconciliation and difference analysis process are uniformly recorded in the reconciliation log to ensure the reproducibility and auditability of the reconciliation process.

[0065] like Figure 5The diagram shown is a visualization of the differences between line section statistics and reconciliation based on the section detail table provided in this application embodiment. The horizontal axis represents the section number, with different sections represented in the form of inter-station pairs (A1–A2, A2–A3, B1–B2, B2–B3, C1–C2). The vertical axis represents the number of times a section is passed, in units of times. Each section in the diagram corresponds to two bars: the blue bars represent the statistical results of the number of passes obtained by the present invention based on the section detail table, and the orange bars represent the statistical results of the external clearing system for the same section. Each group of bars is labeled with a difference text. The difference between the statistical results of this invention and the statistical results of the external system represents the statistical deviation between the two systems in a given segment. Segments with a difference within ±2 thresholds are marked with green text, indicating that they are within the acceptable deviation range. When the difference exceeds ±2, such as the "Difference: 3" marked above segment B2–B3, it is highlighted in the graph with red difference text and a "★ Anomaly" mark, indicating that there is a significant difference between the process modeling results and the statistical results of the existing clearing system for this segment, requiring an audit and recalculation of this segment and its related processes. Through this segment-based reconciliation visualization method, segments with concentrated differences and potential modeling or clearing problems can be quickly located. The statistical results in the segment details table are compared segment by segment with the output of the external system, providing an intuitive presentation of the reconciliation and anomaly investigation process.

[0066] In this implementation plan, minimum output field sets are defined for the settlement interface, analysis interface, and audit reconciliation interface, and a data path that can be directly connected is established in the output results, avoiding repeated parsing of the original ticket transaction records or re-deriving the outbound path. Based on the combined output of the segment-level results and the difference marker field, statistical deviations and clearing anomalies can be quickly located, shortening the investigation process and reducing the risk of manual reconciliation and misjudgment. This provides a stable, clear, and easily reproducible data foundation for settlement, analysis, and auditing in the single-ticket system scenario.

[0067] Specifically, in this second embodiment, based on the first embodiment, the second aspect of the present invention provides a rail transit single-fare system multi-scenario transfer identification and journey modeling system, applied to the rail transit single-fare system multi-scenario transfer identification and journey modeling method, including: a basic topology data acquisition module, used to collect multiple types of rail transit basic datasets and perform normalization processing and standardized encapsulation to form a rail transit single-fare system journey modeling input data frame; through an access gateway, ticketing events, equipment basic configurations, line and station topologies, interconnection and transfer relationships, and modeling parameters are synchronously obtained from the ticketing system, equipment management system, and scheduling and planning system, and different sources of records are unified in terms of field naming, time format, and encoding method. An equipment affiliation identification module is used to identify and determine transfer candidates and types based on topological constraints for multiple types of rail transit basic datasets, generate a transfer event record set, and form an extended journey event sequence; using the equipment basic configuration table, a mapping relationship is established between equipment number and operating entity, line number, and station number; the semantics of the line and station are completed for each ticketing event, and a unified analysis time is calculated to form a candidate journey sequence sorted by medium identifier and analysis time. Subsequently, combining the line and station topology and interconnection / transfer relationships, time window constraints and topological constraints are applied to adjacent exit and arrival events to generate transfer event records with transfer type and confidence information. These records are then merged with the original entry and exit events to form an extended travel event sequence. The travel segmentation modeling module is used to reconstruct travel paths and divide operational segments based on the extended travel event sequence. It encapsulates segment data structures and generates segment-level travel views. Using transfer events as line switching boundaries, it divides continuous operational segments. Combining the line and station topology and operating timetable, each operational segment is expanded into a sequence of actual stations passed through, arranged in station order. The travel result management module is used to manage travel result status based on the segment-level travel view. It constructs a result output and audit reconciliation interface oriented towards settlement. It maintains result status, version information, and lifecycle markers in the main travel table and segment detail tables, managing and tracking different travel versions. Meanwhile, it provides a settlement output interface at the trip level and an analysis and audit reconciliation interface from the perspective of trips and segments. It supports triggering trip recalculation by trip ID or time interval after version parameter changes, and compares the differences between the old and new results and records the logs.

[0068] In this implementation plan, the process of identifying and modeling multiple transfer scenarios under a single-ticket system is divided into a basic topology data acquisition module, an equipment ownership identification module, a trip segmentation modeling module, and a trip result management module, forming an end-to-end processing link. This decouples the acquisition side from the modeling side, and the trip identification side from the settlement and auditing side in the system architecture. This facilitates flexible deployment and module-based expansion in environments with different operating entities and different pricing methods. It also enables local upgrades and recalculation control at the module boundary when parameters or rules change, thereby stably supporting daily operation, settlement reconciliation, and historical data review in large-scale single-ticket scenarios.

[0069] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0070] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for identifying and modeling a trip of rail transit one-ticket multi-scene transfer, characterized in that, Comprise the following steps: S1, collect multi-class rail transit basic data sets and carry out normalization processing and standardization packaging, constitute rail transit one-ticket system trip modeling input data frame; S2, based on topological constraint, the transfer candidate identification and type determination of multi-class rail transit basic data set are carried out, and the transfer event record set is generated and the extended trip event sequence is formed; S3, based on the extended trip event sequence, the trip path reconstruction and operation segment division are carried out, the section data structure is packaged, and the section level trip view is generated; S4, based on the section level trip view, the trip result state management is carried out, and the result output and audit reconciliation interface for settlement are constructed. 2.The method of claim 1, wherein: The specific process of collecting multi-class rail transit basic data sets and carrying out normalization processing and standardization packaging is: Multi-class rail transit basic data sets are collected through access gateway, including ticketing event data set, device basic configuration data set, line and station topology data set, candidate route data set, operation timetable, interval reach graph, intercommunication transfer relationship data set and modeling parameter and version information data set;The collected multi-class rail transit basic data sets are uniformly converted and field standardized, and the records of different sources are aligned in field naming, time representation and character encoding;And normalization processing is carried out, linear mapping to unified interval is carried out by using minimum-maximum scaling method, discrete fields are assigned continuous integer index by dictionary encoding method, and are expanded into fixed length vector, to obtain processed multi-class rail transit basic data sets. 3.The method of claim 1, wherein: The specific process of constituting rail transit one-ticket system trip modeling input data frame is: The time axis of processed multi-class rail transit basic data sets is unified by using time synchronization mechanism and access time mark, the access time stamp and collection node identifier are added to each ticketing event record on the data access gateway side, and the device local time field sent by the front-end device is also retained;The gateway is time-synchronized with the upper time service, and the time deviation between the current node and the unified time reference is recorded; When the absolute value of the time difference between the device local time and the access time stamp of a certain record is less than or equal to the clock drift tolerance threshold, the two are regarded as the same event time and are written as the analysis time of the record;When the absolute value of the time difference is greater than the clock drift tolerance threshold, the access time stamp is taken as the analysis time, and the time difference between the two is written in the deviation field for quality evaluation; After completing field standardization and time marking, the medium identifier, event type, line number, station number, device number, analysis time, device local time, access time stamp, collection node identifier and quality mark field are saved in the same record, and the ordered cache queue is maintained in the access gateway according to the medium identifier and analysis time, to constitute the rail transit one-ticket system trip modeling input data frame. 4.The method of claim 1, wherein: The specific process of identifying and determining the transfer candidate of multi-class rail transit basic data set based on topological constraint is: The input candidate line program sequence dataset, line and station topology dataset, interworking transfer relationship dataset and modeling parameter and version information dataset are traversed for the candidate line program sequence under the same medium identification and uniform analysis time, the event sequence is scanned in the same candidate line program according to the uniform analysis time, each outbound event and the first inbound event form a candidate transfer event pair, the candidate transfer event pair is screened and classified according to the time interval and the topology relationship: for each pair of outbound event and subsequent inbound event, the difference between the inbound time and the outbound time is taken as the transfer interval time, when the transfer interval time is greater than the maximum duration threshold of single line program, it is determined that the current candidate line program has ended; when the transfer interval time is within the same station transfer time window threshold, the candidate event pair is marked as a same station transfer candidate; when the transfer interval time is greater than the same station transfer time window threshold and does not exceed the cross-station transfer time window threshold, the candidate event pair is marked as a cross-station walking transfer candidate; when the outbound event belongs to a line or an operation subject different from the line or the operation subject of the inbound event, the candidate event pair is marked as a cross-mode transfer candidate; The conflict resolution and sequence constraint of the optimal path based on dynamic programming are performed on the multiple pairs of transfer candidate event pairs in the same candidate line program: the candidate transfer event pairs are prioritized according to the order of the uniform analysis time, the size of the transfer interval time and the topology relationship between stations, forming a transfer skeleton sequence; in the transfer event identification process, the ticket numbers of the inbound transaction and the outbound transaction need to be matched to form a complete inbound and outbound transaction, so as to ensure that the station and line attribution of the inbound event and the station and line attribution of the outbound event in the complete transaction can be clearly marked. 5.The method of claim 1, wherein: The specific process of generating the transfer event record set and forming the extended line program event sequence is: Based on the transfer skeleton sequence, each confirmed transfer candidate pair is structured and packaged to generate a standardized transfer event record set, and each transfer event is marked with confidence and quality, the matching degree of the transfer interval time, the spatial distance and the configuration parameters is comprehensively evaluated in the transfer event packaging process to obtain the transfer confidence score and write it into the transfer event record; in the candidate line program sequence, the transfer event, the original inbound event and the outbound event are merged in time sequence according to the uniform analysis time as the sorting key to form an extended line program event sequence. 6.The method of claim 1, wherein: The specific process of reconstructing the line path and dividing the running segment based on the extended line program event sequence is: The input extended trip event sequence is sorted according to a uniform analysis time for the entry events, the exit events and the transfer events in each range of the trip number, the transfer events are taken as the line switching boundaries, and continuous operation segments are divided on the time axis: in each operation segment, the line number, the starting station number and the ending station number of the segment are read, the station order table and the adjacent station reachability of the line are called from the line and station topology data, and the next station that can be directly reached is sequentially searched from the starting station to the ending station according to the station order by combining the operation timetable or the interval reachability diagram, so that an actual passing station sequence is generated; when there are multiple candidate paths in the topology structure, the path that is consistent with the regular operation direction and has the least total number of stations is preferentially selected, the detour path or the reverse riding path that is inconsistent with the path is marked as abnormal and is not written as a normal operation segment; one operation interval between adjacent stations is taken as the minimum operation granularity, and multiple minimum operation granularities are sequentially combined to form a line-based station path, thereby forming an operation segment record. 7.The method of claim 1, wherein: The specific process of encapsulating and generating the section-level trip view by the section data structure is as follows: The operation segment record, the line and station topology data set and the section modeling parameter in the modeling parameter and version information data set are acquired, the section is divided according to the station number order and the section modeling parameter in each operation segment, and a basic section set is formed; the attributes of the divided basic sections are completed and the data structure is encapsulated, a standardized section record is generated for each section, and the basic sections are regularly merged as needed to form a section view; the section list is organized with the trip ID as the primary key, and the section-level trip view is constructed to provide a unified data interface; the trip main table, the section detail table and the version configuration data set are output. 8.The method of claim 1, wherein: The specific process of managing the trip result state based on the section-level trip view is as follows: Based on the trip main table, the section detail table, the standardized transfer event record set and the version configuration data set, the result state field and the life cycle management logic are introduced into the trip main table and the section detail table for phased control from generation, consumption to recalculation and abandonment; Based on the trip main table, the section detail table, the standardized transfer event record set and the version configuration data set, the result state field and the state transition rule are set in the trip main table and the section detail table for phased management of each trip result from generation, downstream system reading, triggering recalculation to marking as abandoned. When the trip modeling process is completed and successfully written into the trip main table and the section detail table, the state is automatically switched from to be modeled to modeling completed; when the settlement system or the industrial internet platform reads the trip result through the interface, the state is switched to having been output externally and the last reading time is recorded; when the line and station topology configuration, the interworking transfer relationship configuration or the section modeling parameter version is changed and the change range covers a trip in a time interval, a recalculation task list is generated according to the version configuration data set with the trip number, the time interval or the version condition as the screening condition, and the state of the corresponding record is switched from having been output externally or modeling completed to to be recalculated. For the new and old versions of the same trip number results, compare the start and end stations, transfer times, section numbers, section mileage and section time interval fields one by one, record the parts with different field values as difference entries and attach difference reason markers. When it is confirmed that the new version result is accurate, the status of the old version record can be updated to abandoned, and only when it is necessary to trace back, the version number and modeling time are used for query. 9.The method of claim 1, wherein: The specific process of constructing the settlement-oriented result output and audit reconciliation interface is as follows: The settlement-oriented result output interface is constructed in the granularity of trip, and the trip structure and section list information are output. The settlement system completes the fare calculation and clearing under its own rules. The analysis interface is constructed for the industrial internet platform and operation analysis system, which supports output of modeling results in the perspective of trip and section. In the aspect of audit and reconciliation support, for each complete entry and exit station trip record, the ticket numbers of the entry and exit gates are checked for matching, and the reconciliation auxiliary interface and difference analysis capability are provided in the perspective of trip and aggregated dimension.

10. A rail transit one-ticket multi-scene transfer identification and trip modeling system, applying the rail transit one-ticket multi-scene transfer identification and trip modeling method according to any one of claims 1-9, characterized in that, The specific process of constructing the settlement-oriented result output and audit reconciliation interface is as follows: The basic topology data acquisition module is used to acquire multiple types of rail transit basic data sets and perform normalization processing and standardized packaging to form a rail transit single-ticket trip modeling input data frame. The equipment attribution recognition module is used to identify and determine the type of transfer candidates based on topology constraints for multiple types of rail transit basic data sets, generate transfer event record sets, and form extended trip event sequences. The trip segmentation modeling module is used to reconstruct trip paths and divide running segments based on the extended trip event sequences, package section data structures, and generate section-level trip views. The trip result management module is used to manage trip results based on section-level trip views, construct settlement-oriented result outputs, and audit reconciliation interfaces.

Images