Intelligent bus scheduling method based on multi-source data fusion

Abstract

The invention relates to the technical field of intelligent traffic system (ITS) and urban public traffic scheduling control, in particular to an intelligent bus scheduling method based on multi-source data fusion, which comprises the following steps: S1, a central scheduling platform receives and stores multi-source data; s2, obtaining a fusion feature sequence; s3, sending to a calibrated demand prediction model to obtain a point prediction and demand interval; s4, constructing a transport capacity interval with an upper bound and a lower bound based on the vehicle availability, the driver shift, the maximum passenger capacity of the single vehicle and the road section speed distribution; s5, calculating overlapping ratio = intersection / prediction interval length; when the vehicle number is lower than the threshold value, distributed robust multi-target scheduling optimization of an ambiguity set defined by the Wasserstein radius is solved, the departure interval and the vehicle distribution number are updated, and the target is that the vehicle waiting time condition is weighted in a risk value and an empty driving rate, and the vehicle number, the employees, the departure interval and the insertable control point constraint are met; and S6, issuing an instruction and executing according to a vehicle positioning and control point arrival event. And unified modeling and robust triggering in the same space-time key interval are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of intelligent transportation system (ITS) and urban public transportation scheduling control, and particularly relates to a bus intelligent scheduling method based on multi-source data fusion. BACKGROUND

[0002] Urban bus scheduling has long relied on offline timetable compilation and intraday fine-tuning based on "historical average + experience rules". In recent years, although point prediction and threshold triggering based on single-source data have been introduced, there are still three types of difficulties in actual operation: first, on the data side, the multi-source heterogeneous data such as historical passenger flow, real-time passenger flow, vehicle positioning, road conditions, weather and temporary events have significant differences in time granularity, spatial reference and quality stability, and it is difficult to form a unified representation that can be directly used for decision-making under the same time-space key; second, on the uncertainty side, existing methods generally measure future demand by point prediction and estimate capacity by fixed rules, lacking explicit quantification of "prediction error and operation fluctuation", resulting in large fluctuations in congestion risk and empty running loss in different scenarios; third, on the triggering and execution side, the common practice is to drive adjustment by single threshold or local indicators, which is prone to lag and frequent changes that cause scheduling shock, and the scheduling instructions are often disconnected from the vehicle position event, making it difficult to guarantee the timing and feasibility of landing execution. As a result, during peak hours, there is a two-way mismatch between "overestimation or underestimation of demand and synchronization of capacity allocation": on one end, passenger waiting time and congestion exceed the standard, and on the other end, vehicle turnover efficiency and full load rate decrease, making it difficult to balance service quality and operational stability.

[0003] In view of the above status, the technical problem to be solved by the present application is: under the condition of multi-source heterogeneity and high uncertainty, how to uniformly model the bus travel demand and the available capacity in the same time-space key, and trigger the robust (distributionally robust) scheduling adjustment based on the overlap rate, so as to ensure that the service risk is controlled while suppressing the scheduling shock and ensuring the executability. SUMMARY

[0004] In order to overcome the above technical defects, the purpose of the present application is to provide a bus intelligent scheduling method based on multi-source data fusion. The present application realizes the uniform modeling of bus travel demand and available capacity in the same time-space key under the condition of multi-source heterogeneity and high uncertainty, and triggers the robust (distributionally robust) scheduling adjustment based on the overlap rate, so as to ensure that the service risk is controlled while suppressing the scheduling shock and ensuring the executability.

[0005] This invention discloses a method for intelligent bus scheduling based on multi-source data fusion, comprising the following steps: Step S1, Multi-source data collection: The central dispatch platform receives and stores multi-source data related to bus operation, including historical passenger flow data, real-time passenger flow data, vehicle positioning and road condition data, meteorological data, and temporary event data; Step S2, Feature-level fusion processing: The multi-source data from step S1 is cleaned, standardized, and missing data is filled in to obtain a fused feature data sequence; Step S3, Interval-based travel demand prediction: Input the fused feature data sequence into the calibrated demand prediction model to obtain the travel demand point prediction for the target time period and the corresponding predicted demand interval. The upper and lower bounds of the predicted demand interval are obtained through consistency prediction calibration on the sliding calibration set. Step S4, Capacity Range Characterization: Based on vehicle availability, driver shifts, maximum passenger capacity per vehicle, and road speed distribution, construct the capacity range for the target time period. The capacity range is characterized by its lower and upper bounds. Step S5, Overlap Rate Triggering and Split-Brow Bar Scheduling Optimization: Calculate the overlap rate between the predicted demand interval and the capacity interval. The overlap rate is defined as the ratio of the intersection length of the two to the length of the predicted demand interval. When the overlap rate is less than a preset threshold, solve the split-Brow bar multi-objective scheduling optimization model to update the departure interval and number of vehicles for the target time period. The robust ambiguity set is defined by the preset Wasserstein distance radius. The objective function is the weighted sum of the conditional risk value of passenger waiting time and the empty running rate. The constraints include vehicle quantity constraints, driver working hours constraints, departure interval constraints, and insertable control point constraints determined by vehicle positioning and road condition data. Step S6, Location-Driven Execution: The scheduling instructions obtained in step S5 are sent to the central dispatch platform, and scheduling adjustments are performed based on vehicle positioning and control point arrival events.

[0006] Preferably, the temporary event data is mapped to an event impact intensity index in step S2. The event impact intensity index is calculated based on the event impact range, start and end time, historical amplification factor, and the topological relationship between bus stops and routes. It is used as a component of the fused feature data sequence in steps S3 and S5. When the event impact intensity index reaches the level of severe weather or large-scale event, the confidence level of step S3 is adaptively increased, and the confidence level used in the conditional risk value calculation is increased accordingly.

[0007] Preferably, the fusion weights in step S2 are adaptively updated using an online multi-armed gambling machine algorithm. The immediate benefit is defined as the weighted result of the decrease in travel demand prediction error and the increase in scheduling stability index, thereby achieving self-calibration of the weights of the fusion feature data sequence over a continuous period.

[0008] Preferably, the consistency prediction calibration in step S3 is performed on a stratified sliding calibration set divided by meteorological level and time period type, and coverage constraints are set for each stratum to ensure that the marginal coverage of the prediction demand interval is consistent under different scenarios.

[0009] Preferably, the capacity range in step S4 is obtained by estimating the capacity distribution using a Monte Carlo sample generated by a mixture of vehicle availability Bernoulli variables and road segment speed distributions, and using the lower quantile of this distribution as the lower bound of the capacity range and the upper quantile as the upper bound of the capacity range.

[0010] Preferably, the multi-objective scheduling optimization model of step S5 includes not only vehicle quantity constraints, driver work hours constraints, and departure interval constraints, but also upper limit constraints on continuous driving time for drivers, lower limit constraints on mandatory rest time, and time window constraints for returning to the depot or refueling; it also includes departure interval stability constraints, which require that the departure interval deviation decreases exponentially in adjacent adjustment cycles, with the decay rate not lower than the preset first stability parameter, and allowing a disturbance margin not exceeding the preset second stability parameter.

[0011] Preferably, the dynamic adjustment in step S5 is performed with a freeze window set before execution. Within the freeze window, adjustments are only allowed when the probability of service level agreement default, determined based on the predicted demand range and capacity range, exceeds a threshold, in order to suppress operational fluctuations caused by frequent changes.

[0012] Preferably, in the multi-objective scheduling optimization model of the sub-Bruker bar in step S5, the Wasserstein distance radius and overlap rate threshold are calibrated offline based on the risk and stability trade-off curve of the external validation set of the model and are periodically reviewed to ensure the consistency of scheduling effect and stability within the rolling cycle.

[0013] Preferably, when the overlap rate is not lower than the preset threshold but the predicted travel demand point has a positive deviation from the median capacity of the capacity range, the central dispatching platform shall prioritize either vehicle waiting or short-line turnaround insertion at the insertable control point, and the strategy shall be selected according to the principle of minimizing the risk under the incremental conditions.

[0014] Preferably, in step S6, the central dispatch platform marks the scheduling instructions and vehicle execution status for the target time period on the electronic map interface in real time based on vehicle positioning and road condition data, and issues execution instructions when the vehicle arrives at the preset insertable control point.

[0015] Compared with existing technologies, the above technical solution has the following advantages: 1. Difficulty in unifying and aligning multi-source heterogeneous data. In existing technologies, data such as historical passenger flow, real-time passenger flow, vehicle positioning and road conditions, weather, and temporary events have different granularities, different coordinate systems, and large quality fluctuations. They are often spliced ​​together with temporary scripts, making it difficult to form feature sequences that can be directly used for decision-making. In this invention, a unified time granularity and primary key are established through steps S1–S2, data cleaning, standardization, and data completion are completed, and temporary events are converted into event impact intensity indices. This enables multi-source data to form a stable fused feature data sequence in the same key space, reducing the overhead of pre-alignment and improving the availability and reproducibility of downstream prediction and optimization.

[0016] 2. Point-based forecasting alone cannot quantify risk and uncertainty. Existing technologies generally rely on point-based forecasting and fixed rules to estimate capacity, which struggles to express the uncertain range of demand and capacity, leading to uncontrollable service risks. In this invention, the predicted demand range is obtained in step S3, and a capacity range is constructed using Monte Carlo methods in step S4. Both are fully aligned to the same spatiotemporal key, allowing for explicit quantification of risk. Subsequent overlapping rates can be used for consistent and interpretable trigger judgments, enabling range-oriented management of SLA risk.

[0017] 3. The triggering mechanism is scattered or opaque, prone to delays and false triggers. In existing technologies, multiple thresholds or empirical rules are relied upon, resulting in inconsistent indicator definitions and poor interpretability. In this invention, the overlap rate between the predicted demand range and the capacity range is used as the single triggering criterion, supplemented by a default probability check of "demand exceeding capacity," to achieve transparent, calibrable, and reusable triggering conditions, thereby reducing false triggers and delays.

[0018] 4. The optimization objective lacks risk control and is prone to failure in extreme scenarios. In existing technologies, optimization is mostly based on expected value, ignoring tail risk and making it difficult to suppress peak congestion. In this invention, a multi-objective scheduling optimization model is constructed through step S5. Within the ambiguity set defined by the Wasserstein distance radius, the objective is the weighted sum of the conditional risk value and empty-running rate of passenger waiting time. This makes it robust to tail scenarios, significantly reduces the risk of high-ranking waiting areas, and also takes into account the vehicle empty-running rate.

[0019] 5. Frequent adjustments and significant shift fluctuations. In existing technologies, rolling optimization lacks vibration suppression design, resulting in repeated "addition and subtraction of trains" and "expansion and compression of intervals" within the day. In this invention, by introducing departure interval stability constraints and a freeze window in step S5, the thresholds for "exponentially decaying deviation convergence" and "over-limit readjustment" are clearly defined, thereby suppressing unnecessary changes and chain fluctuations, maintaining a continuous and perceptible departure interval, and making operations smoother.

[0020] 6. Instructions are disconnected from vehicle status, resulting in poor on-site executability. In existing technologies, dispatch instructions are mostly time-driven, lacking synchronization with vehicle location events, and their execution relies on manual coordination. In this invention, by using insertable control points as anchors in step S6 and employing geofencing to trigger arrival events, the instructions are issued and take effect with location alignment, achieving "execution upon arrival," reducing communication costs and execution deviations, and improving the certainty of execution.

[0021] 7. Delayed response to large-scale events and severe weather. Existing technologies suffer from crude event identification and static thresholds, making them prone to delayed or erroneous capacity expansion during events such as sporting events or heavy rainstorms. This invention addresses this by generating an event impact intensity index in step S2 and adjusting the coverage rate and the confidence level of the conditional risk level in step S3 when severe weather or large-scale events are detected. This proactively provides sufficient safety margins in high-disturbance scenarios, significantly reducing the probability of SLA default and the risk of sudden congestion.

[0022] 8. Capacity estimation relies on static experience, resulting in significant bias. Existing technologies often use fixed travel times and nominal estimates to compile capacity estimates, ignoring fluctuations in vehicle / driver availability and speed distribution. In this invention, a sample distribution is constructed in step S4 by superimposing Bernoulli sampling of vehicle and driver availability with road segment speed distribution sampling. Quantiles are then extracted as capacity ranges, making the capacity representation closer to real fluctuations and reducing mismatches caused by overestimation or underestimation.

[0023] 9. Static weighting makes it difficult to adapt to environmental and device conditions. In existing technologies, fixed weights or offline experience-based weights are difficult to maintain optimal performance over a long period. In this invention, the weights are adaptively updated using an online multi-armed gambling machine in step S2. The reward consists of a decrease in prediction error and an improvement in scheduling stability, enabling the fusion strategy to continuously learn and optimize with environmental changes, maintaining the dual objectives of prediction and stability.

[0024] 10. The system lacks auditability and traceability. In existing technologies, it is difficult to reproduce "why it was arranged this way or why it was changed this way", making compliance and review difficult. In this invention, by recording the model version, feature scheme version, Wasserstein distance radius, overlap rate threshold, sample statistics and instruction lifecycle at each step, a complete audit chain from data to decision to execution is formed, which facilitates compliance verification and problem localization.

[0025] 11. Resource utilization and service quality are difficult to balance. In existing technologies, either reducing waiting time leads to a surge in empty-running rates, or reducing empty-running rates leads to uncontrollable congestion. In this invention, a weighted multi-objective optimization based on conditional risk value and empty-running rate is used in step S5. When a slight positive bias occurs, a choice is made between "controlling vehicle waiting / short-line turnaround insertion" and the optimal choice is made based on the minimum incremental conditional risk value. This achieves the goal of ensuring high-quality service while suppressing unnecessary resource waste and improving load factor and turnover efficiency.

[0026] 12. Insufficient engineering and timeliness. In existing technologies, batch processing chains are long and delivery cycles are slow, making it difficult to support minute-level rolling scheduling. In this invention, steps S1–S6 are implemented through an engineering system of streaming access, hot storage and object archiving layering, and location event-triggered execution, which supports minute-level or faster rolling prediction-comparison-optimization-execution closed loop, meeting the timeliness requirements of large-scale networks. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a method for intelligent bus scheduling based on multi-source data fusion according to the present invention. Detailed Implementation

[0028] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.

[0029] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0030] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0031] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0032] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0033] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0034] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.

[0035] See Figure 1As shown in this embodiment, a method for intelligent bus scheduling based on multi-source data fusion will be described in detail, specifically including the following steps: Step S1, Multi-source data acquisition: The central dispatching platform receives and stores multi-source data related to bus operation, including historical passenger flow data, real-time passenger flow data, vehicle positioning and road condition data, meteorological data, and temporary event data; Step S2, Feature-level fusion processing: The multi-source data from Step S1 is cleaned, standardized, and missing data is filled to obtain a fused feature data sequence; Step S3, Inter-regional travel demand prediction: The fused feature data sequence is input into a calibrated demand prediction model to obtain the predicted travel demand points for the target time period and the corresponding predicted demand intervals. The upper and lower bounds of the predicted demand intervals are obtained through consistency prediction calibration on a sliding calibration set; Step S4, Capacity interval characterization: Based on vehicle availability, driver shifts, maximum passenger capacity per vehicle, and road segment... Speed ​​distribution is used to construct the capacity range for the target time period, which is characterized by its lower and upper bounds. Step S5, overlap rate triggering and sub-Brussels bar scheduling optimization: calculate the overlap rate between the predicted demand range and the capacity range, which is defined as the ratio of the intersection length to the length of the predicted demand range. When the overlap rate is less than a preset threshold, solve the sub-Brussels bar multi-objective scheduling optimization model to update the departure interval and number of vehicles for the target time period. The robust ambiguity set is defined by a preset Wasserstein distance radius. The objective function is the weighted sum of the conditional risk value and empty running rate of passenger waiting time. Constraints include vehicle quantity constraints, driver working hours constraints, departure interval constraints, and insertable control point constraints determined by vehicle positioning and road condition data. Step S6, location-driven execution: send the scheduling instructions obtained in step S5 to the central dispatch platform and perform scheduling adjustments based on vehicle positioning and control point arrival events.

[0036] This embodiment will describe step S1 in detail. In one embodiment, the purpose of step S1 is to enable the central dispatch platform to uniformly receive and store historical passenger flow data, real-time passenger flow data, vehicle location and road condition data, meteorological data, and temporary event data, forming a time-traceable, source-identifiable, and unaltered original hierarchical dataset, providing stable, complete, and auditable input for the feature-level fusion processing in step S2. To achieve this purpose, the central dispatch platform continuously operates four types of capabilities: access, buffering, persistence, and auditing. The platform provides data access externally through an encrypted channel and performs identity verification, structure verification, and rate control on the accessed data. Internally, the platform uses a highly available message stream as a buffer to absorb sudden traffic and network jitter. The platform writes data to hot storage for near real-time querying and warm / cold storage for long-term archiving. The platform also maintains source mode, field constraints, and version information, and outputs operational metrics such as end-to-end latency, success rate, duplication rate, and packet loss rate for easy auditing and traceability. The platform is typically deployed in multiple availability zones using a containerized approach, with horizontal scaling of access and message flow. Storage is divided into cold and hot tiers and features cross-zone replication and periodic snapshots. TLS is enabled throughout the transport layer, and encrypted static storage and least privilege access control are implemented across the entire chain.

[0037] The data reception links vary depending on the source. Reports from vehicles and stations are transmitted to the platform via cellular or private networks through onboard or roadside equipment. Vehicle positioning data, including road condition data, is sent by the onboard positioning terminal every 1-5 seconds, containing latitude, longitude, speed, heading, and positioning accuracy. Real-time passenger flow data is transmitted in real-time by the IC card front-end device, or periodically by the automatic passenger counter within the door opening and closing window, including boarding and alighting counts and confidence levels. Road conditions, weather, and temporary events from urban traffic management or third-party platforms are retrieved via API pull or subscription push. Historical passenger flow data is pushed in batches daily or hourly by the enterprise's historical operation system. Each record must carry both the source timestamp and the platform's receiving timestamp. The platform calculates the receiving delay, a monitoring indicator, defined as the platform receiving timestamp minus the source timestamp. This delay is used for maintenance alarms and link quality assessment, but the original time is not corrected in step S1; time alignment is handled uniformly in step S2. The authentication on the access side is completed using device certificates, device tokens, or platform tokens in conjunction with a source address whitelist, depending on the source. All rejected requests and discarded data are recorded with the reason for rejection and the fingerprint of the original payload to ensure traceability.

[0038] The data storage organization adopts a core strategy of "partitioning by day and binning by source and region" to ensure that both near real-time query and long-term archiving needs are met simultaneously. Vehicle location and traffic condition data, as well as real-time passenger flow data, are prioritized for hot storage with time-series capabilities. A composite index based on vehicle or route identifiers and time is constructed, and a geographic index is created on the location data to facilitate rapid retrieval by vehicle, route, time window, or spatial range. All data is synchronously or periodically aggregated to object storage to form an archive. The directory structure is organized hierarchically by source, year, month, and date, and is stored in a compressed columnar format with versioning and immutable archiving strategies enabled. Master data such as routes, stations, road segments, meteorological grids, and event types are maintained in independent master data tables within the platform, with original records associated with them through identifiers to ensure consistent referencing. To facilitate preliminary assessment of deployment scale, the following quantitative scenario can be used as a reference: If a city has 1200 buses operating for 18 hours daily, and vehicle location data is uploaded at 1 second per instance, there would be approximately 64,800 records per bus per day, totaling approximately 77,760,000 records for the entire fleet. Assuming each record is approximately 180 bytes, the raw daily volume would be approximately 13 GiB. If 30% of the buses are equipped with automatic passenger counters and upload counting events every 5 seconds, the daily volume would be approximately 4,660,000 records, at 120 bytes per record. Each entry is approximately 0.52 GiB; traffic conditions, if calculated at 1 entry per minute for 10,000 road segments, would amount to approximately 10,800,000 entries over 18 hours, or approximately 0.80 GiB at 80 bytes / day; grid weather, if calculated at 100 grids updated every 5 minutes, would amount to approximately 21,600 entries over 18 hours, with a file size of approximately 4MB; historical passenger flow, if estimated over 2 years, with 2,000 stations and a 5-minute granularity, would have a total of approximately 4.2 × 10^8 entries, or approximately 9.4 GiB at 24 bytes / day, suitable for long-term archiving.

[0039] In step S1, the five types of multi-source data are stored in the database as is. Their composition and acquisition methods are as follows, so that those skilled in the art can implement them without confusion with subsequent processing. Historical passenger flow data comes from the enterprise's historical operation database or data lake. It usually includes route identifier, trip identifier, service date, station identifier, start and end time window, as well as the number of passengers boarding, alighting, and inside the vehicle within that time window. If the source system has already summarized the data in 5-minute granularity, the platform directly receives the statistical value and adds a batch number and a platform receiving timestamp. Reruns are distinguished by the batch number. If the source provides historical details of card swiping or counting, the platform does not perform aggregation in step S1, but only retains the original details. Aggregation is reserved for step S2. Real-time passenger flow data consists of two parts: card swipe event records include card swipe serial number, vehicle and route, trip, station, source timestamp, ticket type and amount, and desensitized card identifier; and counting event records include device and vehicle, route and trip, source timestamp, boarding and alighting counts, and confidence level. Both types of events generate a platform receiving timestamp and calculate the receiving delay for monitoring. For example, if the source time is 06:30:15.124 on a certain day, and the platform receives it at 06:30:15.450 on the same day, the receiving delay is 0.326 seconds. Vehicle positioning and traffic condition data come from the vehicle positioning terminal and the traffic management platform, respectively. Vehicle positioning records include vehicle, route and trip, source timestamp, latitude and longitude, speed, heading, positioning accuracy, odometer reading, receiving timestamp, and auto-incrementing sequence number. Traffic condition records include road segment identifier, source timestamp, average speed, free-flow speed, congestion index, and source and receiving timestamps. In step S1, the platform only labels the coordinate system as WGS84, without map matching or speed conversion. Meteorological data comes from city-level or grid-level interfaces of meteorological departments, recording grid or station identifiers, source timestamps, temperature, precipitation intensity and type, wind speed, visibility, and weather codes, as well as receiving timestamps, typically updated every 1-5 minutes. Temporary event data comes from municipal activity platforms, traffic management construction notices, and public transport company network adjustment systems, recording event identifiers, event types, titles and descriptions, start and end times, geometric representation of the affected area, severity and a list of associated routes, as well as the last update time, source, and receiving timestamps. If the same event is updated multiple times, a zipper-style record is created using the same identifier to save all update traces.

[0040] To ensure the stable storage and traceability of the aforementioned data, step S1 performs minimal validation, deduplication, and compliance control without altering business values. During the access phase, the platform checks required fields, formats, and value ranges according to the registration patterns of each source. For example, it checks whether longitude and latitude are within valid ranges and whether the timestamp is in Coordinated Universal Time (UTC) format. Units are explicitly stated in the field names but are not converted in step S1. During the storage phase, the platform establishes a unique index using a composite key composed of the source identifier, device or vehicle identifier, source timestamp, and sequence number. If duplicates are encountered, the record is written to a dead-letter queue with the rejection reason and entry fingerprint, facilitating subsequent replay or manual intervention. Information involving personal payment identifiers only receives irreversibly anonymized values, static storage is encrypted, and access control follows the principle of least privilege. Through the above access, reception, and storage process, step S1 ultimately delivers a set of original hierarchical datasets that are partitioned by day and binned by source and region. Each record simultaneously holds the source timestamp and the platform reception timestamp, source identifier, data version, and audit information, which can be directly used as input for step S2. The platform also generates a reception quality report, summarizing the access success rate, average and maximum reception latency, duplication rate, and packet loss rate of each source, providing an operable foundation for subsequent feature-level fusion and demand prediction.

[0041] This embodiment will describe step S2 in detail. In one embodiment, the purpose of step S2 is to complete data cleaning, data standardization, and data completion without changing the semantics of the original records in step S1, and to align historical passenger flow data, real-time passenger flow data, vehicle positioning and road condition data, meteorological data, and temporary event data to a unified time granularity, a unified spatial reference, and a unified primary key, forming a fused feature data sequence that can be directly used in step S3. The platform first determines a unified time granularity, preferably 60 seconds per time window, which can be adjusted between 30 seconds and 300 seconds depending on the city size and prediction step size. At the same time, the spatial reference is fixed as WGS84, and the primary key is defined as a combination of four items: "route identifier, trip identifier, station or road segment identifier, and time window start time", ensuring that all sources ultimately fall into the same key space.

[0042] During the data cleaning phase, the platform first performs deduplication, avoiding cross-source merging. Duplicates are only identified within the same source using a combination of "source identifier, device or vehicle identifier, source timestamp, and sequence number or batch number." The first duplicate is retained, while subsequent duplicates are written to a dead-letter pool with their fingerprints and rejection reasons recorded. Following this, rule-based validation is performed: latitude must be between -90 and 90 degrees, longitude between -180 and 180 degrees, speed must be in km / h, amount in minutes, temperature in degrees Celsius, precipitation in millimeters per hour, and time is uniformly converted to Coordinated Universal Time (UTC) strings while retaining milliseconds. Non-compliant records are marked as abnormal and added to the audit table. Outliers are further controlled using a two-level discrimination mechanism. The first level calculates the absolute deviation between the median and the median within a sliding window for a single device or vehicle, with a recommended window length of 5 to 15 minutes. Deviations exceeding the threshold are marked as suspicious. The second level performs group verification across the horizontal distribution of the same route, trip, station, and time window. For example, within the same 60-second window, if a vehicle's speed is more than twice the free-flow speed of that road segment and its positioning accuracy is less than 20 meters, it is downweighted or removed. All actions are recorded with a reason code.

[0043] During data completion, the platform follows a "time priority, space second, and cross-source conservatism" approach. For vehicle positioning, time completion is performed first, followed by spatial matching: for missing 60-second windows, linear interpolation with equal speeds between preceding and following points is used to recover the coordinates and speed; after matching the road segment network, the average speed and congestion index for that time window are calculated. Road conditions are aggregated by road segment within time windows, and a weighted average of the records within each time window is used to obtain window-level indicators. For real-time passenger flow, the platform first accumulates boarding and alighting counts within the door opening and closing window to complete the 60-second window, then merges card-swiping and automatic passenger counting sources; when both sources have values ​​within the same time window, weights are assigned based on data quality score and reception latency. For example, a source with "good" device health and a reception latency of less than 1 second has a weight of 0.7, while the other source has a weight of 0.3, and a linear weighted average is used to obtain the boarding and alighting counts for that window. For historical passenger flow, the expected value and quantiles are calculated based on multi-year samples of the same route, station, weekday type and time period as the baseline. When there is a complete lack of data in a certain time window on a given day, the historical expected value is used to fill the gap, and it is marked "the source of the filling is historical expected value".

[0044] For meteorological and temporary events, the platform uses spatial overlay to map grids or event-affected areas onto routes and stations or routes and road segments. If a route crosses multiple meteorological grids, weights are assigned based on the proportion of the route's geometric length falling within each grid, and a weighted sum is obtained to obtain the route's meteorological vector for that time window. For temporary events, an event impact intensity index is generated in this step. The calculation method is as follows: first, a base score is mapped based on the event severity; it is recommended that low, medium, and high scores be mapped to 0.3, 0.6, and 0.9, respectively. Then, a linear attenuation is applied based on the shortest distance from the geometric center of the station or road segment to the event-affected area, for example, attenuating by 0.1 every 500 meters, taking 1 for distances less than 100 meters, and 0 for distances greater than or equal to 5000 meters. Simultaneously, the overlap ratio between the time window and the event's validity period is multiplied by a time factor; for example, if half the duration of a window falls within the event's validity period, it is multiplied by 0.5. If multiple events exist within the same time window, the maximum value can be used, or a weighted sum can be calculated after configuring weights according to event type. The weights are stored in an external parameter table, which the platform loads daily.

[0045] During the data standardization phase, the platform maps different units of measurement to a comparable range to improve the stability of model training and inference. One option is linear scaling to a 0-1 interval, using the 1st and 99th quantiles of the past 90 days as upper and lower bounds to suppress extreme values. Another option is zero-mean unit variance standardization, where the mean and standard deviation are updated daily during training using a sliding window and written to the feature list with a version number. For categorical elements, such as ticket types and weather codes, a consistent numerical or unique thermal coding scheme is used, with the coding table managed uniformly in the metadata center and including versioning.

[0046] After cleaning, completion, and standardization, the system proceeds to feature-level fusion. The platform assembles multi-source elements into ordered vectors according to time windows and primary keys. Common components include historical passenger flow baselines, real-time boarding and alighting counts, average road segment speed and congestion index, temperature and precipitation intensity and type coding, event impact intensity index, and metadata such as reception delay and data quality score from step S1. If the implementation method in this embodiment is adopted, the platform adaptively selects a weighted fusion scheme using an online multi-armed gambling machine algorithm. Several candidate weighted reassemblies are pre-configured, such as weighted reassemblies emphasizing real-time passenger flow, road conditions and location, and historical and meteorological data. Within a rolling cycle, the platform selects the best candidate for each time window and writes the selection result and weighted reassembly identifier into the feature record.

[0047] The reward signal is settled when it is observable downstream and consists of two parts: the decrease in travel demand forecast error and the increase in scheduling stability index. The two parts are added together according to the coefficients in the external parameter table to form a single reward. The platform can use the upper confidence boundary or Thompson sampling to update the selection tendency of each candidate weight reorganization, so that the more effective weight reorganization in the long run is adopted more frequently. To facilitate understanding, a numerical example is given: Within a 60-second window at 07:30 on route R45 and station S9021, the historical passenger flow baseline is 40, the real-time boarding count is 5, the alighting count is 1, the average speed of the road segment is 24 km / h, the congestion index is 0.6, the temperature is 18 degrees Celsius, the precipitation intensity is 1.5 mm per hour, the event impact intensity index is 0.8, the median reception delay is 0.3 seconds, and the data quality score is 0.9. If this window chooses to emphasize the weighted combination of road conditions and location, and sets the linear combination weights of "short-term demand proxy quantity" to 0.35 for real-time boarding, 0.25 for historical baseline, 0.25 for road condition correlation, 0.10 for weather, and 0.05 for event intensity, then the proxy quantity is equal to 0.35 multiplied by 5 plus 0.25 multiplied by 40 plus the linear parts corresponding to road conditions, weather, and event items. The resulting scalar, together with the standardized features that are not linearly combined, constitutes the fused feature vector of this time window.

[0048] Finally, the platform writes the fused feature vector, primary key, feature scheme version, weighted reorganization identifier, and data lineage pointer for each time window into the feature storage. The feature storage is organized in a way that is "partitioned by day, and binned by route and station or route and segment" to ensure that step S3 can stably, sequentially, and traceably read the fused feature data sequence. At the same time, the platform generates a processing report for step S2, listing the deduplication rate, anomaly rate, completion rate, and standardized version distribution of each source, providing a basis for subsequent investigation and audit.

[0049] This embodiment will describe step S3 in detail. In one embodiment, the purpose of step S3 is to input the fused feature data sequence produced in step S2 into the calibrated demand prediction model to obtain the travel demand point prediction for the target time period and the corresponding lower and upper bounds of the predicted demand interval. To ensure that subsequent steps can be triggered and optimized in a risk-consistent manner, step S3 delivers three types of results simultaneously on the same pipeline: point prediction values ​​defined by route, trip, station or road segment and time window, lower bound values ​​of the predicted demand interval, and upper bound values ​​of the predicted demand interval. It also records metadata such as the model version, feature scheme version, calibration set time range, and coverage target used to generate these results to ensure traceability.

[0050] In terms of model training and updating, the platform first constructs supervised learning samples based on the key space aligned in step S2. The target variable is defined as the actual short-term travel demand on the same key, with the default time window consistent with step S2, such as one window every 60 seconds. Sample features are directly taken from the fused feature data sequence, including historical passenger flow baseline, real-time boarding and alighting counts, average road segment speed and congestion index, temperature and precipitation intensity and type coding, event impact intensity index, and metadata such as reception latency and data quality score. To balance short-term dynamics and inertial structure, the platform introduces multi-scale lag and rolling statistics for each sample, such as the moving mean, moving standard deviation, and rate of increase for the past 5 minutes, 15 minutes, and 60 minutes, and fixes the generation rules and versions of these derived features during the training period. The training process employs a rolling window approach, dividing the model into a training set and a validation set. The training set is used to fit the demand prediction model, while the validation set is used to select hyperparameters and stop early. The platform supports sequence models, gradient boosting tree models, or a stack of both. Regardless of the structure used, a single point prediction value is output, and intermediate values ​​required for residual evaluation of that point prediction are retained. After model training is complete, the model is released with a version number and updated daily or weekly according to the operational strategy. The most recent versions are also retained for quick rollback in case of drift.

[0051] In terms of point prediction generation, the platform reads the fused feature vector and necessary lag and rolling statistics on the same key for each new time window, and feeds them into the published demand forecasting model at once to obtain the predicted travel demand point value for that time window. To ensure interpretability and stability, the platform performs two consistency controls during inference: first, it performs standardization or encoding processing on the input features in complete consistency with the training period; second, it performs physical feasibility pruning on the output point predictions, with a lower bound of zero and an upper bound that can be derived from a conservative upper limit based on the maximum passenger capacity of vehicles and the maximum number of departures per hour. For example, if a route can only depart once every 60 seconds during peak hours and the maximum passenger capacity of a single vehicle is 80, then the upper limit of demand for that time window will not exceed 80. If station-based prediction is used, the upper limit is estimated based on the maximum number of passengers that a single vehicle can serve and the available number of trips at that station within that time window. The platform stores the estimation rules and parameters for these upper limits in the metadata.

[0052] In generating the predicted demand interval, the platform employs a consistent prediction calibration method to extend the point predictions given by the model to upper and lower bounds, ensuring that the empirical coverage on the sliding calibration set aligns with the target coverage. The process involves first determining the time span and coverage target of the calibration set, for example, using the most recent 28 days as the sliding calibration set and 90% as the target coverage. Then, for each time window sample within this calibration set, the residual sequence between the point predictions and the actual demand is calculated. The residuals can be measured using absolute residuals or quantile residuals. The platform calculates the empirical quantiles corresponding to the target coverage from the residual sequence. If a two-sided interval is used and the target coverage is 90%, the quantiles of 5% on each side can be used as the extended half-width or upper and lower offsets. The platform records these quantiles and uses them as the calibration values ​​for the current time period. During online inference, the point prediction value at that moment is taken as the center value, and the lower and upper bounds of the interval are obtained by extending downwards and upwards using the calibration values. These are then further pruned according to physical feasibility to ensure that the lower bound is not less than zero and the upper bound does not exceed the serviceable upper limit. To address systematic biases across different scenarios, the platform can use scenario-specific sliding calibration sets during consistency prediction calibration. For example, it can divide the data by weather level and time period type, independently calculate residual quantiles and interval expansion within each stratum, and select the corresponding interval expansion based on the stratum to which the current sample belongs during inference. This approach can significantly improve the consistency of interval coverage during severe weather, peak and off-peak periods, and event periods.

[0053] When a reproducible example is required, a numerical demonstration can be performed following these steps. Set the target coverage rate to 90%, use the most recent 28 days as the sliding calibration set, and take a 60-second time window at 07:30 AM on route R45, station S9021, as an example. The platform first generates the fused feature vector for this time window according to the rules in step S2, taking the historical passenger flow baseline as 40, real-time boarding count as 5, alighting count as 1, average road speed as 24 km / h, congestion index as 0.6, temperature as 18 degrees Celsius, precipitation intensity as 1.5 mm per hour, event impact intensity index as 0.8, median reception delay as 0.3 seconds, and data quality score as 0.9. After transformation according to the standardization scheme of the training period, it is fed into the demand forecasting model to obtain a point prediction value of 46. The platform then takes the residual sequence from the same stratum on the sliding calibration set, calculates the absolute residual of the two-sided quintiles as 6, and sets the predicted demand interval for this time window to a lower bound of 40 and an upper bound of 52. If the physical serviceability limit of the line is 80, then the upper bound of 52 is compliant; if the lower bound is negative, it is corrected to zero. To maintain consistent coverage, the platform updates the sliding calibration set daily and recalculates the interval expansion, smoothly switching between the old and new expansions within a preset transition period to avoid abrupt changes in the interval width.

[0054] Regarding adaptive handling in abnormal scenarios, step S3 does not change the feature meaning of step S2, but introduces a mild adaptive strategy in the interval generation stage to resist rapid shifts. For example, when external monitoring shows that the measured coverage rate in a certain layer in the most recent hour is significantly lower than the target coverage rate, the platform will temporarily increase the proportional coefficient of the interval expansion of that layer. The upper limit and recovery condition of the proportional coefficient are controlled by external parameters. When the coverage rate recovers to near the target value and remains stable for a period of time, the proportional coefficient automatically falls back to 1. This strategy ensures the short-term steady-state consistency of interval coverage, while not changing the version of the model or feature engineering, facilitating auditing and backtracking.

[0055] In terms of output organization and delivery, step S3 writes back the point prediction value, the lower and upper bounds of the predicted demand interval, the coverage target, the time range of the sliding calibration set, the interval expansion, the stratification identifier, the model version, the feature scheme version, and the data lineage pointer for each time window and each key. These results are then stored in the prediction result storage by day, by route and station, or by route and segment. The platform simultaneously generates coverage and error reports. The coverage report provides statistics on interval coverage and interval width over several hours and days using both full and stratified methods. The error report provides indicators such as point prediction deviation, absolute error, and logarithmic error, as well as their distribution over time, for operation and maintenance and parameter tuning. Through the continuous process of training, inference, and consistent prediction calibration described above, step S3 transforms the fused feature data sequence into travel demand prediction results with point prediction and interval information in a reproducible and auditable manner. This provides direct and stable input for the capacity interval characterization and comparison in step S4 and the overlap rate triggering and sub-blog scheduling optimization in step S5.

[0056] It should be noted that when the event impact intensity index of the corresponding time window reaches the preset threshold (severe weather level or large-scale event level), the platform will adjust the target coverage or conditions of the layer at the risk confidence level according to the threshold table, thereby widening the range expansion and recording the parameter version simultaneously to enhance the protection capability in extreme scenarios.

[0057] This embodiment will describe step S4 in detail. In one embodiment, the purpose of step S4 is to convert the key constraints on the operation side—vehicle availability, driver shifts, maximum passenger capacity per vehicle, and road segment speed distribution—into a "capacity range" that can be compared and triggered within a given time window. This range is characterized by a lower bound and an upper bound, corresponding to the passenger carrying capacity that can be provided under unfavorable and favorable conditions, respectively. This process directly follows the time granularity and primary key definition of step S2, that is, it calculates the output on the same route, trip, station, or road segment and time window key, so that subsequent steps can be compared with the predicted demand one by one.

[0058] Regarding pre-operation data, the platform first establishes a route geometry and operational procedure description for each route, including route direction, stop sequence, station spacing, empirical distribution of average stop time per station, and fixed time consumption for non-passenger transport links (such as turnaround waiting and necessary scheduling buffers). The segment speed distribution comes from the aggregation results of step S2, providing speed distribution parameters or empirical distribution samples for each segment according to time windows. The vehicle inventory records the technical status and availability parameters of each vehicle, and driver shifts record the start and end times of each shift, available job positions, and qualifications matching the route. The maximum passenger capacity per vehicle is fixed in the vehicle master data as a static parameter. Capacity calculation within the same time window must simultaneously satisfy the availability of both vehicles and drivers; therefore, the platform uses the constraint that "the number of effective vehicles equals the lesser of the number of available vehicles and the number of available drivers" as the starting point within each time window.

[0059] In terms of core calculation methods, the platform uses Monte Carlo sampling to generate a capacity sample distribution. For each time window, several independent and repeated sampling calculations are performed, each in the following order: First, a vehicle availability Bernoulli sampling is performed on each vehicle in the vehicle list, with the availability probability calculated based on the vehicle's health status, whether it is under maintenance, and whether it has completed its previous trip. Next, a driver availability Bernoulli sampling is performed on the driver shift schedule based on the available driver set for that route, with the availability probability calculated based on whether the driver is currently on duty, whether they meet the requirements for continuous driving time and mandatory rest time, and whether they are currently occupied within the current time window. The results of the two samplings are summed to obtain the number of available vehicles and the number of available drivers, and the smaller value is taken as the effective number of vehicles in this sampling. Subsequently, for each segment of the entire route, independent sampling is performed according to the speed distribution corresponding to the time window, and the time is converted into segmented travel time. Then, the average stop time at each station and the fixed turnaround buffer are superimposed to obtain a sample value of a "complete round-trip time". Divide the sample value by the number of valid vehicles to obtain the achievable average departure interval corresponding to this sampling; divide the time window length by the departure interval and round down to obtain the number of departures that can be initiated within the time window; multiply the number of departures by the maximum passenger capacity of a single vehicle to obtain the sample value of the carrying capacity of the time window corresponding to this sampling.

[0060] In terms of capacity characterization at the station or road segment level, the platform refines the aforementioned capacity sample key granularity. If characterized by station, the number of available departures within each sampling period is mapped to the sequence of whether the station is served within the current time window, and multiplied by the maximum passenger capacity per vehicle to obtain the "capacity sample of that station within that time window." If characterized by road segment, the number of vehicles passing through that road segment within the time window is multiplied by the maximum passenger capacity per vehicle to obtain the "capacity sample of that road segment within that time window." After all sampling is completed, a capacity sample distribution for that time window and that key is formed.

[0061] For interval extraction, the platform calculates quantiles for the sample distribution, using the lower quantile as the lower bound and the upper quantile as the upper bound. The quantile values ​​can be set by external parameters; in engineering, the 10th and 90th quantiles are commonly used, but can be adjusted to the 5th and 95th quantiles for more conservative or aggressive approaches. To avoid physically infeasible values, the platform performs a feasibility pruning after quantile extraction: lower bounds less than 0 are corrected to 0, and upper bounds greater than the physical limits of the time window under the combined constraints of maximum vehicle passenger capacity and maximum hourly departure frequency are corrected to the physical limits. The platform then writes the final lower and upper bounds back into the capacity interval for that time window.

[0062] To facilitate understanding by those skilled in the art, a numerical example is provided. Assume route R45 has a one-way distance of 12.6 kilometers, stops at 24 stations, and an empirical average stop time of 20 seconds per station, with a fixed buffer of 180 seconds for turnarounds. At 07:30 during the weekday morning rush hour, the average speed distribution given in step S2 is 24 km / h on the main road and 18 km / h on the side roads. The platform independently samples each road segment according to its corresponding distribution and converts it into segmented travel time, accumulating a sample value for the total round-trip time that fluctuates approximately 90 minutes. Vehicle master data indicates a maximum passenger capacity of 80 per vehicle, and the vehicle list shows 14 vehicles on this route. The availability probability of a single vehicle, calculated based on its health status and on-the-go occupancy, is 0.95. The driver shift schedule shows that the availability probability of a driver matched for this route during this time window is approximately 0.97. Taking 5000 samples as an example, if the number of available vehicles is 13 and the number of available drivers is 12 in a certain sample, then the number of effective vehicles is 12. The round-trip travel time sample for this sample is 92 minutes, so the average departure interval is 92 minutes divided by 12, which is approximately 7.67 minutes. The number of departures that can be started within a 60-second time window is 1 minute divided by 7.67 minutes and rounded down, which is 0. Considering that departure is a discrete event, the platform simultaneously calculates the "start probability" of each time window across several rolling time windows, thereby reflecting the total number of departures that can be started at a higher granularity of minute groups or 5-minute groups. If we recalculate using a 5-minute window, under the same sampling conditions, 5 minutes divided by 7.67 minutes equals 0.65, which rounds down to 0. However, in other sampling scenarios, when the number of valid vehicles is 14 and the round-trip travel time sample is 84 minutes, the average departure interval is approximately 6 minutes. The number of departures that can be initiated within the 5-minute window is either 0 or 1, depending on the alignment of departure times. Under long-term sampling, the platform has calculated that the frequency of "1 possible departure" within this 5-minute window is approximately 0.35, and the frequency of "0 possible departures" is approximately 0.65. By summarizing the capacity samples of "departure frequency multiplied by 80", we obtain the capacity sample distribution on this key. Taking the 10th quantile gives a lower bound of 0, and taking the 90th quantile gives an upper bound of 80. Therefore, the capacity range of this 5-minute window is a lower bound of 0 and an upper bound of 80. At the station level, if a station has a 35% probability of being served once within a 5-minute window, then the station's capacity sample distribution will be between two discrete points, 0 and 80, with the lower quantile at 0 and the upper quantile at 80, consistent with the route level. On busier routes with higher vehicle numbers, as the distribution of effective vehicle numbers shifts to the right and the distribution of round-trip travel time shifts to the left, the upper bound will reach higher values ​​such as 160 or 240, and the lower bound will also rise from 0 to 80 or higher.

[0063] In terms of output organization, the platform writes back the lower and upper bounds of the capacity range for each time window and key, while also saving key metadata for reproducing the experiment, including the number of samplings, vehicle and driver availability parameters, versions of road segment speed distributions, turnaround buffer parameters and stop time distributions, as well as threshold settings for quantile extraction. To ensure consistency with subsequent steps, the platform retains summary statistics of the capacity sample distribution for the same time window and key, such as the sample mean, sample median, and sample standard deviation, for auditing and performance tracking.

[0064] In terms of quality control and boundary handling, the platform protects against outliers: when the sampled round-trip travel time is abnormally lower than the physical lower limit, it is replaced by the physical lower limit; when the sampled effective number of vehicles is greater than the quota, it is replaced by the quota. When a sample sequence of vehicles that cannot be started within a long window occurs, the platform backtracks to check whether the driver shift constraints and vehicle availability parameters are configured incorrectly, and triggers maintenance alarms when necessary. In addition, for electric bus routes, if there is a charging time window constraint, the platform additionally superimposes the planned charging stop time into the travel time sample to make the interval closer to the actual available capacity, but does not change the principle that "vehicle availability, driver shifts, maximum passenger capacity per vehicle, and road speed distribution" are the core determining factors of this step. Through the above process, step S4 transforms the operational constraints into a quantitatively comparable capacity interval, and organizes the results with a time and space key that is completely aligned with step S3, providing a direct and stable input for the overlap rate calculation and triggering of step S5.

[0065] This embodiment will describe step S5 in detail. In one embodiment, the purpose of step S5 is to compare the predicted demand range generated in step S3 with the capacity range generated in step S4 window by window, using the single, interpretable trigger indicator of "overlap rate" to determine whether the current schedule needs to be adjusted, and when adjustment is needed, to update the departure interval and number of vehicles in conjunction with the multi-objective scheduling optimization model. This model takes the weighted sum of the conditional risk value of passenger waiting time and the empty running rate of vehicles as the objective, and calculates the executable adjustment instructions under constraints such as the number of vehicles, driver hours, departure interval, and insertable control points. To ensure stable execution, step S5 also includes a freeze window and a threshold control for the probability of service level agreement (SLA) default: within the freeze window, adjustments are only allowed when the probability of default exceeds the threshold, thereby avoiding operational fluctuations caused by frequent changes.

[0066] In triggering the decision, the platform calculates the overlap rate between the predicted demand interval and the capacity interval in each time window, defined as the proportion of the intersection length to the length of the predicted demand interval. When this proportion is lower than the threshold calibrated by the external validation set, it is determined that the current scheduling cannot fully cover the demand uncertainty and needs to enter the optimization solution. To ensure that the decision result is consistent with the service quality expectation, the platform evaluates the service level agreement default probability in parallel, that is, the probability of "demand exceeding capacity" in the sense of random variables. The estimation method is to use the residual calibration amount in step S3 and the capacity sample distribution in step S4 to generate demand samples and capacity samples by sampling, and calculate the proportion of samples with demand exceeding capacity as the default probability. For example, if a route's predicted demand range for a 5-minute window is between a lower bound of 60 and an upper bound of 90, and its capacity range is between a lower bound of 40 and an upper bound of 80, then the intersection of these two ranges is 60 to 80. The overlap rate is equal to the intersection length of 20 divided by the demand range length of 30, resulting in approximately 0.67. If the overlap rate threshold for this route is 0.8, optimization is triggered. Simultaneously, a sampling assessment indicates that the probability of demand exceeding capacity in this window is 0.32, while the default probability threshold within the frozen window is 0.2. Therefore, adjustments are allowed even within the frozen window. Conversely, if the overlap rate is not lower than the threshold but there is a significant positive deviation between the point-based predicted and median capacity, the route is not directly rescheduled. Instead, two options are chosen at insertable control points: vehicle waiting or short-line turnaround insertion. The better strategy is selected by comparing the magnitude of the "incremental conditional risk value," prioritizing the strategy that results in a smaller increase in the conditional risk value of waiting time.

[0067] In terms of optimization, the platform establishes a multi-objective scheduling optimization model with time windows as the basic granularity. The decision variables include at least the departure interval and number of vehicles assigned to each route within the target time window, and may also include the waiting time for vehicles at insertable control points and the number of short-line turnaround insertions. The objective function is a weighted sum of the conditional risk value of passenger waiting time and the vehicle empty-running rate. The distribution of waiting time is derived from queue approximation or simulation evaluation of the combination of demand and departure intervals; the conditional risk value is obtained through sample approximation; and the empty-running rate is derived from the ratio of vehicle mileage to passenger mileage. To handle the uncertainty of demand and travel time, the platform wraps the sample space with a Wasserstein distance-bound ambiguity set, meaning that it simultaneously optimizes the worst-case objective across all probability distributions whose distance from historical or recent sample distributions does not exceed a pre-defined radius. This explicitly avoids overfitting caused by sample randomness, ensuring that scheduling remains robust even in scenarios that are "better than average but not extreme." In terms of constraints, in addition to the number of vehicles, driver working hours, and departure intervals, the system also includes constraints on the upper limit of continuous driving time for drivers, the lower limit of mandatory rest time, the time window for returning to the depot or refueling, and the feasibility of inserting control points. Furthermore, departure interval stability constraints are added, requiring that the departure interval deviation between adjacent adjustment cycles show a convergence trend, with a convergence rate not lower than the preset stability parameter, while allowing for a limited disturbance margin to accommodate occasional fluctuations. These constraints collectively ensure that the scheme is both executable and does not fluctuate excessively frequently.

[0068] In engineering implementation, the platform uses a sample approximation method to transform the "conditional risk value" and "distributed risk value" into a computable form. The approach involves generating a set of representative scenario samples for the target time window, with each scenario given a set of demand and travel time values. Then, the corresponding waiting time and empty-running rate are calculated for these scenarios. Auxiliary variables of "threshold level and excess loss" are introduced through the standard of the conditional risk value, approximating the conditional risk value using a linear or piecewise linear method. For the Wasserstein ambiguity set, an embedded search for the "worst-case distribution" is achieved by using sample weights as variables and subjecting the total deviation to a radius constraint. If the route scale is large, the platform can adopt a decomposition and coordination solution process. First, it finds the locally optimal departure interval and number of vehicles within the route, and then performs a coordinated update at the network level based on the congestion of intersections and shared resource constraints until the overall target improvement is less than the threshold. To avoid drastic changes, the platform performs a bundled reduction of differences from the current schedule before release, prioritizing changes that significantly reduce the conditional risk value and postponing adjustments with low marginal returns to the next rolling cycle.

[0069] To facilitate understanding by those skilled in the art, a simplified numerical process is provided. Assume a route has a predicted demand of 70 points within a 5-minute window, a predicted demand range of 60 (lower bound) and 90 (upper bound), and a capacity range of 40 (lower bound) and 80 (upper bound), with an overlap rate of approximately 0.67, less than the threshold of 0.8. The sampled service level agreement (SLA) default probability is 0.32, higher than the threshold of 0.2, meeting the opening conditions. Therefore, the platform includes this time window in its optimization. Within this window, the departure interval to be optimized is selectable between 4 and 8 minutes, the maximum number of vehicles is 14, and the maximum number of available drivers is 13, resulting in a maximum of 13 effective vehicles. A representative set of scenarios is used for sample approximation. For each scenario, a demand value and average travel time are given. The platform calculates the waiting time distribution and empty-running rate corresponding to different departure intervals and vehicle allocations under this set of scenarios, and extracts the average excess at the high quantile using the definition of risk value to obtain the waiting risk. Then, the waiting risk and empty-running rate are weighted, and the weights are used to... From the external parameter table, the solver's update suggestions might be to tighten the departure interval from 7 minutes to 6 minutes, while increasing the number of vehicles from 12 to 13. If driver shifts allow, this will take effect immediately. If some scenarios show that inserting a short-line turnaround can significantly reduce the risk of specific congested sections, then insert one short-line turnaround at the insertable control point and fine-tune the vehicle waiting time to the tens of seconds level. If comparing the incremental conditions for "vehicle waiting" and "short-line turnaround," the former reduces the risk by 3, while the latter reduces it by 5, then the latter will be adopted. Upon deployment, the platform issues a "execute upon reaching the next insertable control point" instruction to all vehicles to ensure that the adjustment is aligned with vehicle position events and avoids execution chaos caused by hard cuts mid-journey.

[0070] Regarding freezing and rollback, the platform enters a pre-set freeze window after each new schedule is released. Within this window, optimization and release are only permitted again if the probability of service level agreement (SLA) default, calculated based on the latest predicted demand and capacity ranges, exceeds a threshold. Otherwise, evaluation is postponed until the first rolling moment after the freeze window ends. To ensure long-term stability, the platform continuously tracks and verifies key parameters used for optimization: the overlap rate threshold and Wasserstein radius are periodically checked according to the risk-stability trade-off curve of the external validation set. If recent coverage or oscillation indicators deviate from the target, the threshold or radius is adjusted appropriately. The departure interval stability parameter and the freeze window length are also adjusted annually or quarterly based on the seasonal changes in network layer congestion.

[0071] In terms of results implementation and auditing, the platform records the triggering results, default probability, departure intervals and number of vehicles before and after optimization, the selection and rationale for vehicle control and short routes, the tightness of the objective function and various constraints, as well as the sample set and parameter version used for each time window, for review and compliance verification. Thus, step S5, with its closed loop of "overlap rate determination—default probability gate—multi-bar optimization—position event alignment execution," stably transforms uncertain predictions into executable, traceable scheduling adjustments with risk control capabilities, providing a solid foundation for subsequent execution monitoring and rolling iterations.

[0072] It should be noted that the departure interval stability constraint requires that the departure interval deviation decreases exponentially in adjacent adjustment cycles, with the rate of decrease not lower than the preset first stability parameter, and the disturbance margin not exceeding the preset second stability parameter.

[0073] In this embodiment, step S6 is described in detail. In one embodiment, the purpose of step S6 is to reliably issue the scheduling adjustment results generated in step S5 in a location-driven manner and strictly align them with the timing of vehicles arriving at the "interceptable control point" for execution. This safely converts instructions such as "calculated departure interval and vehicle allocation adjustment, vehicle waiting time, and short-line turnaround insertion times" into operable actions at the driver and vehicle levels. To this end, the central dispatch platform continuously maintains high-frequency subscriptions to vehicle locations, geofence matching of control points, lifecycle management of instructions, and execution feedback loops. At the same time, it marks the scheduling instructions and vehicle execution status for the target time period in real time on the electronic map interface, ensuring that dispatchers and the system can understand and intervene in the execution process in the same spatial and temporal context. Before issuing any scheduling instruction, the platform binds it to a specific key space and preconditions. The minimum binding includes route identifier, trip identifier or subsequent relay trip identifier, target time window, insertable control point identifier, and version number. It also sets the effective start and end times and idempotency flag so that the same vehicle will only be executed once if it is repeatedly collected due to network jitter or retransmission. The instruction also carries the condition that "it can only be executed if the current scheduling version and the trip_id carried by the vehicle are consistent with the version of step S5 and the freeze window is outside or the probability of default exceeds the gate", which fundamentally avoids the risks of "old instructions overriding new schemes" and "false triggering of the freeze period".

[0074] In determining the "vehicle location and control point arrival event", the platform uses a combination of geofencing and time, speed, and orientation rules to determine arrival. The control point fence radius is 20-50 meters depending on the station and road segment environment. After the vehicle's GNSS message arrives, the platform first calculates the distance between the point and the control point center using WGS84 coordinates. Then, it uses "speed less than a threshold (e.g., 5km / h), orientation in a serviceable sector, and the time interval between the most recent message arrivals less than 3 seconds" as secondary filtering conditions to avoid false arrivals caused by high-speed vehicle crossings or positioning drift. When all conditions are met, an "arrival event" is generated. The platform immediately pops up an operation card on the vehicle's driver terminal, displaying clear instructions such as "wait for X seconds" or "execute a short-line turnaround to station Y and then re-enter the main line". At the same time, the event and instructions are highlighted on the map interface. To ensure on-site executability, all instructions are accompanied by a "latest execution time" and an "overtime degradation strategy." For example, the vehicle waiting time is set to a latest execution time of 90 seconds and a minimum execution time of 30 seconds. If the vehicle has not started execution by the latest execution time, the instruction is automatically invalidated and the vehicle is included in the next control point for re-evaluation. If a short-line turnaround insertion cannot be executed at the current control point due to road conditions or safety restrictions, it will automatically revert to the suboptimal control point according to the preset alternative control point table or use an equivalent amount of vehicle waiting time.

[0075] In the "command issuance and receipt" chain, the platform prioritizes using low-latency message channels (such as MQTT over TLS) for proactive push, and uses HTTPS as a compensation channel for polling and retrieval to ensure delivery within seconds even in weak network conditions. Each command requires the driver to return a receipt within 2 seconds, and to return an "execution start" event upon commencement and an "execution complete" event upon completion. The platform uses this to calculate end-to-end execution latency and on-site compliance. To ensure idempotency and replayability, both commands and receipts carry a globally unique command_id and an incrementing version number. The driver only responds to commands with a version number not less than the latest known version. The platform marks lower-version receipts as "expired receipts" and ignores their impact on the global state. If no receipt is received for two consecutive reporting cycles, the platform will retry according to the exponential backoff strategy. If the third retry still fails, the vehicle will be marked as "link abnormal" and manual intervention will be prompted on the map interface and the dispatch screen. At the same time, a "regional replacement instruction" will be triggered to reduce the risk of local congestion caused by the vehicle's failure to execute.

[0076] Regarding the specific actions of "position alignment execution," the vehicle waiting instruction displays a countdown and an "early termination / release" button on the driver's end. Early termination is only allowed under the premise that "the estimated congestion level at the next station is below the threshold and the departure interval stability constraint will not be violated." The short-line turnaround insertion instruction provides the "turnaround terminal station" and "access station for rejoining the main line" on the driver's end, and the route display is updated simultaneously on the electronic road signs and station announcement system. The passenger information system also issues a temporary route change notice to reduce the risk of boarding the wrong vehicle. For instructions related to "departure interval and number of vehicles," the platform does not directly cut off the vehicle en route. Instead, it takes effect only after the vehicle arrives at the control point and meets the condition that "the current departure interval deviation is within the allowable disturbance margin," thus maintaining consistency with the "departure interval stability constraint" in step S5. If the current deviation is too large, to avoid further exacerbating the fluctuations, the platform delays execution by one or two control points and displays "delayed execution" in different colors on the map interface.

[0077] Regarding the linkage between "driver shifts and safety compliance", any instruction involving "increasing the number of vehicles or extending the operating range" must be linked with driver working hours and mandatory rest constraints. The platform has already performed a consistency check when generating the instruction, but it will still check again when executing the instruction at the location to see if "the remaining driving time is sufficient to cover the time required by the instruction". If it is insufficient, it will automatically reassign the nearest backup vehicle or shorten the insertion length. When the vehicle is an electric bus and the remaining battery power is below the threshold, the short-line turnaround insertion will be replaced by vehicle control waiting or direct release to the refueling station. The platform will give a clear mark of "refueling replacement" on the map interface to avoid dispatchers misjudging it as not being executed.

[0078] In terms of "Execution Monitoring and Closed-Loop Evaluation," the platform continuously tracks four types of indicators for each issued instruction: delivery success rate, delay from receipt to execution start, execution completion time, and real-time marginal contribution to the objective function (weighted sum of waiting time conditions, risk level, and empty running rate). The marginal contribution is estimated by subtracting the counterfactual queue approximation or micro-simulation results of "unexecuted instructions" from the real-time observations of "executed instructions" under the same time window and local network conditions, and then weighting it according to the weights in step S5. When multiple consecutive control point observations show that the marginal contribution of a certain type of instruction is below the threshold, the platform automatically reduces the priority of that type of instruction in subsequent rolling cycles until it is restored after retraining or parameter review. All key events in the execution process, including "arrival at control point, instruction push, receipt of acknowledgment, execution start, execution completion, expiration and invalidation, and alternative execution," are written into the audit log, carrying vehicle, route, control point, timestamp, location, and version number, to ensure complete post-event review.

[0079] Regarding "manual intervention and conflict handling," the platform allows dispatchers to manually cover individual vehicles or entire routes on the map interface. Manual coverage instructions have the same preconditions and idempotency mechanisms as system instructions, but a reason code and validity period must be filled in. The platform incorporates manual coverage into the same audit chain and uses it as a "fixed boundary condition" in the rolling optimization process to participate in the next round of decision-making, preventing the system from rolling back manual handling in the next cycle. If there are two mutually exclusive instructions for the same vehicle within the same time window, such as "control vehicle waiting" and "immediate short-line turnaround," the platform will decide according to a three-tier rule of "priority of decrease in probability of default, priority of minimum stability disruption, and priority of execution feasibility." When both scores are the same and time is tight, the default choice is to control vehicle waiting to reduce execution complexity, and then the need for a short-line turnaround will be reassessed at the next control point.

[0080] Regarding "abnormalities and rollbacks," when a vehicle malfunctions before reaching a control point or fails to arrive as planned, the platform immediately removes the vehicle from the current execution queue and triggers a "nearby vehicle substitution" strategy. This involves selecting candidate vehicles that meet the schedule and power constraints within a range of 2-3 adjacent control points and issuing equivalent instructions. If no substitute vehicle is available in the area, the platform raises the expected waiting risk warning level for adjacent stations and provides network-level cross-line vehicle borrowing suggestions. All suggestions are displayed to the dispatcher for confirmation in the form of a map overlay. To ensure system robustness, the platform initiates a configurable-length freeze window after each batch release. During this period, unless the probability of service level agreement (SLA) default calculated based on the latest predicted demand range and capacity range exceeds a threshold, no new instructions will be repeatedly issued for the same vehicle and the same control point. After the freeze window ends, the platform summarizes the execution results of the previous cycle at the first rolling moment and compares them with the target coverage and oscillation indicators. If necessary, it fine-tunes the overlap rate threshold and Wasserstein radius used in step S5 and synchronizes the new parameter version to S6 for the next round of execution judgment.

[0081] Through the above process, step S6 connects "location event triggering, conditional activation, idempotent issuance, and closed-loop evaluation" into a reproducible execution chain, enabling the multi-objective scheduling optimization results of step S5 to be accurately implemented the moment the vehicle actually arrives at the insertable control point, and to be recorded throughout the process in the map interface and audit system. This ensures that the departure interval stability constraints and service level objectives are followed on-site, and also provides high-quality execution feedback and data support for the rolling optimization of the next cycle.

[0082] For ease of understanding, a specific implementation example is given in this embodiment. A certain city's bus route R45 (12.6 km one-way distance, 24 stops along the route, with priority service during weekday morning rush hour 07:00-09:00) is selected as the pilot project. The system uses 60 seconds as the uniform time granularity and "route identifier, trip identifier, station or road segment identifier, and time window start time" as the primary key throughout steps S1 to S6. The fleet has 14 vehicles assigned to this route, with 13 qualified drivers, and a maximum passenger capacity of 80 per vehicle. To verify the effectiveness of the method under strong disturbance scenarios, the time window of 07:30-07:35 on September 11, 2025, is selected as the core window. During this period, a large-scale event is scheduled at the nearby sports center at 08:00, and the venue area overlaps with three adjacent stops on R45.

[0083] First, in step S1, the central dispatch platform accesses five types of multi-source data via dual channels of MQTT over TLS and HTTPS. Vehicle positioning is transmitted from the vehicle-mounted GNSS every 1 second, and after passing through the access gateway, it is written into the time series database and object storage; real-time passenger flow data is transmitted by the IC card front-end machine to transmit card swipe events, and the vehicle-mounted APC transmits boarding and alighting counts every 5 seconds within the door opening and closing window; road condition data is provided by the urban traffic management platform every 60 seconds, including average road segment speed, free flow speed, and congestion index; meteorological data is provided by the gridded interface every 5 minutes, including temperature, precipitation, wind speed, and weather code; temporary event data is created by the municipal event platform 12 hours before the event and updated again 90 minutes before the event starts, and includes the event type "stadium_event", the impact polygon, and the severity "high". The platform retains the source timestamp and the platform receiving timestamp for all records, calculates the receiving delay as a monitoring indicator, and does not change any business values. At the same time, it constructs a unique key using "source identifier, device or vehicle identifier, source timestamp, and sequence number" to remove duplicate reports and writes the reason for rejection into the dead letter pool.

[0084] In step S2, the platform performs deduplication, regularization, and anomaly marking on the five types of data, and aligns them according to a 60-second time window. Vehicle positioning uses constant-speed linear interpolation to fill gaps within the window and performs nearest segment matching on the road network map to obtain the average speed and congestion index of each segment within the time window. Real-time passenger flow is accumulated in 60-second increments within the door opening and closing window, and the card swipe and APC sources are weighted and merged according to quality score and reception delay. If both sources are available simultaneously and the device is healthy ("good") within the window with a reception delay of less than 1 second, the card swipe weight is 0.3 and the APC weight is 0.7. Historical passenger flow is calculated using multi-year samples with the same "route-station-weekday type-time period". The expected value and quantiles are used as filler values ​​for completely missing measurement windows on that day. Meteorological data are allocated according to the length proportion of the line geometry in each grid, forming line-level temperature and precipitation vectors. Temporary events are mapped to event impact intensity indices, with severity levels of low, medium, and high mapped to 0.3, 0.6, and 0.9 respectively. If the geometric center of the station is within the event polygon, the distance decay is 1; otherwise, it decays by 0.1 every 500 meters, up to a maximum of 0 after 5000 meters. The overlap ratio between the window time and the event validity period is multiplied as a time factor. Within the core window of 07:30-07:35, the station on the Sports Center side is located within the event polygon and falls completely within the validity period, resulting in an event impact intensity index of 0.9. For standardization, continuous features are linearly scaled to the 0-1 interval according to the 1st to 99th quantiles of the past 90 days, and categorical features use a unified coding table. Ultimately, the platform assembles elements such as "historical baseline, real-time boarding and alighting, road segment speed and congestion, temperature and precipitation, event impact intensity, reception delay and quality score" into a fusion feature vector for this key. To improve adaptability over time, the platform deploys an online multi-arm gambling machine that adaptively selects among three sets of candidate weights: weight group A emphasizing real-time passenger flow, weight group B emphasizing road conditions and location, and weight group C emphasizing history and weather. The reward signal is a weighted sum of "the decrease in demand forecasting error and the improvement in scheduling stability index," and Thompson sampling is used to update the propensity.

[0085] Next, in step S3, the platform trains and publishes a demand forecasting model using a rolling window of the past 28 days. The features are the aforementioned fusion vector and its multi-scale lag and rolling statistics, with the target variable being short-term travel demand within a 60-second window. During inference, the model outputs a predicted point of 72 for the 07:30-07:35 window. Based on consistent prediction calibration, the platform calculates the residual quantiles on the hierarchical sliding calibration set, with a standard coverage target of 90, corresponding to a two-sided quintile expansion to obtain the interval [62, 90]. Since the event impact intensity index for this window is 0.9, exceeding the threshold of 0.8 for "severe weather or large-scale events," the platform adjusts the hierarchical coverage target to 95 according to the external parameter table, and simultaneously adjusts the confidence level of the conditional risk value in step S5 to 0.95. Thus, the predicted demand interval for this window expands to [58, 94]; the physical upper bound, after being pruned according to "80 per vehicle and the maximum number of vehicles that can be served within the window," remains 94.

[0086] In step S4, the platform generates 5000 capacity samples using the Monte Carlo method. Vehicle availability is sampled at a probability of 0.95 per vehicle and driver availability at a probability of 0.97; the smaller of the sum of these two is the effective number of vehicles in this sample. Road segment travel time is independently sampled based on the speed distribution from step S2, and a round-trip travel time sample is obtained by overlaying an average 20-second stop at each station and a 180-second turnaround buffer. This sample is divided by the effective number of vehicles to form the sample-level average departure interval. A 5-minute window is used to assist in statistically analyzing the "number of times a vehicle can be started," which is then multiplied by 80 to obtain the carrying capacity sample. The sample distribution of this core window exhibits a two-point discreteness of "0 times and 1 time" on a 5-minute scale. Taking the 10th quantile as 0 and the 90th quantile as 80, the capacity range [0, 80] is obtained. During write-back, the sample mean, sample median, number of samplings, and parameter version are simultaneously saved.

[0087] In step S5, the platform calculates the overlap rate between [58,94] and [0,80]. The intersection is [58,80] with a length of 22. The demand interval length is 36, and the overlap rate is approximately 0.611, which is lower than the threshold of 0.8, requiring optimization. Simultaneously, joint sampling is performed using demand and capacity samples, estimating the probability of "demand exceeding capacity" to be 0.32. The default threshold for the frozen window is 0.2, thus allowing optimization within the frozen window. The multi-objective scheduling optimization model uses the weighted sum of "waiting time conditional risk value (confidence level 0.95) and empty-running rate" as its objective, with weights of 0.7 and 0.3 respectively. The Wasserstein distance radius is 0.12 (calibrated from the risk-stability trade-off curve of the external validation set). Decision variables include departure interval and number of vehicles assigned, and the platform allows selection of "vehicle waiting time or short-line turnaround insertion number" on the control point candidate set. The constraints include a maximum of 14 vehicles, a maximum of 13 available drivers, a maximum of no more than the legal limit for continuous driving, a minimum of no less than the legal limit for mandatory rest, and the feasibility of the return-to-depot or refueling time window and control point. Simultaneously, a departure interval stability constraint of "exponential decay + disturbance margin" is applied: the departure interval deviation between adjacent adjustment cycles is denoted as... ,Require λ is not less than the first stability parameter of 0.5. The second stability parameter should not exceed 30 seconds. The solution shows that the core window reduces the departure interval from 7 minutes to 6 minutes and increases the number of vehicles from 12 to 13. It is also recommended to insert a short-line turnaround at control point CP-3 west of the Sports Center to reduce peak traffic. Comparing the incremental conditions of "60-second vehicle waiting time" and "one short-line turnaround," the former reduces the risk by 3, while the latter reduces it by 5. Therefore, the short-line turnaround scheme is adopted. To avoid network layer fluctuations, low-yield fine-tuning was reduced before release, retaining only the two changes that contribute most to the risk factor.

[0088] Finally, in step S6, the platform binds the above instructions with "route, trip, control point, version, effective period, and idempotency identifier," and executes them under the trigger condition of "vehicle arrival at control point event." The arrival event is determined by a combination of rules: a geofence radius of 30 meters, a speed threshold of 5 km / h, and an orientation sector with a message interval of less than 3 seconds. At 07:31:20, vehicle B1203 enters the CP-3 fence and meets the secondary conditions. The driver's terminal displays an operation card that says "Short-line turnback to S9040 and then back to the main line," requiring a receipt within 2 seconds. The receipt is successfully received within 0.6 seconds. At 07:31:35, "Execution Start" is returned, and at 07:34:50, "Execution Complete" is returned. The electronic road sign and passenger information system simultaneously display the temporary change. At the same time, another vehicle, B1207, arrives at CP-2 and receives a pending instruction to "tighten the departure interval to 6 minutes." However, because the current interval deviation exceeds ε, the platform delays execution by one control point and highlights "Delayed Execution" on the map interface. Throughout the window, the command delivery success rate was 1.0%, the median delay from receipt to execution start was 1.3 seconds, and no link anomalies or backoffs occurred. Execution closed-loop statistics show that the estimated sample of "demand exceeding capacity" within this 5-minute window decreased from 0.32 to 0.14, the waiting time condition risk level decreased by 22%, and the empty-running rate increased by 3 percentage points but remained below the line's upper limit. During the subsequent 30-minute rolling observation period, the service level agreement (SLA) default rate of the three adjacent stations at the Sports Center decreased by 41% compared to the baseline without intervention, and the fluctuation range (standard deviation) of departure intervals decreased by 37% compared to the alternative without stability constraints. This indicates that the link structure of "interval overlap triggering + Wasserstein split bar + condition risk level + location event aligned execution" achieved the goal of "significantly reduced risk while maintaining stability" under strong disturbance scenarios. After the window ends, the platform enters a freeze period, and only triggers the next round of optimization when the latest prediction shows that the probability of default is higher than 0.2 again. At the same time, an external validation set is used to review the overlap rate threshold and Wasserstein radius used in this test. The indicators are within acceptable range and no parameter fine-tuning is triggered.

[0089] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A bus intelligent scheduling method based on multi-source data fusion, characterized in that, The method comprises the following steps: Step S1, multi-source data collection: receiving and storing bus operation related multi-source data by a central scheduling platform, the multi-source data including historical passenger flow data, real-time passenger flow data, vehicle positioning and road condition data, weather data and temporary event data; Step S2, feature level fusion processing: performing data cleaning, standardization and missing data completion on the multi-source data of step S1 to obtain a fusion feature data sequence; Step S3, intervalized travel demand prediction: inputting the fusion feature data sequence into a calibrated demand prediction model to obtain travel demand point prediction and corresponding prediction demand interval of a target period, the upper and lower bounds of the prediction demand interval being obtained through consistency prediction calibration on a sliding calibration set; Step S4, capacity interval description of transport capacity: based on vehicle availability, driver shift, maximum passenger capacity of a single vehicle and speed distribution of a road section, a transport capacity interval of a target period is constructed, the transport capacity interval being represented by its lower bound and upper bound; Step S5, overlap rate triggering and distribution robust scheduling optimization: calculating the overlap rate between the prediction demand interval and the transport capacity interval, the overlap rate being defined as the proportion of the intersection length of the two to the length of the prediction demand interval; when the overlap rate is less than a preset threshold, a distribution robust multi-objective scheduling optimization model is solved to update the departure interval and the number of vehicles of the target period, wherein the robustness ambiguity set is defined by a preset Wasserstein distance radius, the objective function is the weighted sum of the conditional value at risk of passenger waiting time and the empty running rate, and the constraints include vehicle quantity constraint, driver work hour constraint, departure interval constraint and insertable control point constraint determined by vehicle positioning and road condition data; Step S6, location driven execution: issuing the scheduling instruction obtained in step S5 to the central scheduling platform, and performing scheduling adjustment according to the vehicle positioning and control point arrival event. 2.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The temporary event data is mapped to an event influence intensity index in step S2, the event influence intensity index is calculated by diffusion according to the event influence range, start and end time, historical amplification coefficient and the topological relationship between bus stops and lines, and is used as a component of the fusion feature data sequence to participate in steps S3 and S5; when the event influence intensity index reaches the severe weather level or the large event level, the confidence level of step S3 is triggered to be adaptively adjusted, and the confidence level used in the conditional value at risk calculation is improved accordingly. 3.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The fusion weight of step S2 is adaptively updated by an online multi-armed bandit algorithm, the immediate return is defined as the weighted result of the decrease of travel demand prediction error and the improvement of scheduling stability index, so as to realize the weight self-calibration of the fusion feature data sequence in continuous periods.

4. The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The consistency prediction calibration of step S3 is implemented on a hierarchical sliding calibration set divided according to weather level and period type, and coverage constraints are set for each hierarchy to ensure the marginal coverage rate of the prediction demand interval is consistent under different scenarios.

5. The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The capacity interval of the step S4 is obtained by estimating the capacity distribution using Monte Carlo samples jointly generated by the vehicle availability Bernoulli variables and the mixed distribution of link speeds, and taking the lower quantile of the distribution as the lower bound of the capacity interval and the upper quantile as the upper bound of the capacity interval. 6.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The distribution robust multi-objective scheduling optimization model of the step S5 contains vehicle number constraint, driver work time constraint and departure interval constraint, as well as driver continuous driving time upper limit constraint, mandatory rest time lower limit constraint and warehouse returning or energy supplement time window constraint; meanwhile, the departure interval stability constraint is contained, which requires the departure interval deviation to be exponentially attenuated within adjacent adjustment periods, with an attenuation rate not lower than a preset first stability parameter and a disturbance allowance not exceeding a preset second stability parameter. 7.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, The dynamic adjustment of the step S5 sets a freeze window before execution, and only allows further adjustment when the service level agreement violation probability determined based on the predicted demand interval and the capacity interval exceeds a threshold within the freeze window, so as to suppress the operation shock caused by frequent changes. 8.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, In the distribution robust multi-objective scheduling optimization model of the step S5, the Wasserstein distance radius and the overlap rate threshold are calibrated offline and reviewed regularly according to the risk and stability trade-off curve of the model external validation set, so as to ensure the consistency of scheduling effect and stability within the rolling period. 9.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, When the overlap rate is not lower than a preset threshold but there is a positive deviation of the travel demand point prediction relative to the median capacity of the capacity interval, the central scheduling platform preferentially implements one of the vehicle control waiting or short-line U-turn insertion at the insertable control point, and the strategy selects according to the principle of minimum at-risk value under incremental conditions. 10.The bus intelligent scheduling method based on multi-source data fusion according to claim 1, characterized in that, In the step S6, the central scheduling platform labels the scheduling instructions and vehicle execution status of the target period on the electronic map interface in real time according to the vehicle positioning and road condition data, and issues execution instructions when the vehicle arrives at a preset insertable control point.

Images