CN115958995A - 电动自主车辆乘车服务辅助 - Google Patents

Abstract

本公开提供了“电动自主车辆乘车服务辅助”。一种自主车辆可以确定其具有预计通过在预定义系统被禁用的情况下自主行驶而到达再充电点所需的剩余功率量。所述车辆可以禁用所述预定义系统并朝向所述再充电点行驶。在所述禁用之后，所述自主车辆可以确定其不再具有预计到达所述再充电点所需的剩余功率量。然后，所述车辆可以与服务器通信并请求辅助。然后，所述车辆可以与第二自主车辆行驶到指示的会合点，所述会合点是从服务器接收的。然后，两个车辆进行通信以响应于所述第一自主车辆和所述第二自主车辆在通信范围内而允许所述第一车辆利用所述第二自主车辆的能力，从而允许所述第一车辆经由所述利用到达所述再充电点。

Description

电动自主车辆乘车服务辅助

技术领域

说明性实施例涉及电动自主车辆乘车服务辅助。

背景技术

电池电动车辆(BEV)正在成为未来的优选运输来源，特别是就自主车辆而言。它们有可能通过车载电池存储可由计算系统和车辆本身两者使用的大量能量，以用于为行驶提供动力。然而，在有限的情况下，当功率储备较低并且车辆不接近燃料补给点时，车载计算机和传感器与车辆从同一电源汲取的事实可能会出现问题。

BEV和/或电池电动自主车辆(BEAV)在其内部电源上经历相当大的行驶续航里程。唯一可能的缺点是，与汽油不同，电力往往不是便携式燃料补给的选择。因此，最好使BEV保持在某个功率阈值，以确保它不会被滞留在远离再充电点处。虽然在人口密集的地区(在这些地区可能更容易再充电)问题较小，但是仍然存在很长一段距离的乡村，在那里再充电有限，甚至没有再充电。当BEV是BEAV时，驱动车辆的车载计算资源也可能使用大量功率，这可能会减小续航里程。因此，例如，如果一个人要穿越一长段相对无人居住的地带从一个主城市行进到另一个主城市，则必须进行规划以确保计算资源加上行驶不会将车辆滞留在可能很难获得额外功率的地方。

按需车队内的这些车辆也可以基于行驶的人口统计来重新调整用途，从而需要基于它们可能被需要的地方在一天或一周的过程中在广泛的地理区域周围重新定位。然而，即使没有乘客，车队所有者也不希望车辆被滞留。由于每次车辆必须重新定位或行驶很长距离时，可能无法立即获得重新供电，因此车辆的任务可能是到达推动其续航里程阈值的目的地。然后，任何意外的延迟或绕道都可能导致车辆耗尽电源。如果在发生这种情况时再充电点接近路线，则车辆可以重新制定路线。但是如果不存在此类站，则车辆可能无法自导航到更远的站。并且，如果没有胜任的驾驶员，则车辆也不能被手动驾驶，因此当人驾驶车辆到另外的燃料补给点时，车辆不能简单地禁用自主特征来保存功率。

发明内容

在第一说明性示例中，一种系统包括处理器，所述处理器被配置为从第一自主车辆接收行驶辅助请求，所述请求指示所述第一自主车辆的低功率状态。所述处理器被进一步配置为确定供所述第一自主车辆使用的再充电点。所述处理器被进一步配置为在所述第一自主车辆可实行的一个或多个功率保存状态下确定所述第一自主车辆到达所述再充电点所需的功率，并且对于所述功率保存状态中的至少一个，确定可以以针对所述至少一个功率保存状态预定义的方式向所述第一自主车辆提供辅助并且允许所述第一自主车辆到达所述再充电点的第二自主车辆。所述处理器另外被配置为指示所述第二自主车辆在确定的会合点处与所述第一自主车辆会合。

在第二说明性实施例中，第一自主车辆包括处理器，所述处理器被配置为确定当前功率水平小于到达再充电点所需的预计功率水平。所述处理器被进一步配置为从远程服务器请求辅助。此外，所述处理器被配置为响应于所述请求，接收会合指令，所述会合指令包括用于第二自主车辆的会合点，并且执行到所述会合点的行驶。所述处理器被配置为当所述第一自主车辆和所述第二自主车辆两者在彼此的可通信范围内时直接与所述第二自主车辆通信，并且将计算任务或感测任务中的至少一者卸载到所述第二自主车辆，其中所述第二自主车辆提供对所卸载任务的响应，从而允许所述第一自主车辆利用所述响应继续自主行驶。另外，所述处理器被配置为继续：将计算任务或感测任务中的至少一者卸载到所述第二自主车辆；接收对所卸载任务的响应；以及利用所述响应自主地行驶，直到所述第一自主车辆到达所述再充电点或接近所述再充电点的其中所述第一自主车辆预计所述当前功率水平大于到达所述再充电点所需的所述预计功率水平的位置中的至少一者。

在第三说明性实施例中，一种方法包括在第一自主车辆上，确定所述第一自主车辆具有预计通过在禁用一个或多个预定义系统的情况下行驶而到达充电点所需的、仍然允许自主行驶的剩余功率量。所述方法还包括禁用所述预定义系统并朝向所述再充电点行驶。此外，所述方法包括在所述禁用之后，确定所述第一自主车辆不再具有预计到达所述充电点所需的、从所述第一自主车辆的当前位置重新预计的剩余功率量。所述方法另外包括响应于所述第一自主车辆不再具有所述剩余功率量而与服务器通信并请求辅助。此外，所述方法包括响应于所述请求而接收包括用于与第二自主车辆相会的会合位置的会合指令。并且，所述方法包括：在所述第一自主车辆处，响应于所述第一自主车辆和所述第二自主车辆在通信范围内，利用所述第二自主车辆的能力，从而允许所述第一车辆经由所述利用到达所述再充电点。

附图说明

图1示出了多车辆BEAV车队管理系统的说明性示例；

图2示出了车辆辅助程序的说明性过程；

图3示出了说明性警报处置过程；以及

图4示出了说明性辅助队列处置过程。

具体实施方式

本文描述了本公开的实施例。然而，应理解，所公开的实施例仅仅是示例并且其他实施例可以采用各种和替代形式。附图不一定按比例绘制；一些特征可能被放大或最小化以示出特定部件的细节。因此，本文公开的具体结构细节和功能细节并不解释为限制性的，而仅解释为用于教导本领域技术人员以各种方式采用本发明的代表性基础。如本领域普通技术人员将理解，参考附图中的任一者示出和描述的各种特征可与一个或多个其他附图中示出的特征组合以产生未明确地示出或描述的实施例。所示特征的组合提供用于典型应用的代表性实施例。然而，对于特定的应用或实现方式，可能期望与本公开的教示一致的对特征的各种组合和修改。

除了使示例性过程由位于车辆中的车辆计算系统执行之外，在某些实施例中，所述示例性过程还可由与车辆计算系统进行通信的计算系统来执行。此类系统可包括但不限于无线装置(例如但不限于移动电话)或通过无线装置连接的远程计算系统(例如但不限于服务器)。此类系统可统称为车辆相关联的计算系统(VACS)。在某些实施例中，VACS的特定部件可依据所述系统的特定实现方式来执行过程的特定部分。作为示例而非限制，如果过程具有与配对的无线装置发送或接收信息的步骤，则很可能无线装置未执行所述过程的所述部分，因为无线装置不会与自己“发送并接收”信息。本领域普通技术人员将理解何时将特定计算系统应用于给定解决方案是不合适的。

可通过使用单独工作或彼此结合工作并执行存储在各种非暂时性存储介质(诸如但不限于快闪存储器、可编程存储器、硬盘驱动器等)上的指令的一个或多个处理器来促进过程的执行。系统与过程之间的通信可包括使用例如蓝牙、Wi-Fi、蜂窝通信和其他合适的无线和有线通信。

在本文讨论的说明性实施例中的每一者中，示出了由计算系统执行的过程的示例性非限制性示例。关于每个过程，执行所述过程的计算系统可能为了执行所述过程的有限目的而变得被配置为用于执行所述过程的专用处理器。所有过程不需要完整地执行，并且被理解成是可执行以达成本发明的要素的过程类型的示例。可根据需要在示例性过程中添加或移除额外步骤。

关于在示出说明性过程流程的附图中描述的说明性实施例，应注意，出于执行由这些附图示出的一些或所有示例性方法的目的，可暂时启用通用处理器作为专用处理器。当执行提供执行所述方法的一些或所有步骤的指令的代码时，处理器可暂时改换用途作为专用处理器，直到所述方法完成为止。在另一示例中，在适当的程度上，根据预配置的处理器起作用的固件可致使处理器充当为执行所述方法或其某种合理变型而提供的专用处理器。

因为车辆在远离可用再充电长距离行驶时可能会耗尽功率，所以具有用于防止完全功率损失的选项是有用的。当电动车辆是BEAV时，它可能未被占用，或者可能缺少胜任的驾驶员(未成年或无执照的乘客)，并且因此关闭自主功能并允许乘客驾驶到指定再充电点的简单解决方案可能是不可行的。同时，在没有传感器引导和计算的情况下，车辆通常不能自驾驶，并且因此在没有拖车的情况下，当车辆意外地低功率运行时，可能存在有限的选项。

仔细规划可以避免许多此类情况，但是交通延误、意外的电池寿命缩短、意外的绕行等仍可能导致以下情况：车辆缺乏足够的功率来自驾驶到再充电点，从而需要比剩余功率量更多的功率量来为车辆供电以及执行必要的感测和计算。

很可能并非所有车辆都将能够持续充电，并且因此道路上可能必然存在处于中等或低功率状态的车辆。乘客也可能以意外的方式重新制定车辆路线，并且行驶合同的条款可能会限制车辆在乘员在场时进行再充电的能力，因为再充电通常需要相当长的持续时间(相对于行驶时间)。

经由本文的实施例在说明性示例中示出的一个提出的解决方案概念允许具有较高功率的第二车辆辅助BEAV到达目的地。虽然可能并不总是能够在行程开始时预计到车辆的功率会过低，但是当前的功率储备是已知的商品，并且知道车辆何时可能耗尽功率或在到达再充电点之前达到临界功率状态可能更合理。也就是说，一旦行程正在进行，将观察到意外延迟和绕道的影响，并且可确定从任何点开始完成行程所需的可能的功率量。随着车辆接近目的地，该数字的可变性可能会减小，这可能具有更准确预计的积极影响，但这也可能揭示原始预计以可能使车辆滞留的方式而不正确。

随着这种情况发生的可能性增加(例如，当车辆继续行驶，但功率使用超出预期并且似乎剩余有限的储备时)，中央管理系统可以采取缓解措施以避免功率完全损失，同时车辆仍在行驶。在该示例中，这包括指派另一车辆通过引导故障车辆并充当引导来向BEAV提供辅助以将其引导到目的地，这可以包括分布式感测和计算(其中引导车辆感测并计算尾随车辆)和/或使尾随车辆以某种方式尾随引导车辆(实际上以类似于一个车辆在挂车上拖曳另一车辆的方式起作用)，其中感测和计算过程关闭以节省功率。

在前一示例中，可以将一定量的感测和计算卸载到引导车辆上，并且引导车辆可以使用多余的功率来对尾随车辆执行感测和计算过程，从而将数据发送回到尾随车辆，其中可以在所述引导车辆的引导下执行有限的自主驾驶。在后一示例中，尾随车辆可以紧密地跟随引导车辆，这可以以避免将两个车辆分开的方式起作用(例如，最小化车道变换、加速等)。由于两个车辆都可以是自主的，因此可以在引导车辆实行下一次移动之前向尾随车辆通知所有决策，因此其可以预期到引导车辆的移动，这将会限制车辆分离的可能性。

由于能够预测其他车辆的动作并且由于计算机的反应时间，因此自主车辆也可能比针对手动驾驶的车辆所建议得更紧密地一起行驶。因此，车辆可能能够接近一致地行动并且足够紧密地一起移动以避免任何中间车辆干扰。知道其正在任一模式(或另一种类似的引导模式)下运行的引导车辆可以做出适应情况的决定，从而限制可能使该组分开的移动(例如，限制车道变换、在交通信号灯下要小心不使该组分开、在停车标志处通知其他穿行车辆，等等)。

如果车辆分离，则除非功率处于绝对临界状态，否则尾随车辆可以始终自驾驶回到引导车辆，所述引导车辆可能已经减速或停止以等待尾随车辆。并且，在如车道变换的情况下，出于谨慎考虑，可能会将完全控制权交还给每个车辆。但是，对于大部分行程，引导车辆应能够减轻第二车辆的一些计算和/或驾驶负荷，并且通过限制高功率使用计算系统的使用来允许第二车辆获得增加的续航里程。

图1示出了多车辆BEAV车队管理系统的说明性示例。在该示例中，车辆100包括车载计算系统101，所述车载计算系统尤其可以包括可用于蜂窝通信的远程信息处理控制单元105。车辆100还可以包括蓝牙收发器107和Wi-Fi收发器109，其可用于与车辆100附近且在相应收发器的范围内的相应蓝牙装置和Wi-Fi装置通信。

车辆100还可以包括各种车载计算过程111和113或模块、传感器或其他功率密集型元件。存储这些过程的存储器以及传感器和/或模块可以通过一个或多个车辆总线115连接到CPU 103。车辆100还可以包括GNSS接收器117，诸如GPS接收器。

除了确保车辆能够与另一车辆120和/或云140进行某种形式的通信之外，车辆100内的特定的整组元件不是感兴趣的主题。通信可以以各种形式提供，并且甚至不一定需要涉及传统的无线通信。例如，如果车辆100设置有相机并且车辆120设置有后向LED阵列灯，则车辆120可以通过简单地改变灯阵列的图案来向车辆100传达信息，这对于车辆100来说可能比使用无线通信来交换大数据包更节能。

在一个实施例中，虽然在车辆100中保留了足够的功率，但是可以使用更高级的通信形式，但是当功率减少并且尚未到达目的地时，通信可能变得更加简单，以便最大化用于驾驶的功率。还可以考虑当前驾驶条件-车辆100是否靠近燃料补给点以及当前道路/路线是否适合于不太精细的控制功能(例如，其中车辆100比自主车辆执行起来更像挂车牵引车)。尽管如此，仍然可以使用各种通信介质来交换信息，所述通信介质可以包括光或甚至声音，这同样取决于条件是否允许。

车辆120是与100类似的车辆，但不一定是相同的品牌和型号。如果车辆120要为车辆100提供传感器信息和/或处理，则云140可以在调派之前确认车辆120适合于此类任务(基于系统、配置和当前功率状态等)。

车辆120具有车载计算系统121，所述车载计算系统还包括CPU 123和各种通信收发器。这些可以包括用于通过蜂窝、蓝牙127和Wi-Fi 129收发器与云进行通信的TCU 125，以用于与另一车辆100或其他本地装置通信。车辆120还可以包括GNSS收发器131。

云140可以包括多个远程过程，诸如调度器141。调度器可以负责将调派指令传送到车辆100、120，并且可以从这些车辆接收与活动作业有关的通信(以及其他通信)。因此，例如，车辆100(其上可能有或可能没有乘员)可以通知调度器(基于对邻近电源的当前车载评估和当前功率状态)不太可能车辆100将能够在功率耗尽之前到达再充电点或预计低于预定义阈值。

该信息可以被传递到请求处置过程143，所述请求处置过程可以访问功率规划过程147以确定如何最好地辅助潜在滞留车辆100。这些仅仅是示出可能发生何种后端确定的示例性过程。功率规划过程可以考虑将多少功率报告为来自车辆100的剩余功率，其可以用于基于使某些系统断电和/或使某些任务脱离来确定各种可能的续航里程。对于这些重新配置中的一者或多者，所述过程还可以确定应发送哪种车辆(特征、功率水平、接近度等)以进行辅助。

100的某些重新配置可能需要车辆120包括某些传感器。其他重新配置可能需要在车辆120中具有某些远程计算功能。还有其他重新配置可能需要车辆120具有简单的通信能力和一定的功率储备。即使尚不知道给定车辆120的当前位置，也可以确定要求，并且对于满足要求的每个候选车辆，可以确定在车辆在一个或多个会合点处与车辆100会合时可能剩余多少功率。如稍后所讨论的，如果车辆100向调度器提供可能的滞留状态的充分提前通知，则这些可以包括车辆100的当前位置或沿着车辆100的当前路线的点。

功率规划可以将要求传递回请求处置程序，所述请求处置程序可以访问实时或接近实时的车辆统计数据的数据库145，所述数据库可以包括位置、当前功率状态、当前任务等。如果车辆120经常用于辅助，则基于将需要车辆的统计可能性，可以针对给定地点使一定数量的车辆120不被分配任务。在其他示例中，所述过程将找到处于任务之间或可能以其他方式存在的车辆120。即使给定车辆120已被向用户引导，它也可能是合适的辅助候选者，因此它可以被重新引导，并且可以以对用户端体验几乎没有或没有影响的方式将另一可用车辆引导至用户(例如，替代的接载车辆行驶了10分钟，而原始接载车辆被重新引导以进行辅助，同时它也距离用户10分钟或更长时间)。

车辆120可以确认其具有辅助车辆100的适当能力，并且可以从调度器接收会合位置。车辆100也可以被引导至该位置，并且无论哪个车辆100、120首先到达都可以等待。即使车辆100包括乘客，乘客也可能会在辅助向乘客行驶时等待较短的某个时间段。

图2示出了车辆辅助程序的说明性过程。在该示例中，所述过程在例如车辆100上执行并且允许车辆100确定低功率状态、请求辅助并主动地监测功率状态以最大化到达再充电点的可能性。

在行程中的某个时刻，车辆100在201处确定其处于低功率状态。这可以包括用户或所有者定义的阈值，或者可以是与当前维持的对到达再充电点需要的可能功率量的感知相关的动态阈值。在后一示例中，车辆100可以连续地确定下一个可到达的再充电点(或方便地定位的相同点，例如，不是最近的，而是在正确的方向上)可能需要的功率量。据推测，当行程开始时，车辆100具有足够的功率或应当具有足够的功率来到达该点，但是一路上，功率情况可能已经发生了实质性的变化。替代地，规划的再充电可能已经因停电而关闭，从而需要车辆100行驶得更远，并且车辆100也可以获知此类变化。如果剩余功率量达到例如但不限于到达再充电点所需的功率加上10％(例如，其包括缓冲量)，则车辆100可以确定其处于低功率状态。可以适当地包括和/或改变缓冲量和阈值。

如果车辆100尚未知道充电点，则它将找到最近的和/或最方便(在正确或半正确的方向上)的功率点以进行再充电。例如，车辆100最初可能已经简单地设想了到达目的地所需的功率量，其中存在已知的充电。如果剩余功率运行得太低而无法实现该目标，则车辆100可能必须搜索本地充电。它可以首先寻找可到达的方便再充电，并且如果不可到达，则它可以寻找“不方便但可到达的”再充电(例如，由原路返回)。由于发送辅助车辆120可能需要在相当长的一段时间内使用两个车辆，因此可能建议尝试找到对车辆100来说甚至不方便但可到达的点。另一方面，订阅模型(如果乘员订阅分层共乘模型)或甚至仅存在乘员的事实可以使以下情况更合理：车辆100沿其当前路线行驶并简单地发送辅助车辆120来会合，使得被占用的车辆不会原路返回。

如果车辆100找到在205处可到达并且在207处在容差阈值内的充电点，则车辆100可以在219处简单地规划路线，而无需最初联系服务器。也就是说，如果车辆100确定当前功率等于到达再充电的功率+3*“低”阈值(例如，10％)，则可能不需要辅助并且车辆100可以在其自己的功率下继续行进到再充电。

如果该点不在阈值内，例如，当前功率等于到达再充电的功率+0.5*低阈值，则可能需要在207处调度辅助。在第一示例中，功率是预计需要的功率的130％，其中阈值为10％(例如，110％是截止值)。在第二示例中，剩余的功率仅为所需功率的105％，因此可能(但不一定)需要辅助。

如果低于截止阈值，则车辆100在209处向服务器发出警报，并且在211处确定辅助是否可用，如服务器响应于警报而指示的。由于各种原因，例如，辅助车辆优先于被占用的辅助需求或非常低(<100％需要)的功率辅助需求车辆，可能没有可用的辅助车辆。例如，给定地点可能有3个需要辅助的车辆和一辆可用的辅助车辆。它可以首先辅助3个车辆中有乘客的一个车辆，从而基于乘客的存在赋予该车辆优于其他两个车辆的优先级。其他两个车辆的下一个优先级可以是具有<100％功率状态的车辆，其中所述车辆预计甚至缺乏足够的功率来到达再充电。如果两个车辆都具有足够的预计功率，则辅助车辆可能仅辅助两者中位置更方便的那个，或者两者中相对于所需功率具有最低预计功率(例如，102％对104％)的那个。

如果辅助车辆120不可用，则车辆100可以在217处尝试最大化功率并在219处规划到再充电点的路线。当车辆100在阈值(例如，130％)内时，车辆100还可以在207处使功率最大化，但是由于使功率最大化可以包括首先禁用如HVAC的东西，然后禁用非关键传感器、车载互联网热点等，因此用户可能更喜欢不启用最大化算法，除非功率处于亚阈值状态(在该示例中<110％)。

车辆100还在行驶到再充电点期间连续地监测自身，因此如果130％的需求变为<剩余需求的110％，则可以采取下一步骤(例如，联系服务器、最大化功率等)。类似地，如果105％的需求下降到低于100％的需求(例如，车辆100在最大化功率模式下不再能够到达站点)，则过程可以在205处分支到不可到达。如果在209处车辆100已经在寻求辅助或可能的辅助，并且在211处辅助可用，则车辆100可以接收会合点并且将在213处规划与车辆120的交汇。在所有情况下，车辆100可以继续遵循路线规划并在231处连续地检查可达性，如果预计情况变为更糟糕的情况，则在205处分支到不可达。

如果在任何时间，基于当前功率与到达再充电点所需的预计功率(其可以适应最大功率模式，其中暂时禁用所有非必要系统)相比，所述再充电点看起来不可达，则车辆100可以在221处警告服务器。

服务器可以在223处以辅助的可用性作出响应，这可以涉及向车辆100通知车辆120可以辅助并且应在被包括为会合点的位置处相会。车辆100在229处规划到该点的路线并遵循规划215。如果在231处会合点变为不可达，则所述过程可以重复，从而将会合点重置为更靠近车辆100，直到并包括简单地使车辆100停下、停车并等待，如果这是保存足够功率以到达再充电点的唯一方式，甚至在有来自车辆120的辅助的情况下。

如果在223处没有可用的辅助车辆120，则车辆100可以排队以获得辅助(可以在服务器处发生的过程)，然后在227处停车并等待或行驶合理的距离到达可能的会合点。在后一示例中，例如，如果车辆100位于距下一个出口10英里但距前一个出口100英里的高速公路上，则很可能会在下一个出口处发生会合，且因此不存在极端功率状态，合理的是，即使不知道特定的辅助，也使车辆100行驶10英里中的大部分或全部到达下一个出口。然后可以在下一个出口处发生停车和等待，但是如果辅助车辆最终被揭示为紧邻该出口，则这会产生效率问题。

图3示出了说明性警报处置过程。这是服务器侧过程，其中云140或一个或多个后端服务器试图找到辅助车辆120以辅助滞留或潜在滞留车辆100。服务器在301处接收警报，并且在303处确定在请求车辆100附近是否存在可用车辆120。这可以包括例如确定车辆100中剩余的功率(所报告的)以及在当前行驶状况下以及在各不相同的传感器和系统关闭状况下行驶到各种附近再充电点所需的功率。车辆100还可以通知服务器它被占用(这可以影响对再充电点的选择)和/或车辆100可以识别已经由车辆100识别的优选充电点。

在303处，服务器可以确定辅助车辆120的功率需求和/或系统需求，并且确定任何此类车辆120是否在可到达的接近度内并且将是可用的，这可以包括确定其在行驶到任何会合点之后是否仍然具有足够的功率。

如果不存在此类车辆120，则服务器可以忽略一个或多个车辆法令(例如，优选的再充电)并确定是否存在至少导致即时辅助的替代性辅助解决方案。如果找不到解决方案，则服务器将在305处报告当前没有可用的辅助。然后，服务器可以在307处使待处理的车辆请求排队。

如果在303处存在揭示可能的辅助场景的一个或多个解决方案，则服务器可以在309处联系任何识别的车辆120。因为车辆120可能并不总是能够使服务器了解即时状况(例如，功率或本地交通)，所以车辆120可以被给予拒绝请求的机会，即使服务器可能应该负责为车辆100、120制定路线。

309处的请求也可以是有条件的，例如，它可以包括用于接受的参数，所述参数包括例如服务该请求的预计时间(给定只有车辆120可能知道的当前状况)、请求的关键性(例如，如果车辆100可能到达站点并且重新制定车辆120的路线可能将车辆120置于不稳定的功率状态)等。因此，车辆120可以确认所有条件都得到满足并且然后确认请求，从而在不满足任何条件的情况下拒绝所述请求。

如果车辆120全部拒绝辅助请求，则服务器在305处再次报告没有车辆120可用。否则，它可以在313处确定合理的交汇/会合点。这可以适应车辆100的当前位置以及任何其他约束，诸如车辆100是否应或甚至能够保持行驶(“能够”意旨在甚至有限功能的AV行驶下也会耗尽太多功率)，每个车辆的哪些行驶时间决定了任一车辆等待时间最短的点，车辆120是否需要在经过车辆100的路线上的某个点处与车辆100相会以便具有足够的功率来辅助车辆100等。

可以在313处确定主要和/或辅助会合点并在315处进行分配。例如，主要点可以优化大多数变量，但是辅助点可以解决车辆100或120的状态的可能变化。这些辅助点可能需要重新计算，但是如果一个辅助点被触发并且车辆100和120两者都确认它们可以使用辅助点，则不需要重新计算并且两者都可以继续进行。例如，一个辅助点可以是车辆100在最大功率模式下是否降低到低于可达性阈值，例如，如果当前100+％的所需功率低于100％，这意味着如果车辆要到达再充电，AV在没有辅助的情况下行驶是不可能的。这并不意味着车辆必须停止，辅助可能导致10％的功率增益(由于过程卸载)，因此车辆100大概可以在等待之前行驶一定的距离(例如，下降到95％)。如果截止值为95％，则在任何情况下都可以使车辆100非常接近原始会合，因为该数字是针对剩余距离确定的，且因此100％的值随着车辆100保持行驶而减小。也就是说，这并不意味着车辆必须仅行驶剩余距离的5％，而是在行驶该距离的5％之后，例如，车辆100确定是否仍然存在所需功率的95％来行驶该距离的剩余95％。

在另一个示例中，辅助车辆120本身可能正在经历低功率状态，并且可能需要另一车辆100在会合之前行驶得更远。发送辅助状态和条件不是必需的，但是如果车辆100和120具有在某些情况下触发的辅助条件并且调度器可以从一个车辆接收条件被触发的消息并与另一车辆确认可以在没有来自后端的进一步辅助(重新制定路线或重新确定)的情况下到达对应于该条件的辅助点，则这可以节省时间和未来这两个车辆之间的协商。

图4示出了说明性辅助队列处置过程。如果没有辅助车辆120可用于给定请求，则可以指示请求车辆100停车并等待，直到可以为辅助车辆120制定路线。请求车辆100是否继续移动可能取决于其自身的功率，但是在那个时刻，它可能没有辅助保证，因此它可以自行确定适当的下一行动方案。

同时，诸如当车辆120识别为已经完成任务时，服务器可以连续地或周期性地检查帮助请求的队列。队列可以以任何方式组织，但是一个示例将包括使每个队列元素具有排队时间(当其排队时)和位置(其当前所在的位置)，且然后基于此信息和/或其他信息的某种组合，可以将新释放的车辆120与排队的车辆相关联。

服务器还可以检查来自多个车辆100的请求队列是否具有共同的路段(或进行可能的调整)。如果是，则单个辅助车辆120可能能够针对共同的路段一起引导这些车辆100。

所述确定还可以包括例如在403处的距当前排队车辆100位置最近的电源位置(其可以与车辆位置一起被跟踪)和/或基于排队车辆在各种关闭和辅助条件(如前所述)下的当前功率状态的排队车辆的续航里程405。然后，对于每个排队车辆或选定的排队车辆，所述过程可以分支到303。

例如，新释放的(任务完成的)车辆120可以识别为在3个排队车辆100的20英里内，具有足够的功率以基于它到达它们中的一个所花费的功率最大地(最大辅助)将那些车辆100引导额外的10-15英里。可以检查3个车辆100的特性(例如但不限于存在乘员、队列持续时间、剩余功率、与车辆120的接近度等)。此外，如果车辆120可以最容易地辅助一个车辆，然后以某种合理的顺序辅助下一个车辆，则可以使用这些车辆100的相对位置，假设不能找到其他辅助车辆120。其他因素也可以被认为是合理的，使得在资源允许的情况下，请求辅助的车辆100在没有即时辅助的情况下仍然可以以合理及时的方式得到帮助。

尽管上文描述了示例性实施例，但是这些实施例并不意图描述权利要求所涵盖的所有可能形式。在说明书中使用的词语是描述词语而非限制性词语，并且应理解，在不脱离本公开的精神和范围的情况下，可做出各种改变。如前所述，各种实施例的特征可被组合来形成可能未明确描述或示出的本发明的另外的实施例。尽管各种实施例就一个或多个期望的特性而言可能已经被描述为提供优点或优于其他实施例或现有技术实现方式，但是本领域普通技术人员应认识到，可折衷一个或多个特征或特性来实现期望的整体系统属性，这取决于具体应用和实现方式。这些属性可包括但不限于成本、强度、耐久性、生命周期成本、可销售性、外观、包装、大小、可维护性、重量、可制造性、易组装性等。因此，就一个或多个特性而言被描述为不如其他实施例或现有技术实现方式期望的实施例处在本公开的范围内，并且对于特定应用来说可能是期望的。

根据本发明，提供了一种系统，所述系统具有：处理器，所述处理器被配置为：从所述第一自主车辆接收对行驶辅助的请求，所述请求指示所述第一自主车辆的低功率状态；确定供所述第一自主车辆使用的再充电点；在所述第一自主车辆可实行的一个或多个功率保存状态下确定所述第一自主车辆到达所述再充电点所需的功率；对于所述功率保存状态中的至少一个，确定可以以针对所述至少一个功率保存状态预定义的方式向所述第一自主车辆提供辅助并且允许所述第一自主车辆到达所述再充电点的第二自主车辆；以及指示所述第二自主车辆在确定的会合点处与所述第一自主车辆会合。

根据一个实施例，所述再充电点被识别为所述请求的部分。

根据一个实施例，至少部分地基于所述第一自主车辆是否被占用来确定所述再充电点。

根据一个实施例，所述功率保存状态包括禁用对自主驾驶非关键的传感器，从而允许继续自主驾驶，并且其中所述方式包括所述第二自主车辆提供来自与所禁用的传感器相当的传感器的数据。

根据一个实施例，所述功率保存状态包括禁用对自主驾驶非关键的传感器，从而在没有来自所述第二自主车辆的辅助的情况下防止自主驾驶，并且其中所述方式包括所述第二自主车辆提供来自与所禁用的传感器相当的传感器的数据。

根据一个实施例，所述功率保存状态包括与所述第二自主车辆共享计算周期，至少包括使所述第二自主车辆执行预计在计算期间消耗高于阈值的功率的一个或多个计算密集型任务。

根据一个实施例，对可提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的能力。

根据一个实施例，对可提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的位置。

根据一个实施例，对可提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的功率状态。

根据一个实施例，所述处理器被进一步配置为响应于从所述第二自主车辆接收到所述第二自主车辆可提供辅助的确认而指示所述第一自主车辆在确定的会合点处与所述第二自主车辆会合。

根据本发明，提供了一种第一自主车辆，所述第一自主车辆具有：处理器，所述处理器被配置为：确定当前功率水平小于到达再充电点所需的预计功率水平；从远程服务器请求辅助；响应于所述请求，接收会合指令，所述会合指令包括用于第二自主车辆的会合点；执行到所述会合点的行驶；当所述第一自主车辆和所述第二自主车辆两者在彼此的可通信范围内时，直接与所述第二自主车辆通信；将计算任务或感测任务中的至少一者卸载到所述第二自主车辆，其中所述第二自主车辆提供对所卸载任务的响应，从而允许所述第一自主车辆利用所述响应继续自主行驶；以及继续：将计算任务或感测任务中的至少一者卸载到所述第二自主车辆；接收对所卸载任务的响应；以及利用所述响应自主地行驶，直到所述第一自主车辆到达所述再充电点或靠近所述再充电点的其中所述第一自主车辆预计所述当前功率水平大于到达所述再充电点所需的预计功率水平的位置中的至少一者。

根据一个实施例，所述预计功率水平包括在对自主驾驶非关键的传感器被禁用的情况下的行驶，从而允许继续自主驾驶。

根据一个实施例，除了预计使所述车辆到达所述再充电点所需的实际功率量之外，所述预计功率水平还包括预定义的缓冲量。

根据一个实施例，所述会合点包括所述第一自主车辆的所述当前位置。

根据一个实施例，所述处理器被配置为响应于来自所述服务器的当前没有第二自主车辆可用于辅助所述第一车辆的通知而使所述第一车辆停车并等待。

根据本发明，一种方法包括：在第一自主车辆上确定所述第一自主车辆具有预计通过在一个或多个预定义系统被禁用的情况下行驶而到达再充电点所需的、仍然允许自主行驶的剩余功率量；禁用所述预定义系统并朝向所述再充电点行进；在所述禁用之后，确定所述第一自主车辆不再具有预计到达所述充电点所需的、从所述第一自主车辆的当前位置重新预计的剩余功率量；响应于所述第一自主车辆不再具有所述剩余功率量，与服务器通信并请求辅助；响应于所述请求，接收包括用于与第二自主车辆相会的会合位置的会合指令；以及响应于所述第一自主车辆和所述第二自主车辆在通信范围内，在所述第一自主车辆处利用所述第二自主车辆的能力，从而允许所述第一车辆经由所述利用到达所述再充电点。

在本发明的一个方面，所述能力包括感测能力，并且其中所述利用包括从所述第一自主车辆向所述第二自主车辆发送至少一个传感器数据请求并在所述第一车辆处接收响应，从而允许所述第一车辆基于所述响应继续自主驾驶。

在本发明的一个方面，所述能力包括计算能力，并且其中所述利用包括从所述第一自主车辆向所述第二自主车辆发送至少一个计算请求并在所述第一车辆处接收响应，从而允许所述第一车辆基于所述响应继续自主驾驶。

在本发明的一个方面，所述能力包括行驶能力，并且其中所述利用包括使用所述第一自主车辆的能够跟踪所述第二自主车辆的移动的感测能力来跟随所述第二自主车辆。

在本发明的一个方面，所述能力包括行驶能力，并且其中所述利用包括使用所述第一自主车辆的与所述第二自主车辆通信并基于接收到以下各项中的至少一者而跟随所述第二自主车辆的通信能力来跟随所述第二自主车辆：所述第二自主车辆的预期动作或从所述第二自主车辆接收的用于所述第一自主车辆的驾驶指令。

Claims (15)

1.一种系统，其包括：

处理器，所述处理器被配置为：

从第一自主车辆接收行驶辅助请求，所述请求指示所述第一自主车辆的低功率状态；

确定供所述第一自主车辆使用的再充电点；

在所述第一自主车辆能够实行的一个或多个功率保存状态下，确定所述第一自主车辆到达所述再充电点所需的功率；

对于所述功率保存状态中的至少一个，确定能够以针对所述至少一个功率保存状态预定义的方式向所述第一自主车辆提供辅助并且允许所述第一自主车辆到达所述再充电点的第二自主车辆；以及

指示所述第二自主车辆在确定的会合点处与所述第一自主车辆会合。

2.如权利要求1所述的系统，其中所述再充电点被识别为所述请求的部分。

3.如权利要求1所述的系统，其中至少部分地基于所述第一自主车辆是否被占用来确定所述再充电点。

4.如权利要求1所述的系统，其中所述功率保存状态包括禁用对自主驾驶非关键的传感器，从而允许继续自主驾驶，并且其中所述方式包括所述第二自主车辆提供来自与所禁用的传感器相当的传感器的数据。

5.如权利要求1所述的系统，其中所述功率保存状态包括禁用对自主驾驶非关键的传感器，从而在没有来自所述第二自主车辆的辅助的情况下防止自主驾驶，并且其中所述方式包括所述第二自主车辆提供来自与所禁用的传感器相当的传感器的数据。

6.如权利要求1所述的系统，其中所述功率保存状态包括与所述第二自主车辆共享计算周期，至少包括使所述第二自主车辆执行预计在计算期间消耗高于阈值的功率的一个或多个计算密集型任务。

7.如权利要求1所述的系统，其中对能够提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的能力。

8.如权利要求1所述的系统，其中对能够提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的位置。

9.如权利要求1所述的系统，其中对能够提供辅助的所述第二自主车辆的所述确定至少基于所述第二自主车辆的功率状态。

10.如权利要求1所述的系统，其中所述处理器被进一步配置为响应于从所述第二自主车辆接收到所述第二自主车辆能够提供辅助的确认而指示所述第一自主车辆在所确定的会合点处与所述第二自主车辆会合。

11.一种第一自主车辆，其包括：

处理器，所述处理器被配置为：

确定当前功率水平小于到达再充电点所需的预计功率水平；

从远程服务器请求辅助；

响应于所述请求，接收会合指令，所述会合指令包括用于第二自主车辆的会合点；

执行到所述会合点的行驶；

当所述第一自主车辆和所述第二自主车辆两者在彼此的可通信范围内时，直接与所述第二自主车辆通信；

将计算任务或感测任务中的至少一者卸载到所述第二自主车辆，其中所述第二自主车辆提供对所卸载任务的响应，从而允许所述第一自主车辆利用所述响应继续自主行驶；以及

继续：

将计算任务或感测任务中的至少一者卸载到所述第二自主车辆；

接收对所卸载任务的响应；以及

利用所述响应自主地行驶，直到所述第一自主车辆到达所述再充电点或接近所述再充电点的其中所述第一自主车辆预计所述当前功率水平大于到达所述再充电点所需的所述预计功率水平的位置中的至少一者。

12.如权利要求11所述的车辆，其中所述预计功率水平包括在对自主驾驶非关键的传感器被禁用的情况下的行驶，从而允许继续自主驾驶。

13.如权利要求11所述的车辆，其中除了预计使所述车辆到达所述再充电点所需的实际功率量之外，所述预计功率水平还包括预定义的缓冲量。

14.如权利要求11所述的车辆，其中所述会合点包括所述第一自主车辆的当前位置。

15.如权利要求11所述的车辆，其中所述处理器被配置为响应于来自所述服务器的当前没有第二自主车辆可用于辅助所述第一车辆的通知而使所述第一车辆停车并等待。

Images