Patent Description:
Autonomous driving (sometimes referred to as automatic driving, automated driving or piloted driving) is the movement of vehicles, mobile robots and driverless transport systems which are largely autonomous. There are different degrees of autonomous driving. In this case, autonomous driving is also spoken at certain levels even if a driver is still present in the vehicle, who possibly only takes over the monitoring of the automatic driving operation. In Europe, the various transport ministries (in Germany, the Federal Institute for Road Systems (Bundesanstalt für Straßenwesen) was involved) worked together and defined the following autonomous stages. A slightly different categorization is available from the society of automotive engineers.

Future cooperative driving applications are envisioned to significantly improve efficiency and comfort of automated driving. Increase in cooperation between vehicles pose specific requirements on communication systems and the way messages are exchanged among cooperating vehicles. The field of use, where the invention is concerned with, is from Level <NUM> onwards and concerns the important aspect of cooperative driving maneuvers. Such applications more in particular the cooperative collision avoidance pose very strict requirements on the overall time to build a cooperative decision and require simple, reliable and efficient solution.

The automated vehicles broadcast their future paths as trajectories. A path is an ordered set of spatial points. A trajectory is a path with a time plan, generally for a fixed time period, e.g. <NUM>. As a result, the distance covered by the planned trajectory will depend on the speed, which is determined by the time plan. The coordination of the manoeuvres among a group of vehicles is operated through negotiations. These negotiations are supported by the exchange of maneuver coordination messages (MCM). The MCM will consist of a planned trajectory and a desired trajectory. The idea behind the desired trajectory is that other vehicles may accept the desired trajectory from one partner and adapt their planned trajectory. Depending on the number of communication partners and their trajectories, the complexity for the negotiation phase varies. The higher the number of communication partners the longer the negotiation may need.

In these systems, an exact position determination of the vehicle from stage to stage is important as well as a precise observation of the surroundings of the vehicle. In particular, position determination techniques are known which take into account absolute position data and odometry position data in determining the estimated position of the motor vehicle.

In this case, the absolute position data indicate the measured position of the motor vehicle at a certain time in absolute values, for example in a UTM or WGS84 reference coordinate system. Optionally, the absolute position data may also be provided with an orientation, e.g. a current direction of movement of the motor vehicle. A combination of position and orientation is often referred to as a pose. The position is usually expressed two-dimensionally in a Cartesian coordinate system.

For the cooperative or autonomous driving, the exchange of certain messages of the vehicles among each other is very important. Such information included in messages may be position information, surroundings information, trajectory information, warning information, control information and more.

<CIT> relates to the field of network communications technologies, and in particular, to IEEE <NUM>. 11p protocol-based vehicle-to-roadside and vehicle-to-vehicle communication test methods oriented to the Internet of Vehicles. The proposal relates to sending, by the host vehicular communication unit, a throughput test request data packet to the target vehicular communication unit, and starting a timer with it as a period after receiving the throughput test request data packet.

From KR <NUM> A1 a vehicle-to-vehicle tester for use in a transmission and reception testing system including a testing method is known.

An overview of the different phases of maneuver coordination for automated vehicles is found in the article "<NPL>.

The inventors identified different problems with these approaches described above. The main challenge with the approach described in the article "A reference architecture for CISS/CDAS within the field of cooperative driving" is that it requires extensive message exchange among partners within a very short time over an error prone communication network.

<NPL> a communication protocol based on which a cooperative driving maneuver is acknowledged between vehicles and their respective trajectories during a negotiation phase. Details of this communication protocol have been described already above. The described consensus mechanism prevents a collision between requesting and accepting vehicles. The coordination protocol is mentioned as time-safer in relation to situations without any coordination.

<NPL> a fault-tolerant negotiation-based intersection Crossing protocol. Rigorous analytic proofs are used for demonstrating the correctness and faulttolerance properties. Experimental results validate the correctness proof via detailed Computer simulations and provide a preliminary evaluation of the System performances.

<NPL>, vehicle-to-vehicle (V2V) communication technology to implement computationally efficient decentralized algorithms for two-vehicle cooperative collision avoidance at intersections.

XUE YANG ET AL describe in "A vehicle-to-vehicle communication protocol for cooperative collision warning", MOBILE AND UBIQUITOUS SYSTEMS: NETWORKING AND SERVICES, <NUM>. MOBIQUIT OUS <NUM>. THE FIRST ANNUAL INTERNATIONAL.

<NPL> a vehicle-to-vehicle communication protocol for cooperative collision warning. Emerging wireless technologies for vehicle-to-vehicle (V2V) and vehicle-to-roadside (V2R) Communications such as DSRC are promising to dramatically reduce the number of fatal road-way accidents by providing early warnings. One major technical challenge addressed in this paper is to achieve low-latency in delivering emergency warming in various road situations.

Cooperation messages are usually meant to negotiate a cooperation in a certain time gap; hence this process is constrained in time. This time is not constant and depends on several parameters such as the relative speed between vehicles and the validity time of the desired maneuver. It does not make sense to send a request message for a cooperative maneuver if the negotiation time is greater than the validity time of the desired maneuver. In other words, it is not efficient if the vehicle requests a cooperative maneuver although it knows in advance that the remaining time for negotiation is not sufficient. On the other hand, vehicles which receive that request message should not agree on the negotiation if there is not enough time to perform the negotiation with regard to the validity time of the desired trajectory.

The problem with such cooperative maneuvers therefore is that the negotiation phase may expire during negotiation and this could lead to an inefficient and longer lasting maneuver. A further problem is related with the increase of the amount of V2V-communications for the planning of cooperative maneuvers.

There is therefore a need for an improved approach for the negotiation phase of cooperative driving maneuvers which avoids the above mentioned disadvantages. This corresponds to the problem of the invention.

This object is achieved by a method for planning a cooperative driving maneuver according to claim <NUM>, a computing unit according to claim <NUM>, a vehicle according to claim <NUM> and a computer program according to claim <NUM>. The dependent claims include advantageous further developments and improvements of the invention as described below.

The solution according to the invention comprises a method for planning a cooperative driving maneuver, according to appended claim <NUM>.

This solution has the advantage that inefficient cooperative driving maneuvers are avoided. This could happen if the negotiation phase for the cooperative driving maneuver is started but needs to be stopped before the negotiation phase is finished. A reason for this might be that the requesting vehicle has missed the entry point into the desired trajectory before the negotiation phase has come to an end. Therefore, in an enhanced embodiment it is advantageous if the method further comprises a step of determining a branch point corresponding to a point lying commonly on both the planned trajectory and the desired trajectory. This branch point is further characterized that from this point on the planned and the desired trajectory separate even though it is allowed that they merge again later on. The method then further comprises a step of checking if the vehicle will reach the branch point before the negotiation phase is over according to the determined timeout value and if yes, it follows a step of terminating the planning of the cooperative driving maneuver and not sending out said cooperative driving maneuver request message.

For the determination of the timeout value it is advantageous that the method comprises a step of determining the number of vehicles involved in the cooperative driving maneuver. Then it is advantageous to add the typical time for deciding on the acceptance or rejection of the cooperative driving maneuver to the typical one-way trip time required for sending a message from one vehicle to another multiplied by the number of vehicles involved in the cooperative driving maneuver to calculate the negotiation time for the cooperative driving maneuver. The number of vehicles involved corresponds to the number of vehicles from which a response to the cooperative driving maneuver request message is due. It is noted, that not the time for deciding on the acceptance or rejection of the cooperative driving maneuver is multiplied with the number of involved vehicles, since the deciding process will be performed in parallel in the involved vehicles.

In addition, it is advantageous that the typical round trip time for the internal network transfer in the vehicle having sent out the cooperative driving maneuver request message is added to the negotiation time. This solution has the advantage that the negotiation time needed under the perspective of the vehicle having sent out the cooperative driving maneuver request message is relatively accurately determined.

The accuracy of the negotiation time can be further increased if in the vehicle having sent out the cooperative driving maneuver request message the typical one-way trip time required for sending a message from one vehicle to another is adapted to the current estimation of the quality of service of the V2V radio communication.

The determined negotiation time can be advantageously used in the vehicle having sent out the cooperative driving maneuver request message in the following way: First, the timeout value is set to the overall negotiation time when it is found that the requesting vehicle will reach the branch point before the overall negotiation time is over. This timeout value is entered into the payload field of the cooperative driving maneuver request message. With the timeout value entered in the cooperative driving maneuver request message the involved vehicles are informed about the timeout value for the negotiation phase of the cooperative driving maneuver.

It is also advantageous that in the payload field of the cooperative driving maneuver request message also the planned trajectory and the desired trajectory is entered to inform the involved vehicles about the planned cooperative driving maneuver.

Likewise, it is advantageous that an involved vehicle performs a step of checking the timeout value in the received cooperative driving maneuver request message. When it finds that the typical time for deciding on the acceptance or rejection of the cooperative driving maneuver is longer than the reported timeout value, it will stop negotiating about the cooperative driving maneuver. To inform the requesting vehicle, the involved vehicle will transmit back to the requesting vehicle a message in which the cooperative driving maneuver is rejected.

Another embodiment of the invention concerns a control unit, which is adapted to perform the steps of the method according to the invention.

Likewise, a vehicle, which is equipped with such a control unit corresponds to a further embodiment of the invention.

Moreover, a computer program having program steps which, when the program is processed by a computing unit, cause it to carry out the method according to the invention is another embodiment according to the invention.

An exemplary embodiment of the invention is illustrated in the drawings and is explained in more detail below with reference to the figures.

Thus, for example, it will be appreciated by those skilled in the art that the diagrams presented herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure.

The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, read only memory (ROM) for storing software, random access memory (RAM), and nonvolatile storage.

In the claims hereof, any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements that performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The disclosure as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. It is thus regarded that any means that can provide those functionalities are equivalent to those shown herein.

<FIG> shows the principle of vehicle communication using mobile radio. The vehicles are labeled with reference number <NUM>. The term vehicle is to be understood as a collective term for motor vehicles with an internal combustion engine or an electric motor, whether for bicycles with or without an electric motor or other vehicles powered by muscle, or for vehicles with one, two, four or more wheels. Whether for motorcycles, passenger cars, trucks, buses, agricultural vehicles or construction machines. The list is not exhaustive and includes other vehicle categories.

Since automated driving is on the rise, a lot more data needs to be exchanged among the road participants and also between the road participants and the network. The communication systems for V2V and V2X communication need to be adapted correspondingly. The 3GPP standard setting organisation has been and is releasing features for the new generation of the <NUM> cellular mobile communication system, including vehicle-to-everything (V2X) features. A large panel of vehicular use cases have been designed, ranging from infotainment to cooperative driving. When it comes to safety-related time-critical applications such as cooperative driving these requirements are the exchange of information with low latency, high data rate and high reliability. In LTE, according to Long Term Evolution, the V2X communication is called LTE-V, in the case of the <NUM> initiative this variant is called PC5. Another approach for implementing V2X-communication is based on the WLAN-standard IEEE <NUM>.

In <FIG>, the vehicles are each equipped with a communication module <NUM>, which serves as a transmitting and receiving unit for communication in a mobile radio network. The vehicle <NUM> here corresponds to a mobile radio network subscriber station because of the integrated communication module <NUM>. All messages from the vehicles (uplink) and to the vehicles (downlink) are routed either via a base station <NUM> which serves a mobile radio cell or, in the case of direct vehicle communication (sidelink), directly between the vehicles <NUM>. If the vehicles <NUM> are within this mobile radio cell, they are registered or logged in at the base station <NUM>. If they leave the mobile cell, they are handed over to the neighboring cell (handover) and accordingly logged out or logged off at the base station <NUM>. The base station <NUM> also provides access to the Internet so that the vehicles <NUM> or all other mobile radio subscribers are supplied with the Internet data in the mobile radio cell. For this purpose, the base station <NUM> is connected to the EPC <NUM> (Evolved Packet Core) via the so-called S1 interface. A backend server <NUM> is also accessible via the Internet <NUM> or another wide area network WAN. This may be located in a traffic control center to which e.g. some of the position data or trajectory information of the individual vehicles <NUM> may be reported.

Finally, an infrastructure network component is also shown. This may be exemplified by a road-side unit RSU <NUM>. For the ease of implementation, it is considered that all components have assigned an Internet address, typically in the form of an IPv6 address, such that the packets transporting messages between the components can be routed correspondingly. When the V2X-communication is implemented based on WLAN p, the vehicles may also exchange information with the road side units <NUM>.

<FIG> shows an example of a cooperative driving scenario. <FIG> shows five vehicles. The vehicle 10A is driving on the left lane of the road having two lanes in each direction. In front of vehicle 10A there is located vehicle 10D which has breakdown. Vehicle 10A therefore needs to change to the second lane in order to pass vehicle 10D having a breakdown. Vehicle 10C is driving slightly behind vehicle 10A on the second lane and vehicle 10B is driving in front of vehicle 10C on the second lane. Vehicle 10A seeks for a cooperative driving maneuver with vehicle 10C and sends out a cooperation request message to the surrounding vehicles. This message is called a maneuver coordination message MCM. Such MCM messages are broadcast via a broadcast channel of the mobile radio system. Other vehicles are taking into account the timeout of this cooperation request. The timeout value in the MCM message is the time until when the requesting vehicle 10A needs to receive an answer.

<FIG> shows a vehicle 10A and illustrates how its own possible movement in the future could be described. The predicted self-movement is described by a desired vehicle trajectory DT within the next few seconds. A typical time period of a trajectory is <NUM>. <FIG> shows a cooperative driving maneuver where the requesting vehicle 10A has a planned trajectory available which is labelled PT. The planned trajectory PT describes the planned movement from the <NUM>st driving lane to the <NUM>nd driving lane of the road. Of course, since vehicle 10A has recognized that vehicle 10D is blocking the way on the <NUM>st lane, vehicle 10A determines another trajectory, which allows vehicle 10A to avoid the blocking situation. This alternative trajectory is named desired trajectory and is labelled with reference sign DT. <FIG> illustrates the trajectory DT consists in a number of successive locations up to the point (xe, ye) provided in a two-dimensional Cartesian coordinate system. The desired trajectory DT describes a path on which vehicle 10A could change to the <NUM>nd lane on which vehicles 10B and 10C are already driving, see <FIG>. Since vehicle 10C is very close to vehicle 10A, an immediate change to the <NUM>nd lane is not possible and therefore, vehicle 10A needs to request a cooperative driving maneuver. For this vehicle 10A broadcasts its desired trajectory DT to the surrounding vehicles in the MCM message.

<FIG> shows schematically a block diagram of the vehicle's 10A board electronics system. Also the vehicles 10B to 10D may be equipped with the same kind of board electronics system. It is considered that the vehicle 10A is equipped with autonomous driving capability. Also the vehicles 10B to 10D may be equipped with autonomous driving capability. Part of the board electronics system is an infotainment system which comprises: a head-up display <NUM>, the touch-sensitive display unit <NUM>, a computing device <NUM>, an input unit <NUM>, and a memory <NUM>. The display unit <NUM> includes both a display area for displaying variable graphical information and an operator interface (touch-sensitive layer) arranged above the display area) for inputting commands by a user. The memory device <NUM> is connected to the computing device <NUM> via a further data line <NUM>. In the memory <NUM>, a pictogram directory and / or symbol directory is deposited with the pictograms and / or symbols for possible overlays of additional information.

The other parts of the infotainment system such as camera <NUM>, radio <NUM>, navigation device <NUM>, telephone <NUM> and instrument cluster <NUM> are connected via the data bus <NUM> with the computing device <NUM>. However, the modern vehicle <NUM> can also have further components such as further surroundings scanning sensors like a LIDAR (Light Detection and Ranging) sensor <NUM> or RADAR (Radio Detection and Ranging) sensor <NUM> and more video cameras <NUM>, e.g. as a front camera, rear camera or side camera. Such sensors are used more and more in vehicles for surroundings observation. The RADAR and LIDAR sensors <NUM>, <NUM> could be used for scanning a range up to <NUM> or <NUM> and the cameras <NUM>, <NUM> cover a range from <NUM> to <NUM>. Moreover, also an inertial measurement unit <NUM> is connected with the communication bus <NUM>. It may be used as part of the odometry of the vehicle in order to improve the accuracy of the positioning system of the vehicle.

As data bus <NUM> the high-speed variant of the CAN bus according to ISO standard <NUM>-<NUM> may be taken into consideration. Alternatively, for example, the use of an Ethernet-based bus system such as IEEE <NUM>. 03cg is another example. Bus systems in which the data transmission via optical fibers happens are also usable. Examples are the MOST Bus (Media Oriented System Transport) or the D2B Bus (Domestic Digital Bus). For inbound and outbound wireless communication, the vehicles 10A - 10D are equipped with a communication module <NUM>. It can be used for mobile communication, e.g. mobile communication according to the <NUM> standard and/or communication based on the WLAN p communication system.

Reference numeral <NUM> denotes an engine control unit. The reference numeral <NUM> corresponds to an ESC control unit corresponding to electronic stability control and the reference numeral <NUM> denotes a transmission control unit. The networking of such control units, all of which are allocated to the category of the drive train, typically occurs with the CAN bus system (controller area network) <NUM>. Since various sensors are installed in the motor vehicle and these are no longer only connected to individual control units, such sensor data are also distributed via the bus system <NUM> to the individual control devices.

Further control devices, such as an automatic driving control unit ADC <NUM>, etc. may be provided in the vehicles 10A to 10D. The Ethernet-Bus may be a choice for this communication bus <NUM> due to its higher bandwidth for data transport. One Ethernet-Bus adapted to the special needs of car communication is standardized in the IEEE <NUM>. 1Q specification. Moreover, a lot of information for surroundings observation may be received via V2V communication from other road participants. Particularly for those road participants not being in line of sight LOS to the observing vehicle it is very advantageous to receive the information about their position and motion via V2V communication.

Reference number <NUM> denotes an on-board diagnosis interface.

For the purpose of transmitting the vehicle-relevant sensor data desired trajectories etc. via the communication interface <NUM> to another vehicle <NUM> or to the backend server <NUM>, a gateway <NUM> is provided. This is connected to the different bus systems <NUM>, <NUM>, <NUM> and <NUM>. The gateway <NUM> is adapted to convert the data it receives via the one bus into the transmission format of the other bus so that it can be distributed in the packets specified there. For the forwarding of this data to the outside, i.e. to another vehicle <NUM> or to control central computer <NUM>, the on-board unit <NUM> is equipped with the communication interface to receive these data packets and, in turn, to convert them into the transmission format of the correspondingly used mobile radio standard. The gateway <NUM> takes all the necessary format conversions if data are to be exchanged between the different bus systems if required.

When vehicle 10A is planning the cooperative maneuver the ADC unit <NUM> calculates the desired trajectory DT. It also transfers the desired trajectory DT to the communication module <NUM> via gateway <NUM> and requests the transmission of an MCM message with the desired trajectory DT. The format of the MCM message is depicted in <FIG>.

In the header field M1 of the MCM message it is contained the PDU Header for the MCM message with entries for the protocol version, the message identifier and the station identifier sending out the MCM message. In the first payload field M2 the starting point SP is included with the position information e.g. in WGS84 coordinate system, the lane position and the time information when the message has been formed. In the second payload field M3 the planned trajectory PT is entered. The third payload field M4 contains the desired trajectory DT. As mentioned above the planned and desired trajectories may span a time period of future vehicle movement of <NUM> to <NUM>. Optionally, after the payload fields there might be used a further field with an error code for protecting the message against errors (not shown).

The MCM message will be broadcast to the surrounding vehicles. In the WLAN p communication system a broadcast channel may be used for that purpose. The surrounding vehicles 10B - 10D when receiving the MCM message from vehicle 10A need to check if the desired trajectory DT from vehicle 10A is acceptable for them. Thereafter, they will inform vehicle 10A whether they will accept the desired trajectory DT or whether they will refuse the desired trajectory DT. Therefore, with the sending of the MCM message with the request for a cooperative driving maneuver from vehicle 10A a negotiation phase is started which ends with the acceptance of the desired trajectory DT or the refusal of the desired trajectory DT.

According to an embodiment of the invention there is a process of estimating a timeout value for the negotiation phase of the cooperative maneuver, which limits the negotiation phase to a certain amount. The estimation of the timeout value is preferably performed in the ADC unit <NUM> of vehicle 10A. How the timeout estimation will be performed is illustrated in the flow chart of <FIG>. The process starts in step NTE1. In step NTE2 the algorithm determines the amount of vehicles involved in the requested cooperative driving maneuver. This can be performed by checking the positions of the surrounding vehicles and their corresponding velocities. It is noted that the positions, velocities and the planned trajectories are exchanged between the neighboring vehicles in common awareness messages CAM. By checking the positions and speeds of the surrounding vehicles it will be found that vehicle 10B and 10C are involved in the cooperative driving maneuver which is illustrated in <FIG>. In step NTE3 vehicle 10A determines the branch point BP between the planned trajectory PT and the desired trajectory DT. The branch point is the location on the two trajectories where the desired trajectory DT starts to deviate from the planned trajectory. When this branch point BP is determined, the point in time when the vehicle 10A reaches the branch point BP is also determined in step NTE3.

In the next step NTE4 the time needed for the negotiation of the cooperative driving maneuver is also estimated. In one embodiment the negotiation time can be estimated in the following manner: First, the typical internal processing time used for deciding on acceptance or rejection of the desired trajectory DT is taken out of the memory in step NTE2. Since the vehicles 10B and 10C receive the MCM message in broadcast form almost at the same time, they perform the checking of acceptance or rejection of the desired trajectory in parallel such that the time will not be doubled if two vehicles are involved. However, what is also to be considered is that each involved vehicle needs to transmit back its answer to the requesting MCM message. Since different resource blocks are assigned to the different vehicles this can be done in parallel and therefore the known one-way trip time for sending the answer needs not to be multiplied with the number of involved vehicles in this embodiment. The latency of the network is however dependent on the current transfer conditions at the location of the respective vehicles. To take this into consideration the vehicle 10A estimates the latency of the network based on the current quality of service the network can provide.

A typical example for the time for deciding about acceptance or rejection of the desired trajectory is <NUM>. It is noted that since the two involved vehicles 10B and 10C receive the MCM message at the same time, they will start deciding about acceptance or rejection of the desired trajectory in parallel. A typical example for the one-way trip time on the WLAN p link is about <NUM>. In addition the vehicle intern network processing latency is to be considered for vehicle 10A. Since the internal message transfer in vehicle 10A takes longer because of the reformatting need in gateway <NUM>, this latency should not be neglected. A typical value for the two-way transfer of internal messages is about <NUM>. In total the negotiation time NT will be calculated by summing-up these values.

In the following step NTE5 it will be checked if the estimated negotiation time NT is shorter than the branch point time determined in step NTE4. If yes, vehicle 10A transmits the MCM message. If not, it means that there is not enough negotiation time NT available to decide about the cooperative driving maneuver and vehicle 10A does not send out the requesting MCM message. At the driving situation illustrated in <FIG> it means vehicle 10A starts braking and waits behind vehicle 10B until the traffic situation allows changing to the <NUM>nd lane. If yes, in step NTE6 the timeout value TO is set to be equal to the calculated negotiation time NT. Then in step NTE7 the MCM message with the set timeout value TO is sent out.

Once the MCM message has been sent out, the two vehicles 10B and 10C need to decide about acceptance or rejection of the cooperative driving maneuver. Thereby, they will take into account the timeout value TO in the field M5 of this maneuver coordination message MCM. The timeout value has the meaning of the time until when the requesting vehicle 10A needs to receive an answer. Also vehicle 10B and 10C perform a step of checking if they can deliver the answer to the MCM message within the set time limit defined by the timeout value. What they know is that they need <NUM> for deciding about the request. They also know about the one-way trip time of <NUM> and the internal message distribution time of <NUM> in vehicle 10A. This way they will find that in total a time of <NUM> + <NUM> + <NUM> is needed and compare the resulting value of <NUM> with the announced timeout value. If they find that there is sufficient time to answer the request they will transmit the acceptance message back to the requesting vehicle 10A. If they find that there is insufficient time to answer the request they will transmit the rejection message back to the requesting vehicle 10A. This way superfluous V2V communication can be avoided.

<FIG> shows on the left side the different message exchanges for a cooperative driving maneuver. In phase <NUM> the vehicles 10A, 10B, 10C exchange common awareness messages CAM. This also includes the exchange of their currently planned trajectories PT. In phase <NUM> vehicle 10A finds that there is a need for a cooperative driving maneuver and sends the MCM message in broadcast form to vehicles 10B and 10C. In phase <NUM> the vehicles 10B and 10C send their response message to the MCM message back to vehicle 10A. In phase <NUM> when the two vehicles 10B and 10C have accepted the cooperative driving maneuver, the cooperative driving maneuver is started by means of a broadcast message from vehicle 10A.

On the right side of <FIG> different time lines for the cooperative driving maneuver are illustrated. The duration of the desired and planned trajectories is <NUM>. The negotiation time has been calculated to be equal to <NUM>. The branch point time is calculated to be equal to <NUM>. Finally, the timeout value TO has been set to be equal to <NUM>.

It is to be understood that the proposed method and apparatus may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Special purpose processors may include application specific integrated circuits (ASICs), reduced instruction set computers (RISCs) and/or field programmable gate arrays (FPGAs). Preferably, the proposed method and apparatus is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

It should be understood that the elements shown in the figures may be implemented in various forms of hardware, software or combinations thereof. Preferably, these elements are implemented in a combination of hardware and software on one or more appropriately programmed general-purpose devices, which may include a processor, memory and input/output interfaces. Herein, the phrase "coupled" is defined to mean directly connected to or indirectly connected with through one or more intermediate components. Such intermediate components may include both hardware and software based components.

Claim 1:
A computer-implemented method
for planning a cooperative driving maneuver, comprising the steps of observing the surroundings of a vehicle (10A), determining a planned trajectory (PT) the vehicle (10A) drives on for a certain amount of time,
determining a desired trajectory (DT) different from the planned trajectory (PT) requiring a cooperative driving maneuver with at least one of the surrounding vehicles (10B, 10C),
starting a negotiation phase with said vehicles (10B, 10C) involved in the cooperative driving maneuver by sending a maneuver coordination message (MCM),
waiting for the response messages from said involved vehicles (10B, 10C),
determining a timeout value (TO) which limits the negotiation phase of said cooperative driving maneuver, and
changing to the desired trajectory (DT) if said involved vehicles (10B, 10C) have accepted the desired trajectory (DT) before the negotiation phase has expired according to said timeout value (TO),
wherein said timeout value (TO) is entered into a payload field of the maneuver coordination message (MCM) to inform said involved vehicles (10B, 10C) about a timeout value for the negotiation phase of the cooperative driving maneuver.