Methods for coordinating one or more operations between vehicles

Abstract

A method is provided for coordinating one or more maneuvers among autonomous vehicles. The method includes: planning (21) a coordinated maneuver sequence involving an initiating vehicle (HV) and remote vehicles (RV, RV1, RV2, RV3, RV4); and transmitting (22) a request message (CQM) to the remote vehicles (RV, RV1, RV2, RV3, RV4), the request message (CQM) including information specifying the coordinated maneuver sequence.

Description

Technical Field

[0001] This specification relates to methods for coordinating one or more operations between vehicles and computing devices configured to perform such methods. Specifically, this specification relates to aspects of protocols for arbitrary complex interactions between connected and automated vehicles (CAVs), exemplary embodiments of which will also be referred to hereinafter as the Complex Vehicular Interactions Protocol (CVIP). Background Technology

[0002] In the field of autonomous driving, it is widely accepted that autonomous vehicles must be interconnected to create mutual awareness and coordinated maneuvering. However, how to achieve this interaction between autonomous vehicles in detail remains an open question. Several new protocols for cooperative services have been discussed, such as lane changing or overtaking within the European Telecommunications Standards Institute (ETSI) and the Society of Automotive Engineers (SAE). These communication protocols are often dedicated to individual maneuvering or based on implicit assumptions about the intentions of other vehicles.

[0003] Furthermore, beyond internet connectivity for infotainment use, direct communication between road users, Vehicle-to-Everything (V2X) wireless communication technology, is very close to becoming a reality. Although this has been touted for over a decade, the situation has recently changed. Standards regarding basic safety can be considered nearly mature, and first-generation original equipment manufacturers (OEMs) have begun deploying basic V2X services in a range of production vehicles, although not all questions have been answered.

[0004] Recently, attention has shifted from basic warning services to how vehicle communication can support collaboration and autonomous driving. Those 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 already begun in Europe[4] and the United States[5].

[0005] Recently, many researchers have begun to study complex interactions. For example, Burger et al. [7] defined a type of voluntary and conscious collaborative action that aims to work toward a common goal (i.e., joint optimality). They categorize collaboration based on the information exchanged (information-based) and the optimization objective used for the joint action (manipulation-based). At the highest level, total utility is optimized by sharing state information, intentions, and individual utilities.

[0006] Generally, collaborative behavior protocols can be divided into implicit protocols and explicit protocols.

[0007] Using an implicit approach, vehicles periodically share intentions and must infer whether their proposals have been accepted based on potential changes received from other vehicles [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 also sent. 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] increases the possibility of trajectory proposals by Road Side Units (RSUs) acting as traffic coordinators.

[0008] The approach based on explicit coordination is conceptually different. The idea is that the vehicle's desired maneuver must be explicitly submitted to or confirmed by the relevant actor to ensure that the proposal has been accepted. In [6], a lane change protocol is proposed. A lane change request is broadcast and responded to via a unicast lane change response. Based on the feedback, a suitable peer vehicle is selected, which will make room for the initiator and announce that this has been completed with a lane change preparation message. The initiator then changes lanes without further communication.

[0009] Another form of explicit cooperation is the spatiotemporal reservation procedure

[11] : a vehicle sends a request for some stationary or moving lane-level road space. Other vehicles will evaluate this based on inferred costs and send a commit message if other vehicles accept. Vehicles that do not send a commit message are unwilling or unable to participate in the negotiation; the behavior of vehicles that do not send a commit message must be predicted based on a non-cooperative mobility model. Considering all received commits, the initiating vehicle will determine whether it is safe to enter the reserved road space, and if so, enter the reserved road space without further communication.

[0010] Franke et al. proposed a protocol in which each vehicle announces possible maneuvers and associated costs, and selects the best subset of maneuvers for execution

[12] .

[0011] The methods mentioned have certain limitations. Specifically, most known protocols are capable of very specific maneuvers (e.g., lane changes) and need to be adapted for each new use case [6].

[0012] With the implicit method, vehicles must guess whether other vehicles have understood their suggestion or have simply changed their trajectories. This can result in very conservative CAVs. Furthermore, the periodic broadcasting of trajectories leads to a large amount of bandwidth usage that would be unnecessary if no manipulation is performed. How to govern the generation rules of such periodic beacons is another unresolved problem

[10] .

[0013] Current explicit methods are highly application-specific or based on road geometry. The former is suboptimal because each new maneuver will require a new set of messages. The latter is more general and can only consider fairly simple reservations of road space for initiating vehicles.

[0014] A common drawback of all current explicit manipulation coordination methods is that they only support a single initiator and feedback from other initiators. They do not support manipulation in which two or more participants jointly negotiate and execute certain actions.

[0015] To address this issue, Correa et al.

[10] proposed using an infrastructure. They suggested a manipulation coordination message, via which the RSU could advise vehicles to follow certain trajectories. However, because these are based on intention beacons, it is not possible to perform true joint manipulation among several vehicles, as there is no mechanism to ensure that all or none of the addressed vehicles take the actions advised by the infrastructure. Summary of the Invention

[0016] The object of this invention is to overcome or mitigate at least some of the aforementioned disadvantages of solutions known in the art. For example, it is desirable to provide a method for maneuvering coordination between vehicles in a flexible, efficient, and robust manner.

[0017] This objective is achieved by the method and computing apparatus according to the independent claim. Preferred embodiments are the subject of the dependent claims.

[0018] It should be noted that additional features of a claim subordinate to an independent claim can constitute a separate invention, independent of all features of the independent claim, either in the absence of features of the independent claim or in combination with a subset of features of the independent claim. This separate invention can be the subject 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.

[0019] As used in this specification, the term "vehicle" should be interpreted broadly. 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 either an autonomous or non-autonomous vehicle.

[0021] Additionally, it should be noted that, according to some embodiments, certain method steps described below (e.g., steps concerning the planning and / or evaluation of coordinated maneuver sequences) can be performed by elements in the interconnected infrastructure (e.g., roadside units, edge computing devices, back-end servers, quasi-stationary elements in a manufacturing plant, or others). Therefore, the elements performing these steps need not be located in the 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.

[0022] According to a first aspect of the invention, a method for coordinating one or more maneuvers among vehicles (particularly CAVs) is provided. The method includes: planning a coordinated maneuver sequence involving an initiating vehicle (sometimes referred to hereinafter as the "master vehicle") and a remote vehicle; and transmitting a request message to the remote vehicle, the request message including information specifying the coordinated maneuver sequence.

[0023] In other words, the request message includes specific suggestions for the remote vehicle to perform one or more actions (e.g., sub-manipulations) within a specified coordinated maneuvering sequence. Additionally, the request message may include one or more actions planned by the master vehicle to be performed within the specified coordinated maneuvering sequence.

[0024] These individual actions can be independent of each other in time. Alternatively, the temporal relationship between these individual actions (e.g., with respect to their respective start or end times) can be expressed in the proposal.

[0025] The proposed method allows for explicit joint manipulation negotiation while maintaining general applicability. In other words, the method is not use case specific, but allows for reuse and supports scalability for future manipulations. For example, future use cases can also be easily implemented by including new fields in the request message (and possibly in subsequent messages, as described below in conjunction with some embodiments).

[0026] This method can also be used to coordinate multiple operations.

[0027] Each manipulation can include several actions, such as sub-manipulations.

[0028] Coordinated manipulation sequences can include multiple individual actions, sub-manipulations, and / or manipulations.

[0029] In this context, coordination can refer to the coordination of the planning of the manipulation sequence, and optionally also to the coordination of the execution of the manipulation sequence.

[0030] It should be understood that, according to some embodiments, the method may involve multiple remote vehicles, such as at least two remote vehicles. Therefore, in principle, the method allows for the coordination of complex operations involving any number of participants.

[0031] For example, individual request messages can be sent to each remote vehicle, which can be addressed by means of a corresponding ID (such as a so-called station ID).

[0032] For example, the initiating vehicle may send such a request message after determining that it needs to jointly operate one or more remote vehicles that are potential partners.

[0033] According to some embodiments, the request message can be transmitted directly or indirectly from the initiating vehicle to a remote vehicle.

[0034] For example, the wireless transmission path for requesting a message may 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, optionally, one or more intermediate stations, such as base stations, may be involved.

[0035] In one embodiment, the planning of the coordinated manipulation sequence is triggered or executed by a computing device of the initiating vehicle. For example, at least some of the data processing involved in the planning can be performed by a computing device that may be located in the initiating vehicle. For example, such a computing device can implement (at least a portion) of what will be further referred to below as "cooperation logic".

[0036] For example, planning can be accomplished through one or more components of an interconnected infrastructure (e.g., roadside units, edge computing devices, back-end servers, etc.), which is also within the scope of this invention.

[0037] For example, in one embodiment, some of the data processing involved in the planning can be performed at least partially on external computing devices (such as by means of edge or cloud services and / or remote servers). For example, an edge computing platform other than the road can initiate the manipulation. In this case, the planning of coordinating the manipulation sequence can be set up so that the planning is triggered (i.e. initiated) at least by the computing device of the initiating vehicle.

[0038] Preferably, the planning of the coordinated manipulation sequence considers assumptions (or knowledge) about the maneuverability of the remote vehicle, such as its physical capabilities and vehicle dynamics. In other words, the proposed manipulation can directly reflect the assumptions (or knowledge) about the initiating vehicle regarding the physical capabilities and vehicle dynamics of other actors. For example, this could also refer to certain limitations of the remote vehicle. Such assumptions or knowledge about the initiating vehicle can, for example, be based on protocol-based queries of value or state information, which can produce indications of (inadequate) capacity, etc. Such information can be conveyed, for example, through response schemes explained below.

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

[0040] For example, the aforementioned assumptions or knowledge can be based on environmental models and / or predictive models available to the initiating vehicle. Backend information available to the initiating vehicle can also be used as the basis for such assumptions or knowledge.

[0041] Regarding the content of the request message, in the embodiments, the request message may further represent one or more information needs that the initiating vehicle requests be met by a remote vehicle. In other words, in the request message proposing a coordinated manipulation sequence, the information needs may additionally indicate that the initiating vehicle wishes to be met by one or more remote vehicles. Therefore, the method can also implement demand-based information exchange based on the same message set used for manipulation coordination. Thus, the proposed protocol can combine cooperative sensing and cooperative manipulation.

[0042] 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 a coordinated manipulation sequence.

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

[0044] In this embodiment, the evaluation of the information included in the request message is triggered or performed by a computing device of the initiating 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 a remote vehicle. For example, such a computing device can implement at least a portion of what will be further referred to below as “cooperative logic”.

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

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

[0047] According to some embodiments, response messages can be transmitted directly or indirectly from a remote vehicle to the initiating vehicle.

[0048] For example, the wireless transmission path for responding to the message can therefore extend 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 optionally, one or more intermediate stations, such as base stations, may be involved.

[0049] The response message (explicitly or implicitly) indicates whether the coordinated maneuvering sequence is acceptable for the remote vehicle. Therefore, the response message can convey confirmation or rejection of the proposed coordinated maneuvering sequence, the latter possibly in conjunction with a contrary recommendation, as described below.

[0050] In one embodiment, the response message includes a reverse suggestion of a coordinated maneuver sequence acceptable to the remote vehicle.

[0051] For example, in this case, the method may also include the step of planning a coordinated manipulation sequence of adjustments acceptable to the remote vehicle, wherein the planning may be performed or triggered by the remote vehicle (such as by means of a computing device of the remote vehicle, which may, for example, implement so-called cooperative logic).

[0052] The combination of the transmitted request and the received response can provide the initiating vehicle with a clear picture of the remote vehicle's willingness to participate.

[0053] In particular, by providing a response message as part of the protocol for coordinated manipulation, the willing participants in coordinated manipulation can be determined via responses received from remote vehicles. Thus, for example, some of the known drawbacks associated with the concept of group formation involving complex manipulations can be avoided [8].

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

[0055] Alternatively or additionally, the method may include, in response to the initiating vehicle receiving one or more affirmative response messages indicating that the coordinated maneuvering sequence is acceptable to all involved remote vehicles, transmitting a maneuvering status message to the involved remote vehicles indicating that the coordinated maneuvering sequence has been planned.

[0056] For example, according to some embodiments, it can be configured to iterate through (potentially updated) request and response messages repeatedly until no changes are proposed and no more errors are sent. This can be considered a sign of “convergence” in the manipulation coordination.

[0057] When convergence is achieved, the initiating vehicle can send a status message, along with the agreed-upon actions and the "planned" action status for each action. In this way, each participating vehicle can ensure that all other involved vehicles have also agreed to the actions.

[0058] More generally, according to some embodiments, the method may include transmitting one or more status messages between vehicles involved in a (possibly adjusted) coordinated maneuvering sequence, wherein each status message indicates to the receiving end the corresponding status of the maneuvering in the coordinated maneuvering sequence at the sending end.

[0059] Therefore, the proposed method supports explicit negotiation of maneuvering among the vehicles involved, while allowing monitoring of maneuvering progress via state updates.

[0060] For example, in addition to the status "Planning" as mentioned above, other possible status values ​​that can be conveyed along with status messages are "InProgress", "Finished" and "Cancelled".

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

[0062] In this embodiment, the execution state of a specific action is set so that it can only be changed by the actor performing the action. This can help avoid inconsistencies.

[0063] For example, once the corresponding state of all manipulations in the coordinated manipulation sequence has been set to Finished, the joint manipulation can be considered complete.

[0064] Furthermore, it can be configured that each participating vehicle (i.e., the initiating vehicle and the remote vehicle) can cancel the coordinated manipulation sequence via status messages. The interaction protocol can then be responsible for coordinating the orderly and consistent cancellation of the manipulation sequence.

[0065] Optionally, an appropriate retransmission scheme can be implemented for the status messages to ensure that each status message reaches every participating actor (except the sender of the status message). Such an exemplary retransmission scheme is described below in the detailed description of the embodiments.

[0066] For example, the necessity of applying a retransmission scheme and its specific design may depend on the reliability of the transmission channel, and may be adjusted according to the reliability of the transmission channel (e.g., in the case of a very unreliable transmission channel, the message may be retransmitted several times).

[0067] Furthermore, in the embodiments, the manipulation state information included in the received state information is stored at the corresponding receiving end. Specifically, it can be configured that upon receiving the first state message, each participating vehicle that has already received the state message internally stores the current state of all manipulations in the coordinated manipulation sequence, in order to track the execution of other actors and know when to trigger its own execution.

[0068] In an embodiment, the method further includes transmitting a feedback message in response to receiving a status message.

[0069] Feedback messages can be used for confirmation.

[0070] For example, feedback messages indicate the receipt of status messages for operations and / or execution statuses, such as those received from the internal buffer of the sending vehicle.

[0071] Preferably, the receipt of status messages is confirmed via feedback messages to ensure that each participating vehicle knows the current status.

[0072] For example, it can be configured that the feedback message repeats the content of the received status message. Therefore, it can be ensured that all participating vehicles have a synchronized state of execution status for all involved vehicles. Thus, for example, in the event of a transmission error, conflicts can be identified and consistency can be ensured. In particular, this provides an effective mechanism to prevent deviations in internal execution state among actors, for example, due to the absence of a received message. It should be noted that this functionally goes beyond simply sending an ACK message.

[0073] In some embodiments, all feedback messages can be sent to all other participating vehicles. Alternatively, for example, it can be configured such that feedback messages should at least be sent to the vehicle that sent the pending status message (and possibly also to some or all other participating vehicles).

[0074] Furthermore, in this embodiment, the configuration is such that, within the framework of a coordinated manipulation sequence, the status information transmitted by the participating vehicles is synchronized with the actions performed by the vehicles. That is, for example, in response to receiving a status message indicating that the vehicle should subsequently initiate a certain action (i.e., manipulation or a portion of manipulation, such as decelerating to a certain speed), the vehicle confirms by sending a feedback message, initiates the action, and then sends a status message indicating the corresponding action as InProgress.

[0075] According to a second aspect of the invention, a computing device is configured to: plan a coordinated maneuver sequence involving an initiating vehicle and a remote vehicle; and generate a request message addressing the remote vehicle, the request message including information specifying the coordinated maneuver sequence.

[0076] 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 in the scope involving performing steps at or on behalf of the initiating vehicle.

[0077] Therefore, in some embodiments, the computing device may be located within the initiating vehicle. In other embodiments, the computing device may be located outside the initiating vehicle.

[0078] A third aspect of the invention relates to a computing device configured to: receive a request message originating from an initiating vehicle, the request message including information specifying a coordinated maneuvering sequence proposed to a remote vehicle; and evaluate information included in the request message regarding whether the coordinated maneuvering sequence is acceptable to the remote vehicle.

[0079] According to some embodiments, the computing device according to the third aspect can be configured to perform some or all of the steps of the method according to the first aspect as described above, particularly in the context of a remote vehicle or on behalf of a remote vehicle.

[0080] Therefore, in some embodiments, the computing device may be located inside the remote vehicle. In other embodiments, the computing device may be located outside the remote vehicle.

[0081] It should also be noted that in some embodiments, the computing device according to the third aspect can also be configured as a computing device according to the second aspect. In other words, the computing device can be configured to perform some or all of the steps of the method according to the first aspect as described above, i.e., steps performed at or on behalf of the initiating vehicle and / or at or on behalf of the remote vehicle.

[0082] For example, a vehicle equipped with such a computing device (or having access to such a computing device if the computing device is located outside the vehicle) can be used as both an initiating vehicle and a remote vehicle within the method of the first aspect of the invention.

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

[0084] In a fifth 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.

[0085] The sixth aspect relates to a data carrier signal that carries a computer program according to the fourth aspect.

[0086] On the other hand, methods similar to the first aspect of the invention can be more generally applied to tasks involving the coordination of actions between two or more subjects.

[0087] Therefore, a method for coordinating actions between autonomous vehicles may include:

[0088] - The plan involves a sequence of coordinated actions between the initiating entity and remote entities; and

[0089] - Send a request message to a remote entity, which includes information specifying a sequence of coordinated actions.

[0090] Alternatively, other method steps in this context (e.g., evaluating recommendations, transmitting responses, negotiating recommendations, transmitting one or more status messages during the execution phase of a coordinated action sequence, transmitting feedback messages, etc.) may be performed similarly to some or all embodiments of the method according to the first aspect.

[0091] A corresponding computing device may also be set up, which is configured to perform some or all of the steps of this method of coordinating actions between subjects.

[0092] This also applies to the corresponding computer program, the corresponding computer-readable storage medium, and the corresponding data carrier signal.

[0093] For example, in some embodiments, one or more entities may be robots (such as industrial robots) that can be configured to perform certain actions, for example, in an industrial production environment. More generally, entities may be machines or parts of machines.

[0094] Therefore, the tasks of manipulation planning and execution described in this specification can also be extended to other coordination tasks, such as integration and process coordination, for example, the automated integration of manually moved or replaced machines in an industrial manufacturing plant. Attached Figure Description

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

[0096] 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, features shown or described as part of one embodiment may be used in other embodiments or in combination with other embodiments to produce yet another embodiment. The invention is intended to include these modifications and variations. These examples are described using specific language, which should not be construed as limiting the scope of the appended claims. The drawings are not drawn to scale and are for illustrative purposes only. For clarity, unless otherwise stated, the same elements or manufacturing steps are indicated by the same reference numerals in different drawings.

[0097] Figure 1 A schematic and exemplary model of complex interactions between vehicles is shown, illustrating the actors and the inputs and outputs at different stages of collaboration (days 0-3).

[0098] Figure 2 The sequence of method steps according to one or more embodiments is illustrated schematically and exemplary.

[0099] Figure 3 The message flow between a master vehicle and several remote vehicles according to one or more embodiments is illustrated schematically and exemplary.

[0100] Figure 4 This is an illustrative and exemplary use case diagram for Stationary Vehicle Decision Assist (SVDA) scenarios.

[0101] Figure 5 A graph showing the manipulation ratio relative to the packet loss rate for a successful completion of a protocol stream simulation, according to one or more embodiments.

[0102] Figure 6A graph is shown showing the average rate of message transmission in a successfully completed operation relative to the packet loss rate for each of several message types, such as those simulated for an exemplary protocol stream, according to one or more embodiments. Detailed Implementation

[0103] The following describes exemplary embodiments involving complex interactions between CAVs. For example, according to some embodiments, a complex interaction can be defined as the exchange of messages between two or more actors, wherein at least one of at least three messages depends on another. The basic principle of this definition is as follows: obviously, a single vehicle cannot interact. Furthermore, even though simple interactions may exchange fewer than three messages, most collaborations should involve at least requests / suggestions, responses / acceptance, and decisions.

[0104] Subordination requirements reflect the need for actual interaction. If some changes occur in an earlier message chain, subsequent messages must differ in content or the address being visited. The exchange of periodic beacons broadcast independently of the input received (e.g., about the sender's state or perceived objects) is not a complex interaction because it does not depend on the actions or messages of other actors.

[0105] The above definition of complex interactions encompasses various applications (such as maneuvering collaboration or information sharing) and primarily concerns the underlying protocols. The idea is that in a fully interconnected ecosystem, distinguishing too many types of interactions might not be wise; instead, protocols should be generalized to apply across a wide range of scenarios, provided the overhead allows. For example, a vehicle might need further information to initiate collaborative proposals. Therefore, a vehicle could first request information (e.g., about an object perceived by the vehicle ahead) and then begin subsequent maneuvering negotiation (e.g., about overtaking maneuvers).

[0106] Figure 1 This illustrates a functional breakdown of the interaction between the inputs and outputs of an exemplary system, as well as an exemplary and schematic model of the transition from coexistence to collaboration. Solid line / white cells depict entities already existing in the so-called coexistence phase, dashed line / gray cells realize collaborative awareness, and dotted dashed line / dark gray cells are required for a fully collaborative environment.

[0107] In particular, Figure 1 The collaborative logic (“Collaboration Planning & Monitoring”) schematically depicted is typically OEM-specific, meaning the primary vehicle cannot rely on other vehicles making decisions based on their own expectations. Here, explicitly sharing maneuvering intentions and information needs makes it easier for other actors to process and decide on collaboration. Another advantage of the protocol is that it allows the primary vehicle to send collaboration proposals to one or more remote vehicles to initiate maneuvering negotiations.

[0108] In the context of an exemplary embodiment of the Complex Vehicular Interactions Protocol (CVIP) described below, Cooperative Awareness Message (CAM) or Basic Safety Message (BSM) beacons are considered to be given. They are used to identify potential maneuvering partners in the awareness phase before the actual interaction involving the negotiation and execution phases begins. Any additional information required should be exchanged via dedicated messages. Here, only joint maneuvering performed by an autonomous vehicle is considered. Autonomous vehicles are able to share information about intent, unlike manually driven vehicles which can only measure their current state without knowing the driver's next action.

[0109] Vehicles must be able to estimate the dynamics of other vehicles to make reasonable maneuvering suggestions. They can respond accordingly if the proposed maneuver is impossible for another vehicle. Since the feasibility and practicality of the content of received messages (e.g., maneuvering suggestions) cannot be determined at the protocol layer, higher layers must evaluate the incoming suggestions. This task can be performed by… Figure 1 The “Collaborative Planning & Monitoring” unit is executed.

[0110] Regarding security, for this embodiment, it is assumed that the message is signed, and the interaction is therefore protected. This will potentially increase the message size compared to the message size analyzed in this specification (see further below). The security of the communication and the interaction itself is important, but a more detailed security analysis is postponed to future work because there are ways to prevent certain malicious actions, such as credentials

[14] .

[0111] The guiding principles for Complex Vehicle Interaction Protocols (CVIP) are as follows:

[0112] First, an appropriate number of confirmations are considered necessary because actors need to know whether other vehicles have heard, understood, and agreed to the proposed interaction. In the CVIP protocol, the execution status of a specific action can only be changed by the actor performing the action to avoid inconsistencies.

[0113] Secondly, even if some entities need to express an initial request for manipulation, the decision regarding participation can only come from the participants themselves in a distributed manner. For example, if their own safety is at risk, the actor must be able to stop the manipulation at any given point in time.

[0114] In a preferred embodiment of CVIP, request cascading (see [8]) is not enabled because this would significantly increase the delay before the manipulation can be performed

[11] . Cascading means that a request from vehicle A to vehicle B includes further requests from vehicle B to other vehicles in order to be able to accept vehicle A's request.

[0115] Based on the guiding principles outlined above, preferred embodiments of the method involve the following steps, which are... Figure 2 The diagram illustrates:

[0116] -Plan 21 involves a coordinated control sequence for initiating and remote vehicles;

[0117] - Transmit a Request Message (CQM) to the remote vehicle. The Request Message (CQM) includes information specifying the coordinated manipulation sequence.

[0118] - Receive Request Message (CQM) 23 at the remote vehicle;

[0119] - Evaluate 24, including information in the request message regarding the acceptability of the coordinated manipulation sequence; and

[0120] - Send a 25-Response Message (CRM) to the initiating vehicle, wherein the Response Message (CRM) indicates whether the coordinated maneuvering sequence is acceptable to the remote vehicle.

[0121] Furthermore, the method may include: in response to the initiating vehicle receiving one or more affirmative response messages indicating that the coordinated maneuvering sequence is acceptable for all involved remote vehicles:

[0122] - Transmit a 26-maneuver status message (MSM) to the remote vehicles involved, which indicates that a coordinated maneuver sequence has been planned.

[0123] More generally, the method may include:

[0124] - Transmit one or more status messages (MSMs) between the vehicles involved in the coordinated maneuvering sequence, each status message (MSM) indicating to the receiving end the corresponding status of the maneuvering in the coordinated maneuvering sequence at the sending end.

[0125] The method may also include:

[0126] - In response to receiving a status message (MSM), a feedback message (MFM) is transmitted.

[0127] Specifically, the CVIP protocol described herein as an exemplary embodiment is designed to involve the following four types of messages: such as Figure 3As shown, there are Cooperative Request Message (CQM), Cooperative Response Message (CRM), Maneuver Status Message (MSM), and Maneuver Feedback Message (MFM).

[0128] It should be noted that Figure 3 The CQM transmission shown corresponds to Figure 2 Similarly, in step 22, the transmission of CRM corresponds to step 25, the transmission of MSM corresponds to step 26, and the transmission of MFM corresponds to step 27.

[0129] Figure 2 The dashed ring in the diagram indicates that steps 26 and 27 can be repeated during the negotiation and execution of coordinated manipulation.

[0130] Figure 2 Another dashed loop in the diagram shows that in the case of a negative response message or a response message that includes the opposite suggestion (step 25), the method can proceed to another (re)planning step 21.

[0131] Exemplary sizes for the specific message elements described below can be found in Table I.

[0132] Table I

[0133] Exemplary size ranges of protocol components mentioned in the text

[0134]

[0135] refer to Figure 4 The following explains how CVIP can be applied to a sample scenario involving a complex interaction called Static Vehicle Decision Assist (SVDA).

[0136] See Figure 4 The SVDA scenario works as follows: A stationary remote vehicle (RV) is located in front of the driving driver vehicle (HV). Upon recognizing this situation, to assess whether it's worthwhile to risk overtaking, the approaching driver vehicle (HV) queries the stationary vehicle for its estimated dwell time ( ). Figure 4 Phase "1" in the text. If the duration is below the threshold or unknown, the approaching main vehicle (HV) proposes to overtake, while the stationary remote vehicle (RV) should remain stationary. Figure 4 (Phase "2" in the process). Both vehicles agree and proceed with the overtaking maneuver.

[0137] The following will refer to Figure 3 and Figure 4In particular, refer to the initiating vehicle HV and the remote vehicles RV, RV1, RV2, RV3, and RV4.

[0138] Typically, after determining that information is needed or joint operations are required, some vehicles send a CQM (Combat Quality Messaging) to potential partners. Its content can be described as a tuple:

[0139]

[0140] G contains basic information: protocol version, message ID i msg Station ID i of the vehicle initiating the operation s Generate timestamp t gen and serial number n seq S contains basic status information, primarily its own GPS location and instance ID for reference. This can be used for reference in subsequent messages.

[0141]

[0142] These are containers used for information requests and manipulations, respectively, where k+l≥1.

[0143] Each I Q Includes the information request container ID i for reference iqc =1,...,k, Destination station (vehicle) ID i that should be provided dest The type of information requested, T Q And the update interval θ for requesting information. In the SVDA scenario, this can be the estimated duration in the current mobility state (i.e., velocity is zero), where one message is θ = -1.

[0144] Element M is a manipulation container describing the anticipated joint action; each element contains a container ID i. mc The target station ID i to be manipulated dest Manipulation type T m and related parameter P m By setting i appropriately dest Even higher-authority parties (such as RSUs or emergency vehicles) can propose manipulations that they themselves do not actively participate in.

[0145] via T m and P m Manipulation can be described using standardized names, parameterized functions, or it can be described via trajectories. These proposed manipulations directly reflect assumptions about the physical capabilities of other actors and the vehicle's dynamics. If desired, a start time t (absolute or relative to another manipulation container) can also be included. start And the expected duration of manipulation τ.

[0146] For example, in Figure 4 In the SVDA scenario, each vehicle can provide a container M, which will hold the initiating vehicle's T. m The statement refers to overtaking, which will cause the stationary vehicle's T to... m The statement is to maintain the current movement state, where both t start =0, τ equals the expected duration of the manipulation.

[0147] In principle, T m More granular statements are also meaningful, for example, having three containers for the main vehicle's HV (lane change, acceleration, lane change) and relative start times to ensure a common understanding of the execution sequence.

[0148] Upon receiving the CQM, the other vehicles RV1, RV2, RV3, and RV4 evaluate the information included in their collaboration logic. They respond with the CRM as defined below:

[0149]

[0150] G and S contain child elements of the same type as those in CQM (i.e., the updated t). gen wait),

[0151]

[0152] The above expression now includes the reference i. iqc and a container for the requested value V or an error message response. When T is given... Q The vehicle can also be described when it is not understood or unavailable.

[0153] Manipulating container M now includes group ID i pkt Its i is based on the original CQM s and n seq For reference in the statement. Additionally, it includes the manipulation state S, which is set to a planned or corresponding error state. m If needed, t can be given. start Or the updated value of τ. The combination of the request and the received response gives the initiator a clear picture of the willingness of other vehicles to participate.

[0154] This iteration of CQM and CRM will be repeated until no changes are proposed and no more errors are sent. This is a sign of convergence, and each participating vehicle HV, RV1, RV2 can be certain that all other vehicles have also agreed to the operation.

[0155] like Figure 3 As shown, CAVs that do not implement the protocol will not send CRM(RV4). TAVs that implement the protocol but do not fulfill the request... Q or Tm Some vehicles that do not meet the requirements from CQM will send a response stating this (RV3). The initiating vehicle HV then updates the recommendations based on the feedback and sends a new CQM only to vehicles that are willing, capable, and have the necessary resources.

[0156] After convergence, the initiating vehicle (HV) will send an MSM:

[0157]

[0158] MSM has agreed-upon manipulations in M, and a manipulation state S planned for each container in M. m ( Figure 4 (Phase "3" in the text). Other possible state values ​​are InProgress, Finished, and Cancelled. Through these states, all vehicles will always know the execution status of each participating actor.

[0159] Upon receiving the first MSM, each vehicle must internally store the current state of all l maneuvers in order to keep track of the execution of other actors and know when to trigger its own execution.

[0160] To notify the sender of the MSM that all participating vehicles have received the MSM and to ensure that the internal state directories of all participants are synchronized, an MFM is sent as an acknowledgment, which can be described as follows:

[0161]

[0162] MFM repeats the content of the just received MSM. While this can consume a considerable amount of the total required bandwidth, it provides an efficient mechanism to prevent actors from deviating from their internal execution state, for example, due to the absence of a message. For instance, when manipulation of container M is detected from the received MSM and MFM... l′ When the state deviates, execute M. l′ The vehicle can send a clarification MSM containing the current correct execution status.

[0163] Whenever the actor subsequently changes its manipulation execution state (via t) start (Knowing the sequence through consistent use of τ), the actor will send an MSM with an updated state so that each other vehicle knows that the actor has entered the new state (e.g., Figure 4 In stages "4" / "6", lane changing has switched to inProgress, or in Figure 4 In stage "5" / "7", lane change switches to Finished). Once all maneuvering statuses are set to Finished, the combined maneuver is completed.

[0164] Since message reception is necessary for synchronized state transitions between vehicles, a timeout-based retransmission mechanism can be optionally implemented. Therefore, for example, it can be assumed that if the CQM is discarded and thus the CRM is not received, the initiator... Then resend its CQM until c cqm Next. If CRM is discarded, the vehicle must be considered uncooperative. In the case of discarded MSM, MFM is not received at all, therefore... Then resend the message, at most c msm Second-rate.

[0165] In the event of loss of MFM, during timeout Afterwards, the corresponding MSM is resent to ensure synchronized state updates. If retrying c... msm If the MFM is subsequently lost, the operation will be cancelled.

[0166] Timeout and maximum retransmission can be adjusted, for example, based on different application scenarios, driving environments, or traffic conditions where surrounding vehicles may block the signal.

[0167] Because the requirements of different use cases can vary significantly, specific message content (e.g., the number and type of containers, which information to transmit, etc.) can be adjusted according to the specific needs. This gives CVIP the flexibility to support different scenarios without defining dedicated messages. By adding T Q ,T m ,P m By defining a set of values ​​or adding new fields, new scenarios can be easily implemented.

[0168] The information in Table I above, together with the simulation analysis presented below, shows that the current message size will not exceed a few hundred bytes. This means that today's vehicular communication technologies (such as ITS-G5 or LTE-V2X) can easily support this scalability.

[0169] Next, we present the evaluation of numerical experiments. To demonstrate the general applicability of CVIP, evaluation settings have been extracted from specific applications. Instead, the following questions will be answered via a simulation set of protocol streams:

[0170] Is the protocol scalable relative to the number of nodes participating in complex interactions?

[0171] Is the protocol feasible? That is, is the message size constrained within reasonable limits, even for high k and l?

[0172] Is the protocol robust? That is, can the protocol handle lost packets?

[0173] Therefore, consider a simple simulation scenario: place a group of N stationary vehicle nodes on a straight lane within the simulation area. The initiating node sends the first CQM to all other nodes. Since the details of the logic for deciding the incoming cooperation request are not the focus of this study, all vehicles send CRMs with positive feedback. In practice, the advanced cooperation logic will have to evaluate the feasibility of the incoming CQM. From then on, simple manipulations are performed as described in Algorithm 1: one node after another begins their manipulations for a duration τ. Using this setup, it is possible to achieve this with probability p. drop Inserting group loss is used to evaluate scalability and robustness with respect to N and l.

[0174]

[0175] All simulations were performed using the Intelligent Transport System (ITS) framework for interconnected applications, ezCar2X

[15] , in conjunction with the simulators SUMO and ns-3. To obtain important results, 100 simulation runs were performed for each parameter set described below.

[0176] The number of messages exchanged in a single interaction can be formalized based on the number of nodes N, the number of negotiation rounds ν, and the number of manipulation containers l as follows:

[0177]

[0178] The coefficient 2 is because the MSM with states InProgress and Finished will be sent to each of the l manipulation containers, and each of the l manipulation containers will be confirmed by N-1 other actors via the MFM. It is easy to see that:

[0179]

[0180] Conversely, in beacon-based methods used for intent sharing, the number of messages transmitted at frequency f is:

[0181]

[0182] The number depends on the total manipulation execution time Θ. For a reasonable set of values, such as N=10, ν=1, l=20, f=5Hz, and Θ=10s, CVIP reduces the number of messages exchanged by almost 20%. This reduction is significant because the beacon is anticipated to be used even when no manipulation is being performed, as the entire concept of implicit manipulation negotiation is based on this periodic broadcast of intent. With CVIP, messages are exchanged only when necessary. For pure information exchange (i.e., l=0, k>0, ν≥1), very few messages will be sent, precisely satisfying the information needs of the requesting vehicle. The size of the messages involved increases only linearly with the number of included containers k and l, as shown in Table I, for each I Q I R The size of M is relatively small. Serialization techniques can further reduce the total size of the transmitted messages. For example, for an MFM with l=7, the average size of the transmitted message is 137 bytes, while the message size within the source code is 203 bytes.

[0183] In the simulation, even for l=7, the total message size never exceeded 225 bytes, thus transmitting all the necessary elements for manipulating the container. This makes our protocol feasible even with today's technologies (such as ITSG5 or LTE-V2X). There is still room for future use cases to include, for example, P... m The additional fields in the code do not render message size infeasible. This also paves the way for more complex manipulation descriptions.

[0184] By introducing a probability p drop This study investigated packet loss and how robust the protocol is to transmission interruptions, even with a basic retransmission mechanism. For evaluation, an operation is considered successful if the last MSM containing all operation states set to Finished is sent and received. The ratio of successful operations to all operations is called the success rate. If a single CRM is dropped, the operation will fail because the initiating node cannot detect a CRM loss. Depending on the application, the initiating vehicle may therefore choose to send several CQMs to minimize the probability of CRM loss. Figure 5 As shown, this significantly improves the success rate for c. cqm =2, even if p drop =0.2, and the success rate also reached 0.8.

[0185] Figure 6 This illustrates the number of messages that need to be exchanged as p increases in a scenario where N=3 and each vehicle has one control. drop Increase, the baseline case is p drop =0. But even for p drop=0.2, and it won't send twice as many messages. Generally, CQM is sent relatively more frequently than CRM because vehicles must resend both lost CQM and lost CRM messages. The same applies when comparing MSM and MFM.

[0186] The above analysis demonstrates that CVIP is feasible for complex interactions. In particular, simulations show that current technology is sufficient to achieve complex interactions. For example, new communication technologies like 5G-V2X can enable unicast or larger message sizes to include very data-intensive information V or manipulation parameters P. m To support further use cases.

[0187] In light of the variations and applications described above, it should be understood that the present invention is not limited to the foregoing description or the accompanying drawings. Rather, the invention is limited only by the appended claims and their legal equivalents.

[0188] References

[0189] [1]K. P. Andres, T. Buburuzan and A. Brakemeier, “Cooperative Intelligent Transport Systems in Europe: Current Deployment Status and Outlook”, IEEE Vehicular Technology Magazine, Vol. 12, No. 2, pp. 89–97, 2017.

[0190] [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.

[0191] [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.

[0192] [4] Intelligent Transportation Systems (ITS); Vehicle Communication; Operation Coordination Service Information Reporting, ETSI TR 103 578 V0.0.4 (2019-11), (draft).

[0193] [5] Application protocols and requirements for manipulation sharing and coordination services, SAE J3186 (draft).

[0194] [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 Magazine, Vol. 53, No. 12, pp. 64–70, 2015.

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

[0196] [8] B. Lehmann, HJ Günther and L. Wolf, “A Generic Approach Towards Maneuver Coordination for Automated Vehicles”, in IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC, 2018, pp. 3333–3339.

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

[0198]

[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”, in IEEE Intelligent Vehicles Symposium, 2019, pp. 20–25.

[0199]

[11] D. Heβ, R. Lattarulo, J. Pérez, T. Hesse and F. "Negotiation of Cooperative Maneuvers for Automated Vehicles: Experimental Results", in IEEE International Conference on Intelligent Transportation Systems (ITSC), 2019, pp. 1545–1551.

[0200]

[12] K. Franke, M. Düring, R. Balaghiasefi, M. Gonter, K. Lemmer and F. Kücükay, “A Reference Architecture for CISS / CDAS within the Field of Cooperative Driving”, in IEEE International Conference on Connected Vehicles and Expo (ICCVE), 2014, pp. 357–363.

[0201]

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

[0202]

[14] B. Brecht, D. Therriault, A. Weimerskirch, W. Whyte, V. Kumar, T. Hehn and R. Goudy, “A Security Credential Management System for V2X Communications” IEEE Transactions on Intelligent Transportation Systems, Vol. 19, No. 12, pp. 3850–3871, 2018.

[0203]

[15] K. Roscher, S. Bittl, A.A. Gonzalez, M. Myrtus and J. Jiru, “ezCar2X: Rapid-Prototyping of Communication Technologies and Cooperative ITS Applications on Real Targets and Inside Simulation Environments”, in 11th Conference Wireless Communication and Information, 2014, pp. 51–62.

Claims

1. A method for coordinating one or more operations between vehicles, the method comprising: The plan (21) involves the coordinated operation sequence of the initiating vehicle (HV) and the remote vehicles (RV, RV1, RV2, RV3, RV4); (22) A request message (CQM) is transmitted to the remote vehicles (RV, RV1, RV2, RV3, RV4), the request message (CQM) including information specifying the coordinated manipulation sequence; as well as (25) A response message (CRM) is obtained from the initiating vehicle (HV), wherein the response message (CRM) indicates whether the coordinated manipulation sequence is acceptable to the remote vehicle (RV, RV1, RV2, RV3, RV4); Where the suggested coordinated maneuvering sequence is unacceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4), the response message (CRM) includes a contrary suggestion indicating a coordinated maneuvering sequence acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4). or In response to the initiating vehicle (HV) receiving one or more positive response messages (CRM) indicating that the coordinated maneuvering sequence is acceptable to all involved remote vehicles (RV, RV1, RV2, RV3, RV4): Transmit (26) a Maneuvering Status Message (MSM) to the remote vehicles involved (RV, RV1, RV2, RV3, RV4), the Maneuvering Status Message (MSM) indicating that the coordinated maneuvering sequence has been planned.

2. The method according to claim 1, characterized in that, The plan (21) takes into account assumptions or knowledge about the maneuverability of the remote vehicles (RV, RV1, RV2, RV3, RV4).

3. The method according to claim 2, characterized in that, The assumptions or knowledge regarding the maneuverability of the remote vehicles (RV, RV1, RV2, RV3, RV4) are based on protocol-based queries of value or state information.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Receive the request message (CQM) (23) at the remote vehicle (RV, RV1, RV2, RV3, RV4); and The assessment (24) includes the information in the request message regarding whether the coordinated manipulation sequence is acceptable.

5. The method according to any one of claims 1-3, characterized in that, The method further includes responding to the initiating vehicle (HV) receiving a response message (CRM) indicating that the coordinated maneuvering sequence is unacceptable for the remote vehicle (RV, RV1, RV2, RV3, RV4) or receiving a response message (CRM) including a contrary suggestion: The plan involves a coordinated control sequence for the adjustment of the initiating vehicle (HV) and the remote vehicles (RV, RV1, RV2, RV3, RV4) and / or one or more other remote vehicles (RV, RV1, RV2, RV3, RV4); as well as An updated request message (CQM) is transmitted to the remote vehicles (RV, RV1, RV2, RV3, RV4) involved in the adjusted coordinated maneuvering sequence. The updated request message (CQM) includes information specifying the adjusted coordinated maneuvering sequence.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: (26) One or more status messages (MSMs) are transmitted between the vehicles (HV, RV, RV1, RV2, RV3, RV4) involved in the coordinated manipulation sequence, each status message (MSM) indicating to the receiving end the corresponding status of the manipulation in the coordinated manipulation sequence at the sending end.

7. The method according to any one of claims 1-3, characterized in that, The method further includes transmitting (27) a feedback message (MFM) in response to receiving a status message (MSM).

8. The method according to claim 7, characterized in that, The feedback message (MFM) repeats the content of the received status message (MSM).

9. The method according to claim 8, characterized in that, The feedback message (MFM) is sent to all other participating vehicles (HV, RV, RV1, RV2, RV3, RV4).

10. A computing device, the computing device being configured to: The plan (21) involves the coordinated operation sequence of the initiating vehicle (HV) and the remote vehicles (RV, RV1, RV2, RV3, RV4); Generate a request message (CQM) addressing the remote vehicle (RV, RV1, RV2, RV3, RV4), the request message (CQM) including information specifying the coordinated manipulation sequence; as well as Receive a response message (CRM) from the remote vehicle (RV, RV1, RV2, RV3, RV4), wherein the response message (CRM) indicates whether the coordinated manipulation sequence is acceptable to the remote vehicle (RV, RV1, RV2, RV3, RV4); Where the suggested coordinated maneuvering sequence is unacceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4), the response message (CRM) includes a contrary suggestion indicating a coordinated maneuvering sequence acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4). or In response to the initiating vehicle (HV) receiving one or more positive response messages (CRM) indicating that the coordinated maneuvering sequence is acceptable to all involved remote vehicles (RV, RV1, RV2, RV3, RV4): Transmit (26) a Maneuvering Status Message (MSM) to the remote vehicles involved (RV, RV1, RV2, RV3, RV4), the Maneuvering Status Message (MSM) indicating that the coordinated maneuvering sequence has been planned.

11. A computing device, the computing device being configured to: Receive (23) a request message (CQM) originating from the initiating vehicle (HV), the request message (CQM) including: Information specifying the coordinated maneuvering sequence recommended to remote vehicles (RV, RV1, RV2, RV3, RV4); The assessment (24) includes the information in the request message regarding whether the coordinated maneuver sequence is acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4); as well as Generate a response message (CRM) addressing the initiating vehicle (HV), wherein the response message (CRM) indicates whether the coordinated manipulation sequence is acceptable to the remote vehicle (RV, RV1, RV2, RV3, RV4); Where the suggested coordinated maneuvering sequence is unacceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4), the response message (CRM) includes a contrary suggestion indicating a coordinated maneuvering sequence acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4). or In response to the initiating vehicle (HV) receiving one or more positive response messages (CRM) indicating that the coordinated maneuvering sequence is acceptable to all involved remote vehicles (RV, RV1, RV2, RV3, RV4): Transmit (26) a Maneuvering Status Message (MSM) to the remote vehicles involved (RV, RV1, RV2, RV3, RV4), the Maneuvering Status Message (MSM) indicating that the coordinated maneuvering sequence has been planned.

12. A vehicle (HV) configured to act as an initiating vehicle in the process of coordinating one or more operations among vehicles (HV, RV, RV1, RV2, RV3, RV4), said vehicle (HV) being configured to: The plan (21) involves the coordinated operation sequence of the initiating vehicle (HV) and the remote vehicles (RV, RV1, RV2, RV3, RV4); Transmit (22) a request message (CQM) to the remote vehicles (RV, RV1, RV2, RV3, RV4), the request message (CQM) including information specifying the coordinated manipulation sequence; and Receive response messages (CRM) from the remote vehicles (RV, RV1, RV2, RV3, RV4), wherein, The response message (CRM) indicates whether the coordinated maneuver sequence is acceptable for the remote vehicle (RV, RV1, RV2, RV3, RV4); Where the suggested coordinated maneuvering sequence is unacceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4), the response message (CRM) includes a contrary suggestion indicating a coordinated maneuvering sequence acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4). or In response to the initiating vehicle (HV) receiving one or more positive response messages (CRM) indicating that the coordinated maneuvering sequence is acceptable to all involved remote vehicles (RV, RV1, RV2, RV3, RV4): Transmit (26) a Maneuvering Status Message (MSM) to the remote vehicles involved (RV, RV1, RV2, RV3, RV4), the Maneuvering Status Message (MSM) indicating that the coordinated maneuvering sequence has been planned.

13. A vehicle (RV, RV1, RV2, RV3, RV4), said vehicle (RV, RV1, RV2, RV3, RV4) being configured to act as a remote vehicle in the process of coordinating one or more operations among vehicles (RV, RV, RV1, RV2, RV3, RV4), said vehicle (RV, RV1, RV2, RV3, RV4) being configured to: Receive (22) a request message (CQM) from the initiating vehicle (HV), the request message (CQM) including: Information specifying the coordinated operation sequence involving the initiating vehicle (HV) and the remote vehicles (RV, RV1, RV2, RV3, RV4); The assessment (24) includes the information in the request message (CQM) regarding whether the coordinated maneuver sequence is acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4); as well as A response message (CRM) is sent to the initiating vehicle (HV), wherein the response message (CRM) indicates whether the coordinated manipulation sequence is acceptable to the remote vehicle (RV, RV1, RV2, RV3, RV4); Where the proposed coordinated maneuvering sequence is unacceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4), the response message (CRM) includes a contrary suggestion indicating a coordinated maneuvering sequence acceptable to the remote vehicles (RV, RV1, RV2, RV3, RV4).

Images