Bus automatic driving method and system

Abstract

The invention provides a bus automatic driving method and system, and relates to the technical field of intelligent public transportation, passenger flow prediction is carried out on a target area, route planning is carried out according to a passenger flow prediction result, and a bus operation baseline is constructed; collecting travel reservation requests of users, performing spatial-temporal clustering analysis, and constructing a travel demand cluster; and performing scheduling decision analysis on the travel demand cluster and the candidate vehicle information, establishing a bus scheduling strategy, issuing and executing the strategy, receiving a real-time travel request of a user, performing matching analysis on the real-time travel request and the initial running path, and performing dynamic insertion updating on the initial running path according to an analysis result. The technical problems of low scheduling efficiency and resource waste caused by the fact that personalized and decentralized travel requirements cannot be responded in time due to fixed lines and scheduling response lag in the prior art are solved, and the technical effects of improving the bus travel service matching rate and enhancing the operation flexibility and the resource configuration efficiency are achieved.

Description

Technical Field

[0001] This application relates to the field of intelligent public transportation technology, specifically to a method and system for automated bus driving. Background Technology

[0002] With the development of intelligent transportation technology, automated driving of buses is gradually becoming an important development direction for urban public transportation. To achieve efficient operation of automated buses, reasonable route planning and scheduling strategies are crucial.

[0003] Currently, the planning of autonomous driving bus routes mainly adopts a fixed route model, which involves operation control and timetable execution based on pre-set routes and stops. However, in actual operation, personalized travel demands are becoming increasingly prominent, especially during off-peak hours, in areas with insufficient coverage by regular public transportation, and in scenarios such as connections between industrial parks and communities, where passenger travel is characterized by fragmented time and dispersed space.

[0004] Existing autonomous driving route planning methods, when faced with these personalized travel demands, lack the ability to generate dynamic routes and schedule in real time. This results in an inability to respond promptly to widely distributed and time-sensitive ride requests, which can easily lead to problems such as high empty running rates, wasted capacity, and decreased service quality. Summary of the Invention

[0005] This application provides a method and system for automated bus driving, which solves the technical problem that existing technologies, due to fixed bus routes and delayed dispatch response, cannot respond to personalized and decentralized travel demands in a timely manner in low-density areas or during peak periods, resulting in low capacity dispatch efficiency and resource waste. It achieves the technical effect of improving the matching rate of public transport services and enhancing the operational flexibility and resource allocation efficiency of the public transport system.

[0006] In view of the above problems, this application provides a method for automated bus driving, the method comprising: collecting historical passenger flow data of a target area and synchronizing it to a passenger flow prediction model for passenger flow prediction, obtaining passenger flow prediction results, planning routes based on passenger flow prediction results, and constructing a bus operation baseline including multiple stops; collecting user-submitted reservation travel requests through an interactive client, performing spatiotemporal clustering analysis on the reservation travel requests to construct travel demand clusters; performing scheduling decision analysis based on the bus operation baseline on the travel demand clusters and candidate vehicle information to establish a bus scheduling strategy including an initial operating path; after the bus scheduling strategy is sent to the automated bus driving control system for execution, receiving real-time user travel requests, performing matching analysis with the initial operating path to determine whether the bus has the conditions to respond; if the bus has the conditions to respond, dynamically inserting and updating the initial operating path based on the user's real-time travel requests, obtaining the real-time operating path and sending it to the automated bus driving control system for execution.

[0007] On the other hand, this application also provides a public transport autonomous driving system, the system comprising: an operation baseline construction module, used to collect historical passenger flow data of a target area and synchronize it to a passenger flow prediction model for passenger flow prediction, obtain passenger flow prediction results, perform route planning based on passenger flow prediction results, and construct a public transport operation baseline including multiple stops; a travel request clustering module, used to collect user-submitted reservation travel requests from an interactive client, perform spatiotemporal clustering analysis on the reservation travel requests, and construct travel demand clusters; a scheduling decision analysis module, used to perform scheduling decision analysis based on the public transport operation baseline on the travel demand clusters and candidate vehicle information, and establish a public transport scheduling strategy including an initial operating path; a real-time request matching module, used to receive user real-time travel requests after the public transport scheduling strategy is sent to the public transport autonomous driving control system for execution, perform matching analysis with the initial operating path, and determine whether the public transport has the conditions to respond; and an operating path update module, used to dynamically insert and update the initial operating path based on the user's real-time travel request if the public transport has the conditions to respond, obtain the real-time operating path and send it to the public transport autonomous driving control system for execution.

[0008] One or more technical solutions provided in this application have at least the following beneficial effects: Historical passenger flow data of the target area is collected and synchronized to a passenger flow prediction model for passenger flow forecasting. Based on the forecast results, route planning is performed, and a public transport operation baseline including multiple stops is constructed, providing spatial and temporal boundary conditions for subsequent task scheduling and route matching. User-submitted travel reservation requests are collected through an interactive client, and spatiotemporal clustering analysis is performed on these requests to construct travel demand clusters. This aggregates numerous dispersed reservation requests into several schedulable demand units, improving scheduling efficiency and route reusability.

[0009] By performing scheduling decision analysis based on the bus operation baseline on the travel demand clusters and candidate vehicle information, a bus scheduling strategy including an initial operating path is established, transforming path prediction and request clustering results into executable autonomous driving tasks. After the bus scheduling strategy is issued to the bus autonomous driving control system for execution, real-time user travel requests are received and matched with the initial operating path to determine whether the bus has the necessary response conditions. This ensures the flexibility of bus operation, allows for local path variability, and thus improves response rate and service matching degree. If the bus has the necessary response conditions, the initial operating path is dynamically inserted and updated based on the user's real-time travel request to obtain the real-time operating path, which is then issued to the bus autonomous driving control system for execution.

[0010] In summary, this application establishes a dynamic response closed-loop autonomous driving bus operation system by introducing a bus operation baseline construction mechanism based on historical passenger flow data and combining it with cluster analysis of user reservation requests. This system enables intelligent prediction and construction of bus operation routes and dynamic adaptation of task scheduling, significantly improving the matching rate of public transportation services and enhancing the operational flexibility and resource allocation efficiency of the public transportation system.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating an automated driving method for public transportation provided in an embodiment of this application.

[0013] Figure 2 This is a schematic diagram of the structure of a public transport automatic driving system provided in an embodiment of this application.

[0014] Figure labeling: Operational baseline construction module 10, travel request clustering module 20, scheduling decision analysis module 30, real-time request matching module 40, and running path update module 50. Detailed Implementation

[0015] This application provides a method and system for automated bus driving, which solves the technical problems of existing technologies where fixed bus routes and delayed dispatch response lead to the inability to respond promptly to personalized and decentralized travel demands in low-density areas or during peak periods, resulting in low capacity scheduling efficiency and resource waste. The system achieves the technical effect of improving the matching rate of public transport services and enhancing the operational flexibility and resource allocation efficiency of the public transport system by matching travel requests, dynamic route planning, and automated driving control.

[0016] Example 1, as Figure 1 As shown in the figure, this application provides a method for automated driving of public transportation, the method comprising: Step S1: After collecting historical passenger flow data of the target area, synchronize it to the passenger flow prediction model to predict passenger flow, obtain the passenger flow prediction results, and plan routes based on the passenger flow prediction results to construct a public transport operation baseline that includes multiple stops.

[0017] Specifically, the target area refers to a designated public transport service area, such as an industrial park or urban area. Historical passenger flow data refers to passenger boarding and alighting behavior data recorded over a certain period (e.g., 30 days), including information such as time, stops, number of passengers, and routes. Passenger flow forecasting models are algorithmic models used to predict changes in travel demand over a future period, such as LSTM (Long Short-Term Memory) and ARIMA (Autoregressive Moving Average). The public transport operation baseline refers to a reference route for public transport operation generated based on forecasts, including information such as several stops, operating hours, and estimated service capacity.

[0018] Historical passenger flow data within the service area is collected through cloud or local platform interfaces. This data is cleaned and spatiotemporally reconstructed before being input into a passenger flow prediction model. The model combines time dimensions (e.g., morning rush hour, weekends), spatial dimensions (boarding / alighting heatmaps), and auxiliary information (e.g., holidays, weather) to model and output the boarding / alighting demand and OD (Original Demand) matrix for each area within a future prediction period. Based on this prediction result, high-frequency boarding / alighting points are extracted, and spatial clustering algorithms (e.g., DBSCAN) are used to generate several candidate station groups. Then, based on the OD matrix, bus routes with high service potential are planned, forming a bus operation baseline. This bus operation baseline, as the service path baseline constructed before buses enter operational status, possesses stability and dynamic evolution capabilities, serving as the basis for subsequent vehicle task scheduling and real-time travel request insertion strategy execution.

[0019] For example, in a certain technology park, by analyzing the bus card swipe data over the past two weeks, it was found that the OD passenger flow from community A to factory C accounted for more than 30% between 7:00 and 9:00 in the morning. Based on the passenger flow analysis, it was decided to construct a bus operation route of "stop A1—A2—B1—C1" and mark it as peak bus route 1.

[0020] Step S2: The interactive client collects the travel reservation requests submitted by users, performs spatiotemporal clustering analysis on the travel reservation requests, and constructs a travel demand cluster.

[0021] Specifically, the client refers to the user's booking portal, such as a mobile app, mini-program, webpage, or touchscreen terminal. A travel booking request is a passenger's intention to travel from point A to point B at time X, including pick-up and drop-off points, travel time, and number of passengers. A travel demand cluster refers to a group of booking requests with similar departure points, destinations, and time periods, facilitating batch scheduling.

[0022] After receiving multiple booking requests through the client data interface, the system first performs data standardization (such as geographic coordinate transformation and timestamp normalization), and then processes the requests in batches according to time windows (such as 15 minutes) and spatial distribution. Requests within the same time period are then filtered by path mapping to ensure they can be served by the current operational baseline. A similarity matrix is ​​constructed by calculating directional consistency (angle between OD vectors) and path overlap. Finally, a clustering algorithm (such as DBSCAN based on similarity) is used to form travel demand clusters. For example, if 10 passengers book trips from different neighborhoods in area A to area B between 8:00 and 8:10, with pick-up points no more than 300 meters apart and expected arrival times in area B similar, these 10 requests are merged into a "morning peak AB-direction travel cluster" as a single service target.

[0023] By constructing travel demand clusters, spatial compression and temporal aggregation of travel requests are achieved, improving the controllability of subsequent scheduling and path reuse rate, and providing structured input for batch task generation.

[0024] Step S3: Perform scheduling decision analysis based on the public transport operation baseline on the travel demand cluster and candidate vehicle information, and establish a public transport scheduling strategy including the initial running path.

[0025] Specifically, candidate vehicle information refers to the information of autonomous buses currently in a dispatchable state, including their location, capacity, battery level, and idle time. The initial operating path is the first complete service path assigned to a vehicle, which is a fine-tuned path based on the vehicle's operational baseline, taking into account the number of vehicles, service hours, and travel demand. The bus dispatch strategy is a plan used to schedule the operation of autonomous buses, including information such as vehicle ID, task cluster, path, and estimated start and end times.

[0026] Based on the path segments, service windows, and number of passengers required for each travel demand cluster, the status and operational capacity of all candidate vehicles are evaluated, including the distance between the current location and the pick-up point, whether the available time matches, and whether the remaining capacity is sufficient. A suitability scoring matrix is ​​used to calculate the matching priority between vehicles and travel demand clusters, the optimal combination is selected to construct a scheduling strategy, and an initial path containing the station sequence, stop time, and execution instructions is generated. For example, cluster C1 needs to depart from station A at 8:00, covering the path A—B—C, for a total of 15 passengers; among the available vehicles, V02 is near A with a capacity of 20 passengers and is idle; V03 has available seats but is in zone E, too far away to reach in time. Therefore, V02 is selected, a running path is generated, and a scheduling strategy is issued.

[0027] This step enables resource matching from demand clusters to task execution, ensuring that the most suitable vehicle completes the most suitable task, effectively improving scheduling efficiency and reducing vehicle empty running rate.

[0028] Step S4: After the bus dispatch strategy is sent to the bus automatic driving control system for execution, the system receives real-time travel requests from users, performs matching analysis with the initial running path, and determines whether the bus has the conditions to respond.

[0029] Specifically, the autonomous driving control system is the onboard driving control module of the bus, responsible for executing the route instructions issued by the system, including route navigation, stop at stations, and acceleration and braking control. Real-time travel requests refer to immediate travel needs submitted by users outside of pre-booked time slots.

[0030] The dispatching platform packages the bus dispatching strategy and sends it to the bus autonomous driving control system via the communication module, triggering automatic driving, stopping, and passenger pick-up / drop-off processes. During autonomous driving operation, the cloud platform receives new temporary travel requests in real time and then determines whether these requests can be inserted into the current vehicle path. First, it extracts the pick-up / drop-off point and request time of the request, compares it with the station sequence in the current vehicle path, and determines whether there is a spatial match (whether the station is on the path or accessible by offset). Then, it determines whether the direction is consistent (whether the pick-up point is earlier than the drop-off point). Next, it assesses whether the estimated response time between the vehicle's current location and the pick-up point meets the passenger waiting limit (e.g., ≤10 minutes). Finally, it determines whether there is enough space inside the vehicle to accommodate the requesting passengers. If all conditions are met, the bus is considered to be ready to respond.

[0031] This step allows for dynamic improvement of vehicle passenger carrying efficiency and user service response rate without affecting task stability, thereby enhancing the flexibility of public transport operations and the user experience.

[0032] Step S5: If the bus has the necessary response conditions, the initial operating path is dynamically inserted and updated based on the user's real-time travel request, and the real-time operating path is obtained and sent to the bus automatic driving control system for execution.

[0033] Specifically, once it's confirmed that a bus can respond to a new real-time travel request (the bus is ready to respond), its current operating route needs to be adjusted. The cloud platform finds insertion points in the original route, inserts new boarding and alighting points at the most suitable locations, and recalculates the total length of the new route segment and the estimated arrival time at each stop, forming a new real-time operating route. Subsequently, this real-time operating route is sent to the vehicle's autonomous driving control system via the communication module. The control system will then adjust navigation instructions and stop plans accordingly, achieving seamless operation after route reconstruction.

[0034] The above steps enable real-time online editing of bus routes. Combined with the automatic driving control system, this allows buses to respond efficiently to temporary demands while maintaining reasonable route scheduling, further enhancing the flexible operation capabilities of buses and realizing intelligent travel services that respond to demand.

[0035] Furthermore, the method described in the embodiments of this application also includes: Step S61: If the bus does not meet the response conditions, generate a reservation request and send it to the client.

[0036] Step S62: Obtain the reservation feedback result uploaded by the client. If the reservation feedback result contains a user reservation request, add the user reservation request to the reservation request list for the next round.

[0037] Step S63: If the reservation feedback result does not contain the user's reservation request, then the task process ends.

[0038] Specifically, the reservation feedback result is a confirmation of the user's "accept" or "decline" of the reservation. The next round of reservation request list is a set of requests that have not yet been responded to by the currently running task, and will be included in the next round of request clustering and scheduling decision processing.

[0039] When it is determined that the current vehicle cannot meet the real-time travel request, the request is not rejected directly. Instead, a request mitigation mechanism is activated, transforming the request into a reservation request information with recommended parameters, which is then pushed to the client. This information includes suggested pick-up and drop-off points, estimated departure time (next departure), waiting time, etc., prompting the user whether they wish to reserve a ride. After receiving the prompt, the user can confirm "accept reservation" or "cancel ride" on the client. If the user chooses to accept, the request will be re-encoded into a standard reservation request, added to the next round of reservation request list, and enter the next clustering and scheduling process; if the user chooses to cancel, the request is marked as "processing completed" and will not enter the subsequent scheduling process.

[0040] The above steps enable flexible handling of unresponsive requests, preventing service failures due to temporary resource unavailability. Through two-way feedback between the client and the platform, user engagement is improved, and unmet travel intentions are appropriately guided to subsequent scheduling rounds, thereby enhancing overall response coverage and scheduling success rate.

[0041] Furthermore, step S1 in the embodiments of this application includes: Step S11: Divide the target area into multiple grid areas according to a preset scale, collect historical passenger flow data of multiple grid areas, input the data into the passenger flow prediction model for time series analysis, and obtain passenger flow prediction results. The passenger flow prediction results include the expected passenger flow for boarding and alighting in each grid area within the prediction time window and the OD correlation matrix.

[0042] Step S12: Based on the passenger flow prediction results, extract high-frequency travel points that meet the preset boarding and alighting frequency thresholds.

[0043] Step S13: Perform hierarchical clustering according to the spatial location of the high-frequency travel points to obtain multiple candidate station groups.

[0044] Step S14: Take the center point of each of the multiple candidate station groups as candidate stop stations, and construct the bus operation baseline by combining the OD correlation matrix.

[0045] Specifically, the OD correlation matrix is ​​a matrix representation of the projected passenger flow from one region (origin) to another region (destination). First, the target service area is divided into multiple grids according to a set scale (e.g., 100m×100m, 500m×500m), with each grid representing a geographic service unit for refined spatial analysis.

[0046] Then, the historical passenger flow database is accessed to extract historical passenger flow data for each grid across multiple time windows, including boarding and alighting times, boarding and alighting station locations, and route information. This historical passenger flow data is then input into the prediction model. The model combines historical trends, holidays, weather, and other features to perform time series modeling, outputting the predicted boarding and alighting volume for each grid within a future time period, and further forming a complete OD correlation matrix for analyzing inter-regional relationships and route orientation.

[0047] Based on passenger flow forecasts, statistical analysis is performed on boarding and alighting frequencies in all grid areas. Boarding and alighting frequency thresholds are set (e.g., boarding frequency ≥ X times / day, alighting frequency ≥ Y times / day). All grid points that meet these boarding and alighting frequency thresholds are extracted and recorded as high-frequency travel points. These grid points have the potential to be used as stations.

[0048] High-frequency travel points are spatially clustered based on their latitude and longitude coordinates. A hierarchical clustering method is used to construct the spatial distribution structure. Points that are close to each other and have a certain overlap radius are merged into a candidate station group, resulting in multiple candidate station groups. Multiple high-frequency points within each candidate station group share travel directionality or spatial proximity, providing a zoning reference for subsequent station setting.

[0049] The centroid coordinates of each candidate station group are calculated as the location of the candidate stop. Then, the OD correlation matrix is ​​used to analyze the high-frequency travel directions between these stations (such as A-B-C forming a trunk line). A directed graph is constructed with travel intensity as the weight, and the bus operation route structure is generated based on the optimal path of the graph (such as maximum flow or shortest path). The final output is a bus operation baseline that includes multiple stop stations, station order, and expected operating time.

[0050] The above steps, through passenger flow prediction and station selection based on boarding and alighting frequency, ultimately determine the bus operation baseline, providing structural support for subsequent scheduling and dynamic adjustments.

[0051] Furthermore, step S2 in this embodiment includes: Step S21: Receive the original travel reservation request from the client based on the advance reservation constraint, perform integrity verification and format encoding, generate a standard reservation request, and build a reservation pool based on the standard reservation request.

[0052] Step S22: Extract the departure time and operation cycle from the standard reservation request and perform time matching. Based on the matching result, divide the standard reservation request into multiple first request sets.

[0053] Step S23: Perform a coverage analysis on the pick-up and drop-off locations in the standard reservation request based on the bus operation baseline, establish a path mapping relationship between the standard reservation request and the bus operation baseline based on the coverage analysis results, and divide the first request set into multiple second request sets based on the path mapping relationship.

[0054] Step S24: Perform directional similarity evaluation and path overlap evaluation on all reservation requests in the second request set in sequence, and construct a similarity matrix based on the evaluation results.

[0055] Step S25: Based on the preset minimum similarity tolerance difference and bus capacity constraints, perform density clustering on the similarity matrix to generate multiple travel demand clusters.

[0056] Specifically, the advance booking constraint is a specified minimum booking submission time, such as booking at least 15 minutes in advance. After a user submits a booking request through the client, the system first checks whether the advance booking constraint is met based on the current time. If it is, the interface platform performs field integrity checks on the booking request (whether the pick-up and drop-off points, departure time, number of passengers, etc. are filled in), standardizes the geographical location encoding (e.g., using Baidu Maps API for Geo encoding), and converts the time into a unified timestamp format, forming a standard booking request structure and caching it in the booking pool as the input set for subsequent processing.

[0057] The day is divided into multiple operating cycles based on the bus timetable (e.g., a time window every 15 minutes). The departure time field is extracted from the standard reservation requests and matched with the operating cycles. All requests in the reservation pool are categorized by time period, forming multiple first request sets. Each set contains reservation requests with departure times within the same time period. These sets will undergo further spatial and directional classification in parallel.

[0058] Coverage analysis determines whether the pick-up and drop-off points of a reservation request fall within the reachable range of the bus operating baseline (e.g., offset distance < 300 meters). The second request set refers to a subset of reservation requests that fall on the same operating baseline service path within the same time period. Coverage analysis is performed on the pick-up and drop-off points of standard reservation requests in each first request set. Coordinate matching is used to determine whether they are located on a serviceable path segment or within the offset tolerance distance (e.g., 300 meters). Based on the analysis results, the standard reservation requests are mapped to specific operating path segments. The first request set is further divided based on the mapping results to obtain multiple second request sets, each containing requests with the same bus operating baseline.

[0059] For each set of second requests, the cosine of the angle between the OD vectors of each request is calculated to assess directional consistency, and the percentage of overlapping path segments is calculated to assess path overlap. Directional consistency and path overlap are then fused according to weights to generate a comprehensive similarity score between each pair of requests. Finally, a symmetric similarity matrix is ​​constructed to provide input for subsequent clustering operations.

[0060] A density-based clustering algorithm (such as DBSCAN) is used to process the similarity matrix. A minimum similarity threshold and a minimum number of samples within a cluster are set as clustering parameters. This outputs multiple travel request clusters that are spatially similar and share paths. Simultaneously, the total number of passengers in each cluster is counted. If the number exceeds the single-vehicle capacity limit (e.g., 30 people), the cluster is split to ensure that each travel demand cluster can be actually scheduled and executed.

[0061] Through the above steps, a large number of scattered user reservation requests are transformed into structured and schedulable travel demand clusters, providing executable inputs for subsequent scheduling route generation and autonomous driving bus task dispatch, and has good spatiotemporal adaptability and practicality.

[0062] Furthermore, step S3 in this embodiment includes: Step S31: Based on the service time window, number of passengers and service path segment of the travel demand cluster, generate vehicle location constraints, vehicle status constraints and capacity constraints.

[0063] Step S32: Based on the vehicle position constraints, vehicle state constraints and capacity constraints, a set of candidate vehicles is selected from the candidate vehicle information, wherein the set of candidate vehicles includes the first candidate vehicle.

[0064] Step S33: Extract the first state information of the first candidate vehicle, perform service adaptability analysis with the travel demand cluster, and construct an adaptability score matrix.

[0065] Step S34: Assign target vehicles to the travel demand clusters based on the suitability score matrix, construct an initial running path based on the target path segments in the travel demand clusters, and generate the bus dispatch strategy.

[0066] Specifically, after obtaining each travel demand cluster, key scheduling parameters are extracted, including: planned service time period, total number of passengers, and expected route segment. Based on these parameters, corresponding scheduling constraints are generated, including vehicle location constraints, vehicle status constraints, and capacity constraints. For example, vehicle location constraints: only vehicles whose current physical location is no more than a threshold (e.g., 1km) from the cluster's boarding point are selected; vehicle status constraints: vehicles with an idle or schedulable operating status are selected; capacity constraints: the remaining passenger capacity of the vehicle should not be less than the total number of passengers in the travel cluster.

[0067] Under the aforementioned scheduling constraints, available vehicles that meet the geographical, temporal, and load requirements are selected from the currently available candidate vehicle information to form a candidate vehicle set. Each vehicle in this set is marked as the first candidate vehicle for subsequent scheduling suitability evaluation.

[0068] Further detailed status information for each first-candidate vehicle is obtained, including its current location, estimated departure time, current route binding status (whether a task has been assigned), and remaining capacity. This information is then compared with the demand information of the travel demand cluster (such as boarding time and boarding location) to perform service suitability analysis. Suitability scores include, but are not limited to: response latency score (the difference between the time required for the vehicle to reach the cluster boarding point and the expected time); load matching score (the degree of matching between vehicle capacity and the number of passengers in the cluster); and route overlap score (the degree of overlap between the vehicle's existing route and the cluster's target route segment). A two-dimensional suitability score matrix is ​​constructed based on the above factors for decision optimization.

[0069] The optimal combination is selected from the suitability score matrix, and the target vehicle with the best service capacity is assigned to each travel demand cluster. Subsequently, based on the target path segment of the travel demand cluster and the extracted pick-up / drop-off points, a complete initial operating path is generated by combining the execution path structure of the public transport operation baseline. This path, along with vehicle identification, expected timetable, etc., forms a complete public transport dispatch strategy. This strategy will ultimately be issued to the vehicle's autonomous driving control system as the basis for executing subsequent autonomous operation tasks.

[0070] Furthermore, step S4 in this embodiment includes: Step S41: Extract the number of people requesting the real-time travel request, and determine whether the current remaining bus capacity meets the number of people requesting the request. If not, determine that the bus does not have the conditions to respond.

[0071] Step S42: If satisfied, extract the boarding and alighting locations of the real-time travel request and perform a direction consistency analysis with the initial operating path to determine whether the real-time travel request satisfies the path direction of the initial operating path. If not satisfied, determine that the bus does not meet the response conditions.

[0072] Step S43: If satisfied, obtain the real-time location of the bus, calculate the estimated response time for the bus to arrive at the requested boarding point based on the real-time location of the bus, and determine whether the estimated response time meets the response time limit constraint. If not satisfied, determine that the bus does not meet the response conditions.

[0073] Step S44: If the conditions are met, the bus is deemed to have the necessary response conditions, and a route change instruction is generated.

[0074] Specifically, upon receiving a real-time travel request from a user, the system first extracts the required number of passengers from the request and reads the real-time operating status of the bus currently performing the task to determine if the bus's available passenger capacity is greater than or equal to the requested number of passengers. If the capacity is insufficient, the system immediately determines that the bus does not have the capability to respond to the current request and skips the subsequent matching steps.

[0075] If capacity is sufficient, continue analyzing the pick-up and drop-off locations of real-time travel requests and map them onto the current vehicle's initial travel path. By calculating the angle (or node order) between the request OD vector and the current path direction, determine if the requested pick-up and drop-off points are arranged in the order of the path direction. If the pick-up point is after the drop-off point or opposite to the current travel direction, it is determined that the directions are inconsistent, and the vehicle cannot respond.

[0076] If the direction is consistent, the real-time geographical location of the current bus is further extracted (which can be obtained through the onboard GPS module), and the estimated arrival time of the bus to the user's boarding point is calculated based on the route network. This estimated arrival time is compared with the requested time. If the estimated response time exceeds the upper limit of the waiting time allowed by the user's request (e.g., 10 minutes), it is determined that the response time limit is not met, and the vehicle is still not ready to respond.

[0077] When all the above conditions are met, namely sufficient capacity, consistent direction, and acceptable response time, it is determined that the bus has the ability to respond to the real-time travel request. Based on this real-time travel request, a route change instruction is generated, which includes the new complete route sequence after inserting the requested pick-up / drop-off point, the estimated stop schedule, etc. The instruction is then prepared to be sent to the vehicle's automatic driving control system, and the route dynamic update stage begins.

[0078] The above steps enable dynamic judgment of real-time travel request responses, ensuring that route insertion and resource utilization efficiency are maximized while meeting security and task stability requirements.

[0079] Furthermore, after establishing a public transport operation baseline that includes multiple stops, it also includes: Step S1-1: Conduct a trial run of the bus operation baseline and collect operation feedback data during the trial run phase. The operation feedback data includes order data, verification data, and user collection data.

[0080] Step S1-2: Based on the operational feedback data, perform route effectiveness assessment and operational matching rate assessment on the bus operation baseline to obtain the baseline assessment results.

[0081] Step S1-3: Perform path optimization based on the baseline evaluation results and update the bus operation baseline.

[0082] Specifically, after initially establishing a public transport operation baseline, autonomous buses will be organized to conduct small-scale or time-limited trial runs in actual operating scenarios. During the trial run phase, feedback data, including order data, verification data, and user-collected data, will be collected through the dispatch platform and onboard systems. Order data records the number of pre-booked orders generated by passengers at each stop along the route, the distribution of boarding and alighting, and order response status. Verification data is based on the actual number of passengers and the passenger arrival rate, calculated using the onboard verification system or electronic ticketing system. User-collected data includes feedback information such as stop satisfaction, suggestions for adding or removing stops, and travel times, collected through app pop-ups, questionnaires, or offline maintenance personnel. All feedback data is archived as structured operational data and used as a basis for route optimization.

[0083] A comprehensive evaluation of the operational feedback data collected during the trial operation phase is conducted, primarily including route effectiveness assessment and operational matching rate assessment. Specifically, route effectiveness assessment counts the number of passengers boarding and alighting at each stop, marking stops below a preset usage frequency threshold (e.g., less than 10 passengers boarding and alighting per day) as inefficient stops. It also calculates the empty load rate between route segments to identify route redundancy. Operational matching rate assessment evaluates the route's ability to cover current actual travel demand by calculating the ratio between the number of reservation orders responded to by the route and the total number of reservation requests. Furthermore, unstructured data such as user suggestion ratings and stop retention / removal suggestions can be combined to extract high-frequency feedback keywords, providing support for future optimization. Based on these indicators, a public transport operation baseline evaluation report is generated, including suggestions for retaining stops, route reduction suggestions, and service time adjustment suggestions.

[0084] Based on the baseline assessment report, route structure adjustments will be implemented, including but not limited to: deleting infrequently used or overlapping stops; trimming redundant route segments between multiple stop groups; generating new route branches based on suggested additions of stops or hotspot areas; adjusting route start and end times or operating cycles to match peak demand periods; and, if route segments differ significantly, breaking them down into multiple branch lines or micro-circulation lines. After optimization, an updated version of the public transport operation baseline will be generated, and the system can choose to enter a new round of trial operation or directly commence formal operation.

[0085] The above steps constitute a data-driven closed-loop optimization mechanism for the bus operation baseline, ensuring that bus routes can be dynamically evaluated and continuously evolved based on actual operating data, thereby improving the efficiency of route resource utilization and passenger service adaptability.

[0086] In summary, the public transportation autonomous driving method provided in this application has the following beneficial effects: By gridding the target service area and inputting historical passenger flow data into a passenger flow prediction model, passenger flow prediction results are obtained. These results are used to identify high-frequency boarding and alighting areas and commuting directions, and further generate candidate station groups and route structures, thereby constructing an initial public transport operation baseline. This provides spatial and temporal boundary conditions for subsequent task scheduling and route matching. User-submitted travel reservation requests are collected through an interactive client. These requests undergo spatiotemporal clustering analysis to construct travel demand clusters, aggregating numerous dispersed reservation requests into several schedulable demand units, improving scheduling efficiency and route reusability. Based on the public transport operation baseline, scheduling decision analysis is performed on the travel demand clusters and candidate vehicle information to establish a public transport scheduling strategy including the initial operating route. The route prediction and request clustering results are transformed into executable autonomous driving tasks. After the public transport scheduling strategy is issued to the public transport autonomous driving control system for execution, real-time user travel requests are received and matched with the initial operating route to determine whether the public transport has the necessary response conditions. This ensures the flexibility of public transport operation, allows for local variability of routes, and thus improves response rate and service matching degree. If the bus has the necessary response conditions, the initial route is dynamically updated based on the user's real-time travel request. The real-time route is then obtained and sent to the bus autonomous driving control system for execution. When the vehicle's current task cannot meet the real-time travel request, a reservation feedback suggestion is generated and pushed to the user. If the user accepts the reservation, the vehicle is added to the next round of dispatching; otherwise, the process ends. This design ensures service continuity and user experience, effectively balancing real-time capabilities and overall capacity utilization efficiency. Furthermore, during the trial operation phase, operational data, including order data, verification data, and user feedback, is collected to evaluate route effectiveness and matching results. This allows for actions such as station reduction, route fine-tuning, and time slot adjustments to be performed, updating the bus operation baseline and achieving closed-loop optimization of the operating routes, thus improving long-term operational efficiency.

[0087] Overall, this application's embodiments establish a closed-loop autonomous driving bus operation system with dynamic response and feedback optimization by introducing a bus operation baseline construction mechanism based on historical passenger flow data and combining multi-dimensional clustering modeling and scheduling adaptation analysis of user reservation requests. This system realizes intelligent prediction and construction of bus operation paths, dynamic adaptation of task scheduling, and self-optimization evolution after operation, significantly improving the matching rate of public transportation services and enhancing the operational flexibility and resource allocation efficiency of the public transportation system.

[0088] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a public transportation automatic driving system, the system comprising: The operation baseline construction module 10 is used to collect historical passenger flow data of the target area and synchronize it to the passenger flow prediction model for passenger flow prediction, obtain the passenger flow prediction results, plan routes based on the passenger flow prediction results, and construct a public transport operation baseline including multiple stops.

[0089] The travel request clustering module 20 is used to collect the travel reservation requests submitted by users through the interactive client, perform spatiotemporal clustering analysis on the travel reservation requests, and construct travel demand clusters.

[0090] The scheduling decision analysis module 30 is used to perform scheduling decision analysis based on the public transport operation baseline on the travel demand cluster and candidate vehicle information, and to establish a public transport scheduling strategy including the initial running path.

[0091] The real-time request matching module 40 is used to receive real-time travel requests from users after the bus dispatching strategy is sent to the bus automatic driving control system for execution, and to perform matching analysis with the initial running path to determine whether the bus has the conditions to respond.

[0092] The route update module 50 is used to dynamically insert and update the initial route based on the user's real-time travel request if the bus has the necessary response conditions, obtain the real-time route, and send it to the bus automatic driving control system for execution.

[0093] Furthermore, the system described in this application embodiment is also used to perform the following steps: If the bus does not meet the response conditions, a reservation request is generated and sent to the client; the reservation feedback result uploaded by the client is obtained. If the reservation feedback result contains the user's reservation request, the user's reservation request is added to the reservation request list for the next round; if the reservation feedback result does not contain the user's reservation request, the task process ends.

[0094] Furthermore, in this embodiment of the application, the operational baseline construction module 10 is also used to perform the following steps: The target area is divided into multiple grid areas according to a preset scale. Historical passenger flow data of multiple grid areas is collected and input into the passenger flow prediction model for time series analysis to obtain passenger flow prediction results. The passenger flow prediction results include the expected passenger flow for boarding and alighting in each grid area within the prediction time window and the OD correlation matrix. Based on the passenger flow prediction results, high-frequency travel points that meet the preset boarding and alighting frequency thresholds are extracted. Hierarchical clustering is performed according to the spatial location of the high-frequency travel points to obtain multiple candidate station groups. The center point of each of the multiple candidate station groups is taken as a candidate stop, and the bus operation baseline is constructed by combining the OD correlation matrix.

[0095] Furthermore, in this embodiment of the application, the travel request clustering module 20 is also used to perform the following steps: Based on advance booking constraints, the system receives original travel booking requests from clients, performs integrity checks and format encoding, generates standard booking requests, and constructs a booking pool based on these standard requests. It then extracts departure times from the standard booking requests and performs time matching with operating cycles, dividing the standard booking requests into multiple first request sets based on the matching results. Next, it performs coverage analysis on the boarding and alighting locations in the standard booking requests based on the public transport operating baseline, establishing a path mapping relationship between the standard booking requests and the public transport operating baseline based on the coverage analysis results. Based on this path mapping relationship, the first request sets are divided into multiple second request sets. For all booking requests in the second request sets, it sequentially performs direction similarity evaluation and path overlap evaluation, constructing a similarity matrix based on the evaluation results. Finally, based on a preset minimum similarity tolerance and public transport capacity constraints, it performs density clustering on the similarity matrix to generate multiple travel demand clusters.

[0096] Furthermore, in this embodiment of the application, the scheduling decision analysis module 30 is also used to perform the following steps: Based on the service time window, passenger number, and service path segment of the travel demand cluster, vehicle location constraints, vehicle status constraints, and capacity constraints are generated. A candidate vehicle set is selected from the candidate vehicle information based on these constraints, wherein the candidate vehicle set includes a first candidate vehicle. The first status information of the first candidate vehicle is extracted, and a service adaptability analysis is performed with the travel demand cluster to construct an adaptability scoring matrix. Based on the adaptability scoring matrix, target vehicles are assigned to the travel demand cluster, and an initial operating path is constructed based on the target path segment in the travel demand cluster, generating the bus dispatching strategy.

[0097] Furthermore, in this embodiment of the application, the real-time request matching module 40 is also used to perform the following steps: Extract the number of people requesting the real-time travel request, and determine whether the current remaining bus capacity can meet the number of people requesting the request. If not, the bus is determined not to be able to respond. If it can, extract the boarding and alighting locations of the real-time travel request, and perform a directional consistency analysis with the initial operating path to determine whether the real-time travel request meets the path direction of the initial operating path. If not, the bus is determined not to be able to respond. If it can, obtain the real-time location of the bus, calculate the estimated response time for the bus to reach the requested boarding point based on the real-time location of the bus, and determine whether the estimated response time meets the response time limit constraint. If not, the bus is determined not to be able to respond. If it can, the bus is determined to be able to respond, and a route change instruction is generated.

[0098] Furthermore, after constructing a public transport operation baseline including multiple stops, the system described in this application embodiment is also used to perform the following steps: The bus operation baseline is tested, and operational feedback data is collected during the test run. The operational feedback data includes order data, verification data, and user collection data. Based on the operational feedback data, the bus operation baseline is evaluated for route effectiveness and operational matching rate to obtain baseline evaluation results. Based on the baseline evaluation results, route optimization is performed to update the bus operation baseline.

[0099] Through the foregoing detailed description of a method for automated driving of public transportation, those skilled in the art can clearly understand that the automated driving system for public transportation in this embodiment corresponds to the system disclosed in Embodiment 2. As it is similar to the method disclosed in Embodiment 1, it has corresponding functional modules and beneficial effects. For relevant details, please refer to the description in the method section.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automated driving of public buses, characterized in that, include: After collecting historical passenger flow data of the target area, the data is synchronized to the passenger flow prediction model to predict passenger flow, obtain the passenger flow prediction results, and plan routes based on the passenger flow prediction results to construct a public transport operation baseline that includes multiple stops. The interactive client collects user-submitted travel reservation requests, performs spatiotemporal clustering analysis on the travel reservation requests, and constructs travel demand clusters. Based on the public transport operation baseline, a scheduling decision analysis is performed on the travel demand clusters and candidate vehicle information to establish a public transport scheduling strategy that includes the initial operating path. After the bus dispatch strategy is sent to the bus automatic driving control system for execution, it receives real-time travel requests from users, matches and analyzes them with the initial running path, and determines whether the bus has the conditions to respond. If the bus has the necessary response conditions, the initial operating path is dynamically inserted and updated based on the user's real-time travel request, and the real-time operating path is obtained and sent to the bus automatic driving control system for execution. Spatiotemporal clustering analysis is performed on the aforementioned travel reservation requests to construct travel demand clusters, including: Based on advance booking constraints, the system receives original travel booking requests from clients, performs integrity checks and format encoding, generates standard booking requests, and constructs a booking pool based on these standard booking requests. Extract the departure time and operating cycle from the standard reservation request and perform time matching. Based on the matching result, divide the standard reservation request into multiple first request sets. Based on the bus operation baseline, a coverage analysis is performed on the pick-up and drop-off locations in the standard reservation request. Based on the coverage analysis results, a path mapping relationship between the standard reservation request and the bus operation baseline is established. Based on the path mapping relationship, the first request set is divided into multiple second request sets. For all reservation requests in the second request set, perform directional similarity evaluation and path overlap evaluation in sequence, and construct a similarity matrix based on the evaluation results; Based on the preset minimum similarity tolerance difference and bus capacity constraints, density clustering is performed on the similarity matrix to generate multiple travel demand clusters; The step of performing scheduling decision analysis based on the public transport operation baseline on the travel demand clusters and candidate vehicle information includes: Based on the service time window, number of passengers and service path segment of the travel demand cluster, vehicle location constraints, vehicle status constraints and capacity constraints are generated. Based on the vehicle location constraints, vehicle state constraints, and capacity constraints, a set of candidate vehicles is selected from the candidate vehicle information, wherein the set of candidate vehicles includes a first candidate vehicle. Extract the first state information of the first candidate vehicle, perform service compatibility analysis with the travel demand cluster, and construct a compatibility score matrix. Based on the suitability score matrix, target vehicles are assigned to the travel demand clusters, and an initial running path is constructed based on the target path segments in the travel demand clusters to generate the bus dispatch strategy.

2. The method for automated bus driving as described in claim 1, characterized in that, Determining whether a bus meets the response requirements also includes: If the bus does not meet the response requirements, a reservation request will be generated and sent to the client. Obtain the reservation feedback result uploaded by the client. If the reservation feedback result contains a user reservation request, add the user reservation request to the reservation request list for the next round. If the reservation feedback result does not contain the user's reservation request, the task process ends.

3. The method for automated bus driving as described in claim 1, characterized in that, The system synchronizes with the passenger flow prediction model to predict passenger flow, obtains the passenger flow prediction results, and performs route planning based on the passenger flow prediction results. It then constructs a public transport operation baseline including multiple stops, including: The target area is divided into multiple grid areas according to a preset scale. After collecting historical passenger flow data from multiple grid areas, the data is input into the passenger flow prediction model for time series analysis to obtain passenger flow prediction results. The passenger flow prediction results include the expected boarding and alighting passenger flow and OD correlation matrix of each grid area within the prediction time window. Based on the passenger flow prediction results, high-frequency travel points that meet the preset boarding and alighting frequency thresholds are extracted. Hierarchical clustering is performed based on the spatial location of the high-frequency travel points to obtain multiple candidate station groups; The center point of each of the multiple candidate station groups is taken as a candidate stop, and the bus operation baseline is constructed by combining the OD correlation matrix.

4. The method for automated bus driving as described in claim 1, characterized in that, The process of receiving a user's real-time travel request, matching and analyzing it with the initial travel route, and determining whether the bus meets the response conditions includes: Extract the number of people requesting the real-time travel request, determine whether the current remaining bus capacity can meet the number of people requesting the request, and if not, determine that the bus does not have the conditions to respond. If satisfied, the boarding and alighting locations of the real-time travel request are extracted and subjected to directional consistency analysis with the initial operating path to determine whether the real-time travel request satisfies the path direction of the initial operating path. If not satisfied, the bus is deemed not to have the conditions to respond. If the conditions are met, the real-time location of the bus is obtained, and the estimated response time for the bus to arrive at the requested boarding point is calculated based on the real-time location of the bus. It is then determined whether the estimated response time meets the response time limit constraint. If it does not meet the constraint, the bus is determined to be unable to respond. If the conditions are met, the bus is deemed to have the capacity to respond, and a route change instruction is generated.

5. The method for automated bus driving as described in claim 1, characterized in that, After establishing a public transport operation baseline that includes multiple stops, it also includes: The bus operation baseline was tested, and operation feedback data was collected during the test run. The operation feedback data included order data, verification data and user collection data. Based on the operational feedback data, the route effectiveness assessment and operational matching rate assessment of the bus operation baseline are performed to obtain the baseline assessment results; Based on the baseline evaluation results, path optimization is performed, and the bus operation baseline is updated.

6. A public transport automatic driving system, characterized in that, The system is used to execute a public transport automatic driving method according to any one of claims 1-5, comprising: The operation baseline construction module is used to collect historical passenger flow data of the target area and synchronize it to the passenger flow prediction model to predict passenger flow, obtain the passenger flow prediction results, plan routes based on the passenger flow prediction results, and construct a bus operation baseline including multiple stops. The travel request clustering module is used to collect user-submitted travel reservation requests from the interactive client, perform spatiotemporal clustering analysis on the travel reservation requests, and construct travel demand clusters. The scheduling decision analysis module is used to perform scheduling decision analysis based on the public transport operation baseline on the travel demand cluster and candidate vehicle information, and to establish a public transport scheduling strategy including the initial running path. The real-time request matching module is used to receive real-time travel requests from users after the bus dispatching strategy is sent to the bus automatic driving control system for execution, and to perform matching analysis with the initial running path to determine whether the bus has the conditions to respond. The route update module is used to dynamically insert and update the initial route based on the user's real-time travel request if the bus has the necessary response conditions, obtain the real-time route, and send it to the bus automatic driving control system for execution.

Images