METHOD OF COORDINATING ONE OR MORE MANEUVERS AMONG VEHICLES

Abstract

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

Claims

1. A method of coordinating one or more maneuvers among vehicles, the method comprising: planning a coordinated maneuver sequence that involves an initiating vehicle and a remote vehicle; and transmitting a request message to the remote vehicle, the request message including information specifying the coordinated maneuver sequence.

2. The method of claim 1, characterized in that the planning takes into account assumptions or knowledge on maneuver capabilities of the remote vehicle.

3. The method of claim 1, characterized in that the method further comprises: receiving the request message at the remote vehicle; and evaluating the information included in the request message as to whether the coordinated maneuver sequence is acceptable.

4. The method of claim 1, characterized in that the method further comprises transmitting a response message to the initiating vehicle, wherein the response message indicates whether the coordinated maneuver sequence is acceptable for the remote vehicle.

5. The method of claim 4, characterized in that the response message includes a counter-proposal indicating a coordinated maneuver sequence that is acceptable for the remote vehicle.

6. The method of claim 4, characterized in that the method further comprises, in response to the initiating vehicle receiving a response message indicating that the coordinated maneuver sequence is not acceptable for the remote vehicle: planning an adjusted coordinated maneuver sequence that involves the initiating vehicle and said remote vehicle and/or one or several other remote vehicle(s); and transmitting an updated request message to the remote vehicle(s) involved in the adjusted coordinated maneuver sequence, the updated request message including information specifying the adjusted coordinated maneuver sequence.

7. The method of claim 4, characterized in that the method further comprises, in response to the initiating vehicle receiving one or more affirmative response messages indicating that the coordinated maneuver sequence is acceptable for all involved remote vehicle(s): transmitting a maneuver status message to the involved remote vehicles, the maneuver status message indicating that the coordinated maneuver sequence is planned.

8. The method of claim 1, characterized in that the method further comprises: transmitting one or more status messages between the vehicles involved in the coordinated maneuver sequence, each status message indicating to the receiving end a respective status of the maneuvers of the coordinated maneuver sequence at the sending end.

9. The method of claim 7, characterized in that the method further comprises transmitting a feedback message in response to receiving a status message.

10. The method of claim 9, characterized in that the feedback message repeats the content of the received status message.

11. A computing device being configured for planning a coordinated maneuver sequence that involves an initiating vehicle and a remote vehicle; and generating a request message addressed to the remote vehicle, the request message including information specifying the coordinated maneuver sequence.

12. A computing device being configured for receiving a request message originating from an initiating vehicle, the request message including information specifying a coordinated maneuver sequence proposed to a remote vehicle; evaluating the information included in the request message as to whether the coordinated maneuver sequence is acceptable for the remote vehicle.

13. A computer program comprising instructions which, when the program is executed by a computing device, cause the computing device to carry out the steps as specified in claim 1.

14. A computer-readable storage medium comprising instructions which, when executed by a computing device, cause the computing device to carry out the steps as specified in claim 1.

15. A data carrier signal carrying the computer program of claim 13.

Description

[0095] Reference will now be made in detail to various embodiments, one or more examples of which are illustrated in the figures. Each example is provided by way of explanation, and is not meant as a limitation of the invention. For example, features illustrated or described as part of one embodiment can be used on or in conjunction with other embodiments to yield yet a further embodiment. It is intended that the present invention includes such modifications and variations. The examples are described using specific language which 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, the same elements or manufacturing steps have been designated by the same references in the different drawings if not stated otherwise.

[0096] FIG. 1 schematically and exemplarily illustrates a model for complex interactions among vehicles showing an actor together with inputs and outputs in different stages of cooperation (Day 0-3).

[0097] FIG. 2 schematically and exemplarily illustrates a sequence of method steps in accordance with one or more embodiments.

[0098] FIG. 3 schematically and exemplarily illustrates a message flow between a host vehicle and several remote vehicles in accordance with one or more embodiments.

[0099] FIG. 4 is a schematic and exemplary use case illustration for a Stationary Vehicle Decision Assist (SVDA) scenario.

[0100] FIG. 5 shows a diagram of a ratio of successfully completed maneuvers vs. packet loss rate as simulated for a protocol flow in accordance with one or more embodiments.

[0101] FIG. 6 shows a diagram of an average ratio of messages sent in successfully completed maneuvers vs. a packet loss rate for each of several message types, as simulated for an exemplary protocol flow in accordance with one or more embodiments.

[0102] In the following, exemplary embodiments involving complex interactions among CAVs will be described. For example, in accordance with some embodiments, complex interactions may be defined as message exchanges between two or more actors with at least three messages of which at least one depends on another. The rationale for this definition is as follows: clearly, a single vehicle cannot interact. Furthermore, even if simple interactions might exchange less than three messages, most cooperations should involve at least a request/proposal, a response/acceptance, and a decision.

[0103] The dependency requirement reflects that an actual interaction needs to happen. Later messages must differ in content or addressee if something in the earlier chain of messages changes. Exchange of periodic beacons broadcasted independent of the received inputs, e.g., about the sender state or perceived objects, are not complex interactions, since they do not depend on other actors' actions or messages.

[0104] The above definition of complex interactions includes different applications like maneuver cooperation or information sharing, and is mostly concerned about the underlying protocol. The thinking is that in a fully connected ecosystem, it may not be sensible to distinguish too many types of interactions, but rather generalize protocols towards applicability across a wide range of scenarios, as long as induced overhead allows. For example, a vehicle may need further information in order to start a cooperation proposal. It therefore may request information first (e.g., on objects perceived by the front vehicle), and then start a subsequent maneuver negotiation (e.g., about an overtake maneuver).

[0105] FIG. 1 shows an exemplary and schematic model for a functional split of interactions and the transition from co-existence to cooperation, regarding the inputs and outputs of an exemplary system. Solid/white elements depict entities that are present already in a so-called co-existence phase, dashed/light gray elements enable cooperative awareness, while dotted/dark gray ones are needed for a fully cooperative environment.

[0106] Especially the cooperation logic (“Cooperation Planning & Monitoring”) depicted schematically in FIG. 1 will generally be OEM-specific, meaning the host vehicle cannot rely on other vehicles taking decisions according to its own expectations. Here, explicitly sharing maneuver intentions and information needs makes it easier for other actors to process and decide on cooperation. This is another advantage of a protocol that allows for the host vehicle to send a cooperation proposal to one or more remote vehicles so as to enter in a maneuver negotiation.

[0107] In the context of an exemplary embodiment to be described in the following, which shall be referred to as Complex Vehicular Interactions Protocol (CVIP), Cooperative Awareness Message (CAM) or Basic Safety Message (BSM) beacons are considered as given. They are utilized to identify potential maneuver partners in an Awareness Phase, before the actual interaction involving a Negotiation and an Execution Phase starts. Additional information needed should be exchanged via dedicated messages. Here, only joint maneuvers performed by automated vehicles are considered. Automated vehicles are able to share information about intentions, unlike manually-driven vehicles that can only measure their current status without knowing the driver's next action.

[0108] Vehicles have to be able to estimate others' dynamics to make reasonable maneuver proposals. In case a proposed maneuver is not possible for another vehicle, it can respond accordingly. As it is undecidable on protocol layer whether the content of a received message, e.g., a maneuver proposal, is realistic and feasible, higher layers have to evaluate incoming proposals. This task can be performed by the “Cooperation Planning & Monitoring” unit in FIG. 1.

[0109] Regarding security, it is assumed for the present embodiment that messages are signed and interactions are thus secured. This will potentially increase message sizes compared to the ones analyzed in this specification (see further below). Security of the communication as well as of the interaction itself is important, but since ways like credentials exist that take care of preventing certain malicious actions [14], a more detailed security analysis is deferred to future work.

[0110] The guiding principles of the Complex Vehicular Interactions Protocol (CVIP) are as follows:

[0111] At first, a suitable amount of acknowledgements is considered necessary, since actors need to know whether others have heard, understood, and agreed to a proposed interaction. In the CVIP protocol, the execution status of a specific action can only be changed by the actor performing this action, in order to avoid inconsistencies.

[0112] Secondly, even if some entity needs to express the initial request for a maneuver, the decisions on participation can only come from the actors themselves in a distributed way. Actors have to be able to abort maneuvers at any given point in time, for example if own safety is at risk.

[0113] In preferred embodiments of CVIP, cascading of requests (cf. [8]) is not enabled, since this would considerably increase delays before a maneuver can be executed [11]. Cascading means that a request of vehicle A to vehicle B induces further requests from vehicle B to others in order to be able to accept vehicle A's request.

[0114] In accordance with the guiding principles outlined above, a preferred embodiment of a method of involves the following steps, which are schematically illustrated in FIG. 2: [0115] planning 21 a coordinated maneuver sequence that involves an initiating vehicle and a remote vehicle; [0116] transmitting 22 a request message (CQM) to the remote vehicle, the request message (CQM) including information specifying the coordinated maneuver sequence; [0117] receiving 23 the request message (CQM) at the remote vehicle; [0118] evaluating 24 the information included in the request message as to whether the coordinated maneuver sequence is acceptable; and [0119] transmitting 25 a response message (CRM) to the initiating vehicle, wherein the response message (CRM) indicates whether the coordinated maneuver sequence is acceptable for the remote vehicle.

[0120] In addition, the method may comprise, in response to the initiating vehicle receiving one or more affirmative response messages indicating that the coordinated maneuver sequence is acceptable for all involved remote vehicles: [0121] transmitting 26 a maneuver status message (MSM) to the involved remote vehicles, the maneuver status message indicating that the coordinated maneuver sequence is planned.

[0122] More generally, the method may comprise: [0123] transmitting 26 one or more status messages (MSM) between the vehicles involved in the coordinated maneuver sequence, each status message (MSM) indicating to the receiving end a respective status of the maneuvers of the coordinated maneuver sequence at the sending end.

[0124] The method may further comprise: [0125] transmitting 27 a feedback message (MFM) in response to receiving a status message (MSM).

[0126] Specifically, the CVIP protocol described herein as an exemplary embodiment is designed to involve the following four types of messages: Cooperative Request Message (CQM), Cooperative Response Message (CRM), Maneuver Status Message (MSM), and Maneuver Feedback Message (MFM), as depicted in FIG. 3.

[0127] It should be noted that the transmission of the CQM as illustrated in FIG. 3 corresponds to step 22 in FIG. 2. Likewise, the transmission of the CRM corresponds to step 25. The transmission of an MSM corresponds to step 26. The transmission of the MFM corresponds to step 27.

[0128] A dashed loop in FIG. 2 indicates that steps 26 and 27 may be performed repeatedly during the negotiation and execution of a coordinated maneuver.

[0129] Another dashed loop in FIG. 2 illustrates that in the case of a negative response message or a response message comprising a counter-proposal (step 25), the method may continue with another (re-)planning step 21.

[0130] Exemplary sizes for specific message elements as described in the following can be found in Table I.

TABLE-US-00001 TABLE I EXEMPLARY SIZE RANGES FOR THE PROTOCOL CONSTITUENTS MENTIONED IN THE TEXT. Element I.sup.Q I.sup.R M Sub-element G S i.sub.iqc i.sub.dest θ T.sup.Q V i.sub.mc i.sub.pkt t.sub.start τ T.sup.m S.sup.m P.sup.m Size [B] 16 46 4 4 4 4 1-100 4 4 4 4 4 4 1-500

[0131] Referring to FIG. 4, it is explained in the following how the CVIP may be applied to a sample scenario involving a complex interaction named Stationary Vehicle Decision Assist (SVDA).

[0132] The SVDA scenario works as follows, cf. FIG. 4: A stationary remote vehicle RV is located in front of a driving host vehicle HV. After becoming aware of the situation, in order to evaluate whether it is worth the risk of overtaking, the on-coming host vehicle HV inquires about the estimated duration of stay of the stationary vehicle (stage “1” in FIG. 4). If the duration is below a threshold or not known, the on-coming host vehicle HV proposes to overtake, while the stationary remote vehicle RV should stay stationary (stage “2” in FIG. 4). Both vehicles agree and the overtake is executed.

[0133] In the following, reference will be made to both FIG. 3 and FIG. 4 and, in particular with the initiating vehicle HV and the remote vehicles RV, RV1, RV2, RV3, RV4 referenced therein.

[0134] In general, after determining a need for information or joint maneuver, some vehicle issues a CQM to potential partners. Its content can be depicted as tuple

CQM(G,S,.sup.Q,).

[0135] G contains basic information: protocol version, message ID i.sub.msg, the initiating vehicle's station ID i.sub.s, generation time stamp t.sub.gen, and a sequence number n.sub.seq. S contains basic status information, mainly the ego GPS position for reference and an Instance ID. Those can be used for referencing in subsequent messages.

.sup.Q=(I.sub.1.sup.Q, . . . ,I.sub.k.sup.Q) and =(M.sub.1, . . . ,M.sub.l)

[0136] are containers for information requests and maneuvers, respectively, with k+l≥1.

[0137] Each I.sup.Q contains an Information Request Container ID i.sub.iqc=1, k for referencing, a destination station (vehicle) ID i.sub.dest that should provide the information, the type of requested information T.sup.Q as well as the update interval e in which the information is requested. In the SVDA scenario, this could be the estimated duration in the current mobility state (i.e., with velocity zero) with θ=−1 for one-time information.

[0138] The elements M are Maneuver Containers describing the foreseen joint actions, each containing a container ID i.sub.mc, a destination station ID i.sub.dest that should perform the maneuver, the maneuver type T.sup.m and related parameters P.sup.m. By setting i.sub.dest appropriately, even higher-authority parties like RSUs or emergency vehicles could propose maneuvers in which they themselves do not participate actively.

[0139] Via T.sup.m and P.sup.m, maneuvers could be described as standardized names, parametrized functions, or also via trajectories. Those proposed maneuvers directly reflect assumptions on the physical capabilities and vehicle dynamics of other actors. A start time t.sub.start—absolute or relative to another maneuver container—as well as the expected maneuver duration τ can also be included, if necessary.

[0140] In the SVDA scenario of FIG. 4, for example, one container M could be provided per vehicle, stating T.sup.m for the initiating vehicle as overtake, and for the stationary vehicle as remain in current mobility state, both with t.sub.start=0 and i equal to the expected duration of the maneuver.

[0141] In principle, also a more fine-grained statement of T.sup.m's may make sense, e.g., having three containers for the host vehicle HV—lane change, acceleration, lane change, along with relative start times to ensure a common understanding of the order of execution.

[0142] After reception of the CQM, other vehicles RV, RV1, RV2, RV3, RV4 evaluate the included information in their Cooperation Logic. They respond with a CRM defined as

CRM(G,S,.sup.R,).

[0143] While G and S contain the same types of sub-elements as in the CQM (i.e. updated t.sub.gen etc.),

.sup.R=(I.sub.1.sup.R, . . . ,I.sub.k.sup.R)

[0144] are now Information Response Containers containing a referenced i.sub.iqc, along with requested values V or an error. The vehicle can also state when a given T.sup.Q was not understood or is not available.

[0145] The maneuver containers M now include a packet ID i.sub.pkt, based on i.sub.s and n.sub.seq of the original CQM for stating references. Besides, a maneuver status S.sup.m set to Planned or a respective error status is contained. If needed, updated values for t.sub.start or τ can be given. The combination of request and received responses gives a clear picture to the initiator on the others' willingness to participate.

[0146] This iteration of CQM and CRM will be repeated until no changes are proposed and no errors are sent any more. This is the sign for convergence and every participating vehicle HV, RV, RV1, RV2 can be sure that all others also have agreed to a maneuver.

[0147] As depicted in FIG. 3, CAVs not implementing the protocol will not send a CRM (RV4). Vehicles that implement the protocol, but that either do not implement some of the requested T.sup.Q or T.sup.m, or that cannot fulfill requirements from the CQM, will send a response stating this (RV3). The initiating vehicle HV then updates the proposal according to the feedback and sends a new CQM involving only willing, capable, and necessary vehicles.

[0148] After convergence, the initiating vehicle HV will send an MSM

MSM(G,S,),

[0149] with the agreed maneuvers in M, together with a maneuver status S.sup.m as Planned for each container in M (stage “3” in FIG. 4). Other possible status values are InProgress, Finished, and Cancelled. Via those status, all vehicles will always know the execution status of each participating actor.

[0150] Upon reception of this first MSM, every vehicle has to store the current status of all l maneuvers internally in order to keep track of the other actors' execution and to know when to trigger own ones.

[0151] In order to inform the sender of the MSM that all participating vehicles have received the MSM and to make sure all participators' internal state directories are synchronized, an MFM is sent as acknowledgement, which can be described by

MFM(G,S,)

[0152] The MFM repeats the content of the MSM just received. While this may consume a considerable amount of the overall necessary bandwidth, it provides an efficient mechanism to prevent diverging internal execution states across actors, for example due to messages not received. For example, when diverging states for maneuver container M.sub.l′ are detected from the received MSMs and MFMs, the vehicle executing M.sub.l′ can send a clarifying MSM containing the currently correct execution state.

[0153] Whenever subsequently an actor changes its maneuver execution state—the sequence is known via a consistent use of the t.sub.start and τ—it will send an MSM with the updated status to let every other vehicle know that it entered a new state (e.g., stages “4”/“6” in FIG. 4 where Lane Change has switched to inProgress, or at stages “5”/“7” in FIG. 4 where it is Finished). Once all maneuvers' status has been set to Finished, the joint maneuver is completed.

[0154] As the reception of messages is essential for synchronized state transitions among the vehicles, a resend mechanism based on a timeout may optionally be implemented. Thus, for example, it may be provided that if a CQM is dropped and thus no CRMs are received, the initiator resends its CQM after t.sub.wait.sup.cqm up to c.sup.cqm times. If a CRM is dropped, then the vehicle has to be regarded uncooperative. In case an MSM is dropped, no MFMs are received at all and the message is thus resent after t.sub.wait.sup.msm, at most c.sup.msm times.

[0155] In case of missing MFMs, the respective MSM is also resent after a timeout of t.sub.wait.sup.msm, in order to ensure synchronized state updates. If MFMs are missing after c.sup.msm retries, the maneuver will be cancelled.

[0156] The timeouts and maximum resends may be adjusted for example based on different application scenarios, driving conditions, or traffic with surrounding vehicles potentially shadowing signals.

[0157] Since the requirements for different use cases may differ substantially, specific message contents (such as the number and type of containers, which information is transmitted, etc.) can be adjusted according to the respective needs. This gives CVIP the flexibility to support different scenarios without the need to define specialized messages. New scenarios are enabled easily by augmenting the set of defined values for T.sup.Q, T.sup.m, P.sup.m or adding new fields.

[0158] The information in Table I above together with the analysis of simulations presented in the following show that message sizes currently would not exceed a few hundred Bytes. This means that today's vehicular communication technologies like ITS-G5 or LTE-V2X can easily support this extensibility.

[0159] Next, an evaluation of numerical experiments is presented. In order to show the general applicability of CVIP, the evaluation setting has been abstracted from specific applications. Instead, the following questions shall be answered via a set of simulations of the protocol flow: [0160] Is the protocol scalable with respect to the number of nodes participating in a complex interaction? [0161] Is the protocol feasible, i.e. is the message size constrained within sensible limits, even for high k, l? [0162] Is the protocol robust, i.e. is it able to cope with lost packets?

[0163] To this end, a simple simulation scenario is considered: a set of N static vehicle nodes is placed on a straight lane in the simulation area. An initiating node sends the first CQM to all other nodes. As the details of the logic deciding on incoming cooperation requests are not at the center of the present investigation, all vehicles send a CRM with positive feedback. In reality, the higher-level cooperation logic would have to evaluate incoming CQMs' feasibility. From then, a simple maneuver is performed as described in Algorithm 1: one node after the other starts their maneuver of duration τ. With this setup, scalability regarding N and l, as well as the robustness can be evaluated by inserting packet losses with probability p.sub.drop.

TABLE-US-00002 Algorithm 1 Sample application on node j. Input: MSM from node j − 1 with S.sup.m = inProgress 1: Send MFM, then wait for t.sub.start 2: Send MSM, setting M.sub.j's S.sup.m to inProgress 3: Wait for τ 4: Send MSM, setting M.sub.j's S.sup.m to Finished

[0164] All simulations have been performed using the Intelligent Transport System (ITS) framework ezCar2X for connected applications [15] in combination with the simulators SUMO and ns-3. For significant results, 100 simulation runs were performed for each parameter set described later.

[0165] The number of messages exchanged in one interaction can be formalized depending on the number of nodes N, of negotiation rounds v, and of maneuver containers l as

n.sub.msgs.sup.cvip=v+v.Math.(N−1)+2.Math.l+2.Math.(N−1).Math.l.  (1)

[0166] The factor 2 is because an MSM with status inProgress and Finished will be sent for each of the l maneuver containers, respectively, and each of them will be confirmed via MFMs by the N−1 other actors. It can be easily seen that

n.sub.msgs.sup.cvip=(N.Math.(v+2l)).

[0167] In contrast, the number of messages transmitted with frequency f in beaconing-based approaches for intention sharing,

n.sub.msgs.sup.beac=f.Math.Θ.Math.N,  (2)

[0168] is dependent on the overall maneuver execution time Θ. For a reasonable set of values, e.g., N=10, v=1, 1=20, f=5 Hz, and Θ=10s, CVIP reduces the number of exchanged messages by almost 20%. This reduction is all the more significant as beacons are foreseen to be used even in times no maneuver is executed, as the whole concept of implicit maneuver negotiation is based on this periodic broadcast of intentions. With CVIP, messages are only exchanged if there is a need to. For a pure information exchange (i.e., l=0, k>0, v≥1), only very few messages will be sent, exactly satisfying information needs of the requesting vehicle. The size of the involved messages increases only linearly with the numbers k and l of included containers and, as Table I shows, the size of each I.sup.Q, I.sup.R, and M is relatively small. Via serialization techniques the overall sent message size can be further reduced. For example, for MFMs with l=7, the sent message size was on average 137 Byte, while the message size within the source code was 203 Bytes.

[0169] In a simulation, even for l=7, the overall message size did never exceed 225 Byte, transmitting all essential elements of a maneuver container. Even for today's technologies like ITSG5 or LTE-V2X, this makes our protocol feasible. For future use cases, there is still space to include additional fields, e.g., in P.sup.m, without message sizes becoming infeasible. This also paves the way for more complex maneuver descriptions.

[0170] By introducing packet losses with probability p.sub.drop, it was investigated how robust the protocol is towards transmission outages, even with the basic resend mechanism. For evaluation, maneuvers are counted as successfully completed if the last MSM containing all maneuver status set to Finished was sent and received. The ratio of successful maneuvers to all maneuvers is called success rate. If a single CRM is dropped, the maneuver will not be successful, since the initiating node cannot find out that one CRM is missing. Depending on the application, the initiating vehicle may thus choose to send several CQMs in order to minimize the probability that CRMs get lost. As FIG. 5 shows, this significantly improves the success rate, reaching 0.8 even for p.sub.drop=0.2 for c.sup.cqm=2.

[0171] FIG. 6 shows for scenarios with N=3 and one maneuver per vehicle, that the number of messages that need to be exchanged increases with p.sub.drop, the base line case being p.sub.drop=0. But even for p.sub.drop=0.2, not even twice as many messages will be sent. In general, CQMs are sent relatively more often than CRMs, since a vehicle has to resend them for a lost CQM as well as for a lost CRM. The same holds for comparing MSMs and MFMs.

[0172] The analysis presented in the above shows that CVIP is feasible for complex interactions. In particular, the simulation shows that current technologies are sufficient to enable complex interactions. New communication technologies like 5G-V2X may support further use cases, e.g., by enabling unicast or bigger message sizes in order to include very data-intensive information V or maneuver parameters P.sup.m.

[0173] With the above range of variations and applications in mind, it should be understood that the present invention is not limited by the foregoing description, nor is it limited by the accompanying drawings. Instead, the present invention is limited only by the appended claims and their legal equivalents.

REFERENCES

[0174] [1] K. Sjoberg, 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. [0175] [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. [0176] [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. [0177] [4] Intelligent Transport Systems (ITS); Vehicular Communication; Informative Report for the Maneuver Coordination Service, ETSI TR 103 578 V0.0.4 (2019-11), (Draft). [0178] [5] Application Protocol and Requirements for Maneuver Sharing and Coordinating Service, SAE J3186 (Draft). [0179] [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. [0180] [7] C. Burger, P. F. Orzechowski, 0. S. Tas, and C. Stiller, “Rating Cooperative Driving: A Scheme for Behavior Assessment,” in IEEE International Conference on Intelligent Transportation Systems (ITSC), 2018, pp. 1-6. [0181] [8] B. Lehmann, H. J. Gunther, 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. [0182] [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. [0183] [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. [0184] [11] D. Heil, R. Lattarulo, J. Perez, T. Hesse, and F. Köster, “Negotiation of Cooperative Maneuvers for Automated Vehicles: Experimental Results,” in IEEE International Conference on Intelligent Transportation Systems (ITSC), 2019, pp. 1545-1551. [0185] [12] K. Franke, M. During, 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. [0186] [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. [0187] [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. [0188] [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.