Bus scheduling method and device based on cloud edge end cooperation, equipment and medium

Abstract

Embodiments of the present disclosure disclose a bus scheduling method and device based on cloud edge cooperation, equipment and medium. A specific embodiment of the method comprises: sending a plurality of multi-source real-time state data corresponding to a bus route to a plurality of roadside edge computing nodes corresponding to the bus route to generate a plurality of traffic state feature information corresponding to the bus route; sending the plurality of traffic state feature information to a cloud platform, and fusing the plurality of traffic state feature information with historical data obtained in advance at the cloud platform; generating a dynamic scheduling instruction set; generating a dynamic signal timing scheme according to the dynamic scheduling instruction set and the real-time state of the related intersection signal lights; generating a bus driving guidance instruction set; and guiding the corresponding bus vehicle to perform a driving operation in cooperation with the dynamic signal timing scheme. The embodiment can realize dynamic cooperation between the bus vehicle and the traffic signal, thereby reducing the waiting time of the passengers and the intersection waiting time of the bus.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a bus dispatching method, apparatus, device, and medium based on cloud-edge-device collaboration. Background Technology

[0002] Currently, urban public transport systems have significant shortcomings in their dispatch response mechanisms when facing sudden route anomalies (such as traffic accidents, traffic congestion, and vehicle breakdowns). Traditional dispatch methods rely on monitoring centers and manual decision-making. However, when using these methods to dispatch buses, the following technical problems often arise: long dispatch instruction information chains, slow response times, and the inability to accurately translate dispatch instructions into executable vehicle guidance, leading to low efficiency in route anomaly recovery, long passenger waiting times, and a serious waste of operational resources.

[0003] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0005] Some embodiments of this disclosure propose a bus dispatching method, apparatus, electronic device, and computer-readable medium based on cloud-edge-device collaboration to solve one or more of the technical problems mentioned in the background section above.

[0006] In a first aspect, some embodiments of this disclosure provide a bus dispatching method based on cloud-edge-device collaboration, comprising: in response to receiving abnormal information about a bus route, sending multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic status feature information; sending the multiple traffic status feature information to a cloud platform, and fusing the multiple traffic status feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, wherein the historical data includes: historical bus operation data and user travel preference data; generating a dynamic dispatching instruction set based on the fused feature vector; generating a dynamic signal timing scheme according to the dynamic dispatching instruction set and the real-time status of traffic lights at relevant intersections, wherein the dynamic signal timing scheme is used to control the traffic lights at the relevant intersections; generating a bus driving guidance instruction set according to the dynamic dispatching instruction set and the dynamic signal timing scheme; and in response to the on-board terminal of the corresponding bus receiving the bus driving guidance instruction set, guiding the corresponding bus to perform driving operations coordinated with the dynamic signal timing scheme.

[0007] Secondly, some embodiments of this disclosure provide a bus dispatching device based on cloud-edge-device collaboration, comprising: a sending unit configured to, in response to receiving abnormal information about a bus route, send multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information; and a fusion unit configured to send the multiple traffic state feature information to a cloud platform, and to fuse the multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, wherein the historical data includes: historical bus operation data and user travel preference data. The first generation unit is configured to generate a dynamic scheduling instruction set based on the aforementioned fused feature vector; the second generation unit is configured to generate a dynamic signal timing scheme based on the aforementioned dynamic scheduling instruction set and the real-time status of the relevant intersection traffic lights, wherein the aforementioned dynamic signal timing scheme is used to control the aforementioned relevant intersection traffic lights; the third generation unit is configured to generate a bus driving guidance instruction set based on the aforementioned dynamic scheduling instruction set and the aforementioned dynamic signal timing scheme; and the guidance unit is configured to guide the corresponding bus to perform driving operations in coordination with the aforementioned dynamic signal timing scheme in response to the on-board terminal of the corresponding bus receiving the aforementioned bus driving guidance instruction set.

[0008] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0009] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0010] The above embodiments of this disclosure have the following beneficial effects: Through the cloud-edge-device collaborative bus dispatching method of some embodiments of this disclosure, dynamic coordination between buses and traffic signals is achieved, reducing passenger waiting time and bus intersection waiting time. Specifically, the reason for the long passenger waiting time and bus intersection waiting time is that when a route anomaly occurs, it is impossible to quickly aggregate multi-source real-time data and perform global optimization, resulting in delayed dispatching instructions, signal timing decoupling from vehicle guidance, and buses frequently encountering red light stops, leading to extended passenger waiting times. Based on this, the cloud-edge-device collaborative bus dispatching method of some embodiments of this disclosure first, in response to receiving abnormal information about a bus route, sends multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information. The multiple multi-source real-time data are distributed to the roadside edge nodes for local processing. The edge nodes generate low-latency traffic state feature information through data cleaning and feature extraction. This effectively compresses the data volume, reduces cloud processing pressure, and provides a high-quality, structured data foundation for subsequent real-time decision-making. Then, the aforementioned traffic state feature information is sent to the cloud platform, where it is fused with pre-acquired historical data to construct a fused feature vector. This historical data includes historical bus operation data and user travel preference data. Leveraging the powerful computing capabilities of the cloud platform, multiple traffic state feature information extracted from various roadside edge computing nodes, along with historical bus operation data and user preference data, are deeply fused to construct a more predictive fused feature vector that incorporates spatiotemporal dimensions. This allows scheduling schemes to be based not only on the current state but also on historical patterns and user needs. Next, a dynamic scheduling instruction set is generated based on this fused feature vector. Generating a dynamic scheduling instruction set based on the fused feature vector realizes the transformation from data to decision-making. It can automatically formulate scheduling schemes such as vehicle adjustments and route optimization based on real-time traffic conditions, capacity demand, and user preferences, improving the rationality and efficiency of resource allocation. Finally, based on the dynamic scheduling instruction set and the real-time status of relevant intersection traffic lights, a dynamic signal timing scheme is generated. This dynamic signal timing scheme is used to control the relevant intersection traffic lights. Based on dispatch instructions and the real-time status of traffic lights at intersections, a dynamic signal timing scheme is generated. This achieves vehicle-road cooperation, translating dispatch strategies into specific traffic control instructions and improving the overall traffic efficiency of the road network. Furthermore, based on the aforementioned dynamic dispatch instruction set and dynamic signal timing scheme, a bus driving guidance instruction set is generated. By integrating the dispatch instructions and signal timing scheme, personalized driving guidance instructions are generated for each bus. This transforms macro-level dispatch objectives into micro-level operations executable by individual vehicles, ensuring that vehicles can accurately coordinate with signal cycles for efficient and smooth operation.Finally, in response to the onboard terminal of the corresponding bus receiving the aforementioned bus driving guidance instruction set, the bus is guided to perform driving operations in coordination with the dynamic signal timing scheme. After receiving the guidance instructions, the onboard terminal guides the driver or autonomous driving system to drive according to the instructions through the vehicle control execution system. This step completes the closed loop from cloud-based decision-making to vehicle execution, ensuring the effective implementation of the scheduling scheme and ultimately achieving dynamic coordination between buses and the signal system, shortening passenger waiting time and bus intersection waiting time. Attached Figure Description

[0011] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0012] Figure 1 This is a flowchart of some embodiments of the cloud-edge-device collaborative bus dispatching method according to this disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the cloud-edge-device collaborative bus dispatching device according to this disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0013] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0014] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0015] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0016] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0017] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0018] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] refer to Figure 1 The diagram illustrates a flowchart 100 of some embodiments of a cloud-edge-device collaborative bus dispatching method according to the present disclosure. This cloud-edge-device collaborative bus dispatching method includes the following steps: Step 101: In response to receiving abnormal information about the bus route, multiple multi-source real-time status data corresponding to the bus route are sent to multiple corresponding roadside edge computing nodes to generate multiple traffic status feature information.

[0020] In some embodiments, the executing entity (e.g., an electronic device) of the above-described cloud-edge-device collaborative bus scheduling method can be hardware or software. When the computing device is hardware, it can be implemented as a distributed cluster composed of multiple servers or terminal devices, or as a single server or a single terminal device. When the computing device is software, it can be installed in the hardware devices listed above. It can be implemented as multiple software programs or software modules to provide distributed services, or as a single software program or software module. No specific limitations are made here.

[0021] In other embodiments, the aforementioned execution entity may, in response to receiving abnormal information about a bus route, send multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information. The bus route may be a public transportation service path operating in a city according to fixed routes, stops, and schedules. The abnormal information may refer to information about unplanned events occurring during bus operation. For example, the abnormal information may be an alarm indicating two-way congestion on a certain section of a route due to a traffic accident. The multiple multi-source real-time status data may be multiple sets of real-time monitoring data from various devices and of different types, including: bus GPS location, bus stop passenger flow camera counts, intersection camera video, and radar data on the speeds of other vehicles. The multiple roadside edge computing nodes may be multiple hardware facilities distributed along the road and possessing computing capabilities. For example, the multiple roadside edge computing nodes may be MEC servers or smart gateway devices installed at multiple intersections or light poles in the target area. The multiple traffic state feature information may be multiple feature information describing the local traffic state generated by each of the multiple roadside edge computing nodes after processing the corresponding multiple multi-source real-time status data. For example, the traffic status feature information mentioned above could be "sudden drop in speed from west to east" output by roadside edge computing node A, or "queue length exceeds 200 meters from east to west" output by roadside edge computing node B.

[0022] In some optional implementations of certain embodiments, the aforementioned execution entity may, in response to receiving abnormal information about a bus route, send multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple corresponding traffic state feature information, which may include the following steps: The first step is to determine the target area corresponding to the abnormal bus route information mentioned above. The target area can be the geographical range directly affected by the abnormal bus route information. For example, it could be the area of ​​all roads and intersections within a 500-meter radius of the accident site.

[0023] The second step involves acquiring multiple sources of real-time status data from various terminal devices within the target area. These terminal devices can be various types of hardware distributed throughout the target area capable of collecting data (e.g., road surveillance cameras). In practice, this can be achieved by sending data acquisition commands to multiple terminal devices registered within the target area, and asynchronously receiving the multiple sources of real-time status data uploaded by each terminal device via protocols such as ZigBee / 4G / V2X.

[0024] The third step involves performing the following steps for each of the aforementioned multi-source real-time status data: Sub-step one involves uploading the aforementioned multi-source real-time status data to the corresponding roadside edge computing nodes, and preprocessing the multi-source real-time status data on these roadside edge computing nodes to obtain a preprocessed dataset. This preprocessed dataset can be a standardized dataset formed by cleaning, calibrating, and formatting the multi-source real-time status data. In practice, firstly, data can be uploaded to the roadside edge computing node with the closest physical location or logical affiliation via 5G / Uu port or RSU (C-V2X). Then, the roadside edge computing node performs operations such as verification, time synchronization, coordinate system unification, and invalid value removal on the multi-source real-time status data to generate the preprocessed dataset.

[0025] Sub-step two involves extracting key features from the preprocessed dataset to generate an initial feature set. These key features can be core quantitative indicators reflecting traffic conditions directly extracted from the preprocessed dataset. For example, key features could be "instantaneous speed" and "number of stops" extracted from GPS trajectories, or "lane occupancy" extracted from video. The initial feature set can be a set of features formed after preliminary summarization and statistical analysis of the key features. For example, the initial feature set could be: {average speed: 15 km / h, stopping delay: 120 seconds, time occupancy: 85%}. In practice, a lightweight object detection model (e.g., YOLO) is run on the roadside edge computing nodes to extract key features representing traffic flow from the preprocessed dataset to generate the initial feature set.

[0026] Sub-step three involves fusing the initial feature set with the local historical traffic pattern data stored at the roadside edge computing nodes to generate corresponding traffic state feature information. The local historical traffic pattern data can be traffic data from the same historical period (e.g., the same week, the same time period) stored at the roadside edge computing nodes. The traffic state feature information can refer to a comprehensive state description after fusing the real-time features of the initial feature set with the local historical traffic pattern data. In practice, traffic state feature information can be generated by comparing or weighting the extracted initial feature set with the local historical traffic pattern data stored at the roadside edge computing nodes.

[0027] Step 102 involves sending multiple traffic status feature information to the cloud platform and fusing the multiple traffic status feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector.

[0028] In some embodiments, the aforementioned executing entity can send the aforementioned multiple traffic state feature information to a cloud platform, and fuse the aforementioned multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector. The aforementioned historical data includes: historical bus operation data and user travel preference data. The aforementioned cloud platform can be a centralized data processing center located in the cloud, a software and hardware system responsible for global computation and coordination, possessing powerful computing and storage capabilities. The aforementioned pre-acquired historical data can be a collection of past data pre-stored on the cloud platform for analysis and comparison. For example, the aforementioned pre-acquired historical data may include: GPS trajectories, arrival times, passenger flow records, and user travel preference data of all city bus routes in the past year. The aforementioned fused feature vector can be a mathematical vector formed by fusing multiple traffic state feature information and pre-acquired historical data, used to characterize the overall traffic state. The aforementioned historical bus operation data can be a structured data collection of past bus operating conditions. For example, the aforementioned historical bus operation data may include: historical GPS trajectories of buses, on-time rate of trips, passenger counts at each stop, and vehicle malfunction records. The aforementioned user travel preference data can be data describing the travel habits and preferences of individuals or groups. For example, the user travel preference data mentioned above could be "A user usually travels at 7:30 on weekdays, prefers fewer than 2 transfers, and can accept a walking distance of 500 meters."

[0029] In some optional implementations of certain embodiments, the aforementioned executing entity may send the aforementioned multiple traffic state feature information to a cloud platform, and fuse the aforementioned multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, which may include the following steps: The first step is to perform the following steps on the aforementioned cloud platform: The first sub-step involves integrating the aforementioned multiple traffic state feature information into global traffic state feature information. This global traffic state feature information can be a globally comprehensive traffic state description formed by integrating multiple traffic state feature information. In practice, the cloud platform receives multiple traffic state feature information from different roadside edge computing nodes, aggregates and aligns features describing the same road segment or area (e.g., by unifying timestamps) to generate global traffic state feature information.

[0030] Sub-step two involves standardizing the aforementioned traffic state feature information across the entire region to obtain standardized feature information. This standardized feature information can be feature data that has undergone normalization or standardization to eliminate differences in dimensions and ranges. For example, the standardized feature information could be vehicle speed (0-60 km / h) and queue length (0-1000m) normalized to the [0, 1] interval, respectively. In practice, standardization algorithms (e.g., Min-Max normalization or Z-score standardization) can be applied to standardize the aforementioned traffic state feature information across the entire region to obtain standardized feature information.

[0031] Step three involves associating the standardized feature information with similar scenario patterns in the historical bus operation data to obtain enhanced feature information with historical reference labels. These similar scenario patterns can be situations in the historical bus operation data that are similar to the current traffic conditions. For example, a similar scenario pattern could be "moderate congestion on the main roads in the core area during weekday evening rush hour, accompanied by a surge in subway transfer passengers," and searching for scenarios with the same conditions in the historical bus operation data. The historical reference labels can be tags representing the development outcome of similar scenario patterns. For example, a tag for the pattern could be "congestion spreads to adjacent areas in 15 minutes, requiring the activation of temporary shuttle buses." The enhanced feature information with historical reference labels can be feature information with predictive labels that integrates real-time standardized features and historical pattern experience. In practice, in the historical bus operation data, using the current standardized feature vector as the query condition, similar scenario patterns are associated through vector similarity calculation (e.g., cosine similarity, Euclidean distance) to generate enhanced feature information with historical reference labels.

[0032] Sub-step four involves adaptively adjusting the enhanced feature information with historical reference labels based on the aforementioned user travel preference data to generate feature information containing user demand information. This feature information can incorporate specific travel needs (e.g., origin and destination, time constraints, preferences) into the features. In practice, user travel preference data can be used to identify, for example, that passengers in the current time period and region are generally sensitive to "number of transfers." Based on this preference, the weights of relevant dimensions in the feature information are adjusted, or feature transformations under preference constraints are performed to generate feature information containing user demand information. For example, user travel preference data shows that over 70% of passengers waiting for this bus route are commuters with high time sensitivity. Therefore, the weight of the feature "estimated travel time" in subsequent optimization is increased from the default 0.5 to 0.8.

[0033] Sub-step five involves constructing a spatiotemporal topology graph based on the aforementioned feature information containing user demand information. This spatiotemporal topology graph can be a network graph data structure that includes spatial (road network, station) connections and temporal (travel time, departure interval) attributes. For example, each node is a bus stop, and the edge weights are dynamic travel times considering current road conditions. In practice, firstly, bus stops or key intersections are used as nodes. Then, feature information containing user demand information (e.g., dynamic road segment travel times) is used as the edge weight attributes to construct a graph data structure with time-varying weights, i.e., a spatiotemporal topology graph. For example, the nodes are bus stops S1, S2, and S3. The weights of the edge (S1->S2) include: geographical distance, dynamic bus travel time (e.g., from S1 to S2 in 8 minutes), and the estimated arrival time of the next bus at S1.

[0034] Sub-step six involves generating the global optimal path probability distribution information based on the aforementioned spatiotemporal topology map. This global optimal path probability distribution information can be derived from the spatiotemporal topology map, reflecting the probability distribution of all possible paths from any point to another being recommended as "optimal." For example, from station A to station B, there is a 60% probability of recommending path 1 (fast but expensive) and a 40% probability of recommending path 2 (slow but cheap). In practice, an improved path search algorithm (e.g., considering multi-objective random walk algorithms or Monte Carlo tree search) is run on the constructed spatiotemporal topology map. For a given origin-destination (OD) pair, the algorithm explores multiple feasible paths and performs probabilistic evaluation based on cost (time, transfers), ultimately outputting the probability of each path being recommended, thus forming the global optimal path probability distribution information.

[0035] Sub-step seven involves generating a fused feature vector based on the aforementioned global optimal path probability distribution information. In practice, the global optimal path probability distribution information is encoded and its dimensionality reduced. One approach is to perform tensor operations on the OD matrix and the path probability distribution to extract its main features (e.g., using Principal Component Analysis (PCA) to extract main features), generating a low-dimensional, dense vector. Another approach is to directly use the probability distribution of the critical path as the feature dimension. The final output vector is the fused feature vector.

[0036] Step 103: Generate a dynamic scheduling instruction set based on the fused feature vector.

[0037] In some embodiments, the aforementioned executing entity can generate a dynamic scheduling instruction set based on the aforementioned fused feature vector. This dynamic scheduling instruction set can be a series of executable bus dispatch control commands. For example, the dynamic scheduling instruction set may include {Instruction 1: Dispatch standby vehicle X from depot A to the starting station B of route L; Instruction 2: Adjust the departure interval of route L from 10 minutes to 7 minutes}.

[0038] In some optional implementations of certain embodiments, the execution entity may generate a dynamic scheduling instruction set based on the aforementioned fused feature vector, which may include the following steps: The first step is to generate network status quantification indicators based on the aforementioned fused feature vectors. These network status quantification indicators can be performance metrics that precisely describe the current operational status of the public transport network using numerical values. For example, the network status quantification indicators could be: {Congestion index for route L01: 0.85, Capacity gap for route L02: 3 vehicles, Average waiting time in area Z: 15 minutes}. In practice, the network status quantification indicators can be determined by decoding and statistically analyzing the fused feature vectors.

[0039] The second step involves generating multi-level scheduling target information based on the aforementioned network state quantification indicators. This multi-level scheduling target information can consist of multiple objectives to be achieved through scheduling, prioritized accordingly. For example, the multi-level scheduling target information could be: {Level 1 objective: Alleviate core congestion on line L01; Level 2 objective: Balance capacity supply and demand in region Z; Level 3 objective: Reduce overall network operating costs}. In practice, based on the network state quantification indicators, the most pressing objective is determined and ranked by importance to form a target list, thus generating the multi-level scheduling target information.

[0040] The third step involves constructing a multi-objective optimization model based on the aforementioned multi-level scheduling objective information and preset constraint information. The preset constraint information can be system restrictions that must be followed during the scheduling process. The multi-objective optimization model can be a mathematical model used to weigh multiple objectives and find the optimal solution under constraints. For example, the multi-objective optimization model can be a mathematical programming model with the objectives of minimizing total passenger waiting time and minimizing total empty vehicle mileage, and constraints such as the number of vehicles and driver working hours. In practice, the multi-level scheduling objective information can be mathematically transformed into objective functions (e.g., transforming the objective of "reducing delays" into minimizing the total travel time of all passengers), and the preset constraints can be transformed into constraint conditions (e.g., the number of available vehicles ≤ N), thus constructing the multi-objective optimization model.

[0041] The fourth step involves generating a candidate solution set based on the aforementioned multi-objective optimization model and objective algorithm. The objective algorithm can be a computational algorithm used to solve the multi-objective optimization model, such as the Non-Dominated Sorting Genetic Algorithm (NSGA-II) or Particle Swarm Optimization. The candidate solution set can be a set of scheduling schemes generated by the objective algorithm.

[0042] As an example, an objective algorithm (e.g., NSGA-II) is used to solve a multi-objective optimization model. The algorithm iteratively searches the solution space by simulating evolution (selection, crossover, mutation), ultimately outputting a set of Pareto optimal solutions, i.e., a set of candidate solutions. Each solution represents a specific vehicle and shift adjustment scheme.

[0043] The fifth step involves using pre-defined decision rules to filter the candidate solution set and generate the target solution. These pre-defined decision rules can be a set of strategies or criteria used to make a final selection among multiple candidate solutions. For example, the pre-defined decision rules could be: "If it is currently a weekday morning rush hour, prioritize the solution with the lowest total passenger delay; if it is off-peak, prioritize the solution with the lowest operating cost."

[0044] The sixth step is to transform the above target scheme into executable control instructions to generate a dynamic scheduling instruction set. In practice, the target scheme (e.g., "departure interval of line L = 7 minutes") is parsed and translated into a series of discrete, atomic operation commands that can be understood and executed by executable units (vehicles, platforms, drivers), and then standardized and encapsulated to generate a dynamic scheduling instruction set.

[0045] Step 104: Generate a dynamic signal timing scheme based on the dynamic scheduling instruction set and the real-time status of the traffic lights at relevant intersections.

[0046] In some embodiments, the aforementioned executing entity can generate a dynamic signal timing scheme based on the aforementioned dynamic scheduling instruction set and the real-time status of the relevant intersection traffic lights. The dynamic signal timing scheme is used to control the relevant intersection traffic lights. The real-time status of the relevant intersection traffic lights can be the real-time operating parameters and status of the traffic lights at the specified intersection at the current moment. For example, the real-time status of the relevant intersection traffic lights could be intersection A, currently displaying a north-south green light, which has lasted for 25 seconds with 8 seconds remaining, and the current cycle length is 120 seconds. The dynamic signal timing scheme can be a parameter scheme used to adjust the timing of one or more intersection traffic lights. For example, the dynamic signal timing scheme could extend the east-west green light at intersection B by 15 seconds and advance the north-south green light of the next cycle by 5 seconds.

[0047] In some optional implementations of certain embodiments, the executing entity can generate a dynamic signal timing scheme based on the dynamic scheduling instruction set and the real-time status of the relevant intersection traffic lights. The dynamic signal timing scheme, used to control the relevant intersection traffic lights, may include the following steps: The first step is to generate bus priority dispatching demand information based on the aforementioned dynamic dispatching instruction set. This bus priority dispatching demand information can be a specific demand for intersection signal control parsed from the dynamic dispatching instruction set. For example, the bus priority dispatching demand information could be that bus Y will arrive at intersection C in approximately 1 minute and 30 seconds and requests green light right-of-way during that phase. In practice, firstly, the instructions related to traffic light control in the dynamic dispatching instructions are identified (e.g., a bus needs to pass through an intersection during a certain time period), and information such as the bus vehicle ID, estimated arrival at the intersection, and requested passage time window are extracted as the bus priority dispatching demand information.

[0048] The second step involves generating the current signal cycle and phase timing information for the aforementioned traffic lights based on their real-time status. This information can be structured data describing the complete operational pattern of the traffic lights, including cycle duration, phase sequence, and green light start and end times. In practice, V2I communication can be used to send a status query request to the signal controller at the target intersection or to receive its periodically broadcast status information, parsing and obtaining the real-time cycle duration, current phase, remaining phase time, and a preset phase timing table.

[0049] The third step involves generating a signal adjustment request queue based on the current signal cycle and phase timing information and the bus priority scheduling demand information. This queue can be a set of multiple signal adjustment requests awaiting processing, arranged by priority or time sequence. In practice, firstly, the bus priority scheduling demand information is spatiotemporally matched with the current signal cycle and phase timing information. Then, based on the bus's current position, speed, and distance to the stop line, its arrival time is predicted and compared with the current and future signal phases to generate specific adjustment requests (e.g., extending the green light of a certain phase, shortening the red light, inserting into a priority phase). These requests are then sorted by urgency and queued to obtain the signal adjustment request queue.

[0050] The fourth step involves adjusting the request queue based on the aforementioned signals and generating a preliminary green wave timing parameter set using a pre-built green wave coordination control model. This pre-built green wave coordination control model can be a mathematical model or algorithm used to coordinate signals at multiple intersections and form a continuous green wave for vehicles, enabling vehicles (especially buses) to pass through multiple intersections continuously at a set speed without encountering red lights, thus forming a "green wave." This pre-built green wave coordination control model can be a coordination optimization model based on a discrete fleet model and a bandwidth maximization algorithm. For example, on a bus corridor with three intersections, the pre-built green wave coordination control model calculates the signal period at each intersection to be uniformly set to 100 seconds based on the bus speed (e.g., 40 km / h) and the intersection spacing, and sets a phase difference (intersection 2 has a 20-second delay relative to intersection 1, and intersection 3 has a 40-second delay), ensuring that buses encounter a green light when arriving at each intersection. The preliminary green wave timing parameter set can be the initial signal control parameter set calculated by the pre-built green wave coordination control model. The aforementioned preliminary green wave timing parameter set can be the initial signal control parameter set calculated from a pre-constructed green wave band coordination control model. For example, the aforementioned preliminary green wave timing parameter set could be an adjustment of the cycle at intersection A to 130 seconds, a phase difference adjustment of 25 seconds at intersection B, and a recommended bus speed of 45 km / h.

[0051] As an example, a signal adjustment request queue is taken as input, and a pre-built green wave coordination control model is invoked. The pre-built green wave coordination control model aims to maximize the continuous bandwidth of buses or minimize their number of stops. Under the constraint of considering the correlation between adjacent intersections, it optimizes and calculates a new set of signal control parameters as the initial green wave timing parameter set.

[0052] The fifth step involves generating a timing scheme evaluation report based on the aforementioned preliminary green wave timing parameter set and real-time traffic flow data. The real-time traffic flow data can reflect the current traffic conditions at intersections and related road segments. For example, this data may include: queue lengths at each intersection, cross-sectional flow rates, and average vehicle speeds. The timing scheme evaluation report can be a prediction report of the effects derived from simulations or calculations of the preliminary timing scheme. For example, it might state, "After the scheme is implemented, bus delays are expected to decrease by 40 seconds, but the average east-west delay for private vehicles is expected to increase by 15 seconds." In practice, a fast evaluation algorithm can be used, inputting the preliminary green wave timing parameter set and real-time traffic flow data, to simulate traffic operations over a future period and predict changes in key indicators to obtain the timing scheme evaluation report.

[0053] The sixth step involves revising the initial green wave timing parameter set based on the timing scheme evaluation report and the preset balance optimization strategy information to generate an optimized green wave timing parameter set. The preset balance optimization strategy information can be a pre-defined rule that balances different optimization objectives (e.g., bus priority versus the impact on private vehicles). For example, the preset balance optimization strategy information could be that for a single bus priority adjustment, the average delay increase per private vehicle should not exceed 5 seconds. The optimized green wave timing parameter set can be the final parameter set obtained by adjusting the initial green wave timing parameter set based on the timing scheme evaluation report and the preset balance optimization strategy information. In practice, the timing scheme evaluation report and the preset balance optimization strategy information (e.g., "the maximum increase in total delay for private vehicles is 5%) can be compared. If the initial green wave timing parameters exceed the limit, the parameters are automatically adjusted (e.g., reducing the green light extension, fine-tuning the phase difference) for re-evaluation until the strategy requirements are met, finally generating the optimized green wave timing parameter set.

[0054] The seventh step is to encode the optimized green wave timing parameter set into standard traffic control protocol instructions to generate a dynamic signal timing scheme. In practice, the optimized green wave timing parameter set can be encoded into quantifiable instructions according to the data format and instruction set specified by standard protocols (e.g., NTCIP, GB / T 20999) to serve as a dynamic scheduling instruction set.

[0055] Step 105: Generate a bus driving guidance instruction set based on the dynamic scheduling instruction set and the above dynamic signal timing scheme.

[0056] In some embodiments, the aforementioned executing entity may generate a bus driving guidance instruction set based on the aforementioned dynamic scheduling instruction set and the aforementioned dynamic signal timing scheme. The aforementioned bus driving guidance instruction set may be a set of instructions used to guide the bus driver or the autonomous driving system to control the vehicle. For example, the aforementioned bus driving guidance instruction set may be: {Maintain current lane; Accelerate to 45 km / h in 3 seconds; No need to stop before the stop line}.

[0057] In addressing the technical problems mentioned above by adopting technical solutions, and considering the application scenario—emergency situations where urban traffic experiences large-scale delays, disruptions, or severe capacity shortages on specific bus routes due to sudden accidents, large-scale events, or extreme weather—the following technical problems often arise: In emergency scenarios, buses struggle to execute dynamically generated signal priority and scheduling strategies in real time and accurately, resulting in wasted signal priority windows, low overall coordination efficiency, and wasted emergency response time and scheduling resources. To meet the following requirements for this application scenario—real-time execution of instructions, accuracy, dynamic adaptability, and system closed-loop feedback capabilities—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may generate a bus driving guidance instruction set based on the dynamic scheduling instruction set and the dynamic signal timing scheme, which may include the following steps: The first step is to generate individual vehicle dispatch instructions based on the aforementioned dynamic dispatch instruction set. These individual vehicle dispatch instructions can be specific dispatch instructions parsed from the dynamic dispatch instruction set, tailored to a particular vehicle. For example, the individual vehicle dispatch instruction could be: {Vehicle B1234: Must arrive at the South Square Station of the Railway Station before 08:20, suggested route: along Renmin Road - Jiefang Road}. In practice, firstly, the dynamic dispatch instruction set issued by the cloud platform is parsed. Then, based on the vehicle's unique identifier (e.g., license plate number or vehicle terminal ID), all dispatch items related to that vehicle (e.g., route adjustments, arrival time requirements) are filtered out. Finally, the individual vehicle dispatch instruction information is generated.

[0058] The second step is to generate intersection-level priority passage time-space window information based on the aforementioned dynamic signal timing scheme. This information can describe the time window and spatial range reserved for buses at a specific intersection. For example, the intersection-level priority passage time-space window information could be: {Intersection A (Renmin Road-Zhongshan Road intersection): Northbound straight-ahead direction, green light window 08:15:30-08:15:45, recommended speed range 40-50km / h}. In practice, firstly, based on the dynamic signal timing scheme, the signal adjustments set for bus priority are identified. Then, these adjustments (e.g., extended green light, earlier red light termination) are bound to specific intersections, directions, and time periods. Finally, the information is output in the form of a time-space window (intersection ID, direction, green light start time, green light end time) to obtain the intersection-level priority passage time-space window information.

[0059] The third step involves generating an initial reference driving trajectory based on the aforementioned individual vehicle dispatch instructions and real-time high-precision map data. The real-time high-precision map data can be a dynamic map including refined static information (e.g., lane-level topology, slope, curvature, traffic signs). The initial reference driving trajectory can be a roughly planned spatiotemporal path from the starting point to the destination, based on the individual vehicle dispatch instructions and real-time high-precision map data. For example, the initial reference driving trajectory could be: {located at point A at T+0s; passing point B at T+30s; arriving at point C at T+60s}. In practice, firstly, based on the path (or default route) specified in the individual vehicle dispatch instructions, the lane-level geometric information of that path is queried from the real-time high-precision map data. Then, based on the vehicle's real-time position and target speed (from the dispatch instructions), a trajectory planning algorithm (e.g., polynomial curve fitting) is used to generate a smooth spatial path from the starting point to the destination, and a preliminary timestamp is added to obtain the initial reference driving trajectory.

[0060] The fourth step involves co-optimizing the initial reference driving trajectory and the aforementioned intersection-level priority passage time-space information using trajectory and signal coordination to generate a time-optimal speed guidance curve. This time-optimal speed guidance curve can be a function curve calculating the suggested vehicle speed as a function of time, designed to ensure the vehicle passes each intersection "exactly" within the green light time-space. In practice, firstly, the initial reference trajectory is spatiotemporally aligned with the priority passage time-space of each intersection. Then, an optimization model is established, using "passing within multiple time-space windows" as a constraint and "minimizing total travel time" as the objective, to calculate the optimal speed profile. Finally, the speed-time function curve is output as the time-optimal speed guidance curve.

[0061] The fifth step involves performing feasibility verification and smoothing on the aforementioned time-optimal speed guidance curve and real-time vehicle dynamics state to generate a feasible speed guidance command sequence. The aforementioned real-time vehicle dynamics state can be the vehicle's current physical motion parameters. For example, the aforementioned real-time vehicle dynamics state could be: current speed: 35 km / h, engine speed: 2000 rpm, gear: D4, battery SOC: 65%. The aforementioned feasible speed guidance command sequence can be a specific sequence of operation commands obtained by smoothing and discretizing the optimal speed curve after considering vehicle dynamics constraints (e.g., maximum acceleration, engine response). In practice, firstly, based on the real-time vehicle dynamics state (e.g., current speed, maximum acceleration capability), then the time-optimal speed guidance curve is processed in two ways: firstly, a feasibility verification is performed to ensure that the acceleration / deceleration required by the curve does not exceed the vehicle's physical limits; secondly, smoothing is performed to eliminate abrupt changes in the curve, making it more consistent with the actual control response. Finally, the processed smoothed curve is discretized into a series of time-ordered, specific speed or acceleration commands as the feasible speed guidance command sequence.

[0062] Step 6: Based on the aforementioned feasible speed guidance instruction sequence and the acquired real-time traffic environment perception data, generate a safety assessment report. The aforementioned real-time traffic environment perception data can be surrounding environment information acquired through onboard sensors (radar, cameras) or V2X. The aforementioned safety assessment report can be a conclusion drawn from a risk assessment of the anticipated driving behavior based on the guidance instructions and real-time environmental data. For example, the aforementioned real-time traffic environment perception data could indicate that the risk level of executing the guidance instruction "accelerate to 50 km / h" is "low," and a safe distance from the vehicle ahead is expected to be maintained. In practice, firstly, real-time environmental perception data around the vehicle (e.g., the position and speed of surrounding vehicles, pedestrians) is acquired. Then, it is predicted how the vehicle will interact with the traffic environment in the next few seconds if it strictly follows the feasible speed guidance instruction sequence, and the risks of collisions and traffic violations are assessed. Finally, a safety assessment report is generated, including the risk level, main threats, and recommendations.

[0063] Step 7: Based on the aforementioned feasible speed guidance instruction sequence and the aforementioned safety assessment report, generate a bus driving guidance instruction set. In practice, firstly, integrate the feasible speed guidance instruction sequence and the safety assessment report. Then, based on the conclusions of the safety assessment report, make final adjustments to the instruction sequence (e.g., reduce recommended speed, increase safety redundancy). Finally, encapsulate each instruction (speed control, lane suggestion, intersection clearance prompt) according to a protocol to form the final bus driving guidance instruction set issued to vehicles or drivers.

[0064] The above-described operational steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background art: "In emergency scenarios, buses struggle to execute dynamically generated signal priority and scheduling strategies in real time and accurately, resulting in wasted signal priority windows, low overall coordination efficiency, and wasted emergency response time and scheduling resources." The reasons for this technical problem are as follows: the command-to-execution conversion link is incomplete, lacking accurate perception and matching of the vehicle's current state, and the execution process lacks real-time feedback and dynamic adjustment mechanisms. This invention constructs a complete vehicle-side execution link from command parsing, state matching, timing decision-making, precise control to closed-loop feedback, achieving precise implementation of dynamic scheduling strategies and signal timing schemes. This ensures full utilization of priority passage windows, saves bus travel time, and improves the overall reliability and emergency response efficiency of the public transportation system in emergency situations.

[0065] Step 106: In response to the on-board terminal of the corresponding bus receiving the bus driving guidance instruction set, the corresponding bus is guided to perform driving operations in coordination with the dynamic signal timing scheme.

[0066] In some embodiments, the aforementioned executing entity may, in response to the onboard terminal of the corresponding bus receiving the aforementioned bus driving guidance instruction set, guide the corresponding bus to perform driving operations coordinated with the aforementioned dynamic signal timing scheme. The aforementioned driving operations may be specific physical actions performed by the vehicle during operation (e.g., driving at a constant speed of 40 km / h, braking smoothly before the stop line, turning left at an intersection). The aforementioned onboard terminal may be a control device installed on the bus, responsible for receiving, processing, and executing instructions and feeding back data. For example, the aforementioned onboard terminal may be an intelligent in-vehicle information terminal (IVI) integrating a 5G / V2X communication module, a high-precision positioning unit, and a vehicle bus interface.

[0067] In addressing the technical challenges of the aforementioned background technologies, and considering the specific application scenario—urban bus signal priority and coordinated control, particularly in scenarios with extremely high time synchronization requirements such as green wave traffic and emergency priority—e.g., during peak hours, after large events, and in situations of traffic saturation, dynamic green wave traffic is implemented to ensure bus priority. In this scenario, the signal timing scheme reserves precise and continuous green light windows for bus fleets. However, if vehicles cannot accurately follow guidance instructions, they will miss the green wave window, leading to priority failure and interference with other vehicles. This scenario often presents the following technical problems: the bus driving guidance instruction set issued by the cloud platform experiences delays and deviations when executed on the vehicle, and cannot be adjusted in real-time according to the actual vehicle dynamics. This results in a disconnect between vehicle movement and signal changes, wasting valuable signal priority windows and increasing the uncertain waiting time for buses at intersections. Considering the following requirements for this application scenario: high real-time performance, precise execution, dynamic adaptability, and strong closed-loop feedback, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the execution entity may, in response to the onboard terminal of the corresponding bus receiving the bus driving guidance instruction set, guide the corresponding bus to perform driving operations coordinated with the dynamic signal timing scheme, which may include the following steps: The first step involves using the aforementioned onboard terminal to generate an executable instruction queue corresponding to the bus driving guidance instruction set. This executable instruction queue can be a list of instructions that the bus driving guidance instruction set has been parsed and sorted by the onboard terminal, and is available for vehicle execution. In practice, firstly, the onboard terminal receives and parses the bus driving guidance instruction set from the cloud or roadside. Then, each bus driving guidance instruction (e.g., "stop smoothly at a traffic light") is broken down and converted into atomic instructions that the vehicle can directly understand, with timing and triggering conditions. Finally, these atomic instructions are sorted and encapsulated to form an instruction queue for sequential execution or conditional triggering, serving as the executable instruction queue.

[0068] The second step involves generating a matching result between the command and the current vehicle pose, based on the executable command queue and the vehicle's current pose. The current vehicle pose can be the vehicle's spatial position, orientation, and kinematic state at a given moment. For example, the current vehicle pose could be longitude: 116.3°, latitude: 39.9°, heading angle: 15° east of north, speed: 38 km / h, yaw rate: 0.5° / s. The matching result can be the result of comparing the vehicle's current pose with the requirements of the commands to be executed in the executable command queue. For example, the matching result could be: matching degree: good; speed deviation: +2 km / h (actually faster than the command); estimated remaining time for executing the next command: 3 seconds. In practice, first, the vehicle's current pose (e.g., position, speed, orientation) is acquired. Then, the vehicle's current pose is compared with the triggering conditions (e.g., target position, target speed) of the next command to be executed in the executable command queue. Finally, the matching result is output.

[0069] The third step involves determining the timing of instruction execution based on the matching results of the aforementioned instructions and states, thereby generating an instruction execution trigger signal. This instruction execution trigger signal can be a signal generated when the current instruction triggering conditions are met, initiating instruction execution. For example, the instruction execution trigger signal could be generated when the vehicle is ≤50 meters from the stop line, initiating the instruction to "begin slowing down at 50 meters from the stop line." In practice, firstly, the system monitors the matching results of instructions and states in real time. Then, when the matching result meets the preset precise triggering conditions of the instruction (e.g., reaching a specific location or a specific time point), a decision is made. Finally, an instruction execution trigger signal is generated to initiate the execution process of the corresponding instruction.

[0070] The fourth step involves invoking the vehicle control interface in response to the received instruction execution trigger signal to generate low-level vehicle control commands. This vehicle control interface can be a standard communication interface used by the onboard software system to send instructions to the vehicle's low-level control unit (e.g., a speed control interface conforming to the CAN bus protocol). The low-level vehicle control commands can be low-level control signals issued through the vehicle control interface that can be directly recognized by the vehicle's actuators. In practice, firstly, a preset vehicle control interface can be invoked, and the required low-level control parameters can be calculated. Then, the control parameters are encapsulated into a standard-format low-level vehicle control command.

[0071] The fifth step involves sending the aforementioned low-level vehicle control commands to the vehicle actuators to generate actual vehicle motion response information. These actuators can be hardware components that receive the low-level vehicle control commands and directly drive the vehicle to produce physical actions (e.g., electronic throttle controller, electric power steering motor, electric braking unit). The actual vehicle motion response information can be the actual change in the vehicle's motion state after executing the low-level vehicle control commands. In practice, firstly, the low-level vehicle control commands are sent to the corresponding vehicle actuators (e.g., throttle controller, brake controller) via a bus (such as CAN, Ethernet). Then, the actuators drive vehicle components (such as motors, hydraulic systems) to perform actions according to the commands. Finally, the vehicle produces actual changes in its motion state, forming the actual vehicle motion response information.

[0072] The sixth step involves generating vehicle state feedback data based on the aforementioned actual vehicle motion response information. This vehicle state feedback data can be quantitative monitoring data of the vehicle's actual motion response. For example, it could include real-time parameters such as actual speed, actual acceleration, actual position, and fuel / electricity consumption. In practice, firstly, the vehicle sensor network (e.g., wheel speed sensors, IMU, GPS) collects the actual motion parameters of the vehicle after executing commands in real time. Then, the data processing module filters, fuses, and calculates this raw data. Finally, the vehicle state feedback data is generated.

[0073] Step 7: Based on the vehicle status feedback data and the expected goals of the executable command queue, generate cooperative driving efficiency information. The expected goals can be the ideal state that each command in the executable command queue is designed to achieve. For example, the expected goal of the command "accelerate to 40 km / h within 10 seconds" could be that the vehicle speed precisely reaches 40 km / h at the end of the command. The cooperative driving efficiency information can be quantitative information evaluating the cooperative effect between the vehicle's actual driving and the dynamic signal timing scheme. For example, the cooperative driving efficiency information could be "signal coordination successful, saving 12 seconds" for the vehicle passing through the intersection within the reserved green light time window. In practice, firstly, the vehicle status feedback data is compared with the expected goals of the current command to determine the execution deviation (e.g., speed error, time error). Then, the execution deviation is comprehensively analyzed in conjunction with the requirements of the dynamic signal timing scheme (e.g., passing through the intersection within a specific time window). Finally, cooperative driving efficiency information is generated.

[0074] Step 8: Adjust the executable command queue based on the aforementioned cooperative driving efficiency information to complete the corresponding bus's coordinated driving operation with the aforementioned dynamic signal timing scheme. In practice, firstly, if the deviation of the cooperative driving efficiency information is within the allowable range and does not affect subsequent coordination, the queue remains unchanged. If the deviation is large (e.g., severe lag), then firstly, based on the new vehicle status and remaining time window, replan or adjust the parameters of the commands that have not yet been executed in the executable command queue (e.g., increase the recommended speed for subsequent road segments). Then, replace the original queue with the adjusted new queue. Finally, the system continues to loop from step 1, forming a closed-loop control.

[0075] The above-described operational steps, as an inventive point of this disclosure, solve the technical problem mentioned in the background art: "In emergency scenarios, buses struggle to execute dynamically generated signal priority and scheduling strategies in real time and accurately, resulting in wasted signal priority windows, low overall coordination efficiency, and wasted emergency response time and scheduling resources." The reasons for this technical problem are as follows: there is a lack of real-time and accurate state matching and timing decision-making mechanisms between command generation and actual vehicle execution, and a lack of dynamic feedback and adjustment closed loops based on execution results. This invention constructs a real-time execution and adjustment system on the vehicle terminal, including state matching, timing decision-making, closed-loop control, and feedback optimization. This achieves accurate, timely, and adaptive implementation of cloud / roadside control strategies on the vehicle side, ensuring high-precision spatiotemporal coordination between signals and vehicles, saving bus travel time, and significantly improving the success rate of signal priority and the overall operational efficiency of the road network.

[0076] In some optional implementations of certain embodiments, the aforementioned execution entity may perform the following steps: The first step is to generate corresponding dynamic bus stop service information based on the aforementioned bus driving guidance instruction set. This dynamic bus stop service information can be bus service-related information generated from the bus driving guidance instruction set and published at the bus stop. For example, the dynamic bus stop service information could be that bus route K101 is expected to arrive in 2 minutes, and the current crowding level on the bus is "moderate."

[0077] As an example, firstly, based on the bus driving guidance instruction set, dynamic information related to specific routes and vehicles is extracted (e.g., the latest predicted arrival time of the vehicle, whether there are any skipped stops or detours, and the current speed). Then, combined with static information (e.g., station names, route maps) and additional information obtained from other systems (e.g., weather, predicted passenger congestion), the information is arranged and synthesized according to a preset template and natural language rules that are easy for passengers to understand. Finally, dynamic bus stop service information is generated.

[0078] The second step is to publish the aforementioned dynamic bus stop service information to the corresponding bus stops. These bus stops can be physical or virtual passenger waiting facilities equipped with information publishing terminals. In practice, firstly, based on the vehicle and route information included in the bus stop service information, the target set of bus stops that need to receive this information is determined. Then, a suitable communication protocol (e.g., 4G / 5G, Ethernet) and publishing channel (e.g., station main control system, direct cloud push) are selected to send the information data packet to the target station. Finally, after receiving the data packet, the local control system of the target station drives its information publishing terminal (e.g., LED screen, LCD screen, voice module) to display the information to waiting passengers in a visual, auditory, or a combination of both manner.

[0079] The above embodiments of this disclosure have the following beneficial effects: Through the cloud-edge-device collaborative bus dispatching method of some embodiments of this disclosure, dynamic coordination between buses and traffic signals is achieved, reducing passenger waiting time and bus intersection waiting time. Specifically, the reason for the long passenger waiting time and bus intersection waiting time is that when a route anomaly occurs, it is impossible to quickly aggregate multi-source real-time data and perform global optimization, resulting in delayed dispatching instructions, signal timing decoupling from vehicle guidance, and buses frequently encountering red light stops, leading to extended passenger waiting times. Based on this, the cloud-edge-device collaborative bus dispatching method of some embodiments of this disclosure first, in response to receiving abnormal information about a bus route, sends multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information. The multiple multi-source real-time data are distributed to the roadside edge nodes for local processing. The edge nodes generate low-latency traffic state feature information through data cleaning and feature extraction. This effectively compresses the data volume, reduces cloud processing pressure, and provides a high-quality, structured data foundation for subsequent real-time decision-making. Then, the aforementioned traffic state feature information is sent to the cloud platform, where it is fused with pre-acquired historical data to construct a fused feature vector. This historical data includes historical bus operation data and user travel preference data. Leveraging the powerful computing capabilities of the cloud platform, the multiple traffic state feature information extracted from multiple roadside edge computing nodes, along with historical bus operation data and user preference data, are deeply fused to construct a more predictive fused feature vector that incorporates spatiotemporal dimensions. This allows the scheduling plan to not only be based on the current state but also to conform to historical patterns and user needs. Next, a dynamic scheduling instruction set is generated based on this fused feature vector. Generating a dynamic scheduling instruction set based on the fused feature vector realizes the transformation from data to decision-making. It can automatically formulate scheduling plans such as vehicle adjustments and route optimization based on real-time traffic conditions, capacity demand, and user preferences, improving the rationality and efficiency of resource allocation. Finally, based on the aforementioned dynamic scheduling instruction set and the real-time status of relevant intersection traffic lights, a dynamic signal timing scheme is generated. This dynamic signal timing scheme is used to control the relevant intersection traffic lights. Based on dispatch instructions and the real-time status of traffic lights at intersections, a dynamic signal timing scheme is generated. This achieves vehicle-road cooperation, translating dispatch strategies into specific traffic control instructions and improving the overall traffic efficiency of the road network. Furthermore, based on the aforementioned dynamic dispatch instruction set and dynamic signal timing scheme, a bus driving guidance instruction set is generated. By integrating the dispatch instructions and signal timing scheme, personalized driving guidance instructions are generated for each bus. This transforms macro-level dispatch objectives into micro-level operations executable by individual vehicles, ensuring that vehicles can accurately coordinate with signal cycles for efficient and smooth operation.Finally, in response to the onboard terminal of the corresponding bus receiving the aforementioned bus driving guidance instruction set, the bus is guided to perform driving operations in coordination with the dynamic signal timing scheme. After receiving the guidance instructions, the onboard terminal guides the driver or autonomous driving system to drive according to the instructions through the vehicle control execution system. This step completes the closed loop from cloud-based decision-making to vehicle execution, ensuring the effective implementation of the scheduling scheme and ultimately achieving dynamic coordination between buses and the signal system, shortening passenger waiting time and bus intersection waiting time.

[0080] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a bus dispatching device based on cloud-edge-device collaboration. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this cloud-edge-device collaborative bus dispatching device can be specifically applied to various electronic devices.

[0081] like Figure 2 As shown, a cloud-edge-device collaborative bus dispatching device 200 includes: a sending unit 201, a fusion unit 202, a first generation unit 203, a second generation unit 204, a third generation unit 205, and a guidance unit 206. The sending unit 201 is configured to: in response to receiving abnormal information about a bus route, send multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information. The fusion unit 202 is configured to: send the multiple traffic state feature information to a cloud platform, and fuse the multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, wherein the historical data includes: historical bus operation data and user travel preference data. The first generation unit 203 is configured to: generate a dynamic dispatching instruction set based on the fused feature vector. The second generation unit 204 is configured to: generate a dynamic signal timing scheme based on the dynamic dispatching instruction set and the real-time status of relevant intersection traffic lights, wherein the dynamic signal timing scheme is used to control the relevant intersection traffic lights. The third generation unit 205 is configured to generate a bus driving guidance instruction set based on the aforementioned dynamic scheduling instruction set and the aforementioned dynamic signal timing scheme. The guidance unit 206 is configured to, in response to the on-board terminal of the corresponding bus receiving the aforementioned bus driving guidance instruction set, guide the corresponding bus to perform driving operations coordinated with the aforementioned dynamic signal timing scheme.

[0082] It is understandable that the units described in the cloud-edge-device collaborative bus dispatching device 200 are similar to those in the reference device. Figure 1The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the image segmentation apparatus 200 and the units contained therein, and will not be repeated here.

[0083] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0084] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0085] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0086] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0087] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0088] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0089] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following actions: In response to receiving abnormal information about a bus route, it sends multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information; it sends the multiple traffic state feature information to a cloud platform, and on the cloud platform, it fuses the multiple traffic state feature information with pre-acquired historical data to construct a fused feature vector, wherein the historical data includes: historical bus operation data and user travel preference data; based on the fused feature vector, it generates a dynamic dispatch instruction set; according to the dynamic dispatch instruction set and the real-time status of the relevant intersection traffic lights, it generates a dynamic signal timing scheme, wherein the dynamic signal timing scheme is used to control the relevant intersection traffic lights; according to the dynamic dispatch instruction set and the dynamic signal timing scheme, it generates a bus driving guidance instruction set; in response to the on-board terminal of the corresponding bus receiving the bus driving guidance instruction set, it guides the corresponding bus to perform driving operations coordinated with the dynamic signal timing scheme.

[0090] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0092] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a sending unit, a fusion unit, a first generation unit, a second generation unit, a third generation unit, and a guiding unit. The names of these units do not necessarily limit the specific unit itself. For example, a sending unit may be described as "a unit that, in response to receiving abnormal information about a bus route, sends multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple corresponding traffic state feature information."

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0094] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A bus dispatching method based on cloud-edge-device collaboration, comprising: In response to receiving abnormal information about a bus route, multiple multi-source real-time status data corresponding to the bus route are sent to multiple corresponding roadside edge computing nodes to generate multiple traffic status feature information, wherein the abnormal information refers to information on unplanned events that occur during bus operation. The multiple traffic status feature information is sent to the cloud platform, and the multiple traffic status feature information is fused with pre-acquired historical data on the cloud platform to construct a fused feature vector, wherein the historical data includes: public transport historical operation data and user travel preference data; Based on the fused feature vector, a dynamic scheduling instruction set is generated; Based on the dynamic scheduling instruction set and the real-time status of the relevant intersection traffic lights, a dynamic signal timing scheme is generated, wherein the dynamic signal timing scheme is used to control the relevant intersection traffic lights, including: Based on the aforementioned dynamic scheduling instruction set, bus priority scheduling demand information is generated; Based on the real-time status of the traffic lights at the relevant intersections, the current signal cycle and phase timing information of the traffic lights at the relevant intersections are generated; Based on the current signal cycle and phase timing information and the bus priority scheduling demand information, a signal adjustment request queue is generated; Based on the signal adjustment request queue, a preliminary green wave timing parameter set is generated using a pre-built green wave band coordination control model; Based on the preliminary green wave timing parameter set and real-time traffic flow data, a timing scheme evaluation report is generated; Based on the timing scheme evaluation report and the preset balance optimization strategy information, the preliminary green wave timing parameter set is corrected to generate an optimized green wave timing parameter set; The optimized green wave timing parameter set is encoded into standard traffic control protocol instructions to generate a dynamic signal timing scheme. Based on the dynamic scheduling instruction set and the dynamic signal timing scheme, a bus driving guidance instruction set is generated; In response to the onboard terminal of the corresponding bus receiving the bus driving guidance instruction set, the corresponding bus is guided to perform driving operations in coordination with the dynamic signal timing scheme.

2. The method according to claim 1, wherein, The method further includes: Based on the bus driving guidance instruction set, corresponding dynamic bus stop service information is generated; The dynamic bus stop service information will be published to the corresponding bus stops.

3. The method according to claim 1, wherein, In response to receiving abnormal information about a bus route, the system sends multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic state feature information, including: Determine the target area corresponding to the abnormal information of the bus route; Multiple multi-source real-time status data are obtained from multiple terminal devices within the target area; For each of the multiple multi-source real-time status data, perform the following steps: The multi-source real-time status data is uploaded to the corresponding roadside edge computing nodes, and the multi-source real-time status data is preprocessed on the roadside edge computing nodes to obtain a preprocessed dataset. Key features are extracted from the preprocessed dataset to generate an initial feature set; The initial feature set is fused with the local historical traffic pattern data stored in the roadside edge computing node to generate corresponding traffic state feature information.

4. The method according to claim 1, wherein, The step of sending the multiple traffic state feature information to the cloud platform, and fusing the multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, includes: Perform the following steps on the cloud platform: The multiple traffic state feature information is integrated into global traffic state feature information; The overall traffic state feature information is standardized to obtain standardized feature information; The standardized feature information is associated with similar scene patterns in the historical bus operation data to obtain enhanced feature information with historical reference labels; Based on the user travel preference data, the enhanced feature information with historical reference tags is adaptively adjusted to generate feature information with user demand information. Based on the feature information of existing user demand information, a spatiotemporal topology graph is constructed; Based on the spatiotemporal topology map, generate global optimal path probability distribution information; Based on the global optimal path probability distribution information, a fusion feature vector is generated.

5. The method according to claim 1, wherein, The generation of a dynamic scheduling instruction set based on the fused feature vector includes: Based on the fused feature vector, network state quantification index information is generated; Based on the network state quantification index information, multi-level scheduling target information is generated; Based on the multi-level scheduling target information and preset constraint information, a multi-objective optimization model is constructed; Based on the aforementioned multi-objective optimization model and objective algorithm, a set of candidate solutions is generated; The candidate solution set is filtered using preset decision rules to generate a target solution; The target scheme is converted into executable control instructions to generate a dynamic scheduling instruction set.

6. A bus dispatching device based on cloud-edge-device collaboration, comprising: The sending unit is configured to, in response to receiving abnormal information about a bus route, send multiple multi-source real-time status data corresponding to the bus route to multiple corresponding roadside edge computing nodes to generate multiple traffic status feature information, wherein the abnormal information refers to information about unplanned events that occur during bus operation. The fusion unit is configured to send the multiple traffic state feature information to a cloud platform, and to fuse the multiple traffic state feature information with pre-acquired historical data on the cloud platform to construct a fused feature vector, wherein the historical data includes: public transport historical operation data and user travel preference data; The first generation unit is configured to generate a dynamic scheduling instruction set based on the fused feature vector; The second generation unit is configured to generate a dynamic signal timing scheme based on the dynamic scheduling instruction set and the real-time status of the relevant intersection traffic lights, wherein the dynamic signal timing scheme is used to control the relevant intersection traffic lights, including: Based on the aforementioned dynamic scheduling instruction set, bus priority scheduling demand information is generated; Based on the real-time status of the traffic lights at the relevant intersections, the current signal cycle and phase timing information of the traffic lights at the relevant intersections are generated; Based on the current signal cycle and phase timing information and the bus priority scheduling demand information, a signal adjustment request queue is generated; Based on the signal adjustment request queue, a preliminary green wave timing parameter set is generated using a pre-built green wave band coordination control model; Based on the preliminary green wave timing parameter set and real-time traffic flow data, a timing scheme evaluation report is generated; Based on the timing scheme evaluation report and the preset balance optimization strategy information, the preliminary green wave timing parameter set is corrected to generate an optimized green wave timing parameter set; The optimized green wave timing parameter set is encoded into standard traffic control protocol instructions to generate a dynamic signal timing scheme. The third generation unit is configured to generate a bus driving guidance instruction set based on the dynamic scheduling instruction set and the dynamic signal timing scheme. The guidance unit is configured to guide the corresponding bus to perform driving operations in coordination with the dynamic signal timing scheme in response to the on-board terminal of the corresponding bus receiving the bus driving guidance instruction set.

7. An electronic device, comprising: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-5.

8. A computer-readable medium having a computer program stored thereon, wherein, When the program is executed by the processor, it implements the method as described in any one of claims 1-5.

Images