Method for coordinated action between vehicles

Abstract

A method for coordinated actions between vehicles is proposed. The method includes negotiating actions between at least a first vehicle (HV) and a second vehicle (RV, RV1, RV2), the actions being specified at least based on one or more target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV); determining that the first vehicle (HV) has entered an area associated with one of the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), and / or determining that the first vehicle (HV) has left an area associated with one of the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV); and in response to determining that the first vehicle (HV) has entered an area associated with the target road resource (RR1, RR2, RR3) assigned to the first vehicle (HV) and / or in response to determining that the first vehicle (HV) has left an area associated with the target road resource (RR1, RR2, RR3) assigned to the first vehicle (HV), sending a status message (MSM) from the first vehicle (HV) to the second vehicle (RV1, RV2).

Description

Technical Field

[0001] This specification relates to a method for cooperative action between vehicles and a computing device configured to perform this method. Specifically, this specification relates to aspects of a protocol for synchronizing the execution of cooperative actions negotiated between at least a first vehicle and a second vehicle, wherein the vehicles may be connected autonomous vehicles (CAVs). Background Technology

[0002] In the field of autonomous driving, it is generally believed that autonomous vehicles must be interconnected to create mutual awareness and coordinated action. However, how to achieve this interaction between autonomous vehicles in detail remains an open question. Currently, several new protocols for coordinated services, such as lane changing or overtaking, are being discussed within organizations such as the European Telecommunications Standards Institute (ETSI) and SAE International. These communication protocols are often specific to individual actions or based on implicit assumptions about the intentions of other vehicles.

[0003] Furthermore, beyond internet connectivity for infotainment use cases, direct communication between traffic participants—V2X—is also very close to becoming a reality. While this has been announced for over a decade, the situation has recently changed. Standards regarding basic safety can be considered nearing maturity, and first original equipment manufacturers (OEMs) have begun deploying basic V2X services in mass-produced vehicles, although not all questions have been answered.

[0004] Recently, attention has shifted from basic warning services to how vehicle communication can support collaborative and autonomous driving. These so-called second or third-day services will change how vehicles interact with each other on city roads and highways, as well as at intersections[2],[3][1]. They use V2X to enable negotiation between vehicles and leverage distributed intelligence to further enhance safety and convenience. The first standardization efforts for such advanced services have begun in Europe[4] and the United States[5].

[0005] In recent years, many researchers have begun to study complex interactions. For example, Bürger et al. [7] defined cooperative actions as those performed voluntarily and knowingly in order to achieve a common goal, i.e., joint optimality. They categorized cooperative actions based on the information exchanged (information-based) and the optimization objective of the cooperative actions (action-based). At the highest level, total utility is optimized by sharing state information, intentions, and individual utilities.

[0006] Generally speaking, cooperative behavior protocols can be divided into two types: implicit and explicit.

[0007] In implicit approaches, vehicles periodically share their intentions and must infer whether their suggestions are acceptable from the potential changes received from others [8]. For example, in IMAGinE [9], each vehicle periodically broadcasts its planned trajectory as a beacon. If a trajectory update is to be initiated, the desired trajectory is attached. Other vehicles evaluate changes to their own planned trajectories to make the desired trajectory possible. Based on the received updated plans, the initiating vehicle can determine whether it can change its planned trajectory. TransAID

[10] adds the possibility of roadside units (RSUs) making trajectory suggestions as traffic cooperators.

[0008] The approach based on explicit coordination is conceptually different. The idea is that the action required by a vehicle must be explicitly committed to or confirmed by the relevant actor to ensure that the proposal has been accepted. In [6], a lane-changing protocol is proposed. A lane-changing request is broadcast, and q is responded to via a unicast lane-changing response. Based on this feedback, an appropriate peer vehicle is selected to make way for the initiator, and a lane-changing ready message is used to notify that this has been done. The initiator then changes lanes without further communication.

[0009] Another explicit form of cooperation is the space-time reservation process

[11] : a vehicle sends a request for some lane-level road space, whether stationary or moving. Other vehicles will evaluate this request based on inferred costs and, if accepted, will send a commitment message. Vehicles that do not send a commitment message are either unwilling or unable to participate in the negotiation; their behavior must be predicted based on a non-cooperative movement model. Taking into account all received commitments, the initiating vehicle will determine whether it is safe to enter the reserved road space and, if so, will not engage in further communication.

[0010] Franke et al. proposed a protocol in which each vehicle announces possible actions and associated costs, and selects the optimal subset of actions to execute

[12] .

[0011] All of the above methods have certain limitations. In particular, most known protocols allow very specific operations (e.g., lane changes) that need to be adapted for each new use case [6]. Furthermore, with implicit methods, vehicles must guess whether other vehicles understand their suggestions or simply change their trajectories by chance. This can result in very conservative CAVs. In addition, periodically broadcasting trajectories can lead to significant bandwidth usage that is unnecessary if no action is taken. What the rules for generating such periodic beacons should look like is another unresolved issue

[10] .

[0012] recent,

[14] et al. proposed a protocol framework for complex interactions between connected vehicles (CVIP), which allows for arbitrary complex interactions between CAVs. The CVIP protocol framework enables action coordination between vehicles in a flexible, efficient and robust manner. In particular, CVIP supports scenarios where two or more participants can jointly negotiate and execute actions. Therefore, the interaction between participating vehicles can include a negotiation phase and an execution phase. Furthermore, during the cognition phase, cognition can be ensured by exchanging Cooperative Cognition Messages (CAM) or Basic Safety Messages (BSM) beacons. For example, such CAM / BSM can be used by the initiating vehicle to identify potential action partners. Thus, this cognition is provided before the negotiation phase and can also be maintained during the negotiation phase and the execution phase. In addition, CVIP provides status updates through Action Status Messages (MSM) so that each participant can monitor the progress of actions during the execution phase. Summary of the Invention

[0013] Typically (i.e., within protocol frameworks other than CVIP), there is a need for implementations capable of monitoring and synchronizing the execution of cooperative actions already negotiated between vehicles. The object of this invention is to provide a solution to this problem. In particular, the desired solution should be capable of being efficient in terms of both computational complexity and network load.

[0014] This objective is achieved by each of the method, computing device, computer program, computer-readable storage medium, and data carrier signal according to the independent claims. Preferred embodiments are the subject of the dependent claims.

[0015] It should be noted that additional features of a claim subordinate to an independent claim can constitute a separate invention independent of all the features of the independent claim, even without the features of the independent claim or in combination with a subset of the features of the independent claim. This can be the subject matter of the independent claim, a divisional application, or a subsequent application. The same applies to the technical teachings described in the specification, which can constitute an invention independent of the features of the independent claim.

[0016] Furthermore, it should be noted that, according to some embodiments, certain method steps described below can be performed by elements in the interconnected infrastructure (e.g., roadside units, edge computing devices, backend servers, quasi-stationary elements in a processing plant, etc.). Therefore, the elements performing these steps do not necessarily need to be located in a vehicle. For example, the proposed method may involve one or more interactions between infrastructure components and / or interactions between infrastructure components and one or more vehicles.

[0017] According to a first aspect of the invention, a method for coordinated action between vehicles is proposed.

[0018] The method includes: negotiating an action between at least a first vehicle and a second vehicle, wherein the action is specified at least based on one or more target road resources assigned to the first vehicle; determining that the first vehicle has entered an area associated with one of the target road resources assigned to the first vehicle and / or determining that the first vehicle has left an area associated with one of the target road resources assigned to the first vehicle; and transmitting a status message from the first vehicle to the second vehicle in response to determining that the first vehicle has entered an area associated with a target road resource assigned to the first vehicle and / or in response to determining that the first vehicle has left an area associated with a target road resource assigned to the first vehicle.

[0019] As used in this specification, the term "vehicle" should be understood in a broad sense. For example, the term "vehicle" includes passenger cars, buses, commercial vehicles, transport vehicles, drones, robots, motorboats, ships, agricultural vehicles, railway vehicles, etc.

[0020] In addition, the term "vehicle" can refer to a vehicle that is (fully or at least partially) autonomous or non-autonomous.

[0021] As described above, in one step of the method, actions are negotiated between at least the first vehicle and the second vehicle.

[0022] For example, the first vehicle may be the initiating vehicle (hereinafter also referred to as the master vehicle), which initiates the negotiation of a coordinated or collaborative action. In this case, the second vehicle may be referred to as a remote vehicle. According to some embodiments, the method may involve the master vehicle and one or more (such as at least two) remote vehicles. Therefore, in principle, the method allows for coordinated actions among any number of participants.

[0023] In other embodiments, the first vehicle may be a remote vehicle, while the second vehicle may be a primary vehicle or another remote vehicle.

[0024] The action may include multiple individual actions and / or sub-actions performed by at least one participant, namely, by the first vehicle and / or the second vehicle.

[0025] For example, the action may include at least one of the following actions: lane change of a participating vehicle (such as a primary vehicle); merging of a participating vehicle (such as a primary vehicle) into the road via an entrance ramp; one or more participating vehicles crossing an intersection in a cooperative manner; and at least one participating vehicle (such as a primary vehicle) avoiding a dangerous action, for example by avoiding a collision with an obstacle such as a vulnerable road user (VRU).

[0026] The negotiated actions are specified at least based on one or more target road resources assigned to the first vehicle. In some embodiments, the actions may be further specified at least based on one or more target road resources assigned to the second vehicle.

[0027] For example, each target road resource can be associated with an area reserved for a corresponding (first or second) vehicle within a negotiated action. Preferably, each target road resource is defined at least based on area information (specifying the reserved area) and time information. The time information can indicate the time slot (i.e., a specific time period) that the corresponding vehicle should occupy in that area according to the negotiated action.

[0028] This means, for example, that a specific time interval can be reserved in a region of a particular road space (such as a segment of a specific lane or a segment of a limited length) as the target road resource for a first or second vehicle. Therefore, both geographical and temporal characteristics can be used to define the target road resources expected to be occupied by the corresponding vehicles.

[0029] For example, the time information of a specified target road resource can be represented using Coordinated Universal Time (UTC), where each participating vehicle can access a UTC-compliant reference clock to allow for synchronized execution of actions.

[0030] Some examples of how to limit target road resources are shown below. Figures 3 to 9 Further explanation is provided in the detailed description.

[0031] In some embodiments, the action may be further specified based on one or more current road resources of one or more participating vehicles. For example, current road resources may include current location information and optional lane identifiers. Current road resources may also include current time information, such as timestamps.

[0032] In addition, actions can be specified based on action type, which describes the context of the action. That is, it allows for the differentiation of various action situations, such as lane changing or lane merging.

[0033] According to some embodiments, the negotiation steps of the method proposed herein can constitute at least part of the negotiation phase of a more comprehensive protocol framework, for example... The CVIP described in the article by

[14] et al., which is incorporated herein by reference, or, for example, the Action Sharing and Collaboration Service (MSCS) currently being developed by a task group within SAE [5]. Specifically, the action negotiation steps of the method proposed herein may include steps involving the transmission of request and / or response messages as described in one of the documents [5, 14] and / or as described in the international patent application PCT / EP2020 / 060293 filed on 9 April 2020, which proposes a method related to CVIP and is incorporated herein by reference.

[0034] Therefore, the method proposed in this paper may include other steps that may involve, for example, planning of collaborative actions and / or exchanging specific request or response messages as part of action negotiation.

[0035] In one embodiment, the method may further include the steps of: planning a sequence of coordinated actions involving the initiating vehicle and the remote vehicle; and transmitting a request message to the remote vehicle, the request message including information specifying the coordinated actions.

[0036] For example, the initiating vehicle (or master vehicle) may be the first vehicle of the method presented herein, and the remote vehicle may be the second vehicle. Alternatively, for example, the initiating vehicle (or master vehicle) may be the first vehicle of the method proposed herein, and the remote vehicle may be the second vehicle, or both the first and second vehicles of the method proposed herein may be remote vehicles.

[0037] The request message may include specific suggestions for a remote vehicle to perform one or more actions (e.g., sub-actions) within a specified cooperative action sequence. Furthermore, the request message may include one or more actions planned by the master vehicle to be performed within a specified cooperative action sequence. In the context of the methods presented herein, actions can be specified at least based on one or more target road resources assigned to the respective vehicle. For example, temporal and / or spatial relationships between participating vehicles (e.g., regarding corresponding start or end times and / or reserved road segments) can be expressed through the target road resources(s) included in the suggestion.

[0038] For example, a separate request message can be sent to each remote vehicle, where each remote vehicle can be addressed by a corresponding ID such as a so-called site ID.

[0039] For example, the initiating vehicle may send such a request message after determining that it needs to perform joint action with one or more remote vehicles that are potential partners (multiple vehicles).

[0040] According to some embodiments, request messages can be sent directly or indirectly from the initiating vehicle to (multiple) remote vehicles.

[0041] For example, the wireless transmission path of the request message can extend between the transmitter of the initiating vehicle and the receiver of the remote vehicle (specifically, from the transmitter of the initiating vehicle to the receiver of the remote vehicle), wherein one or more intermediate stations, such as base stations, may optionally be involved.

[0042] In one embodiment, the planning of the coordinated action sequence is triggered or executed by a computing device in the initiating vehicle. For example, at least some of the data processing involved in the planning can be performed by such a computing device, which may be located in the initiating vehicle.

[0043] Planning, for example, can be accomplished by one or more elements of the interconnected infrastructure (such as roadside units, edge computing devices, back-end servers, etc.), which is also within the scope of this invention.

[0044] For example, in one embodiment, some of the data processing involved in the planning may be performed at least partially on external computing devices, such as via edge or cloud services and / or remote servers. For instance, an edge computing platform located beside a road may propose actions. In this case, the planning of the coordinated action sequence may be specified to be triggered (i.e., initiated) at least by the computing device of the initiating vehicle.

[0045] Preferably, the planning of the cooperative action sequence considers assumptions (or knowledge) about the capabilities of the remote vehicles, such as their physical capabilities and vehicle dynamics. In other words, the proposed actions can directly reflect the initiating vehicle's assumptions or knowledge about the physical capabilities and vehicle dynamics of (multiple) other actors. For example, this could also refer to certain constraints on (multiple) remote vehicles. Such assumptions or knowledge about the initial vehicle can be based on, for example, queries based on protocol-based values ​​or state information, which may produce indications of (insufficient) capacity, etc. For example, such information can be conveyed through a response scheme explained below.

[0046] Furthermore, according to some embodiments, the planning of the cooperative action sequence may take into account the current and / or future (predicted) quality of service parameters of the communication (e.g., regarding latency, jitter, data rate, channel load, packet scheduling, etc.).

[0047] For example, the aforementioned assumptions or knowledge may be based on environmental models and / or predictive models of vehicle availability. Backend information regarding vehicle availability can also serve as the basis for such assumptions or knowledge.

[0048] Regarding the content of the request message, in one embodiment, the request message may also express one or more information needs that the initiating vehicle requests be met by a remote vehicle. In other words, the request message proposing a sequence of coordinated actions may additionally express information needs that the initiating vehicle hopes will be met by one or more remote vehicles. Therefore, the method can also achieve demand-based information exchange based on the same message set used for action coordination. Thus, the proposed protocol can combine coordinated perception and coordinated action.

[0049] In an embodiment, the method further includes the steps of: receiving a request message at a remote vehicle; and evaluating information included in the request message regarding the acceptability of the sequence of cooperative actions.

[0050] For example, the acceptability of the proposed cooperative action sequence may depend on the feasibility based on the remote vehicle's own environmental model or predictive model and / or, for example, the remote vehicle's willingness as assessed based on its own path planning and / or driving strategy. Specifically, the assessment may involve evaluating a cost function that reflects relevant trajectory planning and / or motion planning criteria.

[0051] In this embodiment, the evaluation of the information included in the request message is triggered or performed by a computing device in the remote vehicle. For example, at least some of the data processing involved in the evaluation can be performed by a computing device that may be located in the remote vehicle.

[0052] Some of the data processing involved in this assessment can be performed, at least partially, on external computing devices, such as via cloud services and / or remote servers, which is also within the scope of this invention. In this case, it can be specified that the assessment of the information included in the request message is triggered (i.e. initiated) at least by the computing device of the remote vehicle.

[0053] As a further step, the method may include sending a response message to the initiating vehicle.

[0054] According to some embodiments, the response message can be sent directly or indirectly from the remote vehicle to the initiating vehicle.

[0055] For example, the wireless transmission path of the response message can therefore be extended between the transmitter of the remote vehicle and the receiver of the initiating vehicle (specifically, from the transmitter of the remote vehicle to the receiver of the initiating vehicle), wherein one or more intermediate stations, such as base stations, may optionally be involved.

[0056] The response message (explicitly or implicitly) indicates whether the cooperative action sequence is acceptable to the remote vehicle. Therefore, the response message can convey confirmation or rejection of the proposed cooperative action sequence, the latter possibly in conjunction with a counter-proposal, as described below.

[0057] In one embodiment, the response message includes a countersuggestion that recommends a sequence of cooperative actions acceptable to the remote vehicle.

[0058] For example, in this case, the method may also include the step of planning a modified sequence of cooperative actions acceptable to the remote vehicle, wherein the planning may be performed or triggered by the remote vehicle (e.g., through the remote vehicle’s computing device, which may, for example, implement so-called cooperative logic).

[0059] The combination of the sent requests and received responses can provide the initiating vehicle with a clear picture of the remote vehicle's willingness to participate.

[0060] Specifically, by providing a response message as part of a protocol for coordinated action, the willingness of participants in a coordinated action can be determined via a response received from a remote vehicle. Thus, for example, some of the known drawbacks associated with the concept of group formation involving complex actions can be avoided [8].

[0061] In an embodiment, the method further includes, in response to the initiating vehicle receiving a response message indicating that the cooperative action sequence is unacceptable to the remote vehicles: planning an adjusted cooperative action sequence involving the initiating vehicle and the remote vehicles and / or one or more other remote vehicles; and sending an updated request message (e.g. from the initiating vehicle) to the remote vehicles(s) involved in the adjusted cooperative action sequence, wherein the updated request message includes information specifying the adjusted cooperative action sequence.

[0062] Alternatively or additionally, the method may include: in response to the initiating vehicle receiving one or more positive response messages indicating that the cooperative action sequence is acceptable to all involved remote vehicles: sending action status messages to the involved remote vehicles indicating that the cooperative action sequence has been planned.

[0063] For example, according to some embodiments, it can be specified that the iteration of request and response messages should be repeated (and possibly updated) until no further changes are recommended and no more errors are sent. This can be seen as a sign of “convergence” in action coordination.

[0064] When convergence is achieved, the initiating vehicle can send a status message, which includes the agreed actions and the action status of each action as "planned". In this way, each participating vehicle can ensure that all other involved vehicles also agree to the actions.

[0065] At this point, the negotiation phase of the method can be considered complete.

[0066] Then, the execution phase can begin, in which the participating vehicles should move appropriately to conform to the agreed actions.

[0067] In a further step, which may be part of the execution phase as described above, it is determined that the first vehicle has entered an area associated with one of the target road resources assigned to the first vehicle and / or that the first vehicle has left an area associated with one of the target road resources assigned to the first vehicle. In the case of only one target road resource assigned to the first vehicle, the area is the area associated with the (sole) target road resource assigned to the first vehicle.

[0068] The determination of whether the first vehicle has entered and / or left an area associated with the target road resource can be performed, for example, through the positioning system of the first vehicle. For instance, a computer device located in the first vehicle can be configured to receive data from one or more environmental perception sensors configured to detect objects in the environment of the first vehicle. Based on this data and / or based on navigation data (such as GPS data), possibly combined with map information (which may be provided, for example, by a map data storage unit), the computing device can determine the vehicle's position relative to the area.

[0069] For example, in the context of the determining step of the method proposed herein, it can be determined that the first vehicle has entered / left the area when the entire first vehicle has entered / left the area. Alternatively, it can be determined that the first vehicle has entered / left the area according to the method presented herein when a specific part or portion of the first vehicle has entered / left the area.

[0070] A further step of the method proposed herein specifies that, in response to determining that the first vehicle has entered the area associated with the target road resource assigned to the first vehicle and / or in response to determining that the first vehicle has left the area associated with the target road resource assigned to the first vehicle, a status message is sent from the first vehicle to the second vehicle. The status message may also be referred to as an action status message (MSM).

[0071] For example, the wireless transmission path of the status message can extend between the transmitter of the first vehicle and the receiver of the second vehicle (specifically, from the transmitter of the first vehicle to the receiver of the second vehicle), wherein one or more intermediate stations, such as base stations, may optionally be involved.

[0072] In one embodiment, the status message includes an identifier of the corresponding target road resource (an associated area that has been entered or left), preferably combined with status information indicating whether the corresponding area has been entered or left.

[0073] For example, when entering an area associated with a target road resource, the sent status message may include the target road resource ID and status indicators such as "in progress" or "entering". When leaving an area associated with a target road resource, another status message may be sent, which includes the road resource ID and status indicators such as "completed" or "departed".

[0074] For example, a joint action can be considered complete once the corresponding status of all target road resources for a collaborative action has been set to complete (or departed).

[0075] In addition, in one embodiment, the status message may include one or more of the following: message ID; timestamp; ID of the sending vehicle; action instance ID indicating which action the status message involves (in the case that more than one action has been negotiated).

[0076] For example, when it is determined that the first vehicle has entered the area associated with the target road resource and / or when it is determined that the first vehicle has left the area associated with the target road resource, the status message can be transmitted from the first vehicle to the second vehicle immediately (i.e., without any intentional delay). In other words, the transmission of the status message can be triggered immediately as soon as the corresponding event (entry / exit from the area) is detected.

[0077] Furthermore, in one embodiment, a status message is transmitted from the first vehicle to the second vehicle whenever it is determined that the first vehicle has entered an area associated with the target road resources assigned to the first vehicle and / or whenever it is determined that the first vehicle has left an area associated with the target road resources assigned to the first vehicle. In other words, it can be specified that a status message is transmitted whenever the first vehicle enters such an area and / or whenever the first vehicle leaves such an area.

[0078] Also within the scope of this invention, the method may further include: determining that the second vehicle has entered an area associated with one of the target road resources assigned to the second vehicle and / or determining that the second vehicle has left the area associated with one of the target road resources assigned to the second vehicle; and transmitting a status message from the second vehicle to the first vehicle in response to determining that the second vehicle has entered the area associated with the target road resource assigned to the second vehicle and / or in response to determining that the second vehicle has left the area associated with the target road resource assigned to the second vehicle. In other words, the transmission of status messages can be performed not only in the direction from the first vehicle to the second vehicle, but also in the opposite direction.

[0079] According to some embodiments, the variant embodiments described above and below in conjunction with the status messages transmitted from the first vehicle to the second vehicle can be similarly applied to the transmission of status messages from the second vehicle to the first vehicle.

[0080] Furthermore, in one embodiment, a status message should be transmitted whenever a vehicle involved in the action enters or leaves an area associated with the target road resource assigned to that vehicle (and preferably immediately). Thus, the status message can be used as a status update for other involved vehicles and can indicate that the action is still in progress.

[0081] For example, through such status messages, all involved vehicles can always know the current execution status of each participating actor.

[0082] In an embodiment, the method further includes determining whether the first vehicle has used the corresponding target road resource according to a negotiated action, based on information transmitted using the status message (including, for example, the time it has been transmitted). For example, this determination may be performed at least in part by the computing device of the second vehicle. For instance, it may be determined whether the time at which the first vehicle has entered or left an area associated with the target road resource allocated to it conforms to the negotiated action, for example, in the sense that the first vehicle was present in the area during the time period associated with the area according to the definition of the target road resource.

[0083] In one embodiment, the method may further include: reassessing the (further) participation of the second vehicle in the negotiation action based on information transmitted using state messages from the first vehicle to the second vehicle. For example, this reassessment may be performed at least in part by the computing device of the second vehicle. For example, the reassessment may refer to the second vehicle's willingness or ability to further participate in the action, particularly considering that the first vehicle may deviate from the negotiation action, which may become apparent based on information transmitted using state messages. For example, the reassessment may be performed by evaluating a cost function.

[0084] In one embodiment, the method includes: determining a deviation between the first vehicle's use of a corresponding target road resource and a negotiated action based on information transmitted using status messages from a first vehicle to a second vehicle; and in response to determining the deviation, transmitting from the second vehicle to the first vehicle at least one of the following: a cancellation message for assigning one or more target road resources to the second vehicle; and one or more alternative target road resources for the first vehicle and / or for the second vehicle. For example, if the second vehicle's computing device detects a deviation from the planned action (e.g., by determining via status messages that the first vehicle entered / left an area associated with a target road resource too early / too late compared to the agreed action), it can request cancellation of the action and / or suggest one or more alternative target road resources that could constitute a modified action.

[0085] If no deviation is detected, or if the assessment of the second vehicle part concludes that operation can continue even with the detected deviation taken into account, then the planned operation can be carried out further.

[0086] More generally, in some embodiments, each participating vehicle (e.g., the initiating vehicle and (multiple) remote vehicles) can cancel its participation in the cooperative action via one or more status messages indicating a status value of "cancelled" (or the like) for the target resource allocated to that vehicle. In a variant, a remote vehicle can transmit a corresponding cancellation request to the initiating vehicle, whereby the initiating vehicle can acknowledge the request and thus cancel the action.

[0087] Preferably, the receipt of the status message is confirmed by a feedback message to ensure that each participating vehicle knows the current status.

[0088] Optionally, an appropriate retransmission scheme can be implemented for status messages to ensure that each status message reaches every participating actor (except the sender of the status message). For example, Such a retransmission scheme has been described by others

[14] .

[0089] In one embodiment, the method includes transmitting a feedback message in response to receiving a status message. The feedback message can be transmitted from the receiving end of the status message, i.e., by the first vehicle or the second vehicle, to the sending end of the status message.

[0090] In some embodiments, all feedback messages may be sent to all other participating vehicles. Alternatively, it may be specified that, for example, feedback messages should be sent to at least the vehicle that sent the pending status message (and optionally, also to some or all other participating vehicles).

[0091] Feedback messages can be used as confirmation to ensure that other participants have received the state transition (i.e., entering or leaving the target road resource).

[0092] In some embodiments, the feedback message (also referred to as an action feedback message - MFM) can be a simple ACK used to acknowledge receipt of a status message. For example, such an ACK message can be triggered by the application layer or by a lower layer of the communication protocol used for V2V communication between vehicles.

[0093] Alternatively, the feedback message can be configured to contain content that can be referred to as an "extended ACK". For example, the feedback message can repeat at least a portion of the content of a received status message. Thus, the feedback message may include, for example, an action instance ID, an MSM message ID, and / or the execution status received in the MSM. For example, such a feedback message can be triggered by the application layer or by a lower layer of the communication protocol used for participating in V2V communication between vehicles.

[0094] Therefore, in some embodiments, the content of the status message repeatedly received in the feedback message can be specified. This ensures that all participating vehicles have a synchronized state of execution status involving all vehicles. In this way, for example, conflicts can be identified and consistency can be ensured in the event of transmission errors. Specifically, this provides an effective mechanism to prevent the internal execution state across actors from becoming scattered, for example, due to unreceived messages. It should be noted that, functionally, this is not merely about transmitting a simple ACK message.

[0095] In a variant embodiment, the status message may be specified to include not only status information about one or more target road resources allocated to the vehicle sending the status message, but also status information about (preferably all) target road resources allocated to other vehicles participating in the action. In other words, the status message may also reflect the sending vehicle's current knowledge (or assumptions) about the execution status of (preferably all) the target road resources of the other participating vehicles.

[0096] Furthermore, it can be specified that the feedback message sent by a vehicle in response to a status message reflects the vehicle's current knowledge (or assumptions) about the execution status of the target road resources of (preferably all) other participating vehicles. This may result in an agreement or deviation from the current knowledge (or assumptions) of the vehicle that has transmitted the status message.

[0097] For example, a combination of such status messages and such feedback messages can be used to implement a scheme in which a vehicle can proactively request clarification, for example, if it detects that other vehicles are deviating from an agreed-upon action. In this case, the first vehicle can send a status message indicating the current state, reflecting the first vehicle's current knowledge (or assumptions) about the current execution state of at least one second vehicle (and preferably all other vehicles) and one or more target road resources. The second vehicle can respond with a feedback message representing its current knowledge (or assumptions). The first vehicle can analyze the feedback message and detect possible deviations.

[0098] According to some embodiments, the method steps presented herein involving the transmission of one or more status messages and / or feedback messages(s) can constitute at least a portion of the execution phase of a more comprehensive protocol framework, for example... The CVIP described in the article by

[14] , or such as the Action Sharing and Collaboration Service (MSCS) currently being developed by a task force within SAE [5]. For example, the status messages and / or feedback messages presented herein may be specific instances of status messages and / or feedback messages as described in

[14] and / or as described in the international patent application PCT / EP2020 / 060293 filed on April 9, 2020, which proposes methods related to CVIP.

[0099] The embodiments described above and below include the understanding that providing action status messages as a "check and control" mechanism during the execution phase of a coordinated action can be beneficial. This can increase safety, particularly in cases of complex actions involving many participating vehicles, as the vehicles can thus ensure to each other that each is still following the original action plan, or react to deviations if one or more vehicles fail to perform the agreed-upon actions.

[0100] According to some embodiments, it can be specified that whenever a vehicle enters or leaves an area associated with a target road resource (reserved for the vehicle) during a negotiated action, it transmits an Action Status Message (MSM) indicating this to other vehicles participating in the action. For example, the MSM may include at least the transmitting vehicle's ID, action instance ID, message ID, target road resource ID, and a status indication regarding whether the area is entered or left. Possible status indications related to a specific target road resource include "Reserved," "Entered," "Leaved," and "Cancelled" (see below for details on cancellation).

[0101] Furthermore, according to some embodiments, it can be specified that other vehicles participating in the action should acknowledge receipt of the MSM by using an Action Feedback Message (MFM) sent to the vehicle transmitting the MSM. For example, the MFM can be an extended ACK, which includes, for example, the action instance ID, the message ID of the MSM, and the execution status received in the MSM. This can be particularly applicable when the MFM is a message triggered by the application layer of a communication protocol used for inter-vehicle communication. In implementation variations where the MFM is not triggered by the application layer, the content of the MFM can differ. For example, if the MFM is triggered by a layer lower than the application layer, the MFM can take the form of a simple ACK.

[0102] According to some embodiments, in the action execution phase, if any participating vehicle needs to cancel a collaborative action, the following process can be provided: any participating vehicle can, at any time, cancel its use of one or more target road resources allocated to it by transmitting an MSM indicating "cancellation" (or the like) as the status of the corresponding target road resource(s). If these resources are not reserved for any other participant in the action, the vehicle can optionally transmit one or more optional target road resources that it wishes to use instead. Preferably, the vehicle should avoid using the target road resources(s) reserved by other participants in the collaborative action, even after such cancellation.

[0103] Participation in the entire action can be cancelled by sending an MSM containing all target road resources reserved for vehicles with a "cancelled" (or similar) status. Similarly, in this case, a vehicle can send alternative sets of target road resources to other participating vehicles.

[0104] When other vehicles receive an MSM containing one or more cancelled target road resources, they should treat it as a normal MSM and transmit an MFM in response. Given that the former vehicle (partially or fully) cancelled the target road resources, the latter vehicle (i.e., other participating vehicles) can reassess its further involvement in the action.

[0105] Furthermore, according to some embodiments, it can be stipulated that when a vehicle has issued an MSM indicating that it has left the last target road resource allocated to it for the current action, it will consider the action to be completed and return to the cognitive state (which may also be called the pre-aware state), in which it is ready to negotiate a new action.

[0106] Receiving an MFM (in response to an MSM) from a vehicle indicating that it has left the last target road resource assigned to it can be considered optional for the remaining participants in the action. For the last two vehicles in a coordinated action, this means that after receiving an MSM indicating that one of the vehicles has left its last target road resource, the other vehicle may or may not issue a remaining MSM indicating entry / exit from the target road resource.

[0107] Furthermore, according to some embodiments, it can be stipulated that when the authorized action is fully executed, that is, when it has been indicated that the last target road resource has been left, all participating vehicles return to the pre-aware state.

[0108] The embodiments described above and below include the understanding that the solution proposed herein can be advantageously implemented because it allows for a good balance between the necessary computational complexity and network resource usage.

[0109] In this context, it should be noted that for the state synchronization problem during the execution phase of a coordinated action, the first possible alternative solution relies on periodic beacons emitted by participating vehicles. For example, the beacons could carry state information such as "action is still in progress" or "execution as planned." The advantage of this alternative solution is that it uses very simple logic for transmission (i.e., periodic transmission), corresponding to low computational complexity. However, since many transmissions without updates will occur, this solution is not optimal in terms of network load. Furthermore, it is unclear how to design the optimal transmission interval, such as static or dynamic.

[0110] The second alternative solution offers the possibility for participating vehicles to proactively request their respective execution status from other participating vehicles. For example, such an implementation could synchronize execution status by requesting clarification whenever an indication of deviation from expected behavior is detected. This solution is beneficial in terms of reducing network load because status messages are only transmitted to at least one participating vehicle when they are actually needed—that is, when the execution status becomes unclear. However, the computational complexity is high because the logic required to determine deviations is much more complex than, for example, transmitting periodic status messages.

[0111] Conversely, the solution presented in this paper, based on action state messages transmitted during state transitions defined by entering or exiting road resources, finds a viable trade-off between the prior conflicting design goals of minimizing both network load and computational complexity: the logic required to determine when to send a state message (i.e., during the state transition) is much simpler than the logic required to determine deviations (which is necessary for the second alternative solution described above). Simultaneously, network resource utilization is significantly lower compared to the first alternative solution based on periodic beacons.

[0112] According to a second aspect of the invention, a computing device is configured to: generate and / or receive information specifying an action that has been (at least) negotiated between a first vehicle and a second vehicle, wherein the action is specified at least based on one or more target road resources assigned to the first vehicle; determine that the first vehicle has entered an area associated with one of the target road resources assigned to the first vehicle and / or determine that the first vehicle has left an area associated with one of the target road resources assigned to the first vehicle; and generate a status message to be transmitted to the second vehicle in response to determining that the first vehicle has entered an area associated with a target road resource assigned to the first vehicle and / or in response to determining that the first vehicle has left an area associated with a target road resource assigned to the first vehicle.

[0113] In some embodiments, the status message does not need to be addressed to the second vehicle individually (i.e., unicast). Instead, the status message can also be multicast or broadcast.

[0114] For example, the information for generating a specified action may include planning and / or negotiating actions, as described above in conjunction with embodiments of the first aspect of the present invention.

[0115] It should be understood that computing devices can also be configured to store information about specified actions that are generated or received.

[0116] For example, the computing device can be configured to receive and evaluate one or more sensor signals associated with GPS signals and / or map information to determine whether a first vehicle has entered or left the area.

[0117] According to some embodiments, the computing device according to the second aspect can be configured to perform some or all of the steps of the method according to the first aspect as described above, particularly steps performed at or on behalf of the first vehicle and / or the second vehicle. Therefore, the explanations and descriptions of embodiments of the method according to the first aspect given above and below can be similarly applied to embodiments of the computing device according to the second aspect—and vice versa.

[0118] Therefore, in some embodiments, such a computing device may be located in the first vehicle or the second vehicle. In other embodiments, the computing device may be located outside the first vehicle and the second vehicle, such as at the rear end.

[0119] For example, in the method of the first aspect of the invention, a vehicle equipped with such a computing device (or capable of accessing such a computing device if it is located outside the vehicle) can be used as both a first vehicle and a second vehicle.

[0120] In a third aspect, the computer program includes instructions that, when executed by a computing device, cause the computing device to perform the steps described above.

[0121] In a fourth aspect, a computer-readable storage medium includes instructions that, when executed by a computing device, cause the computing device to perform the steps described above.

[0122] The fifth aspect refers to the data carrier signal that carries the computer program according to the fourth aspect.

[0123] A sixth aspect of the invention is a method for cooperative action between vehicles, which can form the basis of one or more divisional or subsequent applications, wherein the method includes:

[0124] - Negotiate an action between at least the first vehicle and the second vehicle, wherein the action is specified based at least on one or more target road resources assigned to the second vehicle;

[0125] - Transmitting a status request message from a first vehicle to a second vehicle, wherein the status request message includes one or more status indications (e.g., in the form of "entering" or "leaving") relating to the execution status of one or more target road resources among the target road resources assigned to the second vehicle, included in the status request message(s).

[0126] The status indication reflects the current known ( / perceived by the first vehicle / assumed by the first vehicle) execution state of the first vehicle; and

[0127] - A status response message is transmitted from the second vehicle to the first vehicle, wherein the status response message includes one or more status indications (e.g., in the form of "entering" or "leaving") relating to the execution status of the at least one target road resource assigned to the second vehicle, and the status indications(s) included in the status response message reflect the currently known execution status of the second vehicle.

[0128] For example, according to an embodiment of the first aspect of the invention, a status request message can be configured as a status message (MSM). Furthermore, according to an embodiment of the first aspect of the invention, a status response message can be configured as a feedback message (MFM). Therefore, the content explained above and below in conjunction with the attributes of response messages and / or feedback messages according to the first aspect of the invention can be similarly applied to status response messages / status request messages according to the sixth aspect of the invention.

[0129] However, it should be noted that the method according to the sixth aspect need not implement all the features of the method according to the first aspect. For example, in the method according to the sixth aspect, it is not necessary to automatically transmit status messages when a vehicle enters / leaves an area associated with the target road resources allocated to that vehicle (not to mention every time).

[0130] In an embodiment, the status request message and / or status feedback message may also refer to the execution status of one or more target road resources assigned to the first vehicle within the negotiation action.

[0131] Furthermore, in a preferred embodiment, both the status request message and the status feedback message include a status indication of the corresponding execution status of all target road resources involved in the negotiation action.

[0132] In an embodiment, all vehicles participating in the negotiation process can exchange state information via a combination of state request messages (e.g., in the form of MSM) and state feedback messages (e.g., in the form of MFM).

[0133] Similar to what has already been explained above in the context of some embodiments of the method according to the first aspect of the invention (and will be further explained in the detailed description below with reference to the accompanying drawings), the method according to the sixth aspect can implement a scheme in which a first vehicle participating in a cooperative action proactively requests a state clarification from a second vehicle participating in the action, for example, if the first vehicle detects a significant deviation of the second vehicle from the negotiated action. In this case, the first vehicle can transmit a state request message representing its own current knowledge (or assumptions) about the execution state. The second vehicle can respond with a feedback message representing its own current knowledge (or assumptions) about the execution state. For example, the first vehicle can then analyze the state feedback message by comparing the state information known ( / assumed / perceived) by the first vehicle and the state information known ( / assumed / perceived) by the second vehicle. Thus, for example, a significant deviation can be confirmed (or not confirmed) by the state feedback message.

[0134] For example, such deviations can be detected at least in part based on status messages previously received by the first vehicle from the second vehicle or from another participating vehicle.

[0135] Therefore, for example, the method of the sixth aspect can form the basis for implementing a scheme corresponding to the "second alternative solution" mentioned above, which provides the possibility for participating vehicles to proactively request their respective execution states from other participating vehicles. As mentioned above, such a solution may have certain advantages in reducing network load.

[0136] Those skilled in the art will recognize the additional features and advantages upon reading the following detailed description and viewing the accompanying drawings.

[0137] Reference will now be made in detail to various embodiments, one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation and is not intended to limit the invention. For example, a feature shown or described as part of one embodiment may be used on or in combination with other embodiments to produce yet another embodiment. The invention is intended to include such modifications and variations. These examples are described using specific language that should not be construed as limiting the scope of the appended claims. The drawings are not scaled and are for illustrative purposes only. For clarity, unless otherwise stated, the same elements or method steps are designated by the same reference numerals in different drawings. Attached Figure Description

[0138] Figure 1 This is an illustrative and exemplary use case description of a lane-changing scenario.

[0139] Figure 2 This is an illustrative and exemplary use case description of another lane-changing scenario.

[0140] Figures 3 to 9 Each schematically and exemplary illustrates the definition of the target road resource.

[0141] Figure 10 A sequence of method steps according to one or more embodiments is illustrated schematically and exemplary.

[0142] Figure 11 The message flow between a master vehicle and a plurality of remote vehicles according to one or more embodiments is illustrated schematically and exemplary. Detailed Implementation

[0143] Figure 1 and Figure 2 Each example schematically illustrates a corresponding lane-changing scenario as an exemplary use case of the method presented herein. The method will be explained below within the context of these exemplary scenarios, with reference also to... Figure 10 and 11 The steps are shown in the figure.

[0144] exist Figure 1 In the exemplary scenario shown, the primary vehicle HV is initially traveling in the leftmost lane of a three-lane road and is expected to switch to the middle lane. Two remote vehicles, RV1 and RV2, are traveling in the rightmost lane.

[0145] exist Figure 2 In the exemplary scenario shown, the primary vehicle HV is initially traveling in the rightmost lane of a three-lane road and is expected to switch to the middle lane, while the remote vehicle RV1 is traveling in the leftmost lane.

[0146] Assume that all three vehicles, HV, RV1, and RV2, are CAVs.

[0147] At the start of both exemplary scenarios, all vehicles HV, RV1, and RV2 are in a cognitive state (which may also be referred to as a pre-cognitive state), where they can receive, for example, Cooperative Cognitive Message (CAM) or Basic Safety Message (BSM) beacons. Using such beacons and / or information acquired through environmental perception sensors, the master vehicle HV can identify the corresponding remote vehicles RV1 and RV2 as its intended lane-changing partners.

[0148] The main HV plans road change actions based on one or more target road resources RR, RR1, RR2, RR3 assigned to it.

[0149] Each target road resource RR, RR1, RR2, RR3 is the area expected to be occupied by the indicated master vehicle HV (see [reference]). Figures 1 to 2 The information is specified by the area information (the dashed rectangle in the diagram) and the time information indicating the time period that the main vehicle (HV) wishes to reserve in that area.

[0150] For example, in Figure 1 In this scenario, the time slot associated with the target road resource RR is an interval between 0 and 3 seconds, counted from a reference time known to all participants (e.g., based on the synchronization time used by all participating vehicles HV, RV1, RV2). In this context, another (alternative) possible reference time could be the transmission time of the Request for Action (CQM) message (see below), or the transmission of messages by the initiating vehicle (such as the First Action Status (MSM) message, see below), indicating that a (successfully) negotiated action has been planned. Such a message can also be referred to as a Reservation Message (RVM). For example, such a reservation message could mark the start of the execution phase of a cooperative action.

[0151] exist Figure 2 In the example, the actions planned by the master vehicle HV include three road resources RR1, RR2, RR3 assigned to the master vehicle HV, and the target road resource RR4 assigned to the remote vehicle RV1 (see Figure 2 (The dashed rectangle in the middle).

[0152] Next, the main vehicle HV negotiates the planned actions with the corresponding remote vehicles RV1 and RV2 (see...). Figure 10 (The first block in the flowchart). For example... Figure 11 As shown, negotiation can be performed during the negotiation phase of the agreement.

[0153] For example, according to Figure 11 The primary vehicle (HV) can transmit a Request Message (CQM) to remote vehicles (RV1, RV2) to initiate the negotiation phase. This request message can also be referred to as a Coordination Request Message (CQM). The CQM specifies the expected lane change action based on the corresponding target road resources (RR1, RR2, RR3).

[0154] Each of the remote vehicles RV1 and RV2 receives CQM and evaluates the information included therein regarding the acceptability of the proposed actions.

[0155] In another step, each of the remote vehicles RV1 and RV2 transmits a response message CRM to the master vehicle HV (see...). Figure 11 The Response Message (CRM) indicates whether the coordinated sequence of actions is acceptable to the remote vehicle. The Response Message can also be called a Coordination Response Message (CRM).

[0156] Optionally, the CRM may include a counter-suggestion indicating acceptable modified actions for the corresponding remote vehicles R1, R2. The master vehicle HV can then update its action plan based on this feedback and send a new COM involving the adjusted suggestions, such as... Figure 11 As shown.

[0157] This iteration of CQM and CRM can be repeated until no changes are suggested and errors are no longer transmitted. This is a sign of convergence, and each participating vehicle (HV, RV1, RV2) can ensure that all other vehicles also agree to the action. When such convergence is reached, the negotiation phase ends.

[0158] Subsequently, the execution phase can begin, for example, by transmitting a status message (MSM) via the master vehicle (HV), which indicates that the negotiated action is "planned." The status message can also be referred to as an action status message (MSM). For example, as described above, according to some embodiments, such a first status message (MSM) can also be referred to as a reservation message (RVM).

[0159] More generally, such as Figure 11 The diagram schematically illustrates that during the execution phase, one or more status messages (MSMs) can be transmitted between the vehicles (HV, RV1, RV2) involved in the coordinated action. Each MSM can indicate the corresponding status of the action at the sending end to the appropriate receiver. Specifically, each MSM can contain status indications related to a specific target road resource, such as "reservation," "entry," "departure," and "cancellation."

[0160] In the variant, the MSM includes not only a status indication of the target road resources allocated to the vehicle sending the MSM, but also a status indication of the target road resources allocated to (preferably all) other vehicles participating in the operation. Therefore, the MSM can reflect the current knowledge (or assumptions) of the vehicle sending the MSM regarding the execution status of all target road resources involved in the operation.

[0161] In addition, each vehicle HV, RV1, RV2 participating in the coordinated action may be provided to transmit MSM whenever it enters or leaves the area associated with the target road resources RR, RR1, RR2, RR3 allocated to the corresponding vehicle HV, RV1, RV2 (and preferably as soon as possible).

[0162] For example, refer to Figures 1 to 2 In this scenario, at a certain point during the execution phase, the master vehicle (HV) determines that it has entered (or left) the area marked by the dashed rectangle, which is associated with one of the target road resources RR, RR1, RR2, and RR3. (This step corresponds to...) Figure 10 The second part of the flowchart.

[0163] In response to this determination, the master vehicle (HV) transmits a status message (MSM) to the corresponding remote vehicles (RV1, RV2), where the MSM identifies the corresponding target road resources RR, RR1, RR2, RR3 and indicates the corresponding status "entering" (or "leaving"). (This step corresponds to...) Figure 10 (The third section of the flowchart.)

[0164] Similarly, in Figure 2 In the scenario, remote vehicle RV1 can also transmit an MSM with a status indication of "entering" (or "leaving") to the master vehicle HV in response to determining that remote vehicle RV1 has entered (or left) the area marked by a dashed rectangle associated with the target road resource RR4.

[0165] To notify the MSM transmitter that all participating vehicles (HV, RV1, RV2) have received the MSM and to ensure that the internal state directories of all participants are synchronized, a feedback message (MFM) can be sent from the MSM receiver to the MSM sender as an acknowledgment. Such a feedback message can also be called an Action Feedback Message (MFM).

[0166] For example, an MFM can repeat at least part (or all) of the content of a MSM that has just been received.

[0167] Additionally or alternatively, the MFM transmitted by vehicles HV, RV1, and RV2 in response to the MSM may be provided, reflecting the current knowledge (or assumptions) of vehicles HV, RV1, and RV2 about the execution status of target road resources RR1, RR4, RR3, and RR4 of other participating vehicles HV, RV1, and RV2 (preferably all).

[0168] For example, in Figure 2 In this scenario, the remote vehicle RV1 can proactively request clarification via a Modem of Sensing (MSM), for example, if it detects that the primary vehicle HV may have deviated from the agreed-upon action. For instance, at time t = 5 seconds, the remote vehicle RV1 can transmit an MSM indicating that its own target road resource RR4 is "entering" and the primary vehicle's HV is "entering" for target road resource RR2. This could correspond to a situation where the remote vehicle RV1 assumes (e.g., based on data provided by its own environmental perception sensors) that the primary vehicle HV may have deviated from the agreed-upon action, where at t = 5, it is still in the area associated with target road resource RR2, whereas according to the agreed-upon action, it should already be in the area associated with target road resource RR3.

[0169] The primary vehicle (HV) can respond to this clarification request using an MFM that reflects its current knowledge. For example, it can confirm the status indications contained in the MFM of the remote vehicle (RV1). Alternatively, it can "correct" the assumptions about the remote vehicle's RV1 by including the "entry" status of its target road resource RR3 and the "departure" status of its target road resource RR2 in the MFM.

[0170] Therefore, each participating vehicle HV, RV1, RV2 can use MSM and MFM to determine, based on the information conveyed by MSM and / or MFM, whether another participating vehicle HV, RV1, RV2 uses the corresponding target road resources RR1, RR2, RR3 according to the negotiated action.

[0171] For example, each vehicle HV, RV1, RV2 that has received MSM and / or MFM can (re)evaluate its own further participation in the operation based on the information conveyed by the MSM and / or MFM.

[0172] For example, based on information transmitted via MSM from the master vehicle HV to the remote vehicle RV1 and / or based on information transmitted via MFM from the master vehicle HV to the remote vehicle RV1, in Figure 2 In this scenario, remote vehicle RV1 can determine the deviation between the first vehicle's HV usage of one of the target road resources RR1, RR2, and RR3 and the negotiated action. In response to such a determination, if an assessment concludes that further participation by remote vehicle RV1 under the changed conditions is infeasible or unacceptable (i.e., considering the deviation between the primary vehicle's HV and the agreed action), remote vehicle RV1 can transmit a cancellation message for its own target road resource RR4. Additionally or alternatively, remote vehicle RV1 can also transmit one or more alternative target road resources for the primary vehicle's HV and / or remote vehicle RV1 as suggestions for modified actions.

[0173] Once the corresponding status indicators for all target road resources RR1, RR2, RR3, and RR4 involved in the action are set to "departure," the joint action can be considered complete (see [link to action]). Figure 11 ).

[0174] Figures 3 to 9 Each diagram in the diagram schematically and exemplaryly illustrates possible ways to define the target road resource RR. In each case, the target road resource RR is defined based on certain geographical characteristics and certain temporal characteristics.

[0175] Regarding the time characteristics, in each case, the target road resource RR can be defined by indicating the start time when the aforementioned space can be occupied and the end time when the space must be vacated, where the time can be counted relative to the start time of the action, for example.

[0176] Regarding geographical characteristics, different variations can be considered:

[0177] For example, according to Figure 3The area associated with the target road resource RR can be represented as a bounding box with defined width, length, and height. The location of this area can be defined by its center location, such as... Figure 3 The center position is indicated by the "X" in the diagram. For example, the center position can be specified by GNSS location (latitude, longitude, and altitude), i.e., by absolute position. Alternatively, the center position can be specified by lateral, longitudinal, and elevation displacements relative to the vehicle's current position (or the current road resource), i.e., as a relative position. Furthermore, lane identifiers can be used to define the target road resource RR.

[0178] according to Figure 4 and Figure 5 The area associated with the target road resource RR can be represented by a straight or curved frame with a defined width (e.g., approximately corresponding to lane width). Vertically, the location of the target road resource is defined by the corresponding center positions on either side of the frame (marked with an "X"). For example, the center positions can be specified by GNSS location (latitude, longitude, and altitude), i.e., by absolute position. Alternatively, the center positions can be specified by lateral, longitudinal, and elevation displacements relative to the vehicle's current position (or the current road resource), i.e., as relative positions. Furthermore, lane identifiers can be used to define the target road resource RR.

[0179] It should be noted that references such as those above Figures 3 to 5 The target road resource RR described can also be limited to the moving target road resource RR.

[0180] This is Figures 6 to 9 Each of the diagrams in the figure is illustrated exemplarily, where arrows symbolize movement of the corresponding area that defines the target road resource RR.

[0181] For example, according to Figure 6 Anchoring time and regional movement speed can further define the geographical characteristics of the target road resource RR.

[0182] Figures 7 to 9 The geographical characteristics of the target road resource RR can also be defined by one or two (potentially moving) vehicles A and B.

[0183] For example, according to Figure 7 The shape of the frame can be defined by the descriptions of the two vehicles A and B at either end of the frame. If vehicles A and B appear only at one end of the frame, the length of the frame can be defined using the length value L, such as... Figures 8 to 9 As shown. Even in all Figures 6 to 9 The area in question is always framed; the same constraint principle can also be applied to similar... Figure 5 The curved frame shown.

[0184] In light of the aforementioned variations and scope of application, it should be understood that the present invention is not limited to the foregoing description or the accompanying drawings. Rather, the present invention is limited only to the appended claims and their legal equivalents.

[0185] References

[0186] [1] K. Sjdberg, P. Andres, T. Buburuzan and A. Brakemeier, “Cooperative Intelligent Transport Systems in Europe: Current Deployment Status and Outlook”, IEEE Journal of Vehicle Technology, Vol. 12, No. 2, pp. 89-97, 2017.

[0187] [2] L. Chen and C. Englund, “Cooperative Intersection Management: A Survey”, IEEE Transactions on Intelligent Transportation Systems, Vol. 17, No. 2, pp. 570-586, 2016.

[0188] [3] J. Rios-Torres and A.A. Malikopoulos, “A Survey on the Coordination of Connected and Automated Vehicles at Intersections and Merging at Highway On-Ramps”, IEEE Transactions on Intelligent Transportation Systems, Vol. 18, No. 5, pp. 1066-1077, 2017.

[0189] [4] Intelligent Transportation Systems (ITS); Vehicle Communication; Information Reporting for Action Coordination Services, ETSI TR 103578 V0.0.4 (2019-11), (Draft).

[0190] [5] Application protocols and requirements for action sharing and collaboration services, SAE J3186 (draft).

[0191] [6] L. Hobert, A. Festag, I. Llatser, L. Altomare, F. Visintainer and A. Kovacs, “Enhancements of V2X Communication in Support of Cooperative Autonomous Driving”, IEEE Communications Journal, Vol. 53, No. 12, pp. 64-70, 2015.

[0192] [7] C. Burger, P. P. Orzechowski, O. Sas and C. Stiller, “Rating Cooperative Driving: A Scheme for Behavior Assessment”, IEEE International Conference on Intelligent Transportation Systems (ITSC), 2018, pp. 1-6.

[0193] [8] B. Lehmann, HJ Gunther and L. Wolf, “A Generic Approach Towards Maneuver Coordination for Automated Vehicles”, Proceedings of the IEEE Intelligent Transportation Systems Conference, ITSC, 2018, pp. 3333-3339.

[0194] [9] I. Llatser, T. Michalke, M. Dolgov, F. Wildschutte and H. Fuchs, “Cooperative Automated Driving Use Cases for 5G V2X Communication”, IEEE 5G World Forum (5GWF), 2019, pp. 120-125.

[0195]

[10] A. Correa, R. Alms, J. Gozalvez, M. Sepulcre, M. Rondinone, R. Blokpoel, L. Lucken and G. Thandavarayan, “Infrastructure Support for Cooperative Maneuvers in Connected and Automated Driving”, IEEE Intelligent Vehicles Workshop, 2019, pp. 20-25.

[0196]

[11] D. HeB, R. Lattarulo, J. Perez, T. Hesse and F. Koster, “Negotiation of Cooperative Maneuvers for Automated Vehicles: Experimental Results”, IEEE International Conference on Intelligent Transportation Systems (ITSC), 2019, pp. 1545-1551.

[0197]

[12] K. Franke, M. During, R. Balaghiasefi, M. Gonter, K. Lemmer and F. Kucukay, “A Reference Architecture for CISS / CDAS within the Field of Cooperative Driving”, IEEE International Conference and Exhibition on Connected Vehicles (ICCVE), 2014, pp. 357-363.

[0198]

[13] C. Frese, J. Beyerer and P. Zimmer, “Cooperation of Cars and Formation of Cooperative Groups”, Proceedings of the IEEE Intelligent Vehicles Symposium, 2007, pp. 227-232.

[0199]

[14] B. Hafner, J. Jiru, K. Roscher, J. Ott, GASchmitt and Y. Sevilmis, “CVIP: A Protocol for Complex Interactions Among Connected Vehicles”, will be presented at the 2020 IEEE Intelligent Vehicles Workshop (IV), October 20-23, 2020, Las Vegas, Nevada, USA (preprint available here: http: / / www.netlab.tkk.fi / ~jo / papers / 2020-10-iv-cvip-complex-maneuvers.pdf).

Claims

1. A method for coordinating actions between vehicles, the method comprising: The first vehicle (HV) negotiates actions with the second vehicles (RV1, RV2), wherein the actions are specified based at least on one or more target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV) and one or more target road resources (RR4) assigned to the second vehicle (RV1), wherein the target road resources (RR1, RR2, RR3, RR4) include at least one area information and at least one time information, and wherein the negotiation includes one or more iterations of the first vehicle (HV) sending a request message (CQM) from the first vehicle (HV) to the second vehicle (RV1, RV2) and the first vehicle (HV) receiving a response message (CRM) from the second vehicle (RV1, RV2); The first vehicle (HV) determines that it has entered the area of ​​one of the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), and / or determines that it has left the area of ​​one of the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV). In response to determining that the first vehicle (HV) has entered the area associated with the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), and / or in response to determining that the first vehicle (HV) has left the area associated with the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), the first vehicle (HV) transmits a status message MSM to the second vehicle (RV1, RV2), wherein the status message MSM includes an identifier of the corresponding target road resource (RR1, RR2, RR3, RR4) and information indicating whether it has entered or left the corresponding area associated with the target road resource (RR1, RR2, RR3, RR4).

2. The method according to claim 1, further comprising: The second vehicle (RV1, RV2) determines, based on the information transmitted using the status message MSM, whether the first vehicle (HV) uses the corresponding target road resources (RR, RR1, RR2, RR3) according to the negotiated action.

3. The method according to any one of the preceding claims further includes: The second vehicle (RV1, RV2) reassesses its participation in the negotiation action based on information transmitted using the status message MSM transmitted from the first vehicle (HV) to the second vehicle (RV1, RV2).

4. The method according to any one of the preceding claims, comprising: The second vehicle (RV1, RV2) determines the deviation between the first vehicle's (HV) use of the corresponding target road resources (RR1, RR2, RR3) and the negotiated action based on information transmitted using the status message MSM sent from the first vehicle (HV) to the second vehicle (RV1); and In response to determining the deviation, at least one of the following is sent from the second vehicle (RV1) to the first vehicle (HV): Cancellation message for assigning one or more target road resources (RR4) to the second vehicle (RV1); One or more alternative target road resources for the first vehicle (HV) and / or for the second vehicle (RV1).

5. The method according to any one of the preceding claims, wherein when it has been determined that the first vehicle (HV) has entered the area associated with the target road resources (RR1, RR2, RR3), and / or when it has been determined that the first vehicle (HV) has left the area associated with the target road resources (RR1, RR2, RR3), the status message MSM is immediately transmitted from the first vehicle (HV) to the second vehicle (RV1, RV2).

6. The method according to any one of the preceding claims, comprising: Whenever it is determined that the first vehicle (HV) has entered the area associated with the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), and / or whenever it is determined that the first vehicle (HV) has left the area associated with the target road resources (RR1, RR2, RR3) assigned to the first vehicle (HV), a status message MSM is transmitted from the first vehicle (HV) to the second vehicle (RV1, RV2).

7. The method according to any one of the preceding claims, wherein the method further comprises: In response to receiving the status message MSM, the second vehicle (RV1, RV2) transmits a feedback message MFM.

8. The method of claim 7, wherein the feedback message MFM repeats at least a portion of the received status message MSM.

9. A vehicle configured to perform steps performed by a first vehicle (HV) and / or a second vehicle (RV1, RV2) according to any one of the preceding claims.

10. A computer program product comprising instructions that, when executed by a vehicle, cause the vehicle to perform the steps performed by the first vehicle (HV) and / or the second vehicle (RV1, RV2) according to any one of claims 1 to 8.

11. A computer-readable storage medium comprising instructions that, when executed by a vehicle, cause the vehicle to perform the steps performed by the first vehicle (HV) and / or the second vehicle (RV1, RV2) according to any one of claims 1 to 8.

Images