Vehicle path processing method based on traffic events

Abstract

This application provides a vehicle routing method based on traffic events. The method includes: acquiring multiple traffic events; wherein the multiple traffic events originate from at least two event sources; constructing a trusted event set based on the multiple traffic events; wherein the trusted event set includes multiple trusted events, each of which has undergone standardization and has the same event description structure; generating a vehicle routing plan based on the trusted event set, and pushing the routing plan result to the vehicle. This method aims to achieve unified processing of traffic events from different sources, improving the compatibility of information sources during vehicle routing.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle routing method based on traffic events. Background Technology

[0002] In vehicle navigation scenarios, information related to road traffic events can be obtained in real time, such as V2X information (Vehicle to Everything), and vehicle route planning can be performed based on these traffic events.

[0003] In some technologies, V2X information used to characterize traffic events comes from multiple sources, such as roadside units, vehicle-mounted units, and cloud platforms. The different formats of this V2X information from various sources make it difficult to process traffic events uniformly, resulting in poor information source compatibility issues for path processing.

[0004] Therefore, there is an urgent need for a solution that can uniformly process traffic incident information from different sources. Summary of the Invention

[0005] The vehicle routing method based on traffic events provided in this application is used to achieve unified processing of traffic events from different sources, thereby improving the compatibility of information sources during the vehicle routing process.

[0006] In a first aspect, embodiments of this application provide a vehicle routing method based on traffic events, applied on a server side, the method comprising:

[0007] Acquire multiple traffic events; wherein the multiple traffic events originate from at least two event sources;

[0008] Based on multiple traffic events, a set of trusted events is constructed. The set of trusted events includes multiple trusted events, each of which has been standardized and has the same event description structure.

[0009] Based on the set of trusted events, the system generates the vehicle's route planning results and pushes these results to the vehicle.

[0010] In one possible implementation, a set of trusted events is constructed based on multiple traffic events, including:

[0011] For each traffic incident in a series of traffic incidents, standardization is performed to obtain corresponding candidate incidents; among them, the event description structure of each candidate incident is the same.

[0012] Calculate the credibility of each candidate event, and take the candidate events with credibility greater than or equal to the first threshold as credible events;

[0013] Construct a set of trusted events based on trusted events.

[0014] In one possible implementation, the event description structure includes: event type, event occurrence time, event occurrence location, event priority, and suggested action corresponding to the event.

[0015] In one possible implementation, the method further includes:

[0016] Based on the event occurrence time, event location, and corresponding suggested action in the event description structure, at least one conflict event combination is determined; wherein, the conflict event combination includes at least two credible events, and the credible events in the conflict event combination satisfy preset conditions; the preset conditions indicate that the event occurrence time is within the same time range, the event location points to the same road segment, and the corresponding suggested actions are inconsistent;

[0017] Select one trusted event from the combination of conflicting events as the target event, and remove all other trusted events from the set of trusted events.

[0018] In one possible implementation, one credible event is selected as the target event from the combination of conflicting events, including at least one of the following:

[0019] Select life safety events as target events from the combination of conflict events;

[0020] Select the most credible event from the combination of conflicting events as the target event;

[0021] Select the credible event with the highest correlation to the path planning result from the combination of conflict events as the target event.

[0022] In one possible implementation, the route planning result includes a first path applied to a first vehicle and a second path applied to a second vehicle; wherein the first vehicle is the lead vehicle in the convoy, and the second vehicle is a follower vehicle in the convoy; the route planning result for the vehicles is generated based on a set of reliable events, including:

[0023] Based on a set of trusted events and a pre-defined reference map, a first path is generated.

[0024] Based on the first path, multiple candidate paths are generated based on at least one preset constraint.

[0025] Based on the preset objective function, the function value of the objective function of each candidate path is calculated, and the candidate path with the smallest objective function value is selected as the second path.

[0026] In one possible implementation, the method further includes:

[0027] If the difference in the objective function values ​​of any two candidate paths is greater than or equal to the second threshold, then the objective region of the second path is replanned; and / or,

[0028] If a candidate event is determined to change from the first state to the second state, the target area of ​​the second path is replanned. The first state is when the credibility of the candidate event is less than the first threshold, and the second state is when the credibility of the candidate event is greater than or equal to the first threshold.

[0029] The target area is the area within a preset distance in front of the current position of the second vehicle in the second path.

[0030] In one possible implementation, the method further includes:

[0031] The system receives driving information from the first vehicle and the second vehicle, and adjusts the weights or threshold information in the objective function based on the driving information; wherein the threshold information is one or more of the first threshold and the second threshold.

[0032] In one possible implementation, the route planning results are pushed to the vehicle, including:

[0033] Based on the first path, a first interaction model and a first speech strategy corresponding to the first path are generated; and based on the second path, a second interaction model and a second speech strategy corresponding to the second path are generated.

[0034] The first path, the first interaction model, and the first voice strategy are pushed to the first vehicle; and the second path, the second interaction model, and the second voice strategy are pushed to the second vehicle.

[0035] In one possible implementation, the method further includes:

[0036] If it is determined that the number of trusted events in the trusted event set is less than the third threshold within a preset period, a degraded state is triggered. In the degraded state, the path planning result is formed without considering the trusted event set, based only on the vehicle's current location and destination location.

[0037] Secondly, embodiments of this application provide a vehicle routing processing device based on traffic events, comprising:

[0038] The acquisition module is used to acquire multiple traffic events; wherein the multiple traffic events originate from at least two event sources;

[0039] The building module is used to construct a set of trusted events based on multiple traffic events. The set of trusted events includes multiple trusted events, each of which has been standardized and has the same event description structure.

[0040] The generation module is used to generate the vehicle's route planning results based on a set of trusted events, and then push the route planning results to the vehicle.

[0041] In one possible implementation, a trusted event set is constructed based on multiple traffic events, and the construction module is used for:

[0042] For each traffic incident in a series of traffic incidents, standardization is performed to obtain corresponding candidate incidents; among them, the event description structure of each candidate incident is the same.

[0043] Calculate the credibility of each candidate event, and take the candidate events with credibility greater than or equal to the first threshold as credible events;

[0044] Construct a set of trusted events based on trusted events.

[0045] In one possible implementation, the event description structure includes: event type, event occurrence time, event occurrence location, event priority, and suggested action corresponding to the event.

[0046] In one possible implementation, the building module is also used for:

[0047] Based on the event occurrence time, event location, and corresponding suggested action in the event description structure, at least one conflict event combination is determined; wherein, the conflict event combination includes at least two credible events, and the credible events in the conflict event combination satisfy preset conditions; the preset conditions indicate that the event occurrence time is within the same time range, the event location points to the same road segment, and the corresponding suggested actions are inconsistent;

[0048] Select one trusted event from the combination of conflicting events as the target event, and remove all other trusted events from the set of trusted events.

[0049] In one possible implementation, one trusted event is selected from the combination of conflicting events as the target event, and the building module is used to perform at least one of the following:

[0050] Select life safety events as target events from the combination of conflict events;

[0051] Select the most credible event from the combination of conflicting events as the target event;

[0052] Select the credible event with the highest correlation to the path planning result from the combination of conflict events as the target event.

[0053] In one possible implementation, the route planning result includes a first path applied to the first vehicle and a second path applied to the second vehicle; wherein the first vehicle is the lead vehicle in the convoy, and the second vehicle is the following vehicle in the convoy; based on a set of reliable events, the route planning result for the vehicles is generated, and the generation module is used to:

[0054] Based on a set of trusted events and a pre-defined reference map, a first path is generated.

[0055] Based on the first path, multiple candidate paths are generated based on at least one preset constraint.

[0056] Based on the preset objective function, the function value of the objective function of each candidate path is calculated, and the candidate path with the smallest objective function value is selected as the second path.

[0057] In one possible implementation, the generation module is further configured to:

[0058] If the difference in the objective function values ​​of any two candidate paths is greater than or equal to the second threshold, then the objective region of the second path is replanned; and / or,

[0059] If a candidate event is determined to change from the first state to the second state, the target area of ​​the second path is replanned. The first state is when the credibility of the candidate event is less than the first threshold, and the second state is when the credibility of the candidate event is greater than or equal to the first threshold.

[0060] The target area is the area within a preset distance in front of the current position of the second vehicle in the second path.

[0061] In one possible implementation, the generation module is further configured to:

[0062] The system receives driving information from the first vehicle and the second vehicle, and adjusts the weights or threshold information in the objective function based on the driving information; wherein the threshold information is one or more of the first threshold and the second threshold.

[0063] In one possible implementation, the route planning results are pushed to the vehicle, and the generation module is used for:

[0064] Based on the first path, a first interaction model and a first speech strategy corresponding to the first path are generated; and based on the second path, a second interaction model and a second speech strategy corresponding to the second path are generated.

[0065] The first path, the first interaction model, and the first voice strategy are pushed to the first vehicle; and the second path, the second interaction model, and the second voice strategy are pushed to the second vehicle.

[0066] In one possible implementation, the building module is also used for:

[0067] If it is determined that the number of trusted events in the trusted event set is less than the third threshold within a preset period, a degraded state is triggered. In the degraded state, the path planning result is formed without considering the trusted event set, based only on the vehicle's current location and destination location.

[0068] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0069] The memory stores instructions that the computer executes;

[0070] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0071] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0072] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0073] The vehicle routing method based on traffic events provided in this application obtains multiple traffic events from at least two event sources, constructs a set of credible events containing multiple credible events based on these multiple traffic events, and standardizes each credible event to give it the same event description structure. This enables unified expression and reliable integration of multi-source traffic events, reducing the impact of event conflicts, duplicate reporting, and expression differences on route decisions. Furthermore, the method generates route planning results for vehicles based on the credible event set and pushes them to the vehicle, improving the accuracy, consistency, real-time performance, and stability of route planning during multi-vehicle cooperative navigation. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 1 ;

[0076] Figure 2 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 2 ;

[0077] Figure 3 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 3 ;

[0078] Figure 4 A schematic diagram of the vehicle routing processing device based on traffic events provided in this application;

[0079] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0080] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0082] With the popularization of V2X (Vehicle to Everything) technology, vehicles can obtain real-time information on beyond-line-of-sight traffic events such as traffic light status, construction zone information, intersection perception data, and warnings of vehicles with broken-down vehicles ahead through communication methods such as V2V (vehicle-to-vehicle), V2I (vehicle-to-infrastructure), V2P (vehicle-to-pedestrian), and V2N (vehicle-to-network).

[0083] This technology is intended for use in scenarios where vehicles acquire traffic events and process routes through vehicle-to-everything (V2X) communication. For example, roadside equipment, in-vehicle devices, or network platforms generate traffic events such as construction, congestion, traffic light status, and accident warnings. The server then aggregates the relevant event information and outputs navigation or route results to the vehicle.

[0084] In some embodiments, traffic events from different sources are typically integrated into the navigation platform, and vehicle routes are calculated or adjusted based on the received event information. That is, traffic events are used as navigation input to suggest detours, slowing down, or changing routes. In cases where the event source is single and the event structure is relatively uniform, the above embodiments can achieve basic event-assisted navigation functions.

[0085] However, with the development of V2X information technology, issues such as inconsistent protocols, timestamps, and coordinate systems among multiple vendors' V2X information will arise. This means that multiple traffic events often originate from at least two sources, and these sources differ in protocol format, time base, location representation, and event semantics. This can lead to the same event being reported repeatedly, or to inconsistent or even conflicting descriptions.

[0086] For example, inconsistent event description structures from different sources (such as roadside units and vehicle-mounted units) and misalignment of timestamps and coordinate systems can lead to event conflicts or misjudgments. To address this issue, some embodiments simply overlay these events without providing a reliable filter after unified processing of multi-source events, making it difficult to accurately determine which events are truly relevant to the current path.

[0087] These defects further affect the stability and accuracy of the route processing results. When the server directly plans based on events of varying quality, it can easily lead to frequent route changes and inconsistent prompts. Especially in multi-vehicle cooperative driving scenarios, it may also cause problems such as asynchronous route adjustments between vehicles, increased replanning burden, and a decline in navigation experience.

[0088] In view of this, how to effectively integrate traffic events from multiple event sources on the server side and generate stable vehicle route planning results accordingly has become an urgent technical problem to be solved.

[0089] The vehicle routing method based on traffic events provided in this application obtains multiple traffic events, constructs a set of credible events based on the multiple traffic events, standardizes each credible event and gives it the same event description structure, and then generates the vehicle's route planning result based on the set of credible events and pushes it to the vehicle, thereby improving the consistency of multi-source event utilization and the reliability of route processing.

[0090] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0091] Figure 1 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 1 ,like Figure 1 As shown, this method is applied to the server side and includes:

[0092] Step 101. Obtain multiple traffic events.

[0093] In some cases, the sources of traffic incidents were at least two.

[0094] For example, the vehicle route processing method provided in this embodiment can be deployed on the server side and cooperate with the vehicle side to complete the route result distribution, so as to adapt to the navigation application requirements in the Internet of Vehicles environment.

[0095] The server, as the main body executing the method, is responsible for the centralized access, parsing, and processing of multiple traffic events.

[0096] Traffic events are input data for path processing, used to characterize traffic status information in the road network, such as construction, road closures, congestion, accidents, changes in traffic light status, warnings of disabled vehicles, temporary traffic control, or lane-level traffic restrictions.

[0097] The source of an event is used to limit the origin of a traffic event to at least two different information sources. These at least two event sources can be any two or more of the following: roadside equipment, vehicle-mounted equipment, cloud platform, traffic management access platform, or third-party road information platform. Different sources report event data to the server through their respective communication links.

[0098] In one possible embodiment, the server is pre-configured with a multi-source access module, which corresponds to the cellular vehicle-to-everything (V2X) interface, the Internet message interface, the leased line interface, or the message queue interface. Each interface receives traffic event messages according to the corresponding protocol and adds a reception timestamp, source identifier, access channel identifier, and message sequence number to each traffic event.

[0099] In some cases, for events originating from roadside equipment, the server can receive reporting messages through the vehicle-to-everything (V2X) platform, which include the equipment number, event type, event location, time of occurrence, and duration.

[0100] In other scenarios, for events originating from in-vehicle devices, the server can receive event messages formed from anonymous vehicle identifiers, abnormal vehicle speed, emergency braking, hazard warning light activation, camera recognition results, and vehicle location information.

[0101] In other cases, for events originating from a cloud platform, the server can receive aggregated road congestion indices, construction notices, accident notices, and traffic control information from the platform.

[0102] Subsequently, after receiving multiple traffic events, the server parses the data in different protocol formats, converting binary messages, structured messages, or text-based interface return content into internal event objects. The internal event objects contain at least a source field, an original event type field, a time field, a location field, and additional attribute fields.

[0103] In another possible embodiment, to ensure that subsequent processing is executed continuously, the server also performs a pre-check on events that lack necessary fields.

[0104] Specifically, for data that is missing one of the location, time, or event type and cannot be completed, it is marked as an unavailable event and the current build process is exited; for data that is missing only some fields but can be completed through the source context, it is completed based on the reported device registration information, road matching results, or the most recent valid status.

[0105] For example, the location field can be reported in the form of latitude and longitude coordinates, road number plus station number, intersection number plus entrance lane number or lane number, etc. The server retains the original expression in this step and will be uniformly standardized later.

[0106] Furthermore, the server can aggregate multiple traffic events acquired according to the event occurrence time window, for example, by using 30 seconds, 60 seconds, or 120 seconds as an access batch, and sending events from at least two event sources within the same time window as a group of candidate inputs to the next step.

[0107] Optionally, for persistent events, the event's expiration date can be updated upon receiving a state maintenance message. It should be understood that the above examples are merely illustrative and not limiting.

[0108] Step 102. Construct a set of trusted events based on multiple traffic events.

[0109] The trusted event set includes multiple trusted events, each of which has undergone standardization and has the same event description structure.

[0110] For example, the trusted event set is the basis of route planning, and each trusted event in the trusted event set is generated by processing multiple traffic events.

[0111] Trusted events are valid events that the server determines can participate in route planning. Standardization is used to convert traffic events from different sources, in different formats, and with different semantic expressions into a unified expression.

[0112] The event description structure is used to define the unified field organization of trusted events within the server, so that each trusted event has a unified representation, which facilitates subsequent vehicle route planning processing.

[0113] In one possible embodiment, the server first reads multiple traffic events from the event input pool and establishes a unified event description structure. Then, it performs standardization processing on the multiple traffic events, which may specifically include time standardization, spatial standardization, type standardization, and semantic standardization.

[0114] In the time standardization process, the server converts local time, platform time, or millisecond-level timestamps used by different sources into standard time under a unified time zone, and determines the valid time information of the event based on the event's duration.

[0115] In spatial standardization, the server converts different location representations into unified map coordinates and performs map matching to locate events to the corresponding road objects.

[0116] In type standardization, the server maps event categories with inconsistent definitions from different sources to a unified event type according to a preset mapping relationship.

[0117] In semantic standardization, the server converts different expressions into computable traffic impact information. After standardization, the server merges and organizes multiple traffic events to form a credible event set with a unified descriptive structure.

[0118] By standardizing all trusted events in the trusted event set and ensuring they have the same event description structure, the server can standardize V2X information from different sources, reducing path fluctuations caused by differences in original event formats, duplicate reporting, and semantic differences. It should be understood that the above example is merely illustrative and not limiting.

[0119] Step 103. Generate the vehicle's route planning result based on the set of trusted events, and push the route planning result to the vehicle.

[0120] For example, the path planning result is executable path data output by the server based on a set of trusted events. After receiving the result, the vehicle displays the route, broadcasts navigation, or follows the autonomous driving path accordingly.

[0121] The route planning results may include the road link sequence from the origin to the destination for the target vehicle, lane-level traffic guidance, key turning points, estimated travel time, constraints affected by traffic events, and result version number.

[0122] In one possible embodiment, the server first obtains the current location, destination, vehicle attributes, and navigation context of the vehicle to be planned. The vehicle attributes may include vehicle type, size, height and weight restrictions, whether entry into a specific controlled area is permitted, etc., and the navigation context may include the current route already traveled, the intermediate points confirmed by the user, and the most recent route version.

[0123] Subsequently, the server maps the set of trusted events onto the reference map and performs a path search based on the updated road network. The generated path planning results are then serialized and packaged, and pushed to the vehicle via vehicle-to-everything (V2X) communication links, mobile data links, or long-connection message channels.

[0124] Specifically, the pushed data should include at least vehicle identifier, path geometry information, key maneuver points, event summary, generation time, and version number. The vehicle receives the data and replaces or updates the results based on the version number. It should be understood that the above example is for illustrative purposes only and is not a limitation.

[0125] The vehicle routing method based on traffic events provided in this application involves the server-side receiving traffic events reported from at least two event sources and performing standardized processing on multiple traffic events to form a set of credible events with the same event description structure. This set of credible events is then mapped to traffic constraints and cost constraints on the road network to generate route planning results. Thus, multi-source heterogeneous traffic events no longer directly affect route planning in their original form, but are transformed into inputs for processing vehicle route planning results under a unified event model. This establishes a stable correspondence between route planning results and event changes, and reduces frequent route changes caused by repetition or inconsistent representation of multi-source events.

[0126] Figure 2 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the illustrated embodiment, the process of constructing a trusted event set in step 102 is described in detail. The method includes:

[0127] Step 201. Standardize each traffic event among multiple traffic events to obtain the corresponding candidate events.

[0128] The event description structure is the same for all candidate events.

[0129] Step 202. Calculate the credibility of each candidate event, and take the candidate events with credibility greater than or equal to the first threshold as credible events.

[0130] Step 203. Construct a set of trusted events based on trusted events.

[0131] For example, in a specific implementation, after receiving multiple traffic events, the server first parses the event information from different sources, with different protocol formats and different spatial representations, and then converts it into a unified candidate event structure.

[0132] In some cases, the server maps semantics such as "construction", "accident", "congestion", and "abnormal signal status" to predefined event category codes based on the event type.

[0133] In other cases, for time information, the source time is uniformly converted to the same time zone and the same time base.

[0134] In other cases, for location fields, latitude and longitude, road segment identifiers, or mileage markers are converted into unified road topology coordinates.

[0135] In cases where the same traffic incident is reported multiple times, the server retains multiple corresponding candidate events and records the source identifier and reporting time in each candidate event for subsequent credibility calculation.

[0136] For example, during the credibility calculation process, the server can assign source weights based on the historical accuracy of the candidate event's source, and then generate a credibility value by combining the spatial deviation between the event and the current map positioning result, the time difference with neighboring reported events, and the repeated confirmation of the same event by different sources.

[0137] Specifically, if the credibility of a candidate event is greater than or equal to the first threshold, the candidate event is determined to be a credible event and added to the credible event set; if it is lower than the first threshold, it is not included in the credible event set. The credible event set, composed of multiple credible events, continues to maintain a unified event description structure so that the subsequent path planning module can directly call it.

[0138] In one possible embodiment, a candidate event can be obtained by weighted summation of multiple credibility calculation terms. These multiple credibility calculation terms include: message source reliability, time freshness, multi-source consensus, and the degree of spatial consistency between the candidate event and the current route, direction, and lane semantics.

[0139] The weighted summation can be understood as follows: each credibility calculation item has a corresponding weight value, and the sum of the weight values ​​of all credibility calculation items is 1.

[0140] Among them, the reliability of the message source is exemplified by the fact that the RSU (Road Side Unit) has a higher priority than the OBU (On-Board Unit); the time freshness is exemplified by the difference between the event timestamp and the current time; the spatial consistency is exemplified by the matching degree between the event and the current route; and the multi-source consensus is exemplified by the consistency of descriptions of the same event from different sources.

[0141] Optionally, the weights of the calculated items can be dynamically adjusted based on the event type. For example, in a construction scenario, the weight of spatial consistency is increased to 60%, while the weight of time freshness is reduced to 20%. Through this calculation method, the system can filter out high-confidence events and low-confidence events (such as duplicate reports or misjudged events), thereby reducing path planning deviations caused by low-quality events.

[0142] Furthermore, the credibility of the candidate event can be calculated using the weighted summation method described above. The first threshold can be set to 0.5. It is understood that the specific value of the first threshold can also be set to other values ​​such as 0.8, 0.6, or 0.7, and this embodiment does not limit this.

[0143] Specifically, candidate events can be categorized into three levels—high credibility, medium credibility, and low credibility—based on their credibility. Specifically, when the credibility is greater than or equal to 0.8, the candidate event is classified as high credibility and placed in the high-priority event set; when the credibility is less than 0.8 but greater than or equal to 0.5, the candidate event is classified as medium credibility and needs to be reinforced with historical continuity or other sources before being included in the planning process; when the credibility is less than 0.5, the candidate event is classified as low credibility, and only logs are recorded, without directly triggering collaborative actions.

[0144] In the above embodiments, a feature vector can also be constructed for each candidate event. This feature vector includes multiple feature dimensions, including: V2X information type, V2X information source identifier, timestamp, lifespan, geographic location information, lane information, message priority, contextual cues, and consensus confidence.

[0145] Optionally, based on the feature vector of each candidate event, multiple metrics can be calculated for the candidate event. These metrics include: route relevance, lane consistency, time freshness, and multi-source consensus.

[0146] Specifically, route relevance is used to characterize whether a candidate event hits the current route or the forward candidate subgraph in the reference map; lane consistency is used to characterize the degree of consistency between the candidate event and the vehicle's current or target lane in terms of direction; time freshness is calculated based on the timestamp of the V2X information corresponding to the candidate event and the current time; and multi-source consensus is used to characterize the degree of consistency between different V2X information sources for the same event in terms of space, time, and semantics.

[0147] In the above embodiments, multi-source traffic events are first standardized on the server side, and then subjected to reliable screening. This ensures that events entering the reliable event set have a unified description and comparable reliability indicators. The reliable event set retains only event objects that meet the threshold requirements and provides structurally consistent and highly reliable input data for subsequent route planning, thereby maintaining the stability of the computational basis for the route results. Since all candidate events participate in reliability determination under the same structure, the system can complete event integration and screening with unified rules, thereby improving the stability and consistency of vehicle route processing results.

[0148] Based on the foregoing embodiments, in one example, the event description structure includes: event type, event occurrence time, event occurrence location, event priority, and suggested action corresponding to the event.

[0149] For example, in specific implementation, after the server obtains traffic events from at least two event sources, it first performs a unified mapping on the protocol fields of different sources, converts the time expression of each event into the same time base, converts the location expression into the same spatial reference, and supplements each event with event type, event occurrence time, event occurrence location, event priority, and suggested action corresponding to the event, thereby forming candidate events with consistent structure.

[0150] Among them, the event priority can be determined according to the event category, the scope of the event's impact, and the event's risk level; the suggested actions can be generated according to the event type and the location of the event, corresponding to a preset action table.

[0151] After standardization, each candidate event enters the credibility calculation and screening process, and participates in the subsequent construction of the credibility event set with the same event description structure.

[0152] For example, through standardization, candidate events represented by V2X information from different sources can be compared, conflict-determined, and path association analyzed under the same field system. When multiple candidate events have the same or similar event occurrence time and location, the differences between events are identified based on event priority and suggested actions. Events that meet the credibility requirements are retained as credible events, and path planning results are generated based on the credible events and pushed to the vehicle.

[0153] By adopting the above event description structure, the server can express multi-source traffic events in a homogeneous manner, ensuring consistency between subsequent credibility calculations, conflict resolution, and route planning inputs. This improves the consistency of event integration and makes the correspondence between route planning results and actual traffic conditions more stable.

[0154] Based on the above example, if multiple events pointing to the same road segment within a certain time range have conflicting suggested actions, the conflict resolution mechanism is triggered to filter the multiple events pointing to the same road segment within that time range.

[0155] In one possible implementation, the method further includes:

[0156] Based on the event occurrence time, event location, and corresponding suggested actions in the event description structure, at least one combination of conflicting events is identified.

[0157] The conflict event combination includes at least two credible events, and the credible events in the conflict event combination meet preset conditions. The preset conditions indicate that the events occur within the same time range, the events occur at the same road segment, and the suggested actions corresponding to the events are inconsistent.

[0158] Select one trusted event from the combination of conflicting events as the target event, and remove all other trusted events from the set of trusted events.

[0159] For example, in specific implementation, the server can perform time clustering on trusted events based on the event occurrence time, group multiple trusted events falling within the same preset time range into the same candidate group, and further filter out the event set pointing to the same road segment based on the road segment mapping results of the event occurrence location.

[0160] When the suggested actions corresponding to multiple credible events within the same set differ, a conflicting event combination is determined to exist. This difference in suggested actions may manifest as one event instructing the vehicle to slow down and proceed, while another event instructs the vehicle to detour, or one event instructing the vehicle to continue along the original route while another event instructs the vehicle to change routes.

[0161] The server can select one trusted event as the target event based on the trustworthiness, event source weight, event priority, or update timestamp of each trusted event in the conflict event combination, and retain the target event in the trusted event set, while removing the other trusted events that conflict with it from the trusted event set.

[0162] In the example above, by identifying a set of conflicting events, selecting a target event, and eliminating other reliable events, the server can identify events with inconsistent suggested actions within the same time frame and road segment. It then performs convergence processing on these conflicting events, ensuring the uniqueness and consistency of the events ultimately included in the route planning. This reduces the likelihood of different suggested actions occurring at the same time and on the same road segment, improves the accuracy of subsequent route planning results generated based on the reliable event set, reduces interference from contradictory events in route calculation, and ensures consistency in the navigation results pushed to the vehicle.

[0163] Furthermore, in the above example, the process of selecting one of the trusted events as the target event may include at least one of the following:

[0164] Scenario 1: Select a life safety event as the target event from the combination of conflict events.

[0165] Scenario 2: Select the most credible event from the combination of conflicting events as the target event.

[0166] Scenario 3: Select the most credible event with the highest correlation to the path planning result from the combination of conflict events as the target event.

[0167] For example, in a specific implementation, after determining the combination of conflicting events, the server first judges the event type of each trusted event in the combination in order to identify whether there are any life safety events among them.

[0168] In some cases, when a life-threatening event exists, that event is directly selected as the target event, and the corresponding trusted events for the remaining conflicting events are removed from the trusted event set. If no life-threatening event exists in the combination of conflicting events, the trusted events are compared based on their credibility, and the one with the highest credibility is selected as the target event.

[0169] Furthermore, if multiple credible events with the highest credibility are listed in parallel, their correlation with the current path planning results can be used for further filtering to determine the unique target event.

[0170] In other cases, if the system is pre-set to prioritize relevance, the most credible event with the highest relevance to the path planning result can be selected directly from the combination of conflict events as the target event. The relevance can be calculated by the current vehicle location, the target destination, the route cost, and the impact of the event on the path capacity.

[0171] After selecting a target event, the server retains the target event and updates the trusted event set synchronously, so that subsequent path planning is performed only based on the retained events.

[0172] It should be noted that the examples represented by the above-mentioned situations can be implemented individually or in combination.

[0173] By adopting the above-mentioned method for selecting target events, the server can prioritize events that have a higher impact on security, higher credibility, or are more relevant to the current path when conflicting events coexist. This ensures that the path planning results are consistent with the actual traffic conditions and improves the effectiveness of events after the conflicting events are filtered.

[0174] Based on any of the foregoing embodiments or examples, in one example, the vehicle routing method provided in this application embodiment can be applied to routing processing for fleet collaboration.

[0175] For example, a convoy includes a lead vehicle and at least one follower vehicle. For ease of explanation, the lead vehicle will be referred to as vehicle number one and the follower vehicle as vehicle number two.

[0176] Understandably, based on this, the path planning results include a first path applied to the first vehicle and a second path applied to the second vehicle.

[0177] For example, the first path can be understood as the main path of the lead vehicle, and the second path can be understood as the following path of the following vehicles under the main path and related constraints.

[0178] In some cases, the second path is calculated based on the first path using a pre-defined joint objective function. This objective function can achieve multi-objective optimization, where multiple objectives may include, but are not limited to: consistent arrival, risk avoidance, and interaction cost.

[0179] Furthermore, Figure 3 A flowchart illustrating the vehicle routing method based on traffic events provided in this application. Figure 3 ,like Figure 3 As shown, based on the set of reliable events, the vehicle's path planning results are generated, including:

[0180] Step 301. Generate a first path based on the set of trusted events and a preset reference map.

[0181] Step 302. Based on the first path, generate multiple candidate paths based on at least one preset constraint.

[0182] Step 303. Based on the preset objective function, calculate the function value of the objective function for each candidate path, and take the candidate path with the smallest objective function value as the second path.

[0183] For example, the set of trusted events consists of trusted events that have been standardized and have a consistent event description structure. The reference map is the basic information of road topology data, road segment traffic attributes and path costs pre-stored on the server side, which can represent the current traversable area of ​​the vehicle and the road connection relationship.

[0184] When generating the first path based on a set of trusted events, the server maps the event type, location, and suggested action of each trusted event to the corresponding road segment on the reference map, and combines this with the road segment's traffic status to generate a basic driving path suitable for the first vehicle. The first path represents the recommended route for the first vehicle under the current trusted event conditions and serves as the baseline path for generating subsequent candidate paths.

[0185] When generating multiple candidate paths, the server takes the first path as the initial path and expands, modifies or reconstructs the path by combining it with at least one preset constraint. The preset constraint includes at least one of the following: path length constraint, time constraint, road level constraint, number of turns constraint, restricted area constraint or vehicle type constraint.

[0186] The server can replace some road segments in the first path, or insert alternative road segments under certain constraints, thereby forming multiple candidate paths that meet the current traffic requirements. Each candidate path retains the connectivity between the starting point and the destination related to the first path to ensure the comparability of the path planning results within the same reference map.

[0187] When screening candidate paths, the server calculates the function value of each candidate path based on a preset objective function. The objective function is used to characterize the degree of deviation between the candidate path and the planning objective. Its function value can be obtained by combining at least one of the following: total path mileage, estimated travel time, event impact penalty value, path switching cost, and road congestion weight.

[0188] The server evaluates each candidate path using the same objective function and selects the path with the smallest function value as the second path. When the second path is output as the path result for the second vehicle, it can be combined with the first path to form the vehicle's path planning result. The first path is used to maintain consistency with the baseline planning, while the second path is used to provide a better alternative travel scheme under constraints.

[0189] In one possible implementation, the objective function can be constructed based on a weighted sum of multiple cost terms. Each cost term represents the cost of a candidate path in one dimension. It can be understood that the larger the value of each cost term, the higher the cost in the corresponding dimension of the candidate path.

[0190] The larger the value of the objective function obtained by weighted summation, the higher the overall cost of the candidate path. Weighted summation can be understood as each cost term having a corresponding weight value, and the sum of the weight values ​​of all cost terms being 1.

[0191] For example, multiple cost items include: collaborative arrival time cost, risk cost, fleet consistency cost, resource cost, and interaction cost.

[0192] Among them, the coordinated arrival time cost can be calculated from the estimated time of arrival (ETA) of the first and second vehicles; the risk cost can be composed of the presence of high-risk events, construction time, and road closure events on the candidate path; the fleet consistency cost is used to characterize the dispersion of the ETA between the first and second vehicles and / or the relative positional deviation between the first and second vehicles; the resource cost can be calculated from the communication load, replanning range, and local computing overhead; and the interaction cost can be used to constrain the problems of frequent prompts, repeated broadcasts, and excessively high driver rejection rates.

[0193] Optionally, at least one constraint condition may be introduced during the calculation of the objective function value for each candidate path.

[0194] Specifically, at least one constraint condition includes:

[0195] Constraint 1: The credibility of each trusted event in the candidate path is greater than or equal to 0.65.

[0196] Constraint 2: Potential conflict event window is greater than or equal to 3 seconds.

[0197] Constraint 3: The change in estimated vehicle speed in the candidate path is less than or equal to 5 km / h.

[0198] Constraint 4: The difference between the ETA of the first vehicle and the ETA of the second vehicle is less than or equal to 20s.

[0199] In another possible implementation, on the leader vehicle side, a risk perception search is first performed on the high-level road network skeleton to obtain the main reference path P_leader. On the following vehicle side, a candidate subgraph G_i_sub with time windows and session constraints is constructed centered on P_leader, and individual constraint paths P_i are solved only within this subgraph. This maintains the overall convoy coordination while allowing following vehicles to make fine-grained adjustments based on their own position, route deviations, and local traffic conditions.

[0200] In the above embodiments, a base path is generated by referencing a map, and then candidate paths are expanded under preset constraints and the optimal result is solved using a unified objective function, so that the path planning result includes both the baseline path and the optimized path. Since the generation and evaluation of candidate paths are based on the same set of credible events and standardized map information, the path planning result has a consistent input basis and comparable evaluation criteria among different vehicles, thereby enabling the server to stably output path planning results adapted to multi-vehicle scenarios.

[0201] Based on the above embodiments, in some situations, the credibility of a credible event may change, or the objective function value may differ significantly during the selection of the second path. When any one or more of these phenomena occur, incremental replanning can be triggered.

[0202] In one example, the method also includes:

[0203] If the difference in the objective function values ​​of any two candidate paths is greater than or equal to the second threshold, then the objective region of the second path is replanned; and / or,

[0204] If a candidate event is determined to change from the first state to the second state, the target area of ​​the second path is replanned. The first state is when the credibility of the candidate event is less than the first threshold, and the second state is when the credibility of the candidate event is greater than or equal to the first threshold.

[0205] The target area is the area within a preset distance in front of the current position of the second vehicle in the second path.

[0206] For example, the candidate path is a feasible path obtained based on a set of credible events and preset constraints. The function value of the objective function is used to characterize the comprehensive result of the corresponding candidate path in terms of travel cost, detour length, time consumption or event avoidance. The second threshold is used to limit whether the difference between candidate paths reaches the level that local paths need to be adjusted.

[0207] The second path is the path with the smallest objective function value among several candidate paths. The current position of the second vehicle can be output in real time by the vehicle positioning module. The area within the preset distance ahead can be set as a local replanning interval extending forward along the second path. During replanning, only the path nodes, speed constraints, or steering constraints in this area are updated, while the already passed road segments remain unchanged.

[0208] For example, in some cases, after the server receives the objective function value of the candidate path, it compares the difference between the function values ​​of any two candidate paths. When the difference reaches or exceeds the second threshold, it indicates that there is a significant differentiation in the local cost of different candidate paths. Then, the area in the second path located within a preset distance in front of the current position of the second vehicle is extracted as the area to be replanned, and the path segment in the area is regenerated based on the latest map data, event data and road constraints.

[0209] Optionally, the second threshold can be set to 15% of the function value of the objective function in the previous period.

[0210] In other cases, if the credibility of a candidate event changes from less than the first threshold to greater than or equal to the first threshold in subsequent updates, it indicates that the event has changed from a low-credibility state to a state that can be included in the path decision. Based on this, the server triggers the replanning of the second path target area and re-attaches the updated target area path to the original second path to form a continuous navigation result.

[0211] The stability between candidate paths is determined by the difference in the objective function, and the need for event information to be included in the path update is determined by the change in the credibility state of candidate events. This allows for replanning only in the local area ahead of the second vehicle. Since the target area is limited to the road segment within a preset distance ahead, the path update can be focused on the segment about to be traveled and maintain continuity with the existing path.

[0212] In one possible implementation, this can be achieved through a combined approach of short-cycle fusion and long-cycle correction. Specifically, the set of trusted events and the local risk field are updated every 1 second, and a global correction is performed on fleet consistency, path stability, and weight parameters every 5 seconds.

[0213] In another possible embodiment, during local replanning, only the road network subgraph within a preset distance L_forward from the current vehicle position and related to the risk event is recalculated, avoiding repeated global path solving. The value of L_forward can be an adaptive distance range of 1km to 3km.

[0214] In the above example, when the cost difference between candidate paths is significant or the credibility of an event changes state, the system can update the local path in a timely manner, so that the second path is consistent with the current valid event, reducing unnecessary global recalculation, and ensuring the continuity and timeliness of the path planning results pushed to the vehicle.

[0215] Furthermore, the decision of whether the vehicle chooses the path indicated in the path planning result can be adjusted using an adaptive algorithm. In some cases, the method also includes:

[0216] Receive driving information from the first and second vehicles, and adjust the weights or thresholds in the objective function based on the driving information.

[0217] The threshold information is one or more of the first threshold and the second threshold.

[0218] For example, after receiving the driving information of the first vehicle and the second vehicle, the server can dynamically adjust the weights of each item in the objective function based on the distance relationship between the two vehicles, the speed difference, and the relative relationship between the current position and the target area.

[0219] In some cases, when the first and second vehicles are on the same road segment and the speed difference is small, the path stability-related weights can be increased, and the first threshold can be increased accordingly, so that only events with higher credibility are included in the path calculation.

[0220] In other cases, when the two vehicles are on roads of different grades or one of them is close to the target area, the weights related to traffic efficiency can be increased and the second threshold can be reduced, making it easier for the system to trigger a re-evaluation of candidate paths.

[0221] The weight or threshold information can be automatically updated by the server according to the preset mapping relationship, or it can be generated by the vehicle network platform after online learning based on historical driving data, and then sent to the path planning module to participate in subsequent calculations.

[0222] In one possible embodiment, the vehicle also has a driving state vector that can characterize the driving information of the vehicle.

[0223] Specifically, the driving state vector includes driving information in multiple dimensions, such as: vehicle position, vehicle speed, vehicle heading, current reference route segment, vehicle role identifier (used to distinguish between the first and second vehicles), fleet coordination session identifier, estimated arrival time, and statistics on the adoption of coordination suggestions in the most recent period.

[0224] In another possible embodiment, the weight and threshold information can be stored in a parameter table on the server side and associated with vehicle identification, timestamp, and road scene information, facilitating the invocation of different parameter combinations under different traffic conditions. This application does not limit this.

[0225] In another possible embodiment, the system records the driver's adoption, delayed adoption, and rejection behaviors of cooperative suggestions to form feedback data fb_i. When a certain type of prompt is not adopted in multiple consecutive occurrences, the system reduces the broadcast priority of the corresponding prompt strategy or increases the trigger threshold; when a certain type of cooperative replanning is continuously adopted and can significantly reduce risk or improve consistent arrival, the system increases the weight of the relevant cost item.

[0226] In the above example, by adjusting the weights or thresholds in the objective function based on driving information, the path planning results can be kept consistent with the current vehicle operating state, and the event filtering and replanning trigger conditions can be dynamically changed with the vehicle driving state, thereby improving the adaptability and stability of the path planning results.

[0227] In such Figure 3 Based on the illustrated embodiment, in the application scenario of fleet collaborative path processing, the path planning results can be pushed to the first and second vehicles in the fleet in the form of interactive models and voice strategy prompts.

[0228] In one example, the route planning results are pushed to the vehicle, including:

[0229] Based on the first path, a first interaction model and a first speech strategy corresponding to the first path are generated; and based on the second path, a second interaction model and a second speech strategy corresponding to the second path are generated.

[0230] The first path, the first interaction model, and the first voice strategy are pushed to the first vehicle; and the second path, the second interaction model, and the second voice strategy are pushed to the second vehicle.

[0231] For example, the first path and the second path are used as navigation result inputs for different vehicles. The server generates corresponding interaction models and voice strategies based on the topology of the paths and sends them out together with the path planning results, so that the vehicles can simultaneously obtain route display and voice guidance information in the same navigation session.

[0232] Since different vehicles may have different locations, target areas, and path constraints, the server generates an interaction model and voice strategy that matches their respective paths, so that the navigation display and broadcast content of the two vehicles are consistent with their respective paths.

[0233] In one possible embodiment, the navigation information represented by the path planning result is used to generate an interactive model that can be displayed on a user interface, specifically, a UI model (User Interface).

[0234] The interactive model is pushed to the corresponding vehicles in the fleet, where it can be visualized on the smart devices in the vehicles. These smart devices may include, but are not limited to, the center console, smart instrument panel, and HUD (Head-Up Display).

[0235] In another possible embodiment, the navigation information represented by the route planning result is used to generate audio data, which is generated based on text-to-speech (TTS) technology according to the route planning result. This audio data is then pushed to the corresponding vehicles in the fleet and can be played on the vehicle's speakers or other audio output devices.

[0236] In the two embodiments described above, the path planning results are essentially a first path and a second path. Based on these paths, textual information representing navigation guidance along those paths can be generated. Based on this textual information, the interaction model and voice strategy described above can be obtained and then pushed to the first and second vehicles, respectively.

[0237] In the above example, the route planning results, interface interaction, and voice guidance can be output in a coordinated manner. The vehicle can directly complete the navigation presentation by pressing the sent content, which improves the consistency of the expression after the route planning results are sent and the accuracy of terminal execution.

[0238] Based on any of the foregoing embodiments or examples, in one example, the method further includes:

[0239] If it is determined that the number of trusted events in the trusted event set is less than the third threshold within a preset period, a downgrade state is triggered.

[0240] In the degraded state, the path planning result is formed only based on the vehicle's current position and destination position, without considering the set of credible events.

[0241] For example, in a specific implementation, the server counts the number of trusted events in the trusted event set within a continuous preset period and compares the number with a third threshold.

[0242] In some cases, when the statistical result is less than the third threshold, the server switches the current path processing state to a degraded state and writes this state into the path processing context of the corresponding vehicle. In this state, the server no longer uses event content from the trusted event set to participate in path planning, but instead directly generates the path planning result based on the vehicle's current location and destination location, combined with the basic road network topology, road traffic direction, and default traffic rules.

[0243] To illustrate with a practical example, if a V2X link interruption results in a small number of trusted events in the trusted event set, all trusted events are ignored, and the shortest path from the current location to the destination is calculated directly.

[0244] The vehicle's current location can be determined by the location information reported by the vehicle, the destination location can be determined by the navigation destination information, and the path planning result can be solved by the shortest distance, the shortest time, or the preset comprehensive cost, and the result obtained does not depend on any event constraints in the trusted event set.

[0245] In other cases, when the number of trusted events recovers to the third threshold or above, the server can exit the degraded state and switch back to the path processing mode based on the trusted event set.

[0246] In one possible implementation, if the number of trusted events in the trusted event set falls below a third threshold for M1 consecutive cycles, the system enters a degraded state for normal navigation. If the number of trusted events in the trusted event set reaches the third threshold again for M2 consecutive cycles, the cooperative navigation state is reactivated.

[0247] Optionally, M1 can be set to 2, and M2 can be set to 3. It should be noted that other values ​​can also be selected, and this embodiment does not limit this.

[0248] In the example above, this setup ensures that even with insufficient multi-source event supply or unstable event quality, path planning can still continuously output basic navigation results based on the vehicle's current and destination locations. This allows the server to maintain continuous output of path planning results when reliable events are scarce, and to resume event-assisted planning once events recover, thus maintaining the stability and executability of path processing.

[0249] In one possible embodiment, in a multi-vehicle platooning urban travel scenario, three vehicles A, B, and C form a platoon and travel together. Vehicle A is the lead vehicle, and vehicles B and C are the following vehicles. The platoon starts from the main urban road, plans to go to the same destination, and needs to pass through the main urban road, traffic light intersections, and construction areas.

[0250] The server processes V2X events from Roadside Units (RSUs), Onboard Units (OBUs), and the cloud platform, including construction detours, traffic light countdowns, and warnings of vehicles with breakdowns ahead, to achieve multi-vehicle path consistency, ETA synchronization, and collaborative obstacle avoidance.

[0251] The server obtains multiple traffic events from at least two event sources, including vehicle-side reports, roadside equipment, traffic management platforms, or map services. In this scenario, the corresponding raw V2X events are accessed from RSU, OBU, and cloud platforms.

[0252] In one possible implementation, the methods of any of the above embodiments or examples are implemented in the form of software modules. Specifically, the software modules included in the server and their corresponding functions are shown in Table 1.

[0253] Table 1. Exemplary Software Module Function Table

[0254]

[0255] For example, the V2xAccessManager module receives raw V2X events from RSU, OBU and cloud platform, such as RSU reporting construction area events, OBU broadcasting warnings of vehicles with breakdowns ahead, and cloud platform providing traffic light countdown information.

[0256] For each traffic event in multiple traffic events, the server extracts the event type, event time, event location, event priority, and corresponding suggested actions. The V2xProtocolAdapter module parses these events into a unified V2xConvoyEvent model and standardizes them according to a unified field format, unified time base, unified location expression, and unified action label.

[0257] Optionally, time unit normalization can be completed, such as converting GPS time to system time; coordinate system transformation can be completed, such as unifying coordinate system transformation; and road / lane semantic mapping can be completed, such as normalizing "construction area" to "construction detour" event type, forming candidate events with the same event description structure.

[0258] The V2xConvoyEvent model includes event type, location, and suggested action. The event type can be construction detour, the location can be urban main road K12+300, and the suggested action can be detour to the right lane.

[0259] The server calculates the credibility of each candidate event based on the reliability of the event source, the freshness of the reporting time, the degree of spatial matching, historical consistency, or multi-source cross-verification. In this scenario, the V2xTrustFusionEngine module scores the credibility of the standardized V2xConvoyEvent set.

[0260] For construction detour events, the source reliability is set with RSU priority higher than OBU and is set to 0.8 (weight 0.35). Time freshness corresponds to the current timestamp of the event and is set to 0.7 (weight 0.2). Spatial consistency corresponds to the matching degree between the event and the current route and is set to 0.6 (weight 0.15). Multi-source consensus corresponds to the consistency between RSU and OBU in describing the same construction event and is set to 0.9 (weight 0.3). The sum of the four weights is 1, and the weighted sum gives a comprehensive reliability score of 0.78.

[0261] The credibility score ranges from 0 to 1. The server identifies candidate events with a credibility score greater than or equal to the first threshold as credible events and constructs a set of credible events based on each credible event.

[0262] After the set of trusted events is formed, the server identifies conflicting event combinations based on the event occurrence time, event location, and corresponding suggested actions. Multiple events that point to the same road segment within both spatial and temporal windows but have conflicting suggested actions constitute a conflicting event combination. When at least two trusted events occur within the same time frame, point to the same road segment, and have inconsistent suggested actions, these trusted events are grouped into the same conflicting event combination.

[0263] In this embodiment, if the faulty vehicle warning reported by the OBU and the construction event point to the same road segment but the suggested actions conflict, the construction event suggests "detour" and the faulty vehicle warning suggests "decelerate". The server selects one of the trusted events as the target event for the combination of conflicting events.

[0264] Specifically, when making a selection, you can directly choose life safety events, or you can choose the most credible events, or combine the current route planning results to estimate the scope of impact, the degree of overlap of affected road sections, and the relevance to traffic decisions, and select the most credible events that are most correlated with the route planning results.

[0265] In this embodiment, the vehicle breakdown warning does not fall under the category of life-safety events, therefore it does not trigger the life-safety priority rule. Construction events have higher credibility than vehicle breakdown warnings; therefore, construction events are selected as the target event. Other credible events in the same conflict event combination, excluding the target event, are removed from the credible event set. That is, conflicting vehicle breakdown warnings are removed, and the credible event set after conflict resolution is retained for path calculation. Life-safety events include events that directly threaten driving safety, such as falling rocks and traffic accidents, and have higher priority than ordinary events. Vehicle breakdown warnings only indicate the need to slow down and avoid the vehicle, and do not constitute life-safety events.

[0266] The server generates vehicle path planning results based on the set of trusted events after conflict resolution and a preset reference map. For the first vehicle, i.e., the lead vehicle A, the server maps the event locations in the trusted events to the corresponding road segments, nodes, or areas in the reference map. Combining event priority and suggested actions, the server applies traffic restrictions, traffic cost corrections, or detour markings to the affected roads. A main reference path P_leader is generated on the global road network skeleton to bypass the construction area and form the first path applied to the first vehicle.

[0267] For the second vehicle, corresponding to following vehicles B and C in this scenario, the server first generates a first path based on a set of trusted events and a reference map. Then, based on the first path, it generates multiple candidate paths in conjunction with at least one preset constraint. The preset constraints include traffic restriction constraints, road level constraints, estimated travel time constraints, detour distance constraints, risk avoidance constraints, or vehicle self-driving constraints. Following vehicles B and C use P_leader as a reference to solve for the constrained path P_i within their respective forward subgraphs G_i_sub. The forward subgraph G_i_sub is a road network segment within a preset distance L_forward from the current vehicle's position, which in this scenario is 1km to 3km.

[0268] The server calculates the function value of a preset objective function for each candidate path. The objective function includes factors such as travel time, path length, event risk, road congestion level, number of lane changes or turning complexity, and performs a comprehensive calculation according to weights.

[0269] In this embodiment, the joint cost function also includes terms such as cooperative arrival time T, risk cost R, and formation dispersion Dform, which are used to maintain the consistency of multi-vehicle ETA for vehicles A, B, and C. The server determines the candidate path with the minimum objective function value as the second path applied to the second vehicle.

[0270] The server continuously monitors the evaluation results and event status changes of candidate paths. In some cases, when a construction event causes a change in P_leader, the server detects that the cost function change exceeds a threshold, i.e., the difference between the objective function values ​​of any two candidate paths is greater than or equal to a second threshold. In this case, the server re-plans the target area of ​​the second path, which is the area within a preset distance in front of the current position of the second vehicle in the second path.

[0271] Specifically, only the affected forward subgraph is recalculated; for example, only the road segment 1km before the construction area is recalculated, not the global path. During replanning, the associated road network of the target area is re-extracted, reliable events within the target area are reloaded, and candidate paths and corresponding function values ​​are generated again.

[0272] In other cases, when the credibility of a candidate event changes from less than the first threshold to greater than or equal to the first threshold, the server switches the candidate event from the first state to the second state and triggers the replanning of the target area of ​​the second path.

[0273] Optionally, the server also receives driving information from the first and second vehicles, covering the driving information of the lead vehicle A and the following vehicles B and C in this scenario. The driving information includes real-time location, speed, heading, actual transit time, driving response or yaw situation, and adjusts the weights in the objective function or adjusts one or more of the first threshold and the second threshold according to the driving information.

[0274] Within the interactive feedback loop, the V2xUiCoordinator module generates differentiated prompts based on the vehicle's role (leader or follower) and risk level, and records the driver's acceptance or disregard for the prompts. For example, if vehicle B ignores lane change suggestions three times consecutively, the server dynamically adjusts the prompt strategy based on this driving response. Specifically, it lowers the broadcast priority of vehicle B and can simultaneously adjust the weight parameters related to the driving response in subsequent path calculations.

[0275] Optionally, after generating the route planning results, the server generates a first interaction model and a first voice strategy corresponding to the first path, and generates a second interaction model and a second voice strategy corresponding to the second path. The interaction model is used to represent key nodes, event prompt nodes, lane change prompt nodes, and detour confirmation nodes along the path, and the voice strategy is used to represent the broadcast content, broadcast timing, and broadcast priority of each prompt node.

[0276] For example, a role-based HMI (Human Machine Interface) prompt is generated for the lead vehicle A, with the announcement "Construction ahead, main route adjusted." For following vehicles B and C, a role-based HMI prompt is generated, with the announcement "Route adjusted following the lead vehicle, please change lanes." The server pushes the first path, first interaction model, and first voice strategy to the first vehicle, and the second path, second interaction model, and second voice strategy to the second vehicle, to maintain path consistency, ETA synchronization, and collaborative obstacle avoidance among the three vehicles A, B, and C.

[0277] Optionally, the server may also count the number of trusted events in the trusted event set within a preset period. When the number of trusted events is less than a third threshold, a downgrade state is triggered. In the downgrade state, the server does not consider the trusted event set and only performs route planning based on the vehicle's current location and destination location, and continues to push the route planning results generated in the downgrade state to the corresponding vehicle.

[0278] For example, the ConvoyFeedbackController module monitors the V2X link status. If the RSU signal is interrupted, and the server detects that the number of trusted events is below a threshold for two consecutive short periods, it enters normal navigation mode. The short period is 1 second; that is, if the number of trusted events is below the threshold for two consecutive 1-second periods, it enters degraded mode and ignores V2X events. When the link stabilizes and the critical events reach the trusted threshold again, the system automatically reverts to cooperative navigation mode, restores convoy route coordination, and continues to perform cooperative route planning, interaction model generation, and voice policy push for vehicles A, B, and C based on the restored set of trusted events.

[0279] The vehicle routing method based on traffic events provided in this application obtains traffic events from multiple event sources through a server, performs standardization processing and reliability filtering to obtain a set of reliable events. Based on the set of reliable events, route planning results for vehicles can be generated. Protocol parsing and field mapping in the standardization process eliminate heterogeneous data differences, reducing the probability of field differences or timestamp inconsistencies from different event sources. This ensures that different reliable events in the set have the same event description structure, reducing error messages and duplicate broadcasts caused by differences, thereby improving the reliability and accuracy of route planning results and enhancing the stability and reliability of navigation prompts.

[0280] Figure 4 A schematic diagram of the vehicle routing processing device based on traffic events provided in this application is shown below. Figure 4 As shown, the vehicle routing processing device 40 based on traffic events provided in this embodiment includes:

[0281] The acquisition module 401 is used to acquire multiple traffic events; wherein the multiple traffic events originate from at least two event sources.

[0282] Module 402 is used to construct a set of trusted events based on multiple traffic events; wherein the set of trusted events includes multiple trusted events, each trusted event is standardized, and the event description structure of the trusted events is the same;

[0283] The generation module 403 is used to generate the vehicle's path planning result based on the set of trusted events and push the path planning result to the vehicle.

[0284] In one possible implementation, a set of credible events is constructed based on multiple traffic events, and the construction module 402 is used for:

[0285] For each traffic incident in a series of traffic incidents, standardization is performed to obtain corresponding candidate incidents; among them, the event description structure of each candidate incident is the same.

[0286] Calculate the credibility of each candidate event, and take the candidate events with credibility greater than or equal to the first threshold as credible events;

[0287] Construct a set of trusted events based on trusted events.

[0288] In one possible implementation, the event description structure includes: event type, event occurrence time, event occurrence location, event priority, and suggested action corresponding to the event.

[0289] In one possible implementation, the building module 402 is further configured to:

[0290] Based on the event occurrence time, event location, and corresponding suggested action in the event description structure, at least one conflict event combination is determined; wherein, the conflict event combination includes at least two credible events, and the credible events in the conflict event combination satisfy preset conditions; the preset conditions indicate that the event occurrence time is within the same time range, the event location points to the same road segment, and the corresponding suggested actions are inconsistent;

[0291] Select one trusted event from the combination of conflicting events as the target event, and remove all other trusted events from the set of trusted events.

[0292] In one possible implementation, one trusted event is selected from the combination of conflicting events as the target event, and the construction module 402 is used to perform at least one of the following:

[0293] Select life safety events as target events from the combination of conflict events;

[0294] Select the most credible event from the combination of conflicting events as the target event;

[0295] Select the credible event with the highest correlation to the path planning result from the combination of conflict events as the target event.

[0296] In one possible implementation, the route planning result includes a first path applied to the first vehicle and a second path applied to the second vehicle; wherein the first vehicle is the lead vehicle in the convoy, and the second vehicle is the following vehicle in the convoy; based on a set of reliable events, the route planning result for the vehicles is generated, and the generation module 403 is used to:

[0297] Based on a set of trusted events and a pre-defined reference map, a first path is generated.

[0298] Based on the first path, multiple candidate paths are generated based on at least one preset constraint.

[0299] Based on the preset objective function, the function value of the objective function of each candidate path is calculated, and the candidate path with the smallest objective function value is selected as the second path.

[0300] In one possible implementation, the generation module 403 is further configured to:

[0301] If the difference in the objective function values ​​of any two candidate paths is greater than or equal to the second threshold, then the objective region of the second path is replanned; and / or,

[0302] If a candidate event is determined to change from the first state to the second state, the target area of ​​the second path is replanned. The first state is when the credibility of the candidate event is less than the first threshold, and the second state is when the credibility of the candidate event is greater than or equal to the first threshold.

[0303] The target area is the area within a preset distance in front of the current position of the second vehicle in the second path.

[0304] In one possible implementation, the generation module 403 is further configured to:

[0305] The system receives driving information from the first vehicle and the second vehicle, and adjusts the weights or threshold information in the objective function based on the driving information; wherein the threshold information is one or more of the first threshold and the second threshold.

[0306] In one possible implementation, the route planning results are pushed to the vehicle, and the generation module 403 is used for:

[0307] Based on the first path, a first interaction model and a first speech strategy corresponding to the first path are generated; and based on the second path, a second interaction model and a second speech strategy corresponding to the second path are generated.

[0308] The first path, the first interaction model, and the first voice strategy are pushed to the first vehicle; and the second path, the second interaction model, and the second voice strategy are pushed to the second vehicle.

[0309] In one possible implementation, the building module 402 is further configured to:

[0310] If it is determined that the number of trusted events in the trusted event set is less than the third threshold within a preset period, a degraded state is triggered. In the degraded state, the path planning result is formed without considering the trusted event set, based only on the vehicle's current location and destination location.

[0311] The vehicle routing processing device based on traffic events provided in this embodiment can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0312] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0313] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0314] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0315] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0316] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0317] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0318] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0319] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0320] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0321] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0322] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0323] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0324] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0325] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0326] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0327] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A vehicle routing method based on traffic events, characterized in that, Applied to the server side, the method includes: Multiple traffic events are acquired; wherein the multiple traffic events originate from at least two event sources. Based on the multiple traffic events, a set of credible events is constructed; wherein, the set of credible events includes multiple credible events, each of which has undergone standardization processing, and the event description structure of the credible events is the same; Based on the set of trusted events, a path planning result for the vehicle is generated, and the path planning result is pushed to the vehicle.

2. The method according to claim 1, characterized in that, Based on the multiple traffic events, a set of credible events is constructed, including: Each of the multiple traffic incidents is standardized to obtain corresponding candidate incidents; wherein, the event description structure of each candidate incident is the same. Calculate the credibility of each candidate event, and take the candidate events with credibility greater than or equal to a first threshold as credible events; The trusted event set is constructed based on the trusted events.

3. The method according to claim 1, characterized in that, The event description structure includes: event type, event occurrence time, event location, event priority, and suggested action corresponding to the event.

4. The method according to claim 3, characterized in that, The method further includes: Based on the event occurrence time, event location, and corresponding suggested action in the event description structure, at least one conflict event combination is determined; wherein, the conflict event combination includes at least two credible events, and the credible events in the conflict event combination satisfy preset conditions; the preset conditions indicate that the event occurrence times are within the same time range, the event locations point to the same road segment, and the corresponding suggested actions are inconsistent; Select one trusted event from the combination of conflicting events as the target event, and remove all other trusted events from the set of trusted events.

5. The method according to claim 4, characterized in that, Select one credible event from the combination of conflicting events as the target event, including at least one of the following: Select a life safety event as the target event from the combination of conflict events; Select the most credible event from the combination of conflicting events as the target event; Select the credible event with the highest correlation to the path planning result from the combination of conflict events as the target event.

6. The method according to any one of claims 2-5, characterized in that, The path planning result includes a first path applied to the first vehicle and a second path applied to the second vehicle; wherein the first vehicle is the lead vehicle in the convoy, and the second vehicle is a follower vehicle in the convoy; generating the vehicle path planning result based on the set of trusted events includes: Based on the set of trusted events and a preset reference map, a first path is generated; Based on the first path, multiple candidate paths are generated based on at least one preset constraint. Based on the preset objective function, the function value of the objective function of each candidate path is calculated, and the candidate path with the smallest objective function value is taken as the second path.

7. The method according to claim 6, characterized in that, The method further includes: If the difference in the objective function values ​​of any two candidate paths is greater than or equal to a second threshold, then the objective region of the second path is replanned; and / or, If it is determined that a candidate event changes from the first state to the second state, the target area of ​​the second path is replanned. In the first state, the credibility of the candidate event is less than the first threshold, and in the second state, the credibility of the candidate event is greater than or equal to the first threshold. The target area is the area within a preset distance in front of the current position of the second vehicle in the second path.

8. The method according to claim 7, characterized in that, The method further includes: The system receives driving information from the first vehicle and the second vehicle, and adjusts the weights or threshold information in the objective function based on the driving information; wherein the threshold information is one or more of the first threshold and the second threshold.

9. The method according to claim 7, characterized in that, Pushing the route planning results to the vehicle includes: Based on the first path, a first interaction model and a first voice strategy corresponding to the first path are generated; and based on the second path, a second interaction model and a second voice strategy corresponding to the second path are generated. The first path, the first interaction model, and the first voice strategy are pushed to the first vehicle; and the second path, the second interaction model, and the second voice strategy are pushed to the second vehicle.

10. The method according to any one of claims 2-5, characterized in that, The method further includes: If it is determined that the number of trusted events in the trusted event set is less than a third threshold within a preset period, a degraded state is triggered; wherein, when in the degraded state, the path planning result is formed by planning based solely on the current position and destination position of the vehicle, without considering the trusted event set.

Images