首页 > 专利技术

在车辆之间协调一个或更多个操纵的方法与流程

1.本说明书涉及在车辆之间协调一个或更多个操纵的方法以及被配置用于执行这种方法的计算设备。具体地，本说明书涉及用于互联与自动驾驶车辆(connected and automated vehicles，cav)之间的任意复杂交互的协议的方面，其示例性实施例在下文中也将被称为复杂车辆交互协议(complex vehicular interactions protocol，cvip)。

背景技术：

2.在自动驾驶领域，广泛接受的是：自动驾驶车辆将必须被互联以便创建相互意识和协调操纵。然而，如何详细地实现自动驾驶车辆之间的这种交互仍然是一个开放的问题。目前讨论了用于协作服务的若干新协议，例如在欧洲电信标准协会(european telecommunications standards institute，etsi)和美国汽车工程师学会(society of automotive engineers，sae)内的变道或超车。这些通信协议通常专用于单独的操纵或基于对其它车辆意图的隐含假设。
3.此外，除了用于信息娱乐使用情况的互联网联结之外，交通参与者之间的直接通信，车用无线通信技术(vehicle-to-everything，v2x)，已经非常接近成为现实。尽管这已经宣称了十年以上，但是最近情况发生了变化。关于基本安全性的标准可以被认为几乎是成熟的，第一原始设备制造商(original equipment manufacturer，oem)开始在一系列生产车辆中部署基本v2x服务，尽管还没有回答所有问题。
4.最近，注意力已经从基本警告服务转移到车辆通信如何能够支持协作和自动驾驶。那些所谓的第2天或第3天服务将改变城市道路和高速公路道路以及十字路口[2]、[3]上的车辆彼此交互的方式[1]。它们使用v2x来实现车辆之间的协商并利用分布式智能，进一步增加了安全性和便利性。已经在欧洲[4]和美国[5]开始了这种高级服务的第一次标准化工作。
[0005]
最近，许多研究人员开始研究复杂交互。例如，burger等人[7]定义了一种自愿和有意识地执行的协作动作，其目的是朝着共同目标(即联合最优)工作。它们根据交换的信息(基于信息)和用于联合动作的优化目标(基于操纵)来对协作进行分类。在最高级，通过共享状态信息、意图和个体效用来优化总效用。
[0006]
通常，协作行为协议可以被分成隐式协议和显式协议。
[0007]
利用隐式方法，车辆周期性地共享意图，并且必须根据从其他车辆接收的潜在改变的意图来推断它们的建议是否已经被接受[8]。例如，在imagine[9]中，每个车辆周期性地广播其规划轨迹作为信标。如果要发起轨迹更新，则另外发送期望的轨迹。其它车辆评估它们自己的规划轨迹的改变，以便使期望的轨迹成为可能。基于所接收的更新的规划，发起车辆可以判断它是否可以改变其规划轨迹。transaid[10]增加了由作为交通协调者的路侧单元(road side unit，rsu)进行轨迹建议的可能性。
[0008]
基于显式协调的方法在概念上是不同的。该思想是车辆的期望操纵必须明确地提交给相关行动者或从相关行动者确认以确保该建议已被接受。在[6]中，建议了车道改变协
议。广播车道改变请求，并经由单播车道改变响应来应答该车道改变请求。基于反馈，选择合适的对等车辆，该对等车辆将为发起者腾出空间，用车道改变准备消息来宣布已经完成这一点。现在，发起者改变车道而不进行进一步通信。
[0009]
显式协作的另一种方式是时空预留程序[11]：车辆发送对一些静止或移动车道级道路空间的请求。其它车辆将根据推断的成本对此进行评估，并且如果其他车辆接受则发送提交消息。不发送提交消息的车辆不愿意参与或不能够参与协商；必须基于不协作的移动模型来预测不发送提交消息的车辆的行为。考虑所有接收到的提交，发起车辆将确定进入预留道路空间是否安全，如果是，则进入预留道路空间，而不进行进一步通信。
[0010]
franke等人提出了一种协议，其中每辆车都宣布可能的操纵和相关联的成本，并选择操纵的最佳子集用于执行[12]。
[0011]
所提及的方法具有某些限制。具体地，大多数已知协议能够实现非常特定的操纵(例如，车道改变)，需要针对每个新的使用情况进行调整[6]。
[0012]
对于隐式方法，车辆必须猜测其它车辆是理解了自己的建议还是恰巧改变了它们的轨迹。这可以产生非常保守的cav。此外，周期性地广播轨迹导致了大量的带宽使用，如果不执行操纵则是不必要的。应该如何将这种周期信标的生成规则看似是另一个未解决的问题[10]。
[0013]
当前的显式方法是非常应用特定的，或者是基于道路几何形状的。前者是次优的，因为每个新的操纵将需要新的消息集。后者更一般，仅能够考虑用于发起车辆的道路空间的相当简单的预留。
[0014]
所有当前显式操纵协调方法的共同缺点是它们仅支持单个发起者和来自其他发起者的反馈。不支持两个或更多个参与者共同协商并执行某些动作的操纵。
[0015]
为了解决这个问题，correa等人[10]提出使用基础设施。他们建议操纵协调消息，rsu可以经由该操纵协调消息建议车辆遵循某些轨迹。然而，因为它们建立在意图信标上，所以不可能在若干车辆之间执行真正的联合操纵，因为没有机制确保所寻址的车辆中的全部或没有一个所寻址的车辆采取由基础设施建议的动作。

技术实现要素：

[0016]
本发明的目的是克服或减轻本领域已知解决方案的至少一些上述缺点。例如，期望提供一种能够以灵活、高效和稳健的方式在车辆之间进行操纵协调的方法。
[0017]
该目的通过根据独立权利要求的方法和计算设备来解决。优选实施例是从属权利要求的主题。
[0018]
应当注意，从属于独立权利要求的权利要求的附加特征可以在没有独立权利要求的特征的情况下或者与独立权利要求的特征的子集组合的情况下构成独立于独立权利要求的所有特征的组合的单独发明，该单独发明可以是独立权利要求、分案申请或者后来的申请的主题。这同样适用于说明书中描述的技术教导，其可以构成独立于独立权利要求的特征的发明。
[0019]
如本说明书中所使用的，术语“车辆”应当被广义地理解。例如，术语“车辆”包括客车、公共汽车、商用车辆、运输车辆、无人机、机器人、摩托艇、船舶、农用车辆、铁路车辆等。
[0020]
此外，术语“车辆”可以指自动驾驶或非自动驾驶车辆。
[0021]
另外，应当注意，根据一些实施例，以下描述的某些方法步骤(例如，关于协调操纵序列的规划和/或评估的步骤)可以由互联的基础设施中的元件(例如，路侧单元、边缘计算设备、后端服务器、制造厂中的准静止元件或其他)执行。因此，执行这些步骤的元件不必布置在车辆中。例如，所提出的方法可以涉及基础设施部件之间的一个或更多个交互和/或基础设施部件与一辆或更多辆车辆之间的交互。
[0022]
根据本发明的第一方面，提出了一种在车辆(特别是cav)之间协调一个或更多个操纵的方法。该方法包括：规划涉及发起车辆(在下文中有时也称为“主车辆”)和远程车辆的协调操纵序列；以及向远程车辆传送请求消息，该请求消息包括指定协调操纵序列的信息。
[0023]
也就是说，请求消息包括用于远程车辆执行指定的协调操纵序列内的一个或更多个动作(例如，子操纵)的特定建议。另外，请求消息可包括主车辆规划在指定的协调操纵序列内执行的一个或更多个动作。
[0024]
这些单独的动作可以在时间上彼此独立。或者，这些单独的动作之间的时间关系(例如，关于各自的开始时间或结束时间)可以在该建议中表达。
[0025]
所提出的方法允许显式联合操纵协商，同时仍然保持普遍适用性。换句话说，该方法不是使用情况特定的，但是允许重复使用，以及支持对未来操纵的可扩展性。例如，通过在请求消息中包括新字段(以及可能也在后续消息中包括新字段，如下面结合一些实施例所描述的)，也可以容易地实现未来的使用情况。
[0026]
该方法还可用于协调多个操纵。
[0027]
每个操纵可以包括若干动作，例如子操纵。
[0028]
协调操纵序列可以包括多个单独的动作、子操纵和/或操纵。
[0029]
在本上下文中，协调可以指协调操纵序列的规划的协调，可选地还指协调操纵序列的执行的协调。
[0030]
应当理解，根据一些实施例，该方法可以涉及多个远程车辆，例如至少两个远程车辆。因此，原则上，该方法允许协调任意许多参与者的复杂操纵。
[0031]
例如，可以将单独的请求消息发送到每个远程车辆，其中每个远程车辆可以借助于相应的id(诸如所谓的站id)来寻址。
[0032]
例如，发起车辆可以在确定需要对作为潜在伙伴的一辆或若干辆远程车辆进行联合操纵之后发出这样的请求消息。
[0033]
根据一些实施例，请求消息可以从发起车辆直接或间接地被传送到远程车辆。
[0034]
例如，用于请求消息的无线传输路径可以在发起车辆的发送器和远程车辆的接收器之间(具体地，从发起车辆的发送器到远程车辆的接收器)延伸，其中，可选地，可以另外涉及一个或更多个中间站，诸如等。
[0035]
在一个实施例中，协调操纵序列的规划由发起车辆的计算设备触发或执行。例如，规划中涉及的至少一些数据处理可以由这样的计算设备执行，该计算设备可以布置在发起车辆中。例如，这样的计算设备可以实现下面将进一步被称为“协作逻辑”的事物(的至少一部分)。
[0036]
例如，通过互联的基础设施的一个或更多个元件(例如路侧单元、边缘计算设备、后端服务器等)可以完成规划，这也在本发明的范围内。
[0037]
例如，在实施例中，在规划中涉及的一些数据处理可以至少部分地在外部计算设备上(诸如借助于边缘或云服务和/或远程服务器)执行。例如，除了道路之外的边缘计算平台可以提出操纵。在这种情况下，可以设置：协调操纵序列的规划至少由发起车辆的计算设备触发(即发起)。
[0038]
优选地，协调操纵序列的规划考虑关于远程车辆的操纵能力的假设(或知识)，例如关于远程车辆的物理能力和车辆动态。换句话说，所提出的操纵可直接反映关于其他行动者的物理能力和车辆动态的发起车辆的假设(或知识)。例如，这也可以指远程车辆的某些限制。发起车辆的这种假设或知识可以例如基于对值或状态信息的基于协议的查询，这可以产生(不)充足容量的指示等。例如，可以通过下面解释的响应方案来传达这样的信息。
[0039]
此外，根据一些实施例，协调操纵序列的规划可以考虑通信的当前和/或未来(预测)服务质量参数(例如，关于延迟、抖动、数据速率、信道负载、分组调度等)。
[0040]
例如，上述假设或知识可以基于环境模型和/或基于可用于发起车辆的预测模型。发起车辆可用的后端信息也可以用作这种假设或知识的基础。
[0041]
关于请求消息的内容，在实施例中，请求消息可以进一步表示发起车辆请求由远程车辆满足的一个或若干个信息需求。换句话说，在提出协调操纵序列的请求消息中，信息需求可以另外表示发起车辆希望由一辆或若干辆远程车辆满足。因此，该方法还可以基于与用于操纵协调的消息集相同的消息集来实现基于需求的信息交换。因此，所提出的协议可以组合协作感知和协作操纵。
[0042]
在实施例中，该方法还包括以下步骤：在远程车辆处接收请求消息；以及评估包括在请求消息中的关于协调操纵序列是否可接受的信息。
[0043]
例如，所提出的协调操纵序列的可接受性可以取决于根据远程车辆自身的环境模型或预测模型的可行性和/或取决于例如基于远程车辆自身的路径规划和/或驾驶策略所评估的远程车辆的意愿。具体地，所述评估可以涉及评估反映若干轨迹规划和/或操纵规划标准的成本函数。
[0044]
在实施例中，对包括在请求消息中的信息的评估由发起车辆的计算设备触发或执行。例如，在评估中涉及的至少一些数据处理可以由这样的计算设备执行，该计算设备可以被布置在远程车辆中。例如，这样的计算设备可以实现下面将进一步被称为“协作逻辑”的事物(的至少一部分)。
[0045]
在评估中涉及的一些数据处理可以至少部分地在外部计算设备上(诸如借助于云服务和/或远程服务器)执行，这也在本发明的范围内。在这种情况下，可以设置：至少由远程车辆的计算设备触发(即发起)对请求消息中所包括的信息的评估。
[0046]
作为进一步的步骤，该方法可以包括向发起车辆传送响应消息。
[0047]
根据一些实施例，响应消息可以直接或间接地从远程车辆被传送到发起车辆。
[0048]
例如，用于响应消息的无线传输路径因此可以在远程车辆的发送器和发起车辆的接收器之间(具体地，从远程车辆的发送器到发起车辆的接收器)延伸，其中可选地，可以另外涉及一个或更多个中间站，诸如等。
[0049]
响应消息(明显地或隐含地)指示协调操纵序列对于远程车辆是否是可接受的。因此，响应消息可以传达对所提出的协调操纵序列的确认或拒绝，后者可能与相反建议相结合，如以下所描述的。
[0050]
在一个实施例中，响应消息包括远程车辆可接受的协调操纵序列的相反建议。
[0051]
例如，在这种情况下，该方法还可以包括规划远程车辆可接受的调整的协调操纵序列的步骤，其中所述规划可以由远程车辆(诸如借助于远程车辆的(可以例如实现所谓的协作逻辑的)计算设备)执行或触发。
[0052]
所传送的请求和所接收的响应的组合可以向发起车辆提供关于远程车辆参与意愿的清晰图片。
[0053]
特别地，通过提供响应消息作为协调操纵的协议的一部分，可以经由从远程车辆接收的响应来确定协调操纵的愿意参与者。因此，例如，可以避免与涉及复杂操纵的组形成[13]的概念相关的一些已知缺点[8]。
[0054]
在实施例中，该方法还包括响应于发起车辆接收到指示协调操纵序列对于远程车辆是不可接受的响应消息：规划涉及发起车辆和所述远程车辆和/或一辆或若干辆其他远程车辆的调整的协调操纵序列；以及向在调整的协调操纵序列中涉及的远程车辆传送(例如，来自发起车辆的)更新的请求消息，其中更新的请求消息包括：指定调整的协调操纵序列的信息。
[0055]
替代地或附加地，该方法可以包括响应于发起车辆接收到指示(可能已经调整的)协调操纵序列对于所有涉及的远程车辆都是可接受的一个或更多个肯定响应消息：向所涉及的远程车辆传送操纵状态消息，该操纵状态消息指示协调操纵序列被规划。
[0056]
例如，根据一些实施例，可以设置的是：重复(可能更新的)请求消息和响应消息的迭代，直到没有提出改变并且不再发送错误。这可以被认为是操纵协调的“收敛”的标志。
[0057]
当达到收敛时，发起车辆可以发送状态消息，连同同意的操纵，连同对于每个操纵“规划”的操纵状态。这样，每个参与车辆均可以确保所有其他涉及的车辆也已经同意操纵。
[0058]
更一般地，根据一些实施例，该方法可包括在(可能已经调整的)协调操纵序列中涉及的车辆之间传送一个或更多个状态消息，其中每个状态消息向接收端指示在发送端处的协调操纵序列的操纵的相应状态。
[0059]
因此，所提出的方法支持在所涉及的车辆之间明确地协商操纵，同时允许经由状态更新来监测操纵进展。
[0060]
例如，除了如上所述的状态“规划”之外，可以与状态消息一起传达的可能的其它状态值是“inprogress(进行中)”、“finished(完成)”和“cancelled(取消)”。
[0061]
例如，经由这样的状态消息，所有涉及的车辆可以总是知道每个参与的行动者的当前执行状态。
[0062]
在实施例中，设置：特定动作的执行状态仅可由执行该动作的行动者改变。这可以有助于避免不一致性。
[0063]
例如，一旦协调操纵序列的所有操纵的相应状态已经被设置为finished，则可以认为联合操纵完成。
[0064]
此外，可以设置：每个参与车辆(即，发起车辆和远程车辆)可以通过状态消息来取消协调操纵序列。然后交互协议可以负责协调操纵序列的有序且一致的取消。
[0065]
可选地，可以为状态消息实现适当的重新发送方案，以便确保每个状态消息到达每个参与的行动者(除了状态消息的发送者之外)。下面在实施例的详细描述中描述了这种示例性重新发送方案。
[0066]
例如，应用重新发送方案及其具体设计的必要性可以取决于传输信道的可靠性，并且可能可以根据传输信道的可靠性来调整(例如，在传输信道非常不可靠的情况下，可以将消息重新发送若干次)。
[0067]
此外，在实施例中，包括在接收的状态信息中的操纵状态信息被储存在相应的接收端。具体地，可以设置的是：在接收到第一状态消息时，已经接收到状态消息的每个参与车辆在内部存储协调操纵序列的所有操纵的当前状态，以便跟踪其他行动者的执行并且知道何时触发自己的执行。
[0068]
在实施例中，该方法还包括响应于接收到状态消息而传送反馈消息。
[0069]
反馈消息可以用作确认。
[0070]
例如，反馈消息指示如在发送车辆上内部缓冲的操纵的状态消息和/或执行状态的接收。
[0071]
优选地，状态消息的接收通过反馈消息来确认，以确保每个参与车辆知道当前状态。
[0072]
例如，可以设置：反馈消息重复所接收的状态消息的内容。因此，可以确保所有参与车辆具有所有涉及车辆的执行状态的同步状态。因此，例如，在传输错误的情况下，可以识别冲突并且可以确保一致性。特别地，这提供了有效的机制，以防止例如由于未接收到消息而在行动者之间偏离内部执行状态。应当注意，这在功能上超出了发送简单ack消息。
[0073]
在一些实施例中，所有反馈消息可以被发送到所有其他参与车辆。可替代地，例如可以设置：反馈消息至少应当被发送到待确认状态消息的发送车辆(并且可能还被发送到一些或所有其他参与车辆)。
[0074]
此外，在实施例中，设置：在协调操纵序列的框架内，由参与车辆传送的状态信息与由所述车辆执行的动作同步。也就是说，例如，响应于在状态消息中接收到在其之后车辆应该开始某个动作(即，操纵或操纵的一部分，诸如减速到某个速度)的状态，车辆通过发送反馈消息来确认，开始该动作，然后发送指示相应动作的状态inprogress的状态消息。
[0075]
根据本发明的第二方面，一种计算设备被配置用于：规划涉及发起车辆和远程车辆的协调操纵序列；以及生成寻址到远程车辆的请求消息，该请求消息包括指定协调操纵序列的信息。
[0076]
根据一些实施例，根据第二方面的计算设备可以被配置用于执行根据如上所述的第一方面的方法的一些或所有步骤，特别是在涉及在发起车辆处或代表发起车辆执行步骤的范围内。
[0077]
因此，在一些实施例中，计算设备可以被布置在发起车辆中。在其他实施例中，计算设备可以被布置在发起车辆的外部。
[0078]
本发明的第三方面涉及一种计算设备，该计算设备被配置用于：接收源自发起车辆的请求消息，请求消息包括指定向远程车辆建议的协调操纵序列的信息；以及评估包括在请求消息中的关于协调操纵序列对于远程车辆是否可接受的信息。
[0079]
根据一些实施例，根据第三方面的计算设备可以被配置用于执行根据如上所述的第一方面的方法的一些或所有步骤，特别是在涉及远程车辆处或代表远程车辆执行步骤的范围内。
[0080]
因此，在一些实施例中，计算设备可以被布置在远程车辆中。在其他实施例中，计
算设备可以被布置在远程车辆的外部。
[0081]
还应当注意，在一些实施例中，根据第三方面的计算设备可以同时被配置为根据第二方面的计算设备。换言之，计算设备可以被配置用于执行根据如上所述的第一方面的方法的步骤中的一些或全部，即在发起车辆处或代表发起车辆执行的步骤和/或在远程车辆处或代表远程车辆执行的步骤。
[0082]
例如，配备有这种计算设备(或者在计算设备被布置在车辆外部的情况下具有对这种计算设备的访问)的车辆可以用作本发明的第一方面的方法内的发起车辆以及远程车辆。
[0083]
在第四方面中，一种计算机程序包括指令，当程序由计算设备执行时，指令使计算设备执行如上所述的步骤。
[0084]
在第五方面，一种计算机可读存储介质包括指令，该指令由计算设备执行时，使计算设备执行如上所述的步骤。
[0085]
第六方面涉及一种承载根据第四方面的计算机程序的数据载体信号。
[0086]
在另一方面，类似于本发明的第一方面的方法的方法可以更一般地应用于两个或更多个主体之间的动作的协调的任务。
[0087]
因此，一种在自动驾驶车辆之间协调动作的方法，可以包括：
[0088]-规划涉及发起主体和远程主体的协调动作序列；以及
[0089]-向远程主体传送请求消息，该请求消息包括指定协调动作序列的信息。
[0090]
可选地，可以类似于根据第一方面的方法的一些或所有实施例来执行本上下文中的其他方法步骤(例如，评估建议、传送响应、协商建议、在协调动作序列的执行阶段期间传送一个或更多个状态消息、传送反馈消息等)。
[0091]
还可以设置对应的计算设备，该计算设备被配置用于执行在主体之间协调动作的这种方法的一些或所有步骤。
[0092]
这同样适用于对应的计算机程序、对应的计算机可读存储介质和对应的数据载波信号。
[0093]
例如，在一些实施例中，一个或更多个主体可以是机器人(诸如工业机器人)，该机器人可以被配置用于例如在工业生产环境中执行某些动作。更一般地，主体可以是机器或机器的部分。
[0094]
因此，在本说明书中主要描述的操纵规划和执行的任务也可以被扩展到其他协调任务，如集成和过程协调，例如在工业制造工厂中的手动移动或替换的机器的自动集成。
附图说明
[0095]
本领域技术人员在阅读以下详细描述并查看附图时将认识到附加特征和优点。
[0096]
现在将详细参考各个实施例，在附图中示出了实施例的一个或更多个示例。每个示例都作为解释提供，并不意味着对本发明的限制。例如，作为一个实施例的一部分示出或描述的特征可用于其它实施例或与其它实施例结合使用，以产生又一实施例。本发明旨在包括这些修改和变化。使用特定语言描述这些示例，特定语言不应被解释为限制所附权利要求的范围。附图没有按比例绘制，并且仅用于说明的目的。为了清楚起见，如果没有另外说明，则在不同的附图中，相同的元件或制造步骤由相同的附图标记表示。
[0097]
图1示意性和示例性地示出了车辆之间的复杂交互的模型，其示出了行动者以及协作的不同阶段(第0-3天)中的输入和输出。
[0098]
图2示意性和示例性地示出了根据一个或更多个实施例的方法步骤的序列。
[0099]
图3示意性和示例性地示出了根据一个或更多个实施例的主车辆和若干远程车辆之间的消息流。
[0100]
图4是用于静止车辆决策辅助(stationary vehicle decision assist，svda)场景的示意性和示例性使用情况图示。
[0101]
图5示出了根据一个或更多个实施例的如针对协议流仿真的成功完成的操纵比率相对于分组丢失率的图。
[0102]
图6示出了根据一个或更多个实施例的如针对示例性协议流仿真的若干消息类型中的每个的在成功完成的操纵中发送消息的平均比率相对于分组丢失率的图。
具体实施方式
[0103]
下面，将描述涉及cav之间的复杂交互的示例性实施例。例如，根据一些实施例，复杂交互可以被定义为两个或更多个行动者之间的消息交换，其中至少三个消息中的至少一个依赖于另一个。该定义的基本原理如下：显然，单个车辆不能交互。此外，即使简单的交互可能交换少于三个消息，但大多数协作应当至少涉及请求/建议、响应/接受以及决策。
[0104]
从属要求反映需要发生实际交互。如果较早的消息链中的某些改变，则稍后的消息必须在内容或被访地址方面不同。独立于所接收的输入(例如，关于发送者状态或所感知的对象)而广播的周期性信标的交换不是复杂交互，因为它们不依赖于其他行动者的动作或消息。
[0105]
复杂交互的上述定义包括不同的应用(如操纵协作或信息共享)，而且主要关心底层协议。这种想法是在完全互联的生态系统中，区分太多类型的交互可能不是明智的，而是只要所引起的开销允许，将协议概括为适用于跨广泛的场景。例如，车辆可能需要进一步的信息以便开始协作建议。因此，车辆可以首先请求信息(例如，关于由前方车辆感知的对象)，然后开始随后的操纵协商(例如，关于超车操纵)。
[0106]
图1示出了关于示例性系统的输入和输出的交互的功能拆分以及从共存到协作的转换的示例性和示意性模型。实线/白单元描绘已经存在于所谓的共存阶段中的实体，虚线/灰单元实现协作意识，而对于完全协作环境需要点虚线/深灰单元。
[0107]
特别地，图1中示意性地描绘的协作逻辑(“协作规划&监测”)通常是oem特定的，意味着主车辆不能依赖于根据其自身期望做出决策的其他车辆。这里，明确地共享操纵意图和信息需求使得其他行动者更容易处理和决定协作。协议的另一个优点是，该协议允许主车辆向一辆或更多辆远程车辆发送协作建议以便进入操纵协商。
[0108]
在下面将要被描述为复杂车辆交互协议(complex vehicular interactions protocol，cvip)的示例性实施例的上下文中，协作意识消息(cooperative awareness message，cam)或基本安全消息(basic safety message，bsm)信标被认为是给定的。它们被用来在涉及协商和执行阶段的实际交互开始之前识别意识阶段中的潜在操纵伙伴。需要的附加信息应该经由专用消息来交换。这里，仅考虑由自动驾驶车辆执行的联合操纵。自动驾驶车辆能够共享关于意图的信息，而不像手动驾驶车辆那样仅能够测量它们的当前状态而
不知道驾驶员的下一个动作。
[0109]
车辆必须能够估计其他车辆的动态以做出合理的操纵建议。在所提出的操纵对于另一车辆是不可能的情况下，其可以相应地响应。由于在协议层上不能决定所接收到的消息的内容(例如操作建议)是否是现实的和可行的，因此较高层必须评估传入的建议。该任务可以由图1中的“协作规划&监测”单元执行。
[0110]
关于安全性，对于本实施例，假设消息被签名，交互因此被保护。与本说明书中分析的消息大小相比，这将潜在地增加消息大小(进一步参见下文)。通信以及交互本身的安全性是重要的，但是由于存在诸如凭证之类的负责防止某些恶意动作的方式[14]，所以更详细的安全性分析被推迟到未来的工作。
[0111]
复杂车辆交互协议(cvip)的指导原则如下：
[0112]
首先，适当数量的确认被认为是必要的，因为行动者需要知道其他车辆是否已经听到、理解和同意所提出的交互。在cvip协议中，特定动作的执行状态仅可由执行该动作的行动者来改变，以避免不一致。
[0113]
其次，即使某些实体需要表达对操纵的初始请求，关于参与的决策也仅能够以分布式方式来自参与者本身。例如，如果自己的安全处于危险中，行动者必须能够在任何给定的时间点中止操纵。
[0114]
在cvip的优选实施例中，请求的级联(参见[8])未被启用，因为这将显著地增加在操纵可以被执行之前的延迟[11]。级联意味着车辆a对车辆b的请求包括从车辆b到其它车辆的进一步请求，以便能够接受车辆a的请求。
[0115]
根据上面概述的指导原理，方法的优选实施例涉及以下步骤，这些步骤在图2中示意性地示出：
[0116]-规划21涉及发起车辆和远程车辆的协调操纵序列；
[0117]-向远程车辆传送22请求消息(cqm)，请求消息(cqm)包括指定协调操纵序列的信息；
[0118]-在远程车辆处接收23请求消息(cqm)；
[0119]-评估24包括在请求消息中的关于协调操纵序列是否可接受的信息；以及
[0120]-向发起车辆传送25响应消息(crm)，其中，响应消息(crm)指示协调操纵序列对于远程车辆是否可接受。
[0121]
此外，该方法可包括：响应于发起车辆接收到指示协调操纵序列对于所有涉及的远程车辆是可接受的一个或更多个肯定响应消息：
[0122]-向所涉及的远程车辆传送26操纵状态消息(maneuver status message，msm)，该操纵状态消息指示协调操纵序列被规划。
[0123]
更一般地，该方法可以包括：
[0124]-在协调操纵序列中涉及的车辆之间传送26一个或更多个状态消息(msm)，每个状态消息(msm)向接收端指示在发送端处的协调操纵序列的操纵的相应状态。
[0125]
该方法还可以包括：
[0126]-响应于接收到状态消息(msm)而传送27反馈消息(mfm)。
[0127]
具体地，本文中作为示例性实施例描述的cvip协议被设计为涉及以下四种类型的消息：如图3所示，协作请求消息(cooperative request message，cqm)、协作响应消息
(cooperative response message，crm)、操纵状态消息(msm)和操纵反馈消息(maneuver feedback message，mfm)。
[0128]
应注意，图3所示的cqm的传送对应于图2中的步骤22，同样，crm的传送对应于步骤25，msm的传送对应于步骤26。mfm的传送对应于步骤27。
[0129]
图2中的虚线环指示在协调操纵的协商和执行期间可以重复地执行步骤26和27。
[0130]
图2中的另一个虚线环示出在否定响应消息或包括相反建议的响应消息的情况下(步骤25)，该方法可继续另一个(重新)规划步骤21。
[0131]
下面描述的特定消息元素的示例性大小可以在表i中到。
[0132]
表i
[0133]
文本中提到的协议组成部分的示例性大小范围
[0134][0135]
参考图4，以下解释了如何可以将cvip应用于涉及名为静止车辆决策辅助(svda)的复杂交互的样本场景。
[0136]
参见图4，svda场景工作如下：静止的远程车辆rv位于驾驶主车辆hv的前方。在意识到该情况之后，为了评估是否值得冒险超车，即将到来的主车辆hv询问静止车辆的估计停留持续时间(图4中的阶段“1”)。如果持续时间低于阈值或者未知，即将到来的主车辆hv提出超车，而静止的远程车辆rv应当保持静止(图4中的阶段“2”)。两辆车都同意并执行超车。
[0137]
下面将参考图3和图4，特别是参考其中的发起车辆hv和远程车辆rv、rv1、rv2、rv3、rv4。
[0138]
通常，在确定需要信息或联合操纵之后，一些车辆向潜在伙伴发出cqm。其内容可以被描述为元组：
[0139][0140]
g包含基本信息：协议版本、消息id i
msg
、发起车辆的站id is、生成时间戳t
gen
，以及序列号n
seq
。s包含基本状态信息，主要是用于参考的自我gps位置和实例id。这些可以用于后续消息中的参考。
[0141][0142]
是分别用于信息请求和操纵的容器，其中k+l≥1。
[0143]
每个iq包含用于参考的信息请求容器id i
iqc
＝1,...,k、应当提供信息的目的站(车辆)id i
dest
、所请求信息的类型tq、以及请求信息的更新间隔θ。在svda场景下，这可以是在当前移动性状态(即，速度为零)中的估计持续时间，其中一次信息为θ＝-1。
[0144]
元素m是描述预见的联合动作的操纵容器，每个元素均包含容器id i
mc
、应当执行操纵的目的站id i
dest
、操纵类型tm和相关参数pm。通过适当地设置i
dest
，甚至更高权限方(如rsu或紧急车辆)，可以提出他们自己不主动参与的操纵。
[0145]
经由tm和pm，操纵可以被描述为标准化的名称、参数化的函数，或者也可以经由轨
迹来描述操纵。这些提出的操纵直接反映了对其他行动者的物理能力和车辆动态的假设。如果需要，也可以包括(绝对的或相对于另一操纵容器的)开始时间t
start
，以及预期操纵持续时间τ。
[0146]
例如，在图4的svda场景下，每个车辆可以提供一个容器m，将发起车辆的tm陈述为超车，将静止车辆的tm陈述为保持当前移动状态，其中二者t
start
＝0，τ等于操纵的期望持续时间。
[0147]
原则上，tm的更细粒的陈述也是有意义的，例如，具有用于主车辆hv的三个容器(车道改变、加速、车道改变)、以及相对的开始时间，以确保对执行顺序的共同理解。
[0148]
在接收到cqm之后，其他车辆rv、rv1、rv2、rv3、rv4评估在它们的协作逻辑中包括的信息。他们以以下定义的crm响应：
[0149][0150]
而g和s包含与cqm中相同类型的子元素(即更新的t
gen
等)，
[0151][0152]
现在上式是包含参考的i
iqc
以及所请求的值v或错误的信息响应容器。当给定tq未被理解或不可用时，车辆也可以陈述。
[0153]
操纵容器m现在包括分组id i
pkt
，其基于原始cqm的is和n
seq
以用于陈述参考。此外，包含设置为规划或相应错误状态的操纵状态sm。如果需要，可以给定t
start
或τ的更新值。请求和所接收的响应的组合向发起者给出了关于其他车辆参与意愿的清晰图片。
[0154]
cqm和crm的这种迭代将被重复，直到没有提出改变并且不再发送错误。这是收敛的标志，每个参与的车辆hv、rv1、rv2可以确信所有其他车辆也已经同意操纵。
[0155]
如图3所示，没有实现协议的cav将不发送crm(rv4)。实现该协议但不实现请求的tq或tm中的一些或者不能满足来自cqm的要求的车辆将发送陈述这一点的响应(rv3)。然后，发起车辆hv根据反馈更新建议，并发送仅涉及愿意、有能力和必要的车辆的新cqm。
[0156]
在收敛之后，发起车辆hv将发送msm：
[0157][0158]
msm具有m中的同意的操纵，以及为m中的每个容器规划的操纵状态sm(图4中的阶段“3”)。其它可能的状态值是inprogress(进行中)、finished(完成)和cancelled(取消)。经由这些状态，所有车辆将总是知道每个参与的行动者的执行状态。
[0159]
在接收到该第一msm时，每个车辆必须在内部存储所有l个操纵的当前状态，以便保持跟踪其他行动者的执行，并且知道何时触发自己的执行。
[0160]
为了通知msm的发送者所有参与车辆已经接收到msm并且为了确保所有参与者的内部状态目录被同步，发送mfm作为确认，其可以由以下描述：
[0161][0162]
mfm重复刚接收的msm的内容。虽然这可能消耗相当大量的总的必须带宽，但是它提供了一种有效的机制来防止例如由于未接收到消息而在行动者之间偏离内部执行状态。例如，当从所接收的msm和mfm检测到操纵容器m
l
′
的偏离状态时，执行m
l
′
的车辆可以发送包含当前正确的执行状态的澄清msm。
[0163]
每当行动者随后改变其操纵执行状态时(经由t
start
和τ的一致使用而知道序列)，行动者将发送具有更新状态的msm以使每个其他车辆知道该行动者进入新状态(例如，图4中的阶段“4”/“6”，车道改变已经切换到inprogress，或者在图4中的阶段“5”/“7”，车道改变切换到finished)。一旦所有操纵的状态都被设置为完成，则联合操纵被完成。
[0164]
由于消息的接收对于车辆之间的同步状态转换是必要的，因此可以可选地实现基于超时的重新发送机制。因此，例如，可以假设如果cqm被丢弃并且因此没有接收到crm，则发起者在之后重新发送其cqm直到c
cqm
次。如果crm被丢弃，则车辆必须被认为是不协作的。在丢弃msm的情况下，根本没有接收到mfm，因此在之后重新发送消息，最多c
msm
次。
[0165]
在丢失mfm的情况下，在超时之后，还重新发送相应的msm，以便确保同步状态更新。如果在重试c
msm
之后mfm丢失，则将取消操纵。
[0166]
超时和最大重新发送可以例如基于不同的应用场景、驾驶环境或周围车辆可能遮蔽信号的交通来调整。
[0167]
由于不同使用情况的要求可能显著不同，因此可以根据相应的需求来调整特定消息内容(例如容器的数量和类型、传送哪个信息等)。这给予cvip支持不同场景而无需定义专用消息的灵活性。通过增加tq,tm,pm的定义值集或添加新的字段，容易地实现新的场景。
[0168]
上表i中的信息与下面呈现的仿真分析一起示出了当前消息大小不会超过几百字节。这意味着当今的车载通信技术(如its-g5或lte-v2x)，能够容易地支持这种可扩展性。
[0169]
接下来，呈现数值实验的评估。为了示出cvip的普遍适用性，已经从特定应用中提取了评估设置。相反，以下问题将经由协议流的仿真集来回答：
[0170]
·
协议相对于参与复杂交互的节点数量是否可缩放？
[0171]
·
协议是否可行？即，消息大小是否被约束在合理的限制内，即使对于高k、l也是如此？
[0172]
·
协议是否稳健？即，协议是否能够应付丢失的分组？
[0173]
为此，考虑简单的仿真场景：在仿真区域内的直车道上放置一组n个静止车辆节点。发起节点向所有其它节点发送第一cqm。由于决定传入协作请求的逻辑的细节不在本研究的中心，所以所有车辆发送具有正反馈的crm。实际上，高级协作逻辑将必须评估传入cqm的可行性。从那时起，如算法1中所描述的那样执行简单的操纵：一个节点接着另一个节点开始它们的持续时间τ的操纵。利用这种设置，可以通过以概率p
drop
插入分组丢失来评估关于n和l的可缩放性以及稳健性。
[0174][0175]
所有的仿真都是使用用于互联的应用的智能运输系统(intelligent transport system，its)框架ezcar2x[15]结合仿真器sumo和ns-3来执行的。为了得到重要的结果，对
后面描述的每个参数集执行100次仿真运行。
[0176]
在一次交互中交换的消息的数量可以根据节点的数量n、协商回合的数量ν、以及操纵容器的数量l被形式化为：
[0177][0178]
系数2是因为具有状态inprogress和finished的msm将分别针对l个操纵容器中的每一个被发送，l个操纵容器中的每一个将由n-1个其他行动者经由mfm来确认。可以容易地看出：
[0179][0180]
相反，在用于意图共享的基于信标的方法中以频率f传送的消息的数量：
[0181][0182]
数量取决于总的操纵执行时间θ。对于合理的值集，例如n＝10、ν＝1、l＝20、f＝5hz、以及θ＝10s，cvip将交换的消息的数量减少了几乎20％。这种减少是更重要的，因为信标被预见为甚至在不执行操纵的时候使用，因为隐式操纵协商的整个概念是基于意图的这种周期性广播。利用cvip，仅在需要的情况下才交换消息。对于纯信息交换(即，l＝0，k》0，ν≥1)，将仅发送非常少的消息，从而精确地满足请求车辆的信息需求。所涉及的消息的大小仅随着所包括的容器的数量k和l线性地增加，如表i所示，每个iq、ir和m的大小相对较小。通过串行技术，可以进一步减小总的发送消息大小。例如，对于具有l＝7的mfm，发送的消息大小平均为137字节，而源代码内的消息大小为203字节。
[0183]
在仿真中，即使对于l＝7，总消息大小也从未超过225字节，从而传送操纵容器的所有必要元素。即使对于当今的技术(如itsg5或lte-v2x)，这也使得我们的协议可行。对于将来的使用情况，仍然存在空间来包括例如在pm中的附加字段，而消息大小不会变得不可行。这也为更复杂操纵描述铺平了道路。
[0184]
通过引入具有概率p
drop
的分组丢失，研究了即使是在基本的重新发送机制的情况下协议对于传输中断有多稳健。为了评估，如果包含设置为finished的所有操纵状态的最后msm被发送和接收，则操纵被认为成功完成。成功操纵与所有操纵的比率被称为成功率。如果单个crm被丢弃，则操纵将不成功，因为发起节点不能发现一个crm丢失。根据应用，发起车辆因此可以选择发送若干cqm，以便最小化crm丢失的概率。如图5所示，这显著地提高了成功率，对于c
cqm
＝2，即使p
drop
＝0.2，成功率也达到0.8。
[0185]
图6示出了对于n＝3并且每辆车一个操纵的场景，需要交换的消息的数量随着p
drop
增加，基线情况是p
drop
＝0。但是即使对于p
drop
＝0.2，也不会发送两倍的消息。通常，cqm比crm相对更频繁地发送，因为车辆必须针对丢失的cqm以及丢失的crm重新发送它们。对于比较msm和mfm同样如此。
[0186]
上述分析示出了cvip对于复杂交互是可行的。特别地，仿真示出了当前技术足以实现复杂交互。例如5g-v2x的新通信技术可例如通过启用单播或更大的消息大小以便包括非常数据密集的信息v或操纵参数pm来支持进一步的使用情况。
[0187]
考虑到上述范围的变化和应用，应当理解，本发明不受前面的描述限制，也不受附图限制。相反，本发明仅由所附权利要求及其合法等效物来限制。
transportation systems(itsc)，2019，第1545
–
1551页。
[0200]
[12]k.franke，m.d
ü
ring，r.balaghiasefi，m.gonter，k.lemmer和f.k
ücü
kay，“a reference architecture for ciss/cdas within the field of cooperative driving(协作驾驶领域内的ciss/cdas的参考架构)”，in ieee international conference on connected vehicles and expo(iccve)，2014，第357
–
363页。
[0201]
[13]c.frese，j.beyerer和p.zimmer，“cooperation of cars and formation of cooperative groups(汽车协作与协作组的形成)”，in ieee intelligent vehicles symposium，proceedings，2007，第227
–
232页。
[0202]
[14]b.brecht，d.therriault，a.weimerskirch，w.whyte，v.kumar，t.hehn和r.goudy，“a security credential management system for v2x communications(用于v2x通信的安全凭证管理系统)”ieee transactions on intelligent transportation systems，第19卷，12号，第3850
–
3871页，2018。
[0203]
[15]k.roscher，s.bittl，a.a.gonzalez，m.myrtus和j.jiru，“ezcar2x:rapid-prototyping of communication technologies and cooperative its applications on real targets and inside simulation environments(ezcar2x：通信技术的快速原型和在真实目标与内部仿真环境上的协作its应用)”，in 11th conference wireless communication and information，2014，第51
–
62页。

技术特征：

1.一种在车辆之间协调一个或更多个操纵的方法，所述方法包括：规划(21)涉及发起车辆(hv)和远程车辆(rv1、rv2、rv3、rv4)的协调操纵序列；以及向所述远程车辆(rv1、rv2、rv3、rv4)传送(22)请求消息(cqm)，所述请求消息(cqm)包括指定所述协调操纵序列的信息。2.根据权利要求1所述的方法，其特征在于，所述规划(21)考虑关于所述远程车辆(rv1、rv2、rv3、rv4)的操纵能力的假设或知识。3.根据前述权利要求中的一项所述的方法，其特征在于，所述方法还包括：在所述远程车辆(rv1、rv2、rv3、rv4)处接收(23)所述请求消息(cqm)；以及评估(24)包括在所述请求消息中的关于所述协调操纵序列是否能够接受的所述信息。4.根据前述权利要求中的一项所述的方法，其特征在于，所述方法还包括：向所述发起车辆(hv)传送(25)响应消息(crm)，其中，所述响应消息(crm)指示所述协调操纵序列对于所述远程车辆(rv3)是否能够接受。5.根据权利要求4所述的方法，其特征在于，所述响应消息(crm)包括：指示所述远程车辆(rv3)能够接受的协调操纵序列的相反建议。6.根据权利要求4或5所述的方法，其特征在于，所述方法还包括响应于所述发起车辆(hv)接收到指示所述协调操纵序列对于所述远程车辆(rv3)是不能够接受的响应消息(crm)：规划涉及所述发起车辆(hv)和所述远程车辆(rv、rv1、rv2、rv3、rv4)和/或一辆或若干辆其他远程车辆(rv、rv1、rv2、rv3、rv4)的调整的协调操纵序列；以及向在所述调整的协调操纵序列中涉及的所述远程车辆(rv、rv1、rv2、rv3、rv4)传送更新的请求消息(cqm)，所述更新的请求消息(cqm)包括指定所述调整的协调操纵序列的信息。7.根据权利要求4或5所述的方法，其特征在于，所述方法还包括响应于所述发起车辆(hv)接收到指示所述协调操纵序列对于所有涉及的远程车辆(rv1，rv2)都能够接受的一个或更多个肯定响应消息(crm)：向所涉及的远程车辆(rv1，rv2)传送(26)操纵状态消息(msm)，所述操纵状态消息(msm)指示所述协调操纵序列被规划。8.根据前述权利要求中的一项所述的方法，其特征在于，所述方法还包括：在所述协调操纵序列中涉及的所述车辆(hv、rv1、rv2)之间传送(26)一个或更多个状态消息(msm)，每个状态消息(msm)向接收端指示在发送端处的所述协调操纵序列的所述操纵的相应状态。9.根据权利要求7或8所述的方法，其特征在于，所述方法还包括响应于接收到状态消息(msm)而传送(27)反馈消息(mfm)。10.根据权利要求9所述的方法，其特征在于，所述反馈消息(mfm)重复所接收的状态消息(msm)的内容。11.一种计算设备，所述计算设备被配置用于：规划(21)涉及发起车辆(hv)和远程车辆(rv、rv1、rv2、rv3、rv4)的协调操纵序列；以及生成寻址到所述远程车辆(rv、rv1、rv2、rv3、rv4)的请求消息(cqm)，所述请求消息(cqm)包括指定所述协调操纵序列的信息。
12.一种计算设备，所述计算设备被配置用于：接收(23)源自发起车辆(hv)的请求消息(cqm)，所述请求消息(cqm)包括：指定向远程车辆(rv、rv1、rv2、rv3、rv4)建议的协调操纵序列的信息；评估(24)包括在所述请求消息中的关于所述协调操纵序列对于所述远程车辆(rv、rv1、rv2、rv3、rv4)是否能够接受的所述信息。13.一种包括指令的计算机程序，当所述程序由计算设备执行时，所述指令使所述计算设备执行如前述权利要求中的一项所述的步骤。14.一种包括指令的计算机可读存储介质，所述指令在由计算设备执行时使所述计算设备执行如权利要求1至12中的一项所述的步骤。15.一种承载权利要求13的计算机程序的数据载体信号。

技术总结

提供了一种在自动驾驶车辆之间协调一个或更多个操纵的方法。该方法包括：规划(21)涉及发起车辆(HV)和远程车辆(RV、RV1、RV2、RV3、RV4)的协调操纵序列；以及向远程车辆(RV、RV1、RV2、RV3、RV4)传送(22)请求消息(CQM)，请求消息(CQM)包括指定协调操纵序列的信息。息(CQM)包括指定协调操纵序列的信息。息(CQM)包括指定协调操纵序列的信息。