Bus operation anomaly identification method and device, computer device and program product

Abstract

Embodiments of the present application are suitable for the technical field of data processing, and provide a bus operation anomaly identification method and device, computer equipment and program product. The method comprises: obtaining trajectory information, boarding and alighting record information and ticket fare data of a bus; determining a plurality of driving intervals of the bus based on the trajectory information, the driving intervals being divided by bus stops passed through in the actual driving process of the bus; determining interval boarding and alighting information in each driving interval according to the boarding and alighting record information; determining interval ticket fare records in each driving interval according to the ticket fare data; and performing anomaly identification on operation information of the bus based on the interval boarding and alighting information and the interval ticket fare records. Based on the above method, abnormal operation behavior in the operation process of the bus can be identified, and the identification capability of abnormal operation behavior can be improved.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, and in particular relates to a method, device, computer equipment and program product for identifying abnormal bus operations. Background Technology

[0002] Auditing bus fare collection is a crucial management step in ensuring compliant operating revenue and preventing fare loss. In modern urban bus operations, a single bus makes multiple trips daily, passing through dozens of stops. During bus operations, the determination of fare collection errors is typically made solely by checking fares against those of the final passengers.

[0003] However, relying solely on overall data for ticket verification can make it difficult to detect incorrect or missed fares during bus operations. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, apparatus, computer equipment, and program product for identifying abnormal bus operations, in order to improve the ability to identify abnormal bus operations.

[0005] The first aspect of this application provides a method for identifying abnormal bus operations, including: Obtain bus route information, passenger boarding and alighting records, and fare data; Based on the trajectory information, multiple driving sections of the bus are determined, and the driving sections are divided by the bus stops that the bus passes through during its actual journey. Based on the passenger boarding and alighting record information, determine the passenger boarding and alighting information within each of the travel sections; Based on the ticket revenue data, determine the fare records for each of the aforementioned travel intervals; Based on the passenger boarding and alighting information and the fare records for the section, the bus operation anomalies are identified.

[0006] In one possible implementation, each of the travel intervals has an associated stop, and determining the interval passenger / drop information within each of the travel intervals based on the passenger / drop-off record information includes: Determine the range of time the bus will stop at the designated parking station; Based on the passenger boarding and alighting record information, determine the actual passenger boarding and alighting records of the bus in the operating section; Based on the actual passenger and boarding records, determine the first passenger and boarding record within the parking time range and the second passenger and boarding record outside the parking time range; The first and second passenger stop records are used to determine the passenger stop information for the travel section.

[0007] In one possible implementation, the bus includes multiple bus doors, and the passenger boarding and alighting record information includes passenger flow records for the multiple bus doors. Determining the actual passenger boarding and alighting records of the bus within the specified travel interval based on the passenger boarding and alighting record information includes: The valid boarding and alighting doors of the bus are determined from among multiple bus doors; The passenger flow records associated with the valid boarding and alighting doors are used as the actual boarding and alighting records.

[0008] In one possible implementation, determining the fare records for each of the travel intervals based on the fare data includes: Based on the station information associated with each ticket in the ticket data, the travel section corresponding to the ticket is determined.

[0009] In one possible implementation, the step of identifying operational anomalies in the bus based on the interval passenger and alighting information and the interval fare records includes: Based on the aforementioned section boarding and alighting information, determine whether the bus has any abnormal boarding or alighting. Based on the passenger boarding and alighting information and the fare records for the specified route, it is determined whether there are any fare irregularities for the bus.

[0010] In one possible implementation, determining whether there is a fare discrepancy for the bus based on the interval passenger and alighting information and the interval fare records includes: For each travel segment, based on the segment boarding and alighting information, it is determined whether there are passengers boarding or alighting in the travel segment; If passengers board or alight in the specified travel section, the number of passengers on the bus in that travel section is determined. Based on the number of passengers and the fare records for the specified route, the bus fares for the specified route are compared. If the number of passengers and the ticket price records for the specified route do not match, it is determined that there is a ticket price discrepancy for the specified route.

[0011] In one possible implementation, determining whether the bus has abnormal boarding / alighting based on the interval boarding / alighting information includes: If a second passenger stop / boarding record exists in the travel section, an off-station passenger stop / boarding risk is generated for the travel section. The off-station passenger stop / boarding risk includes passenger stop / boarding coordinates and the number of passengers who boarded or boarded abnormally.

[0012] A second aspect of this application provides a bus operation anomaly identification device, comprising: The acquisition module is used to acquire the bus's trajectory information, passenger boarding and alighting records, and fare data; The segmentation module is used to determine multiple driving sections of the bus based on the trajectory information, wherein the driving sections are divided by the bus stops passed by the bus during its actual journey. The section passenger stop determination module is used to determine the section passenger stop information within each of the travel sections based on the passenger stop record information; The fare determination module is used to determine the fare records for each of the travel intervals based on the fare data. The identification module is used to identify anomalies in the bus operation information based on the interval passenger and alighting information and the interval fare records.

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

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

[0015] A fifth aspect of this application provides a computer program product that, when run on a computer device, causes the computer device to perform the method described in the first aspect.

[0016] Compared with the prior art, the embodiments of this application have the following advantages: In the embodiments of this application, Attached Figure Description To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0017] Figure 1 This is a flowchart illustrating the steps of a method for identifying abnormal bus operations provided in an embodiment of this application; Figure 2 This is a flowchart illustrating another method for identifying abnormal bus operations provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an abnormal operational behavior identification method provided in an embodiment of this application; Figure 4 This is a schematic diagram of a bus operation anomaly identification device provided in an embodiment of this application; Figure 5 This is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0019] Public transport fare auditing is a core control link for regulating public transport operating revenue, preventing fare loss, and ensuring revenue compliance. In modern urban public transport systems, individual vehicles operate multiple trips daily, passing through a large number of stops, generating massive amounts of passenger flow events, GPS location trajectories, and fare transaction records throughout the operation. These three types of core data are collected and generated independently by different business systems, with independent data systems and no native connection, creating a natural obstacle to refined fare auditing. Specifically, onboard IoT passenger flow devices use the device's local clock as a reference to collect passenger boarding and alighting behavior in real time, accurately recording the time, geographical location, and corresponding door number of each boarding and alighting action; onboard GPS positioning systems continuously collect vehicle driving trajectories, and after processing by trajectory matching algorithms, can accurately reconstruct the arrival and departure times of vehicles at each stop; third-party ticketing systems are responsible for recording electronic ticketing transaction data such as NFC card swiping and QR code scanning, with data collected by license plate number and operating date, but not linked to specific operating station information.

[0020] In line with the operational needs of public transportation, fare auditing primarily covers four core application scenarios. First, daily fare auditing: the system automatically performs daily comparisons and analyses of passenger flow and fare revenue across all vehicle trips from the previous operating day, accurately identifying abnormal operating sections. Second, near real-time risk warnings: after dispatchers complete trip entry or modification operations, the backend automatically triggers data matching and risk calculation, displaying the risk results immediately upon completion for rapid warning. Third, historical data supplementation: for historical passenger flow data retransmitted by IoT devices due to network interruptions, the system automatically identifies all affected operating trips and initiates re-statistics, comprehensively ensuring the integrity and accuracy of operational data. Fourth, manual verification assistance: the system generates visual comparison charts of passenger flow and fare data by operating section, supporting auditors in manually verifying, confirming, and closing-loop processing of various risk records.

[0021] In practical applications, multi-source data fusion auditing faces several core technical challenges. First, time alignment of multi-source data is difficult. The clocks of IoT passenger flow devices, vehicle GPS, and third-party ticketing platforms are not synchronized, and the various data formats are inconsistent, making direct integration onto a single timeline for matching impossible. Second, the definition of operating intervals is ambiguous. Passenger boarding and alighting details only record absolute times without corresponding operating interval markings. Station arrival and departure times resolved by GPS are necessary to determine the interval classification of passenger and alighting data. Third, off-station passenger boarding and alighting interfere with statistical accuracy. Some passengers board and alight outside of designated station areas. The statistical rules for this type of passenger flow data differ significantly from those for normal boarding and alighting within the station. Without differentiation processing, this directly leads to inaccurate passenger volume statistics. Fourth, the variety of door types causes statistical discrepancies. The system suffers from several issues: First, it has discrepancies with bus doors. Buses are equipped with various types of doors, including passenger doors, auxiliary doors, and stair doors. The opening and closing of different doors and the data on passenger passage need to be differentiated to determine whether they should be included in passenger flow statistics. A uniform statistical standard can easily lead to inflated or understated passenger flow data. Second, it is difficult to ensure the consistency of historical data. When IoT devices re-upload historical data, the risk audit conclusions for the corresponding trips have often already been generated. The system needs to accurately identify the affected trips and recalculate them in batches, while preventing data interference from normal trips that have no impact. Third, the fare data association is complex. Third-party fare data is collected based on license plate, while the system's trip data is managed based on vehicle ID. It is necessary to decompose the data by linking license plate, vehicle, trip, and section at each level to achieve an accurate correspondence between fare data and operating sections.

[0022] Currently, the mainstream methods for auditing public transport fares still rely primarily on traditional offline aggregation models, with relatively simple and rigid technical implementations. First, a daily summary and comparison model is used, only collecting and statistically analyzing the total daily fare revenue and total passenger flow for a rough comparison at the overall volume level. Second, manual form verification is relied upon, with auditors manually checking fare revenue and passenger flow reports, manually screening for abnormal data line by line. Third, a fixed threshold alarm mechanism is used, with preset thresholds for the ratio of fare revenue to passenger flow, triggering alarm notifications only when the overall daily data exceeds the threshold. Fourth, single data source analysis is implemented, relying solely on fare revenue or passenger flow data for single-dimensional verification, resulting in complete separation and inability to perform integrated analysis of the two core data types.

[0023] Traditional offline auditing models have many inherent flaws and cannot meet the needs of modern public transportation for refined and intelligent auditing management. First, the audit granularity is too coarse. Relying solely on daily total comparisons makes it impossible to accurately pinpoint the specific routes, trips, and stations where anomalies occur. Problem investigation relies entirely on manual line-by-line verification, resulting in extremely low efficiency and a high rate of missed detections. Second, multi-source data is fragmented. GPS station arrival and departure data, IoT passenger flow data, and ticket transaction data are stored and statistically analyzed independently, lacking a unified spatiotemporal framework for coordinated calculations, making multi-dimensional comprehensive audit analysis impossible. Third, it cannot automatically identify passenger boarding and alighting behavior outside the station. Traditional technologies struggle to distinguish between legitimate boarding and alighting within the station and illegal boarding and alighting outside the station, leading to the inability to automatically identify risks such as fare evasion and unauthorized travel outside the station. Fourth, the audit lacks real-time capability. The entire audit work needs to be completed the day after the end of each day's operations or even later, making it impossible to achieve rapid risk identification and immediate early warning after each trip's operation. Fifth, it fails to differentiate door type statistics, ignoring the functional differences between passenger doors and stair doors. This leads to the erroneous inclusion of passenger movement data between floors in double-decker stairwells in passenger flow statistics, generating false passenger flow data and directly affecting the accuracy of audit results.

[0024] Traditional auditing methods that rely on comparing total daily fare figures have significant blind spots, failing to identify hidden anomalies at the interval level. Even if the overall average fare per passenger is within a reasonable range, various violations may still exist in different operational intervals, including instances where passenger flow is recorded but no corresponding fares are generated, instances where fares are generated despite no passenger flow, and instances of fare evasion caused by passengers boarding or alighting outside designated stations. Fundamentally, traditional auditing methods suffer from three major shortcomings: the lack of a refined interval-level correlation between passenger flow and fare revenue; the failure to correlate and match GPS station time-series data with passenger boarding and alighting details; and the lack of intelligent identification capabilities for irregular boarding and alighting behaviors outside designated stations. Ultimately, this leads to a significant risk of lost fares and the inability to promptly detect and address data anomalies.

[0025] The following specific examples illustrate the problems with existing technologies: Traditional ticket revenue audit (daily summary and comparison) Data Source 1: Ticketing System → Total Ticket Revenue for the Day = 2560 Yuan; Data Source 2: Passenger Flow System → Total Passenger Flow for the Day = 320 Passengers; Audit Conclusion: Average ticket price per person is 8 Yuan, which is normal. However, the following problems actually exist: All the following interval-level anomalies could not be detected. Trip 001 - Interval 3 → 4: IoT passenger flow = 15 people, third-party ticket revenue = 0 Yuan ← Ticket revenue lost; Trip 003 - Interval 1 → 2: IoT passenger flow = 0 people, third-party ticket revenue = 12 Yuan ← No passenger flow but tickets available; Trip 007 - Interval 5 → 6: Passengers boarding and alighting outside the station = 3 people, no corresponding ticket revenue ← Risk of fare evasion. The root causes of these problems are: no interval-level passenger flow-ticket revenue correspondence; GPS arrival and departure times are not associated with OD details; and passenger boarding and alighting behavior outside the station is not identified.

[0026] Based on this, this application provides a method for identifying abnormal bus operations, thereby improving the effectiveness of inspections and enhancing the ability to identify abnormal operations. The technical solution of this application is illustrated below through specific embodiments.

[0027] Reference Figure 1 The diagram illustrates a flowchart of a method for identifying abnormal bus operations according to an embodiment of this application, which may include the following steps: S101 obtains bus trajectory information, passenger boarding and alighting records, and fare data.

[0028] The execution subject of this embodiment can be a computer device, which can be a personal terminal, server, mobile terminal, tablet computer, etc. This application does not limit the specific type of computer device.

[0029] S102, Based on the trajectory information, determine multiple driving sections of the bus, wherein the driving sections are divided by the bus stops passed by the bus during its actual driving process.

[0030] The system acquires the bus's trajectory information and passenger / alighting records within a preset time range. The bus has scheduling information, including its operating trips, each with a corresponding stop sequence, which includes at least one bus stop. Based on the trajectory and passenger / alighting records, the system determines the actual trip boundaries and actual stops of the bus. Actual stops are those with passenger boarding / alighting records. Based on the actual trip boundaries, actual stops, and scheduling information, the system determines the bus's actual stopping sequence. Based on the bus's actual stopping sequence, the bus's trajectory can be divided into multiple travel intervals, each associated with a bus stop. Bus stops can be used as the basis for dividing travel intervals.

[0031] S103, Based on the passenger boarding and alighting record information, determine the passenger boarding and alighting information within each of the travel sections.

[0032] Determine the time range for buses to stop at bus stops; Based on the passenger boarding and alighting records, determine the actual passenger boarding and alighting records of the bus within the operating section; Based on the actual boarding and alighting records, determine the first boarding and alighting record within the parking time range and the second boarding and alighting record outside the parking time range; The first and second passenger stop records are used to determine the passenger stop information for the travel section.

[0033] A bus has multiple doors. From these multiple doors, the valid boarding and alighting doors are determined. The passenger flow records associated with the valid boarding and alighting doors are used as the actual boarding and alighting records.

[0034] S104, Based on the ticket data, determine the fare records for each of the travel intervals.

[0035] Based on the station information associated with each ticket in the ticket data, the corresponding travel section of the ticket is determined.

[0036] S105, based on the section passenger and alighting information and the section fare record, identify the bus operation anomaly.

[0037] Based on the boarding and alighting information of the bus route, determine whether there are any abnormal boarding and alighting situations; Based on the passenger boarding and alighting information and fare records for the designated area, it can be determined whether there are any fare irregularities on the bus.

[0038] For each travel section, determine whether there are passengers boarding or alighting within the travel section based on the section's boarding and alighting information; If passengers board and alight within the operating section, then determine the number of passengers on the bus within that operating section. Based on the number of passengers and fare records for the route, the bus fares for the route are compared. If the number of passengers and the ticket price records for the section do not match, it is determined that there is a ticket price discrepancy for the section of travel.

[0039] If a second passenger stop or boarding record exists in the operating section, an off-station passenger stop or boarding risk is generated for that operating section. The off-station passenger stop or boarding risk includes the passenger stop or boarding coordinates and the number of passengers who boarded or boarded abnormally.

[0040] This application's implementation comprehensively improves the accuracy, automation level, and operational efficiency of passenger flow and ticketing audits. The system refines the audit granularity from traditional daily total statistics to the interval level, accurately locating specific routes and intervals between stations. This significantly improves anomaly location accuracy, eliminating the need for auditors to manually review reports line by line; the system directly marks abnormal intervals, effectively simplifying the verification process. Simultaneously, the system automatically integrates three data sources: GPS arrival / departure times, IoT passenger flow events, and third-party ticketing data, aligning them to a standardized interval framework. This completely avoids subjective errors and data omissions arising from manual data association and reconciliation, ensuring accurate data matching. For scenarios involving irregular operations, the system adds automatic identification and location capabilities for off-station passenger boarding and alighting. Through a dedicated off-station marking mechanism, it automatically quantifies off-station passenger boarding and alighting events in each interval and retains accurate geographic coordinate risk records, providing strong evidence for on-site verification by auditors. To address the issue of distorted passenger flow statistics for double-decker buses, the system implements data isolation and filtering at the stairwell doors at the computational link entry point. This prevents inter-floor movement events from being mistakenly counted as passengers, ensuring more accurate and reliable passenger flow statistics. In terms of data calculation, the system employs a dual-mode processing mechanism, balancing data integrity and computational efficiency. The full recalculation mode can completely reconstruct data even when interval boundaries change, while the risk-only recalculation mode avoids redundant calculations in scenarios where intervals remain unchanged, significantly improving the processing response speed for data retransmission scenarios. Furthermore, the system establishes a fully automated risk workflow, enabling automatic identification, classification, and recording of three types of risks. This supports batch verification and write-back of processing conclusions by auditors, greatly reducing the workload of manual audits. Simultaneously, the system adapts to both real-time triggering and batch processing paths. After each trip is entered, real-time matching and risk calculation can be triggered asynchronously, achieving near real-time risk notification. Daily batch tasks comprehensively cover historical data verification and data retransmission scenarios, ensuring the integrity and comprehensiveness of audit data in all aspects.

[0041] Reference Figure 2 The diagram illustrates another method for identifying abnormal bus operations provided in this application. Figure 2As shown, the passenger flow calculation entry point will first perform door type filtering. By filtering OD details according to door type, interference from stairwell door data is avoided at the source, preventing the problem of inflated passenger flow statistics. The specific processing flow is as follows: The system first reads the door configuration information, uniformly classifying all doors into three categories: passenger door groups, auxiliary door groups, and stairwell door groups. Then, auxiliary door groups, which have the same function as passenger doors and also serve as dedicated passenger boarding and alighting channels, are merged into the passenger door groups, forming a valid passenger door set. After the door groups are merged, the system will check the status of the valid passenger door set. If the set is empty, it means that all passenger passage doors for this trip are in a disabled state, and the passenger flow calculation will be terminated directly, with relevant warning information recorded simultaneously. In subsequent interval passenger flow calculations, only OD details belonging to the valid passenger door set are retained for statistics. OD details generated by stairwell doors will be stored normally but will not be included in the interval passenger flow calculation. From a business design perspective, the stairwell door data of double-decker buses records the movement of passengers between the upper and lower levels of the vehicle, not the regular passenger boarding and alighting behavior. Separating this type of data can completely avoid the problem of inflated passenger flow statistics caused by invalid data, and ensure the authenticity and accuracy of passenger flow data.

[0042] After filtering by door type, the system will perform detailed OD (Original Departure / Origin) interval assignment and cumulative passenger volume calculation for each interval. The core objective is to accurately match each OD detail to the corresponding trip interval. Through continuous cumulative statistics, the system calculates the real-time passenger count inside the vehicle at the end of each interval, which is the core logic of overall passenger flow statistics. Regarding interval boundary definition, the system first sorts vehicle arrival and departure records in ascending order of arrival time, forming a complete and ordered sequence of stations. Two adjacent stations (station i and station i+1) constitute the i-th operating interval. The start time of the interval is the arrival time of the previous station, and the end time of the interval is the arrival time of the next station. Special processing rules are set for the first interval. If the departure time of this trip has been manually modified and there is a clear intention to manually calibrate, the registered departure time of the trip will be used directly as the starting time of the first interval, and the GPS arrival time will no longer be considered. If no manual modification has been made, the later time between the GPS arrival time of the first station and the registered departure time of the trip will be selected as the starting time of the first interval. The business significance of this rule is that passenger flow behavior generated when the vehicle is waiting at the station before the trip officially departs will not be included in the statistics of this trip, ensuring that passenger flow statistics are consistent with the actual operating sequence.

[0043] For passenger behavior in different scenarios, the system divides the processing rules into two categories: in-station and out-of-station. In-station passengers correspond to OD data marked as 0 outside the station. In-station boarding events are simultaneously counted in the current segment's boarding count and added to the cumulative passenger volume, reflecting an increase in onboard passengers. In-station alighting events are counted in the current segment's alighting count and deducted from the cumulative passenger volume, reflecting a decrease in onboard passengers. Out-of-station passengers correspond to OD data marked as 1 outside the station. Out-of-station boarding events occur during the vehicle's journey within a segment and are directly counted in the current segment's boarding count and added to the cumulative passenger volume, with real-time synchronization of onboard passenger changes. Out-of-station alighting events are processed with a one-segment delay. The event is only recorded when it occurs, and then counted in the next segment's alighting count and deducted from the corresponding passenger volume when the next segment begins calculation. This delayed processing mechanism is based on sound business logic. While the disembarkation behavior outside a station during vehicle operation is chronologically categorized as belonging to the current segment, the actual impact of this behavior on passenger capacity will only be reflected when the vehicle arrives at the next station due to the characteristics of IoT device data collection. Delayed processing ensures the mathematical continuity of passenger capacity statistics across segments, avoiding data gaps. For special segments with no passenger flow, if no OD (Original Departure / Origin) detailed data is generated within a single segment, the number of passengers inside the vehicle is assumed to have remained unchanged. The passenger capacity at the end of the previous segment is directly reused as the passenger capacity for this segment. Simultaneously, anomaly detection is performed on ticket revenue data to avoid data anomalies. After each segment's calculation is completed, the system uniformly records the cumulative passenger capacity, number of passengers boarding, and number of passengers alighting for that segment, completing the basic passenger flow data statistics.

[0044] To align passenger flow data with ticket revenue data across different time intervals, the system will perform interval correlation calculations on ticket revenue data, accurately associating ticket transaction data from third-party ticketing systems with the corresponding trip intervals according to matching rules. The specific process is as follows: First, based on license plate information, extract valid third-party ticket revenue data for the current operating day; then, based on the arrival and departure records of the current trip, construct a dedicated lookup table of "station name → interval" to establish the correspondence between stations and operating intervals; finally, iterate through all ticket transaction records, matching the departure station name of each record with the corresponding interval in the lookup table, and accumulating the ticket transaction quantity into the ticket revenue statistics field for the corresponding interval. It is important to clarify that the completeness and accuracy of the ticket revenue data are guaranteed by the third-party ticketing system; this system only handles the data correlation and matching process and does not participate in the quality verification and correction of the third-party data source.

[0045] The system is equipped with a dual-mode triggering calculation mechanism, which can automatically adapt the calculation mode according to the type of data change, accurately avoid invalid and duplicate calculations, and improve the overall data processing efficiency. Specifically, it has two modes: full recalculation and risk-only recalculation. The full recalculation mode is suitable for scenarios requiring a complete update of trip data. The process involves first clearing all historical interval records and risk records for the current trip, then re-dividing the operating intervals based on the latest arrival and departure records. Subsequently, it sequentially completes OD detail attribution matching and ticket data association statistics for all new intervals, updating passenger flow and ticket data interval by interval, while simultaneously conducting three types of risk monitoring and generating new risk records. The risk-only recalculation mode is suitable for scenarios where the interval boundaries remain unchanged and only risk data needs to be updated. It does not require recalculating passenger flow and ticket data. The process involves directly reading the valid interval records already generated for the trip, retaining the original interval boundaries, clearing historical risk records, recalculating OD detail attribution and ticket data association based on the existing interval framework, and finally re-executing the three types of risk detection to generate the latest risk records.

[0046] The daily batch calculation task will utilize a daily-level batch processing data preloading mechanism. This preloading strategy, which extends the time window forward, addresses the issue of missing passenger flow data at the first stop of each trip due to time boundaries, ensuring the completeness of daily data statistics. The batch task uses the operating day as the core unit, uniformly loading data from all operating trips for that day. Simultaneously, the query time window for IoT passenger flow OD details is extended forward by 3 hours, retrieving data 3 hours before the start time of the operating day to fully capture early-arriving passenger data before the trip's official departure. This 3-hour extension strategy is based on rigorous evidence; the system's risk backtracking window is configured to a maximum of 120 minutes, and the 3-hour time reserve fully covers all configuration scenarios, preventing data omissions. After data loading, IoT passenger flow data and vehicle arrival / departure records are grouped and isolated by vehicle dimension, with each group processed independently to avoid cross-interference between data from different vehicles. Finally, for each trip of a single vehicle, a complete calculation chain is executed sequentially, including gate type filtering, OD detail range attribution, ticket data association, and risk identification, completing the daily-level batch statistics.

[0047] The system includes three core operational risk identification rules, enabling comprehensive monitoring of abnormal passenger flow and fare data in public transportation operations. The trigger condition for the risk of passengers boarding and alighting outside designated stops is the presence of OD (Original Departure) data with an OD marker of 1 within a single interval. This means that passengers board or alight outside the designated stop area during the vehicle's operation within that interval. During risk identification, the system accurately records the number of passengers boarding and alighting outside designated stops within the corresponding interval, as well as the geographical coordinates of the event, providing data support for on-site verification. From a business perspective, this behavior is highly likely caused by drivers picking up passengers privately outside designated stops or releasing passengers prematurely, which can easily lead to lost fare revenue and is a key operational anomaly requiring close monitoring.

[0048] The trigger condition for the ticket transaction risk is a significant discrepancy between the number of third-party ticket transactions and the number of passengers boarding as recorded in the IoT passenger flow statistics within the same timeframe. The system accurately compares the number of passengers boarding via IoT and the number of ticket transactions within a given timeframe. When the difference exceeds a preset tolerance range, the system automatically triggers a risk warning. The risk record includes the number of passengers boarding via IoT, the number of ticket transactions, and the specific difference for easy verification by staff. The causes of this data discrepancy are varied, with common issues including passengers missing tickets, data delays in third-party ticketing systems, and temporary changes in operating vehicles. Staff need to manually verify and investigate these discrepancies based on the actual operational scenario to pinpoint the root cause of the data anomaly.

[0049] Ticketing fluctuation risk is a specific monitoring rule targeting fundamental discrepancies between passenger flow and ticketing data. The trigger condition is zero IoT passenger flow data and no passenger boarding / alighting OD (Original Departure / Origin) details within a given interval, but valid third-party ticketing transaction records exist within that interval. In this scenario, the system maintains the data continuity assumption, reusing passenger volume data from the previous interval as the current interval's passenger flow data, while simultaneously marking the interval as having ticketing fluctuation risk, pending manual verification by staff. From a business perspective, this type of anomaly most likely stems from issues such as data omissions due to IoT device malfunctions, incorrect ticketing data categorization, or system data synchronization anomalies. This effectively uncovers underlying data discrepancies between the two data sources, ensuring the rigor of operational data statistics.

[0050] Figure 3 This is a flowchart illustrating an abnormal operational behavior identification method provided in an embodiment of this application; as shown below. Figure 3 As shown, for any given travel segment, the system first determines whether OD (Original Departure) details (i.e., passenger flow data) exist. If OD details exist, the system will count the number of passengers boarding and alighting within and outside the station, calculate the cumulative passenger volume, and deduct passengers alighting outside the station from the next segment to ensure the accuracy of passenger volume statistics. Subsequently, the system determines whether there are any passenger boarding / alighting events outside the station within the segment. If so, it generates a risk record for passenger boarding / alighting outside the station containing the number of passengers and their coordinates. Regardless of whether such an event exists, the system will proceed to the consistency verification stage between the number of passengers boarding and the number of tickets. If the two do not match, a ticket quantity risk record indicating the difference between the passenger flow and the number of tickets will be generated. If the verification is consistent, the process will continue directly. If there are no OD details (no passenger flow data) for the segment, the system will directly reuse the passenger volume data from the previous segment and further determine whether there are any ticket transaction records for the segment. If there are ticket transaction records, a ticket change risk record of "no passenger flow but ticket revenue" will be generated. If there are no ticket transaction records, the segment will be deemed risk-free. All branch processes eventually converge into the "Enter Next Interval" step, starting the processing loop for the next interval.

[0051] To illustrate this application more clearly, specific examples are provided below.

[0052] Example: The entire process of fare risk verification for a specific double-decker bus trip on a certain operating day. Basic conditions: Vehicle: Double-decker bus, equipped with 2 passenger doors (Door 1, Door 2) and 1 stairwell door (Door 3); Trip: July 1, 2024, northbound, registered departure time 08:00, last bus time 09:00, route has 6 stops; GPS matching results: 6 arrival and departure records have been restored, forming 5 intervals. OD details original records: 50 records in total, of which 45 are from Door 1 / Door 2, and 5 are from Door 3 (stairwell door); Third-party fare records: 52 valid fare transactions for this license plate on that day.

[0053] Step 1: Gate Type Filtering Door configuration read: Door 1 (passenger door), Door 2 (auxiliary door), Door 3 (staircase door). Auxiliary doors are merged into passenger doors, and the effective passenger door set is {Door 1, Door 2}. After filtering, the effective OD details included in the statistics are 45, and 5 staircase door data are isolated (not included in passenger flow).

[0054] Step 2: Interval Division Divide the data into 5 intervals based on 6 arrival and departure records (sorted by arrival time):

[0055] Step 3: OD details allocation and passenger volume accumulated by interval The 45 valid OD details were categorized into their respective time intervals based on event time, and the cumulative calculations are as follows:

[0056] Step 4: Linking ticket revenue data ranges Matched 52 ticket fare records by boarding station name: Tickets for the boarding station "People's Square": 5 tickets → Associated with section 2; Tickets for the boarding station "Bus Station": 12 tickets → Associated with section 1; The remaining tickets are distributed in sections 3 to 5.

[0057] Step 5: Risk Identification Section 2: 2 people boarding outside the station → generate risk of passengers boarding and alighting outside the station (record the number of people and coordinates); 5 people boarding via IoT (3 inside the station + 2 outside the station) vs 5 tickets → the numbers match, and the ticket quantity risk is not triggered.

[0058] Section 3: During the operation of Section 3, 2 passengers drop off outside the station (the passenger capacity of these 2 people is deducted and delayed to Section 4 for calculation, but the event itself belongs to Section 3) → Generate risk of passengers getting on and off outside the station, and record the number of people getting off outside the station and their geographical coordinates.

[0059] Other areas: No incidents outside the station, passenger flow and ticket revenue are within tolerable range, no risk.

[0060] Final output: Complete passenger flow and ticket revenue data for the five sections are written into the section record table. Two risk records are generated (one for passenger pick-up and drop-off outside the station in section 2 and one for section 3), and the risk status of each trip is marked as "all unprocessed".

[0061] Auditors can log into the system to view the interval visualization charts, check the comparison between passenger flow and ticket revenue for each interval, and mark the conclusions of each risk.

[0062] Based on this embodiment, 1. IoT passenger flow events and third-party ticketing data from different sources and with different clocks are uniformly mapped to the interval granularity defined by the station-to-departure time restored by GPS, achieving temporal and spatial alignment of the three-source data. For the special case where passengers disembark in non-station areas during the interval operation, a cross-interval rolling calculation mechanism is designed to delay their disembarkation time to the next interval settlement, ensuring the mathematical rigor of continuous interval passenger volume statistics. At the passenger flow statistics calculation entry point, data is processed separately for passenger doors, auxiliary doors, and stair doors. A mechanism is in place to prevent stair door data from entering the passenger flow calculation link, eliminating false passenger flow on double-decker buses from the source. Based on the type of data change that triggers the calculation (whether the interval boundary changes), a full recalculation mode or a risk-only recalculation mode is automatically selected, optimizing calculation efficiency while ensuring data accuracy. In daily batch calculation scenarios, the IoT data query time window is extended forward by 3 hours to ensure that passenger flow data for early arrivals at the first station of the trip is not missed due to time boundary issues. 6. The identification rules for three types of risks—passenger boarding / alighting risk outside the station (detection of external markers), ticket revenue risk (comparison of passenger boarding and ticket revenue via IoT), and ticket revenue change risk (detection of ticket revenue even without passenger flow)—are completed simultaneously in a single traversal during the interval calculation process, avoiding redundant overhead from multiple traversals.

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

[0064] Reference Figure 4 The diagram illustrates a bus operation anomaly identification device according to an embodiment of this application. Specifically, it may include an acquisition module 41, a division module 42, a section boarding / alighting determination module 43, a section fare determination module 44, and an identification module 45, wherein: The acquisition module is used to acquire the bus's trajectory information, passenger boarding and alighting records, and fare data; The segmentation module is used to determine multiple driving sections of the bus based on the trajectory information, wherein the driving sections are divided by the bus stops passed by the bus during its actual journey. The section passenger stop determination module is used to determine the section passenger stop information within each of the travel sections based on the passenger stop record information; The fare determination module is used to determine the fare records for each of the travel intervals based on the fare data. The identification module is used to identify anomalies in the bus operation information based on the interval passenger and alighting information and the interval fare records.

[0065] As the apparatus embodiments are basically similar to the method embodiments, they are described in a relatively simple manner. For relevant details, please refer to the description in the method embodiment section.

[0066] In one possible implementation, each of the travel intervals has an associated stop, and determining the interval passenger / drop information within each of the travel intervals based on the passenger / drop-off record information includes: Determine the range of time the bus will stop at the designated parking station; Based on the passenger boarding and alighting record information, determine the actual passenger boarding and alighting records of the bus in the operating section; Based on the actual passenger and boarding records, determine the first passenger and boarding record within the parking time range and the second passenger and boarding record outside the parking time range; The first and second passenger stop records are used to determine the passenger stop information for the travel section.

[0067] In one possible implementation, the bus includes multiple bus doors, and the passenger boarding and alighting record information includes passenger flow records for the multiple bus doors. Determining the actual passenger boarding and alighting records of the bus within the specified travel interval based on the passenger boarding and alighting record information includes: The valid boarding and alighting doors of the bus are determined from among multiple bus doors; The passenger flow records associated with the valid boarding and alighting doors are used as the actual boarding and alighting records.

[0068] In one possible implementation, determining the fare records for each of the travel intervals based on the fare data includes: Based on the station information associated with each ticket in the ticket data, the travel section corresponding to the ticket is determined.

[0069] In one possible implementation, the step of identifying operational anomalies in the bus based on the interval passenger and alighting information and the interval fare records includes: Based on the aforementioned section boarding and alighting information, determine whether the bus has any abnormal boarding or alighting. Based on the passenger boarding and alighting information and the fare records for the specified route, it is determined whether there are any fare irregularities for the bus.

[0070] In one possible implementation, determining whether there is a fare discrepancy for the bus based on the interval passenger and alighting information and the interval fare records includes: For each travel segment, based on the segment boarding and alighting information, it is determined whether there are passengers boarding or alighting in the travel segment; If passengers board or alight in the specified travel section, the number of passengers on the bus in that travel section is determined. Based on the number of passengers and the fare records for the specified route, the bus fares for the specified route are compared. If the number of passengers and the ticket price records for the specified route do not match, it is determined that there is a ticket price discrepancy for the specified route.

[0071] In one possible implementation, determining whether the bus has abnormal boarding / alighting based on the interval boarding / alighting information includes: If a second passenger stop / boarding record exists in the travel section, an off-station passenger stop / boarding risk is generated for the travel section. The off-station passenger stop / boarding risk includes passenger stop / boarding coordinates and the number of passengers who boarded or boarded abnormally.

[0072] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 5 As shown, the computer device 5 of this embodiment includes: at least one processor 50 ( Figure 5 (Only one is shown in the diagram), memory 51, and computer program 52 stored in said memory 51 and executable on said at least one processor 50, wherein said processor 50 executes said computer program 52 to implement the steps in any of the above method embodiments.

[0073] The computer device 5 may be a desktop computer, laptop, handheld computer, or cloud computing device, etc. This computer device may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 The computer device 5 is merely an example and does not constitute a limitation on the computer device 5. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

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

[0075] In some embodiments, the memory 51 may be an internal storage unit of the computer device 5, such as a hard disk or memory of the computer device 5. In other embodiments, the memory 51 may be an external storage device of the computer device 5, such as a plug-in hard disk, SmartMediaCard (SMC), SecureDigital (SD) card, or FlashCard equipped on the computer device 5. Furthermore, the memory 51 may include both internal and external storage units of the computer device 5. The memory 51 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 51 can also be used to temporarily store data that has been output or will be output.

[0076] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0077] This application provides a computer program product that, when run on a computer device, enables the computer device to perform the steps described in the above-described method embodiments.

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

Claims

1. A method for identifying abnormal bus operations, characterized in that, include: Obtain bus route information, passenger boarding and alighting records, and fare data; Based on the trajectory information, multiple driving sections of the bus are determined, and the driving sections are divided by the bus stops that the bus passes through during its actual journey. Based on the passenger boarding and alighting record information, determine the passenger boarding and alighting information within each of the travel sections; Based on the ticket revenue data, determine the fare records for each of the aforementioned travel intervals; Based on the passenger boarding and alighting information and the fare records for the section, the bus operation anomalies are identified.

2. The method as described in claim 1, characterized in that, Each of the aforementioned travel intervals has associated parking stations. The step of determining the interval passenger / drop-off information within each of the aforementioned travel intervals based on the passenger / drop-off record information includes: Determine the range of time the bus will stop at the designated parking station; Based on the passenger boarding and alighting record information, determine the actual passenger boarding and alighting records of the bus in the operating section; Based on the actual passenger and boarding records, determine the first passenger and boarding record within the parking time range and the second passenger and boarding record outside the parking time range; The first and second passenger stop records are used to determine the passenger stop information for the travel section.

3. The method as described in claim 2, characterized in that, The bus includes multiple bus doors, and the passenger boarding and alighting record information includes passenger flow records for the multiple bus doors. Determining the actual passenger boarding and alighting records of the bus within the specified travel section based on the passenger boarding and alighting record information includes: The valid boarding and alighting doors of the bus are determined from among multiple bus doors; The passenger flow records associated with the valid boarding and alighting doors are used as the actual boarding and alighting records.

4. The method as described in claim 1, characterized in that, The step of determining the fare records for each of the travel intervals based on the fare data includes: Based on the station information associated with each ticket in the ticket data, the travel section corresponding to the ticket is determined.

5. The method according to any one of claims 1-4, characterized in that, The method of identifying operational anomalies in the bus based on the interval passenger and alighting information and the interval fare records includes: Based on the aforementioned section boarding and alighting information, determine whether the bus has any abnormal boarding or alighting. Based on the passenger boarding and alighting information and the fare records for the specified route, it is determined whether there are any fare irregularities for the bus.

6. The method as described in claim 5, characterized in that, The step of determining whether there are any fare irregularities for the bus based on the interval passenger and alighting information and the interval fare records includes: For each travel segment, based on the segment boarding and alighting information, it is determined whether there are passengers boarding or alighting in the travel segment; If passengers board or alight in the specified travel section, the number of passengers on the bus in that travel section is determined. Based on the number of passengers and the fare records for the specified route, the bus fares for the specified route are compared. If the number of passengers and the ticket price records for the specified route do not match, it is determined that there is a ticket price discrepancy for the specified route.

7. The method as described in claim 5, characterized in that, The step of determining whether the bus has abnormal passenger boarding or alighting based on the interval passenger and alighting information includes: If a second passenger stop / boarding record exists in the travel section, an off-station passenger stop / boarding risk is generated for the travel section. The off-station passenger stop / boarding risk includes passenger stop / boarding coordinates and the number of passengers who boarded or boarded abnormally.

8. A bus operation anomaly identification device, characterized in that, include: The acquisition module is used to acquire the bus's trajectory information, passenger boarding and alighting records, and fare data; The segmentation module is used to determine multiple driving sections of the bus based on the trajectory information, wherein the driving sections are divided by the bus stops passed by the bus during its actual journey. The section passenger stop determination module is used to determine the section passenger stop information within each of the travel sections based on the passenger stop record information; The fare determination module is used to determine the fare records for each of the travel intervals based on the fare data. The identification module is used to identify anomalies in the bus operation information based on the interval passenger and alighting information and the interval fare records.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-7.

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

Images