CN113264058A

CN113264058A - 用于计划协作式驾驶操纵的方法、对应的控制单元和配备有控制单元的车辆以及计算机程序

Info

Publication number: CN113264058A
Application number: CN202110123473.0A
Authority: CN
Inventors: A·普法德勒; B·莱曼; G·约尔诺德
Original assignee: Volkswagen Automotive Co ltd
Current assignee: Volkswagen Automotive Co ltd
Priority date: 2020-01-30
Filing date: 2021-01-29
Publication date: 2021-08-17
Also published as: EP3859709A1

Abstract

本提议涉及一种用于计划协作式驾驶操纵的方法，所述方法可以用于协作式驾驶或自主驾驶的场景中。所述方法包括以下步骤：观察车辆（10A）的周围环境；确定车辆（10A）在某个时间量内在其上驾驶的计划轨迹（PT）；确定不同于计划轨迹（PT）的期望轨迹（DT），期望轨迹（DT）需要与周围车辆（10B、10C）中的至少一个进行协作式驾驶操纵。根据本发明的解决方案包括以下步骤：确定协作式驾驶操纵的超时值；通过发送协作式驾驶操纵请求消息（MCM）来开始与协作式驾驶操纵中涉及的车辆（10B、10C）的协商阶段；等待来自所涉及的车辆（10B、10C）的响应消息；以及如果所涉及的车辆（10B、10C）在协商阶段根据所述超时值已经到期之前已经接受了期望轨迹（DT），则改变到期望轨迹（DT）。

Description

用于计划协作式驾驶操纵的方法、对应的控制单元和配备有控制单元的车辆以及计算机程序

技术领域

本公开涉及借助于车辆到车辆通信支持的协作式驾驶操纵（cooperativedriving maneuver）的领域。本公开进一步涉及对应的控制单元和配备有这种控制单元的车辆、以及对应的计算机程序。

背景技术

自主驾驶（有时被称为自动驾驶，自动化驾驶或自动驾驶辅助系统（piloteddriving））是很大程度上具有自主性的车辆、移动机器人和无人驾驶运输系统的移动。存在不同程度的自主驾驶。在这种情况下，即使驾驶员仍存在于车辆中，在某些级别下也可说是自主驾驶，该驾驶员可能仅仅接管对自动驾驶操作的监视。在欧洲，各种运输部（在德国，涉及联邦道路系统研究所（Bundesanstalt für Straßenwesen））一起工作并且定义了以下自主阶段。略微不同的分类可从汽车工程师协会获得。

· 级别0：“仅驾驶员”，驾驶员自己驾驶、操控、给气（give gas）、制动等。

· 级别1：某些辅助系统帮助车辆操作（包括巡航控制系统——自动巡航控制ACC）。

· 级别2：部分自动化。其中，自动停车、跟踪功能、一般纵向引导、加速、减速等由辅助系统来接管（包括碰撞避免）。

· 级别3：高度自动化。驾驶员不必连续地监视该系统。车辆独立地执行功能，诸如转向信号的触发、车道改变和跟踪。驾驶员可以转到其他事物，但是如果要求的话，则该系统被要求在预警期内接管领导权。在高速公路上，这种自主形式在技术上是可行的。立法者正在努力允许级别3的车辆。已经创建了法律框架。

· 级别4：完全自动化。该系统永久地采取对车辆的引导。如果该系统不再能够处置任务，则可以要求驾驶员取得领导权。

· 级别5：不需要驾驶员。除了设置目标以及启动该系统之外，不需要人类干预。

设想到未来的协作式驾驶应用将显著改进自动化驾驶的效率和舒适性。车辆之间的协作方面的增加对通信系统、以及在协作的车辆当中交换消息的方式提出了具体要求。本发明所涉及的使用领域是从级别2开始的，并且涉及协作式驾驶操纵的重要方面。这种应用（更特别地是协作式碰撞避免）对用以构建协作式决策的总体时间提出了非常严格的要求，并且需要简单、可靠且有效的解决方案。

自动化车辆将它们未来的路径作为轨迹进行广播。路径是空间点的有序集合。轨迹是具有通常针对固定时间段（例如10秒）的时间计划的路径。作为结果，由计划轨迹所覆盖的距离将取决于速度，速度由时间计划来确定。在一组车辆当中的操纵的协调是通过协商来进行的。这些协商通过操纵协调信息（MCM）的交换来支持。MCM将由计划轨迹和期望轨迹组成。期望轨迹背后的想法是：其他车辆可以从一个伙伴接受期望轨迹，并且适配其计划轨迹。取决于通信伙伴的数量及其轨迹，协商阶段的复杂性会变化。通信伙伴的数量越高，协商可能需要越长时间。

在这些系统中，对车辆从阶段到阶段的精确位置确定、以及对车辆周围环境的精确观察是重要的。特别地，位置确定技术是已知的，该技术在确定机动车辆的估计位置时考虑了绝对位置数据和里程计（odometry）位置数据。

在这种情况下，绝对位置数据用绝对值、例如在UTM或WGS84参考坐标系中来指示机动车辆在某个时间处的测量位置。可选地，绝对位置数据也可以被提供有取向，例如机动车辆的当前移动方向。位置和取向的组合通常被称为姿态（pose）。位置通常在笛卡尔坐标系中以二维方式来表述。

对于协作式驾驶或自主驾驶来说，车辆在彼此当中的某些信息的交换是非常重要的。被包括在消息中的这种信息可以是位置信息、周围环境信息、轨迹信息、警告信息、控制信息等等。

美国2019/0207800 A1涉及网络通信技术领域，并且特别地涉及面向车辆互联网的基于IEEE 802.11p协议的车辆到道路侧和车辆到车辆通信测试方法。该提议涉及：由主机车辆通信单元向目标车辆通信单元发送吞吐量测试请求数据分组；以及在接收到吞吐量测试请求数据分组之后利用其作为周期来启动定时器。

根据KR 2017120420 A1，已知一种用于包括测试方法的传输和接收测试系统的车辆到车辆测试器。

用于自动化车辆的操纵协调的不同阶段的概述在Bernd Lehmann、Hendrik-JörnGünther和Lars Wolf的文章“A generic approach towards maneuver coordination forautomated vehicles”（2018 21st International Conference on IntelligentTransportation Systems（ITSC）.IEEE，2018年）中被找到。

发明人标识了上面描述的这些方法的不同问题。文章“A referencearchitecture for CISS/CDAS within the field of cooperative driving”中描述的方法面临的主要挑战是：它需要在非常短的时间内通过容易出错的通信网络在伙伴当中进行广泛的消息交换。

XU WENBO等人在“Autonomous Maneuver Coordination Via VehicularCommunication”（2019 49TH ANNUAL IEEE/IFIP INTERNATIONAL CONFERENCE ONDEPENDABLE SYSTEMS AND NETWORKS WORKSHOPS（DSN-W），IEEE，2019年6月24日（2019-06-24），第70-77页，XP033602308，DOI：10.1109/DSN-w.2019.00022）中描述了一种通信协议，基于该通信协议，在协商阶段、在车辆与它们的相应轨迹之间确认协作式驾驶操纵。上面已经描述了该通信协议的细节。所描述的一致机制防止了作出请求的车辆和作出接受的车辆之间的碰撞。与没有任何协调的情形相比，该协调协议被认为是更加时间安全的。

协作消息通常意味着在某个时间间隙内对协作进行协商；因此，该过程在时间上是受约束的。该时间不是恒定的，并且取决于若干个参数，诸如车辆之间的相对速度和期望操纵的有效时间。如果协商时间大于期望操纵的有效时间，则发送针对协作式操纵的请求消息是没有意义的。换句话说，如果车辆请求协作式操纵，这是无效的，尽管它事先知道用于协商的剩余时间不足亦如此。在另一方面，如果关于期望轨迹的有效时间，没有足够的时间来执行该协商，则接收到该请求消息的车辆不应当同意该协商。

因此，这种协作式操纵的问题是：协商阶段可能在协商期间到期，并且这可能导致低效和持续时间更长的操纵。另外的问题与用于协作式操纵计划的V2V通信量的增加有关。

因此，需要一种用于协作式驾驶操纵的协商阶段的改进方法从而避免上述缺点。这对应于本发明的问题。

该目的通过根据权利要求1的用于计划协作式驾驶操纵的方法、根据权利要求10的计算单元、根据权利要求11的车辆、以及根据权利要求12的计算机程序来实现。从属权利要求包括如下所描述的本发明的有利的进一步开发和改进。

发明内容

根据本发明的解决方案包括一种用于计划协作式驾驶操纵的方法，包括以下步骤：观察车辆的周围环境；确定车辆在某个时间量内在其上驾驶的计划轨迹；以及确定不同于计划轨迹的期望轨迹，期望轨迹需要与周围车辆中的至少一个进行协作式驾驶操纵。该解决方案进一步包括以下步骤：确定协作式驾驶操纵的超时值（timeout value）；通过发送协作式驾驶操纵请求消息来开始与协作式驾驶操纵中涉及的车辆的协商阶段；等待来自所涉及的车辆的响应消息；以及如果所涉及的车辆在协商阶段根据超时值已经到期之前已经接受了期望轨迹，则改变到期望轨迹。该解决方案具有的优点是避免了低效的协作式驾驶操纵。如果协作式驾驶操纵的协商阶段已开始但是需要在协商阶段完成之前停止，则可能会发生这种情况。对于这一点的原因可能是作出请求的车辆在协商阶段结束之后已经错过了去往期望轨迹中的进入点。

因此，在增强的实施例中，如果该方法进一步包括确定与共同位于计划轨迹和期望轨迹上的点相对应的分支点的步骤，则这是有利的。该分支点的进一步特征在于：从该点开始，计划轨迹和期望轨迹分离，即使允许它们稍后再次合并。然后，该方法进一步包括检查车辆是否将在协商阶段根据所确定的超时值结束之前到达分支点的步骤，并且如果是，则其遵循以下步骤：终止协作式驾驶操纵的计划并且不发出所述协作式驾驶操纵请求消息。

为了确定超时值，有利的是，该方法包括确定协作式驾驶操纵中涉及的车辆数量的步骤。那么有利的是：将用于决定接受或拒绝协作式驾驶操纵的典型时间与从一个车辆向另一个车辆发送消息所需的典型单向行程时间乘以协作式驾驶操纵中涉及的车辆数量的乘积相加，从而计算协作式驾驶操纵的协商时间。所涉及的车辆的数量对应于来自其的对协作式驾驶操纵请求消息的响应应到达（due）的车辆的数量。要注意的是，用于决定接受或拒绝协作式驾驶操纵的时间不与所涉及的车辆的数量相乘，这是由于该决定过程将在所涉及的车辆中并行地执行。

此外，有利的是，将已经发出了协作式驾驶操纵请求消息的车辆中的内部网络传送的典型往返行程时间与协商时间相加。该解决方案具有的优点在于：在已经发出了协作式驾驶操纵请求消息的车辆的视角下所需要的协商时间被相对准确地确定。

如果在已经发出了协作式驾驶操纵请求消息的车辆中，使从一个车辆向另一个车辆发送消息所需的典型单向行程时间适配于V2V无线电通信的服务质量的当前估计，则可以进一步增加协商时间的准确性。

有利地，可以用以下方式将所确定的协商时间用于已经发出了协作式驾驶操纵请求消息的车辆中：首先，当发现作出请求的车辆将在总协商时间结束之前到达分支点时，将超时值设置成总协商时间。将该超时值输入到协作式驾驶操纵请求消息的有效负载字段中。利用在协作式驾驶操纵请求消息中输入的超时值，所涉及的车辆被通知关于协作式驾驶操纵的协商阶段的超时值。

还有利的是，在协作式驾驶操纵请求消息的有效负载字段中，还输入计划轨迹和期望轨迹以便向所涉及的车辆通知关于所计划的协作式驾驶操纵。

同样地，有利的是，所涉及的车辆执行检查接收到的协作式驾驶操纵请求消息中的超时值的步骤。当它发现用于决定接受或拒绝协作式驾驶操纵的典型时间比所报告的超时值更长时，它将停止关于协作式驾驶操纵的协商。为了通知作出请求的车辆，所涉及的车辆将把其中协作式驾驶操纵被拒绝的消息传输回到作出请求的车辆。

本发明的另一个实施例涉及一种控制单元，该控制单元被适配成执行根据本发明的方法的步骤。

同样地，配备有这种控制单元的车辆对应于本发明的进一步实施例。

此外，一种具有程序步骤的计算机程序是根据本发明的另一个实施例，该程序步骤在计算单元处理该程序时使其执行根据本发明的方法。

附图说明

本发明的示例性实施例在附图中被图示，并且在下面参考附图被更详细地解释。

在附图中：

图1 经由移动无线电的车辆通信的原理；

图2 协作式驾驶场景的示例，其中一个车辆通过以协作式驾驶操纵请求消息将其计划轨迹和期望轨迹发送到周围车辆来请求协作式驾驶操纵；

图3 移动车辆前方的期望轨迹的表示；

图4 示出了具有各种车辆电子组件的车辆板电子网络的框图；

图5 操纵协调请求消息的格式；

图6 用于估计在所涉及的车辆当中协商协作式驾驶操纵所需要的协商时间的计算机程序的流程图；以及

图7 根据协作协议（左）和针对执行的时间线（右）的协作式驾驶操纵的所涉及车辆之间的消息交换的示例。

具体实施方式

本描述图示了本公开的原理。因此将领会到的是，本领域技术人员将能够设想到尽管没有在本文中明确地描述或示出但是体现了本公开原理的各种布置。

本文中记载的所有示例和条件式语言意图用于教育目的以帮助读者理解本公开的原理和发明人所贡献以便促进本领域的概念，并且被解释为不限于这种具体记载的示例和条件。

此外，记载了本公开的原理、方面和实施例及其具体示例的本文中的所有陈述意图涵盖其结构和功能等同物两者。附加地，所意图的是，这种等同物包括当前已知的等同物以及未来开发的等同物两者，即执行相同功能的所开发的任何元件，而与结构无关。

因此，例如，本领域技术人员应当领会的是，本文中呈现的图表示体现本公开原理的说明性电路的概念视图。

可以通过使用专用硬件、以及能够与适当的软件相关联地执行软件的硬件来提供图中所示的各种元件的功能。当由处理器提供时，这些功能可以由单个专用处理器、由单个共享处理器、或由多个单独的处理器（它们中的一些可以是共享的）提供。此外，术语“处理器”或“控制器”的明确使用不应当被解释为排他地指代能够执行软件的硬件，而是可以隐含地包括但不限于：数字信号处理器（DSP）硬件、用于存储软件的只读存储器（ROM）、随机存取存储器（RAM）和非易失性存储装置。

还可以包括常规和/或定制的其他硬件。类似地，图中所示的任何开关仅仅是概念上的。它们的功能可以通过程序逻辑的操作、通过专用逻辑、通过程序控制和专用逻辑的交互、或甚至手动地来执行，特定技术可由实现者来选择，如根据上下文更具体地理解的那样。

在本文的权利要求中，被表述为用于执行指定功能的部件的任何元件意图涵盖执行该功能的任何方式，包括例如：a）执行该功能的电路元件的组合；或b）以任何形式的软件，因此包括固件、微代码等，该软件与用于执行该软件的适当电路相组合以执行该功能。如这种权利要求所定义的公开内容在于以下事实：由各种所记载的部件提供的功能以权利要求所主张的方式被组合并且带到一起。因此认为可以提供那些功能的任何部件都等同于本文中所示的那些。

图1示出了使用移动无线电的车辆通信的原理。车辆用参考数字10来标记。术语“车辆”应理解为具有内燃机或电动机的机动车辆的集合术语，无论是针对具有或不具有电动机的自行车或者由肌肉提供动力的其他车辆，还是针对具有一个、两个、四个或更多个车轮的车辆。无论是针对摩托车、乘用车、卡车、公共汽车、农用车辆还是工程机械。该列表并非穷尽的，并且包括其他车辆类别。

由于自动化驾驶正在兴起，因此在道路参与者当中以及还有在道路参与者与网络之间需要交换许多更多的数据。用于V2V和V2X通信的通信系统需要被相应地适配。3GPP标准设置组织已经并且正在发布新一代5G蜂窝移动通信系统的功能，包括车辆到任何事物（V2X）功能。已经设计了大范围的车辆用例，其范围从信息娱乐到协作式驾驶。当其涉及到与安全性相关的时间要求严格的应用（诸如，协作式驾驶）时，这些要求是在低等待时间、高数据速率和高可靠性下的信息交换。在LTE中，根据长期演进，V2X通信被称为LTE-V，在5G倡议的情况下，该变体被称为PC5。用于实现V2X通信的另一种方法是基于WLAN标准IEEE802.11p。

在图1中，车辆均被配备有通信模块160，通信模块160用作传输和接收单元以用于移动无线电网络中的通信。由于集成的通信模块160，因此车辆10在这里对应于移动无线电网络订户站。来自车辆（上行链路）和去往车辆（下行链路）的所有消息要么经由服务于移动无线电小区的基站210被路由，要么在直接车辆通信（侧链路）的情况下在车辆10之间被直接地路由。如果车辆10在该移动无线电小区内，则它们在基站210处被注册或登录。如果它们离开移动小区，则它们被移交到相邻小区（移交），并且相应地在基站210处注销或登出。基站210还提供对互联网的访问，使得向车辆10或所有其他移动无线电订户提供移动无线电小区中的互联网数据。出于该目的，基站210经由所谓的S1接口而连接到EPC 200（演进分组核心）。后端服务器320也经由互联网300或另一个广域网WAN而可访问。其可以位于交通控制中心中，例如可以向该交通控制中心报告个体车辆10的位置数据或轨迹信息中的一些。

最后，还示出了基础设施网络组件。其可以由道路侧单元RSU 310来例示。为了便于实现，认为所有组件已经被指派有互联网地址（通常采用IPv6地址的形式），使得在组件之间传输消息的分组可以被相应地路由。当基于WLAN p来实现V2X通信时，车辆还可以与道路侧单元310交换信息。

图2示出了协作式驾驶场景的示例。图2示出了五个车辆。车辆10A在道路的左车道上驾驶，该道路在每个方向上具有两个车道。在车辆10A的前面，定位有发生故障的车辆10D。因此，车辆10A需要改变到第二车道，以便经过发生故障的车辆10D。车辆10C在第二车道上略微在车辆10A的后面驾驶，并且车辆10B在第二车道上在车辆10C的前面驾驶。车辆10A寻求与车辆10C进行协作式驾驶操纵，并且向周围车辆发出协作请求消息。该消息被称为操纵协调消息MCM。这种MCM消息是经由移动无线电系统的广播信道来广播的。其他车辆考虑该协作请求的超时。MCM消息中的超时值是直到作出请求的车辆10A需要接收到答复时的时间。

图3示出了车辆10A，并且图示了可以如何描述其自己在未来的可能移动。所预测的自我移动由接下来几秒内的期望车辆轨迹DT来描述。轨迹的典型时间段是10秒。图2示出了协作式驾驶操纵，其中作出请求的车辆10A具有被标记为PT的可用计划轨迹。计划轨迹PT描述了从道路的第一驾驶车道到第二驾驶车道的所计划的移动。当然，由于车辆10A已经识别出车辆10D正在阻挡第一车道上的道路，因此车辆10A确定了另一个轨迹，该另一个轨迹允许车辆10A避免该阻挡情形。该替代轨迹被命名为期望轨迹，并且用参考记号DT来标记。图3图示了轨迹DT，该轨迹DT由直到在二维笛卡尔坐标系中提供的点（x_e,y_e）的多个连续位置组成。期望轨迹DT描述了如下路径：在该路径上，车辆10A可以改变到车辆10B和10C已经在其上驾驶的第二车道，参见图2。由于车辆10C非常靠近车辆10A，所以不可能立即改变到第二车道，并且因此车辆10A需要请求协作式驾驶操纵。为此，车辆10A以MCM消息向周围车辆广播其期望轨迹DT。

图4示意性地示出了车辆10A板电子系统的框图。车辆10B至10D也可以配备有相同种类的板电子系统。所认为的是，车辆10A配备有自主驾驶能力。车辆10B至10D也可以配备有自主驾驶能力。板电子系统的一部分是信息娱乐系统，其包括：平视显示器20、触敏显示单元30、计算设备40、输入单元50和存储器60。显示单元30包括用于显示可变图形信息的显示区域和用于由用户输入命令的布置在显示区域上方的操作员界面（触敏层）两者。存储器设备60经由另外的数据线80连接到计算设备40。在存储器60中，象形图目录和/或符号目录与象形图和/或符号一起存放，以用于附加信息的可能覆盖。

信息娱乐系统的其他部分（诸如，相机150、无线电140、导航设备130、电话120和仪表集群110）经由数据总线100与计算设备40连接。然而，现代车辆10还可以具有另外的组件，诸如另外的周围环境扫描传感器，如激光雷达（光检测和测距）传感器152或雷达（无线电检测和测距）传感器154、以及更多视频相机150，例如作为前置相机、后置相机或侧面相机。这种传感器越来越多地针对周围环境观察而在车辆中使用。雷达和激光雷达传感器152、154可以用于扫描高达150米或250米的范围，并且相机150、151覆盖从30至120米的范围。此外，惯性测量单元170也与通信总线100连接。它可以用作车辆的里程计的一部分，以便改进车辆的定位系统的准确性。

作为数据总线100，可以考虑根据ISO标准11898-2的CAN总线的高速变体。替代地，例如，使用基于以太网的总线系统（诸如，IEEE 802.03cg）是另一个示例。其中经由光纤进行数据传输的总线系统也是可用的。示例是MOST总线（面向介质的系统传输）或D2B总线（家用数字总线）。对于入站和出站无线通信，车辆10A-10D配备有通信模块160。它可以用于移动通信，例如根据5G标准的移动通信和/或基于WLAN p通信系统的通信。

参考数字181表示引擎控制单元。参考数字182对应于与电子稳定性控制相对应的ESC控制单元，并且参考数字183表示传输控制单元。这种控制单元（其中的全部被分配到传动系统的类别）的联网典型地利用CAN总线系统（控制器区域网络）104而发生。由于各种传感器被安装在机动车辆中，并且这些传感器不再仅仅连接到个体控制单元，因此这种传感器数据还经由总线系统104被分发给个体控制设备。

可以在车辆10A至10D中提供另外的控制设备，诸如自动驾驶控制单元ADC 180等。以太网总线由于其较高的数据传输带宽而可以是针对该通信总线106的选择。在IEEE802.1Q规范中，适配于汽车通信的特殊需要的一种以太网总线被标准化。此外，可以经由V2V通信从其他道路参与者接收针对周围环境观察的许多信息。特别是针对不处于进行观察的车辆的视线LOS内的那些道路参与者，经由V2V通信来接收关于其位置和运动的信息是非常有利的。

参考数字190表示板载诊断接口。

出于经由通信接口160将期望轨迹等车辆相关的传感器数据传输到另一个车辆10或后端服务器320的目的，提供了网关142。其连接到不同的总线系统100、102、104和106。网关142被适配成将它经由一个总线接收到的数据转换成另一个总线的传输格式，使得可以将其分发在那里指定的分组中。为了将该数据转发到外部，即转发到另一个车辆10或控制中央计算机320，板载单元160被配备有通信接口以便接收这些数据分组，并且进而将它们转换成相应使用的移动无线电标准的传输格式。如果要在不同的总线系统之间交换数据，则网关142采取所有必要的格式转换，如果需要的话。

当车辆10A正在计划协作式操纵时，ADC 单元180计算期望轨迹DT。它还经由网关142将期望轨迹DT传送到通信模块160，并且请求传输具有期望轨迹DT的MCM消息。MCM消息的格式如图5中所描绘。

在MCM消息的报头字段M1中，包含MCM消息的PDU报头，该PDU报头具有针对发出MCM消息的协议版本、消息标识符和站标识符的条目。在第一有效负载字段M2中，包括起点SP，该起点SP具有在该消息已经形成时的例如在WGS84坐标系中的位置信息、车道位置和时间信息。在第二有效负载字段M3中，输入了计划轨迹PT。第三有效负载字段M4包含期望轨迹DT。如上所述，计划轨迹和期望轨迹可以跨越5至10秒的未来车辆移动的时间段。可选地，在有效负载字段之后，可能使用具有错误代码的另外的字段来保护消息免受错误（未示出）。

MCM消息将被广播给周围车辆。在WLAN p通信系统中，广播信道可以用于该目的。周围车辆10B-10D在接收到来自车辆10A的MCM消息时需要检查：对于它们而言，来自车辆10A的期望轨迹DT是否是可接受的。此后，它们将向车辆10A通知它们将接受期望轨迹DT还是它们将拒绝期望轨迹DT。因此，随着具有针对协作式驾驶操纵的请求的MCM消息从车辆10A的发送，协商阶段开始，该协商阶段以接受期望轨迹DT或拒绝期望轨迹DT而结束。

根据本发明的实施例，存在用于估计协作式操纵的协商阶段的超时值的过程，该超时值将协商阶段限制到某个量。对超时值的估计优选地在车辆10A的ADC单元180中执行。图6的流程图中图示了将如何执行超时估计。该过程在步骤NTE1中开始。在步骤NTE2中，该算法确定所请求的协作式驾驶操纵中涉及的车辆数量。这可以通过检查周围车辆的位置及其对应的速度来执行。要注意的是，以共同认知消息CAM在相邻车辆之间交换位置、速度和计划轨迹。通过检查周围车辆的位置和速度，将发现的是，图2中所图示的协作式驾驶操纵中涉及了车辆10B和10C。在步骤NTE3中，车辆10A确定计划轨迹PT与期望轨迹DT之间的分支点BP。分支点是两个轨迹上的位置，在该位置处，期望轨迹DT开始偏离于计划轨迹。当该分支点BP被确定时，车辆10A到达分支点BP时的时间点也在步骤NTE3中被确定。

在下一步骤NTE4中，还估计协作式驾驶操纵的协商所需要的时间。在一个实施例中，协商时间可以用以下方式来估计：首先，在步骤NTE2中，从存储器中取出用于决定接受或拒绝期望轨迹DT的典型内部处理时间。由于车辆10B和10C几乎同时以广播形式接收到MCM消息，因此它们并行地执行对接受或拒绝期望轨迹的检查，使得如果涉及了两个车辆，该时间不会加倍。然而，还要考虑的是，每个涉及的车辆需要将其对请求MCM消息的答复传输回去。由于不同的资源块被指派给不同的车辆，所以这可以并行地进行，并且因此在该实施例中，用于发送答复的已知单向行程时间不需要与所涉及的车辆的数量相乘。然而，网络的等待时间取决于相应车辆的位置处的当前传送条件。考虑到这一点，车辆10A基于网络能够提供的当前服务质量来估计网络的等待时间。

用于决定接受或拒绝期望轨迹的时间的典型示例是500毫秒。要注意的是，由于所涉及的两个车辆10B和10C同时接收到MCM消息，因此它们将开始并行地决定接受或拒绝期望轨迹。WLAN p链路上的单向行程时间的典型示例是大约100毫秒。附加地，针对车辆10A，要考虑车辆内部网络处理等待时间。由于车辆10A中的内部消息传送因为网关142中的重新格式化需要而花费更长的时间，因此该等待时间不应当被忽略。内部消息的双向传送的典型值是大约200毫秒。总计，协商时间NT将通过对这些值求和来计算。

NT = 500毫秒 + 2 * 100毫秒 + 200毫秒 = 900毫秒。

在以下步骤NTE5中，将检查所估计的协商时间NT是否短于在步骤NTE4中确定的分支点时间。如果是，则车辆10A传输MCM消息。如果不是，则这意味着没有足够的协商时间NT可用于关于协作式驾驶操纵作出决定，并且车辆10A不发出请求MCM消息。在图2中所图示的驾驶情形下，这意味着车辆10A开始制动，并且在车辆10B后面等待，直到交通情形允许改变到第二车道为止。如果是，则在步骤NTE6中，将超时值TO设置成等于所计算的协商时间NT。然后，在步骤NTE7中，发出具有所设置的超时值TO的MCM消息。

一旦MCM消息已经被发出，两个车辆10B和10C就需要决定接受或拒绝协作式驾驶操纵。因此，它们将考虑该操纵协调消息MCM的字段M5中的超时值TO。该超时值具有如下含义：即，直到作出请求的车辆10A需要接收到答复时的时间。车辆10B和10C还执行如下步骤：检查它们是否可以在由超时值所定义的设置时间限制内递送对MCM消息的答复。它们所知道的是，它们需要500毫秒以便关于该请求作出决定。它们还知道关于100毫秒的单向行程时间以及车辆10A中100毫秒的内部消息分发时间。这样，它们将发现：总计需要500毫秒+100毫秒+100毫秒的时间，并且将700毫秒的所得值与所宣布的超时值进行比较。如果它们发现有足够的时间来答复该请求，则它们将把接受消息传输回到作出请求的车辆10A。如果它们发现没有足够的时间来答复该请求，则它们将把拒绝消息传输回到作出请求的车辆10A。这样，可以避免多余的V2V通信。

图7在左侧示出了用于协作式驾驶操纵的不同消息交换。在阶段1中，车辆10A、10B和10C交换共同认知消息CAM。这还包括交换它们当前计划的轨迹PT。在阶段2中，车辆10A发现存在协作式驾驶操纵的需要，并且以广播形式向车辆10B和10C发送MCM消息。在阶段3中，车辆10B和10C将它们对MCM消息的响应消息发送回到车辆10A。在阶段4中，当两个车辆10B和10C已经接受了协作式驾驶操纵时，协作式驾驶操纵借助于来自车辆10A的广播消息而开始。

在图7的右侧，图示了协作式驾驶操纵的不同时间线。期望轨迹和计划轨迹的持续时间是10秒。协商时间已经被计算成等于900毫秒。分支点时间被计算成等于4秒。最后，超时值TO已经被设置成等于4秒。

要理解的是，所提出的方法和装置可以以各种形式的硬件、软件、固件、专用处理器或其组合来实现。专用处理器可以包括专用集成电路（ASIC）、精简指令集计算机（RISC）和/或现场可编程门阵列（FPGA）。优选地，所提出的方法和装置被实现为硬件和软件的组合。此外，该软件优选地被实现为有形地体现在程序存储设备上的应用程序。该应用程序可以被上传到包括任何合适架构的机器并由其执行。优选地，该机器在具有诸如一个或多个中央处理单元（CPU）、随机存取存储器（RAM）和（一个或多个）输入/输出（I/O）接口之类的硬件的计算机平台上实现。该计算机平台还包括操作系统和微指令代码。本文中描述的各种过程和功能可以是经由操作系统执行的微指令代码的一部分或应用程序的一部分（或其组合）。另外，各种其他外围设备可以连接到计算机平台，诸如附加的数据存储设备和打印设备。

应当理解的是，图中所示的元件可以以各种形式的硬件、软件或其组合来实现。优选地，这些元件在一个或多个经适当编程的通用设备上以硬件和软件的组合来实现，该通用设备可以包括处理器、存储器和输入/输出接口。在本文中，短语“耦合”被定义为意指通过一个或多个中间组件来直接连接或间接连接。这种中间组件可以包括基于硬件的组件和基于软件的组件两者。

要进一步理解的是，因为优选地以软件来实现附图中描绘的构成性系统组件和方法步骤中的一些，所以系统组件（或过程步骤）之间的实际连接可以取决于对所提出的方法和装置进行编程所采用的方式而不同。在给定本文中的教导的情况下，相关领域的普通技术人员将能够考虑所提出的方法和装置的这些和类似的实现方式或配置。

本公开不限于这里描述的示例性实施例。存在也被认为属于本公开的许多不同适配和开发的范围。

附图标记列表

10 车辆

10A 第一车辆

10B 第二车辆

10C 第三车辆

10D 第四车辆

20 平视显示器

30 显示单元

40 计算单元

50 操作面板

60 存储器

70 第一数据总线

80 第二数据总线

90 第三数据总线

100 高速CAN总线

102 通信总线

104 CAN总线

106 以太网总线

110 仪表集群

120 电话

130 导航系统

140 无线电

142 网关

150 相机

152 激光雷达传感器

154 雷达传感器

170 惯性测量单元

171 传感器1

172 传感器2

173 传感器3

171 驾驶员辅助控制单元

172 雷达设备

180 自动驾驶计算单元

181 引擎控制单元

182 ESC控制单元

183 传输控制单元

200 演进分组核心

210 基站

300 互联网

310 道路侧单元

320 后端服务器

M1 消息报头字段

M2 第一消息有效负载字段

M3 第二消息有效负载字段

M4 第三消息有效负载字段

M5 第四消息有效负载字段

TJ 轨迹

PT 计划轨迹

DT 期望轨迹

BP 分支点

NTE1–NTE8 计算机程序的不同步骤。

Claims

1.一种用于计划协作式驾驶操纵的方法，包括以下步骤：观察车辆（10A）的周围环境，确定车辆（10A）在某个时间量内在其上驾驶的计划轨迹（PT），确定不同于计划轨迹（PT）的期望轨迹（DT），期望轨迹（DT）需要与周围车辆（10B、10C）中的至少一个进行协作式驾驶操纵，通过发送操纵协调消息（MCM）来开始与协作式驾驶操纵中涉及的所述车辆（10B、10C）的协商阶段，等待来自所述涉及的车辆（10B、10C）的响应消息，其特征在于以下步骤：确定用于所述协作式驾驶操纵的计划的超时值（TO），以及如果所述涉及的车辆（10B、10C）在协商阶段根据所述超时值（TO）已经到期之前已经接受了期望轨迹（DT），则改变到期望轨迹（DT）。

2.根据权利要求1所述的方法，进一步包括以下步骤：确定与位于计划轨迹（PT）和期望轨迹（DT）上的点相对应的分支点（BP），在分支点（BP）处，计划轨迹（PT）和期望轨迹（DT）分离；以及检查车辆（10A）是否将在协商阶段根据所确定的超时值（TO）结束之前到达分支点（BP），并且如果是，则终止协作式驾驶操纵的计划并且不发出所述操纵协调消息（MCM）。

3.根据权利要求1或2所述的方法，其中，针对确定所述超时值（TO）的步骤，执行确定协作式驾驶操纵中涉及的车辆数量的步骤，并且其中将从一个车辆向另一个车辆发送消息所需的典型单向行程时间乘以协作式驾驶操纵中涉及的车辆数量的乘积与用于决定接受或拒绝协作式驾驶操纵的典型时间相加，从而计算协作式驾驶操纵的协商时间（NT）。

4.根据权利要求3所述的方法，其中将已经发出了所述操纵协调消息（MCM）的所述车辆（10A）中的内部网络传送的典型往返行程时间与协商时间（NT）相加，以便确定总协商时间。

5.根据权利要求3或4所述的方法，其中在已经发出了所述操纵协调消息（MCM）的所述车辆（10A）中，使从一个车辆向另一个车辆发送消息所需的典型单向行程时间适配于车辆到车辆无线电通信系统的服务质量的当前估计。

6.根据权利要求3至5中的一项所述的方法，其中在已经发出了协作式驾驶操纵请求消息的所述车辆（10A）中，当发现所述作出请求的车辆（10A）将在协商时间（NT）结束之前到达分支点（BP）时，将所述超时值（TO）设置成协商时间（NT）。

7.根据前述权利要求中的一项所述的方法，其中将所述超时值（TO）输入到操纵协调消息（MCM）的有效负载字段中，以通知所述涉及的车辆（10B、10C）关于协作式驾驶操纵的协商阶段的超时值。

8.根据前述权利要求中的一项所述的方法，其中将所述计划轨迹（PT）和所述期望轨迹（DT）输入到操纵协调消息（MCM）的有效负载字段中，以通知所述涉及的车辆（10B、10C）关于所计划的协作式驾驶操纵。

9.根据权利要求6至8中的一项所述的方法，其中所述涉及的车辆（10B、10C）之一执行以下步骤：检查接收到的操纵协调消息（MCM）中的所述超时值（TO），并且当它发现用于决定接受或拒绝协作式驾驶操纵的典型时间比所述报告的超时值（TO）更长时，所述涉及的车辆（10B、10C）将停止关于协作式驾驶操纵的协商，并且将其中协作式驾驶操纵被拒绝的消息传输回到所述作出请求的车辆（10A）。

10.一种计算单元（180），其特征在于，所述计算单元（180）被适配成执行前述权利要求1至9中的一项所述的步骤。

11.一种车辆（30），其特征在于，所述车辆（30）被配备有根据权利要求10所述的计算单元（180）。

12.一种计算机程序，其特征在于，所述计算机程序包括程序步骤，所述程序步骤在计算单元（180）处理所述程序时使其执行根据权利要求1至9中的一项所述的方法。