自我维护的自动驾驶车辆程序的制作方法

自我维护的自动驾驶车辆程序
1.相关申请的交叉引用
2.本技术要求于2019年5月13日提交的、标题为“自我维护的自动驾驶车辆程序(self
‑
maintaining autonomous vehicle procedure)”的第16/410,911号美国申请的优先权的权益，该美国申请的全部内容通过引用的方式并入本文。
技术领域
3.本发明的主题总体上涉及合乘车辆领域，更具体地，涉及用于自动驾驶合乘车辆的自我维护的系统和方法。


背景技术：

4.自动驾驶车辆是一种无需人类驾驶员即可导航的机动车辆。示例性自动驾驶车辆包括多个传感器系统，诸如但不限于相机传感器系统、激光雷达传感器系统、雷达传感器系统等，其中，自动驾驶车辆基于由传感器系统输出的传感器信号进行操作。具体地，传感器信号被提供给与多个传感器系统通信的内部计算系统，其中，处理器基于传感器信号执行指令以控制自动驾驶车辆的机械系统，诸如车辆推进系统、制动系统或转向系统。
5.目前，人类操作员需要不断监控车队，并在认为需要维修时将自动驾驶车辆驾驶到修理厂。这需要对照可接受的值范围检查定量和定性值。一旦认为有必要进行维修，人类操作员必须将自动驾驶车辆引导至车库。由于该操作依赖于人为干预，因此这可能是一个耗时且容易出错的过程，特别是当车队的规模显著增加或运营区域明显扩大时。
附图说明
6.通过参考附图中所示的具体实施方式，本技术的上述和其他优点和特征将变得显而易见。本领域普通技术人员将理解，这些附图仅示出了本技术的一些示例，并且不会将本技术的范围限制于这些示例。此外，本领域技术人员将理解通过使用附图以附加的特性和细节描述和解释的本技术的原理，其中：
7.图1示出了根据一些实施例的自动驾驶车辆和网络环境的示例性示意图：
8.图2示出了根据一些实施例的可以实现自动驾驶车辆的自我维护的自动驾驶车辆和网络环境的示例性示意图；
9.图3a示出了根据一些实施例的自动驾驶车辆的自我维护的流程图表示；
10.图3b示出了根据一些实施例的检测到的问题的危急度确定的流程图表示；以及
11.图4示出了用于实现本技术的某些方面的系统的示例。
具体实施方式
12.下面详细讨论本技术的各种示例。虽然讨论了具体的实现方式，但应当理解，这只是为了说明的目的。相关领域的技术人员将认识到，在不脱离本技术的精神和范围的情况下可以使用其他组件和配置。在一些情况下，众所周知的结构和设备以框图形式示出，以便
于描述一个或多个方面。此外，应当理解，被描述为由某些系统组件执行的功能可由比所示更多或更少的组件来执行。
13.所公开的技术解决了本领域对自动驾驶车辆的自我维护能力的需求。目前，需要人为干预来持续监控车队。当监控车队的人员认为车队需要维修时，他们需要引导另一服务，以将车辆驾驶到车库中。这意味着需要人为干预来对照可接受的值范围检查定量和定性值，然后再次需要人为干预将车辆送到车库进行维修。这需要持续关注并且会引入错误或车辆问题升级的可能性，因为只有主要问题可能被人类操作员标记为需要服务或维修。
14.为了解决上述问题，公开了用于使自动驾驶车辆可以自动且动态地监控和维护自身的系统和方法，这消除了对人工监控和干预的需要。例如，自动驾驶车辆可以分析由其传感器中的一个或多个传感器捕获的诊断数据。基于对诊断数据的分析，自动驾驶车辆可以确定自身需要维护，并且基于所述确定，将对诊断数据的分析发送到路由服务。自动驾驶车辆可以接着接收来自路由服务的指令，以根据维护动作动态地为自动驾驶车辆规定路线。
15.图1示出了包括与远程计算系统150通信的自动驾驶车辆102的环境100。在一些实施例中，自动驾驶车辆102可以基于自动驾驶车辆102的传感器系统104
‑
106输出的传感器信号在没有人类驾驶员的情况下在道路上导航。自动驾驶车辆102包括多个传感器系统104
‑
106(第一传感器系统104至第n传感器系统106)。传感器系统104
‑
106具有不同类型并且围绕自动驾驶车辆102布置。例如，第一传感器系统104可以是相机传感器系统并且第n传感器系统106可以是激光雷达传感器系统。其他示例性传感器系统包括雷达传感器系统、全球定位系统(gps)传感器系统、惯性测量单元(imu)、红外传感器系统、激光传感器系统、声纳传感器系统等。
16.自动驾驶车辆102还包括用于实现自动驾驶车辆102的适当运动的若干机械系统。例如，机械系统可以包括但不限于车辆推进系统130、制动系统132和转向系统134。车辆推进系统130可包括电动机、内燃机或两者。制动系统132可以包括发动机制动器、制动块、致动器和/或被配置为帮助使自动驾驶车辆102减速的任何其他合适的部件。转向系统134包括被配置为在导航期间控制自动驾驶车辆102的移动方向的合适部件。
17.自动驾驶车辆102还包括安全系统136，该安全系统136可以包括各种灯和信号指示器、停车制动器、安全气囊等。自动驾驶车辆102还包括舱室系统138，该舱室系统138可以包括舱室温度控制系统、舱内娱乐系统等。
18.自动驾驶车辆102另外包括与传感器系统104
‑
106和系统130、132、134、136和138通信的自动驾驶车辆(av)av内部计算系统110。av内部计算系统110包括至少一个处理器和至少一个具有由处理器执行的计算机可执行指令的存储器。计算机可执行指令可以构成一个或多个服务，这些服务负责控制自动驾驶车辆102、与远程计算系统150通信、接收来自乘客或人类副驾驶的输入、记录关于传感器系统104
‑
106和人类副驾驶收集的数据的度量等。
19.av内部计算系统110可以包括控制服务112，该控制服务112被配置为控制车辆推进系统130、制动系统132、转向系统134、安全系统136和舱室系统138的操作。控制服务112从传感器系统104
‑
106接收传感器信号以及与av内部计算系统110的其他服务通信，以实现自动驾驶车辆102的操作。在一些实施例中，控制服务112可以与自动驾驶车辆102的一个或多个其他系统协同执行操作。
20.av内部计算系统110还可以包括约束服务114以促进自动驾驶车辆102的安全推
进。约束服务114包括用于在自动驾驶车辆102运行时根据基于规则的约束激活约束的指令。例如，约束可以是根据被配置为避免与其他对象占用相同空间、遵守交通法规、避开避让区域等的协议激活的对导航的限制。在一些实施例中，约束服务可以是控制服务112的一部分。
21.av内部计算系统110还可以包括通信服务116。通信服务116可以包括用于从/向远程计算系统150接收和发送信号的软件和硬件元件。通信服务116被配置为通过网络无线传输信息，例如，通过提供个人蜂窝(长期演进(lte)、3g、5g等)通信的天线阵列。
22.在一些实施例中，av内部计算系统110的一个或多个服务被配置为出于以下原因向远程计算系统150发送和接收通信：报告用于训练和评估机器学习算法的数据、请求来自远程计算系统150的帮助或通过远程计算系统150请求来自人工操作员的帮助、软件服务更新、合乘上车和下车指令等。
23.av内部计算系统110还可以包括等待时间服务118。等待时间服务118可以利用与远程计算系统150的通信的时间戳来确定是否已经及时从远程计算系统150接收到有用的通信。例如，当av内部计算系统110的服务请求来自远程计算系统150的关于时间敏感过程的反馈时，等待时间服务118可以确定是否及时从远程计算系统150接收到响应，因为信息很快就会变得陈旧而无法操作。当等待时间服务118确定未在阈值内接收到响应时，等待时间服务118可以使自动驾驶车辆102的其他系统或乘客能够做出必要的决定或提供所需的反馈。
24.av内部计算系统110还可以包括用户接口服务120，该用户接口服务120可以与舱室系统138通信以便向人类副驾驶或人类乘客提供信息或接收信息。在一些实施例中，可能需要人类副驾驶或人类乘客评估和控制来自约束服务114的约束，或者人类副驾驶或人类乘客可能希望向自动驾驶车辆102提供关于目的地、请求路线或其他请求操作的指令。
25.如上所述，远程计算系统150被配置为从自动驾驶车辆102发送/接收关于以下各项的信号：报告用于训练和评估机器学习算法的数据、请求来自远程计算系统150的帮助或通过远程计算系统150请求来自人工操作员的帮助、软件服务更新、合乘上车和下车指令等。
26.远程计算系统150包括分析服务152，该分析服务152被配置为从自动驾驶车辆102接收数据并分析数据，以训练或评估用于操作自动驾驶车辆102的机器学习算法。分析服务152还可以执行关于与自动驾驶车辆102报告的一个或多个错误或约束相关联的数据的分析。
27.远程计算系统150还可以包括用户接口服务154，该用户接口服务154被配置为向远程计算系统150的操作员呈现从自动驾驶车辆102报告的度量、视频、图片、声音。用户接口服务154还可以从操作员接收输入指令，该输入指令可以发送到自动驾驶车辆102。
28.远程计算系统150还可以包括用于发送关于操作自动驾驶车辆102的指令的指令服务156。例如，响应于分析服务152或用户接口服务154的输出，指令服务156可以向自动驾驶车辆102的一个或多个服务或自动驾驶车辆102的副驾驶或乘客提供指令。
29.远程计算系统150还可以包括合乘服务158，该合乘服务158被配置为与在(潜在)乘客计算设备上运行的合乘应用程序170交互。合乘服务158可以从乘客合乘应用程序170接收要上车或下车的请求，并且可以为行程调度自动驾驶车辆102。合乘服务158还可以充
当合乘应用程序170与自动驾驶车辆102之间的中介，其中，乘客可以向自动驾驶车辆102提供指令以绕过障碍物、改变路线、按喇叭等。
30.图2示出了根据一些实施例的能够实现自动驾驶车辆的自我维护的自动驾驶车辆和网络环境的示例性示意图。系统200可以维护完全自动驾驶的车队，而无需人为干预和/或监控。按照惯例，当前的车辆维护系统需要人为干预——车辆运行诊断程序，如果有监控诊断程序的人员标记的问题，则他们必须联系维护设施(诸如修理厂)的员工，以查看修理厂是否可以对车辆进行维修。这引入了人为错误和低效率，随着时间的推移，这可能会影响可能需要维护的自动驾驶车辆车队。系统200利用自动驾驶车辆202(诸如车队226内的自动驾驶车辆202)的诊断能力的增加来消除对人为干预和/或监控的需要。诊断功能可以集成到调度算法中，该调度算法可以基于一个或多个问题的严重程度动态和/或自动地将自动驾驶车辆送到所需的设施。诊断能力可以应用于预防性维护(例如，知道自动驾驶车辆202需要在50英里内换油，并且基于此，在到达50英里之前将该自动驾驶车辆202送到最近的修理厂)，和/或可以应用于诊断更危急的问题(例如，其中一个激光雷达传感器损坏或出现故障，需要立即送到修理厂修理或更换激光雷达传感器)。
31.自动驾驶车辆202可以通过分析由自动驾驶车辆202的一个或多个传感器204捕获的诊断数据来动态地自我维护。自动驾驶车辆202可以包括多个传感器系统内的多个传感器204，包括但不限于相机传感器系统、激光雷达传感器系统、雷达传感器系统等。多个传感器系统可以彼此独立地或可互操作地工作，以便导航和/或捕获环境和操作条件。例如，传感器204可以检测或捕获将使自动驾驶车辆202能够自我监控的诊断数据。
32.每个传感器204可以将诊断数据存储在自动驾驶车辆202上的数据存储器208内。在一些实施例中，自动驾驶车辆202的内部分析服务210可以基于数据存储器208内的诊断数据生成描述自动驾驶车辆202的行为、操作或环境的一个或多个模型214。例如，内部分析服务210可以基于模型214确定自动驾驶车辆202的偏航、加速度、方向、位置和周围环境(例如，建筑物、人、障碍物、光照水平、温度、声音等)。
33.基于检测到操作问题的对诊断数据的分析，自动驾驶车辆202可以确定它需要维护。例如，诊断服务206可以诊断诊断数据内的问题并确定自动驾驶车辆202是否需要维护以及问题的危急程度。例如，诊断服务206可以通过将模型214应用于诊断数据来检测操作问题。例如，诊断服务206可以对照软件版本、有效校准值等进行检查。例如，如果自动驾驶车辆202的偏航超出可接受的值或值范围，则诊断服务206可以将诊断数据与模型214进行比较，以诊断具体问题。在一些实施例中，对诊断数据的大部分分析是(通过诊断服务206)在自动驾驶车辆202上完成的，以便提供对问题的即时响应(或尽管失去与远程网络的连接也可以提供响应)。在其他实施例中，诊断数据的分析可以在后端远程服务器上进行。
34.基于具体问题的确定，对诊断数据的分析可以发送到后端远程网络，诸如网络232，该后端远程网络可以根据确定经由路由服务224路由自动驾驶车辆202。例如，路由服务224可以向维护服务222发送问题以确定适当的响应，诸如将自动驾驶车辆202路由到特定修理厂、通知和设置维护、接载滞留的乘客等。
35.在一些实施例中，诊断服务206可以额外地接收来自自动驾驶车辆202内的乘客的输入，以提供反馈。例如，用户接口服务230可以在计算机接口(诸如自动驾驶车辆202内的平板电脑)处或通过乘客的移动设备上的合乘应用程序234接收来自乘客的输入。乘客可以
在用户接口服务230处指示自动驾驶车辆202的操作存在问题，如快速停车、急转弯等。在一些情况下，乘客可以通过用户接口服务230手动控制自动驾驶车辆，该用户接口服务230可以与控制服务212通信以相应地操作自动驾驶车辆202。
36.在一些实施例中，模型214可以由整个车队226收集的诊断数据不断补充和更新。诊断数据可以传输到网络232，该网络232可以远程编译和平均从车队226内的所有车辆接收的诊断数据以远程生成模型214。例如，分析服务216可以分析来自车队226的诊断数据，以生成详细、准确的模型214，然后可以在自动驾驶车辆202下一次更新或连接到网络232时将详细、准确的模型214应用于模型214。因此，随着车队226内的每个自动驾驶车辆202随着时间的推移运行，模型214可以被持续训练。在一些实施例中，网络232上的模型214可以通过与合乘应用程序234通信的合乘服务228由乘客输入来补充。
37.基于对来自整个车队226的诊断数据的分析来确定自动驾驶车辆202需要维护可以实现对自动驾驶车辆202的细微的或新出现的操作问题的检测。例如，对于可能记录问题的每个传感器204，可以将来自该传感器204的诊断数据与具有该传感器的其他汽车的顺利行程(或不顺利的行程)进行比较。这可以使模型214能够不断学习和提高危急度级别和其他见解，诸如最佳电量水平、自动驾驶车辆202的组件的最佳状态，以获得最佳里程或乘客体验等。
38.诊断服务206还可以将模型214标记的问题归类为不同的危急度级别。例如，可以基于模型214(并且在一些实施例中，基于根据来自车队226的诊断数据连续更新的模型214)确定自动驾驶车辆的操作问题的危急度级别。例如，自动驾驶车辆202的操作问题可以基于诊断数据在值范围内或超过值范围(这表明自动驾驶车辆202处于紧急危险的故障或误操作)而归类为高危急度级别。基于处于高危急度级别内的操作问题，自动驾驶车辆202可以接收来自路由服务224的指令以使自动驾驶车辆停止。
39.此外，在网络232处，可以存储和分析通常不会被认为对自动驾驶车辆202的操作紧急或危急的附加细节(如果在本地完成，这将比预计花费更多的处理时间)。例如，自动驾驶车辆202可以报告小的维护问题，如低胎压、低油位和其他长期存在的问题，这些问题从长远来看会导致紧急问题。诊断数据内的粒度细节可以从数据存储器208和/或内部分析服务210中取出并在后端存储/分析(诸如经由网络232上的分析服务216并用于修改/更新模型214)。网络232可以确定粒度细节对于调度的重要程度。例如，可以基于某些诊断数据分析服务216接收到的值来标记低胎压。路由服务224可以继续当前行程，并且不需要取消乘客的乘车。但是如果分析服务216确定问题足够严重，则一旦行程结束，可以向控制服务212发送路由服务224，以将自动驾驶车辆202路由到下一个设施以修复胎压。
40.在一些实施例中，一旦基于确定自动驾驶车辆202需要维护而将对诊断数据的分析发送到路由服务224，自动驾驶车辆202可以从路由服务224接收指令，以根据维护服务222指定的维护动作动态地为自动驾驶车辆202规定路线。例如，维护服务222可以与一个或多个维护设施218通信，以动态和自动地为自动驾驶车辆202安排维护。维护服务222还可以与备用服务220通信以派出备用车辆接载滞留的乘客(例如，对于遇到紧急、危险问题的自动驾驶车辆202)。
41.例如，维护服务222可以考虑维护设施218处的当前负载。例如，可以知道给定设施的充电端口总数，以及实际可用与已使用的充电端口数量。
42.维护服务222还可以考虑具有特定专业、特定技术人员和/或特定部件的不同维护设施218。例如，一些维护设施218可能适合于维护，而其他维护设施则最适合为自动驾驶车辆202充电。因此，当自动驾驶车辆202需要自动将其自身路由到维护设施218时，可以基于参数来选择维护设施218，诸如将自动驾驶车辆202引导到具有合适的技术人员和合适的部件的修理厂，以服务自动驾驶车辆202的特定需求。例如，某些维护设施218可以具有专门从事激光雷达传感器系统的技术人员。其他维护设施218可以具有专门从事相机传感器系统、雷达传感器系统、全球定位系统(gps)传感器系统、惯性测量单元(imu)、红外传感器系统、激光传感器系统、声纳传感器系统和/或其他传感器系统。其他维护设施218可以具有专门从事更通用车辆系统的技术人员，诸如自动驾驶车辆202的推进系统、制动系统、转向系统、安全系统、舱室系统(例如，温度控制、照明等)。此外，即使在用于为自动驾驶车辆202充电的维护设施218内，某些维护设施218内的一定数量的充电站也可能已经插入了汽车(例如，提供有限数量的开放式充电站可以为自动驾驶车辆202提供服务)。在那种情况下，可以考虑跳过该维护设施218，转向另一可用设施。
43.在一些实施例中，维护服务222可以根据多个优先级对某些动作进行加权。例如，虽然一些维护设施218可能最适合特定的维护动作，但维护设施218可能已满负荷而不能服务自动驾驶车辆202，因此，维护服务222可以与路由服务224通信以将自动驾驶车辆202路由到不专门从事特定的维护动作或者离自动驾驶车辆202当前位置更远的另一个可用维护设施。
44.在一些实施例中，自动驾驶车辆202可以基于其优先级来排队。其优先级可能与问题的危急度级别有关。例如，队列可以将车队226中具有高危急度问题并且因此需要直接前往维护设施218的自动驾驶车辆的放在队列的最前面。车队226中具有低危急度问题的自动驾驶车辆可以被推到队列中靠后的位置，以便在有额外维护设施可用时将它们调度到维护设施218。
45.图3a示出了根据一些实施例的自动驾驶车辆的自我维护的流程图表示。方法300可以在自动驾驶车辆启动时开始(步骤302)。在一些实施例中，启动可触发诊断检查(步骤304)，该诊断检查可在自动驾驶车辆接载乘客或开始在道路上运行之前检查自动驾驶车辆内的系统是否存在任何问题。额外地和/或替代地，在一些实施例中，诊断检查(步骤304)可以在连续地或周期性地运行，以便监控自动驾驶车辆随时间推移的运行情况。诊断检查可以确定是否检测到任何问题(步骤306)。如果未检测到问题，则可以在随后运行诊断检查以再次检查问题。
46.在一些实施例中，诊断检查可以周期性地(例如，每30秒)或连续地引发心跳事件以检查系统是否还活跃(例如，正常运行)。被检查的系统可以响应心跳事件，并且可以作为响应事件记录在日志中。响应事件可以包括用于分析对应系统所经历的任何问题的诊断数据。
47.在一些实施例中，在启动时，诊断检查可以发现特定固件版本已过时。例如，如果网络已更新到激光雷达系统固件的新版本，则来自诊断检查的响应事件可以检测到正在使用旧版本并且自动驾驶车辆上的激光雷达系统需要更新(以及一旦建立了与网络的链接，就可以启动更新)。或者来自诊断检查的响应事件可以确定激光雷达系统固件的版本1.5已损坏，因此需要进行补丁或更新来解决问题。诊断检查可以包含所需传感器、版本、自动驾
驶车辆组件等的需求列表。因此，诊断检查可以通过监控诊断数据并将其与需求列表进行比较来确定自动驾驶车辆是否具有健康的激光雷达系统、健康的雷达系统等。
48.在一些实施例中，诊断检查可以在不同层进行。例如，在第一层，如果诊断检查针对所有硬件零件运行特定一组的检查，并且这些检查失败，则不允许或禁止自动驾驶车辆启动。在这些检查通过后，即可以确定已满足驾驶自动驾驶车辆的所有基本要求，第二层可以检查运行中的自动驾驶车辆的所有组件。第二层可以定期或连续地向后端(例如网络)传输诊断信息和数据，并确认所有系统都在按需要运行(或系统正在经历一个或多个问题)。在一些实施例中，如果诊断检查的第一层失败，则系统可以标记车辆的可用性，提供关于自动驾驶车辆是否根本无法用于合乘，或者自动驾驶车辆是否可用于合乘但很快需要维护的信息。
49.在一些实施例中，系统可以确定任何检测到的问题的危急度(步骤308)。例如，可以在诊断检查期间从自动驾驶车辆上的传感器接收诊断数据，其中可以包括关于自动驾驶车辆的传感器或组件运行情况的信息。应用于诊断数据的模型可以分析诊断数据以确定自动驾驶车辆正在经历(或将要经历)哪些问题(例如，这些问题可以是预测性的或纯诊断性的)。
50.如果对诊断数据的分析确定了问题在高危急度级别内(步骤310)，则自动驾驶车辆可以安全停止(步骤312)。例如，诊断数据可以具有高于或低于指示危急问题和/或十分紧急问题的阈值的值。如果自动驾驶车辆内有乘客，系统可以呼叫最近的可用备用服务来接载这些乘客(步骤314)。在一些实施例中，系统可以向乘客传达(经由自动驾驶车辆内的平板电脑、合乘应用程序内的通知等)正在向他们提供替代交通工具。系统可以呼叫拖车来取回自动驾驶车辆并将其带到可以维修自动驾驶车辆的维护设施(例如，对自动驾驶车辆具有可用性的最近维护设施)(步骤316)。可以在维护系统中使用预填充指令和诊断信息创建工作订单(步骤318)。然后可以将自动驾驶车辆从合乘可用性中移除(步骤320)。
51.例如，工作订单可以包括针对具有特定专业、特定技术人员和/或特定零件的不同维护设施定制的预填充指令。例如，一些维护设施可能适合维护，而另一些则最适合为自动驾驶车辆充电。当自动驾驶车辆需要自动路由到维护设施时，可以选择维护设施，并且系统可以基于某些参数在维护设施的工作订单中预填充指令。这些参数可以将自动驾驶车辆引导至具有适当技术人员和适当零件的修理厂，以满足自动驾驶车辆的特定需求。例如，工作订单可能适用于具有专门研究激光雷达传感器系统的技术人员的维护设施，并且可以预填充与维修自动驾驶车辆的激光雷达系统相关的指令。其他维护设施218可以具有专门从事相机传感器系统、雷达传感器系统、全球定位系统(gps)传感器系统、惯性测量单元(imu)、红外传感器系统、激光传感器系统、声纳传感器系统和/或其他传感器系统，并且因此，工作订单可以预填充有用于维修自动驾驶车辆的对应系统的指令。还有一些维护设施可以具有专门从事更通用车辆系统的技术人员，诸如自动驾驶车辆的推进系统、制动系统、转向系统、安全系统、舱室系统(例如，温度控制、照明等)；工作订单可以对应地预填充有用于维修需要维修的自动驾驶车辆的特定系统的指令。一些维护设施用于为自动驾驶车辆充电，并且可以拥有一定数量的充电站，这些充电站可能已经插入了汽车(例如，可以为自动驾驶车辆提供服务的开放式充电站数量有限)。在这种情况下，可以通过在工作订单中预填充自动驾驶车辆充电指令来为具有可用性的维护设施生成工作订单。与维修问题相关的诊断信息
也可以包括在内。
52.如果对诊断数据的分析确定问题在中等危急度级别内(步骤322)，则自动驾驶车辆可以在被调度到适当的维护设施之前完成其当前操作。当诊断数据的值在指示问题虽然不危急或十分紧急但应该在特定时间段内修复的范围内时，可以确定中等危急度级别。例如，由于自动驾驶车辆中有多个相机，因此当一个相机熄灭时，在该相机被修好之前，自动驾驶车辆仍然可以安全运行。在这种情况下，自动驾驶车辆可以完成任何乘客的下车(步骤324)，并且在特定时间段过去之前，调度自动驾驶车辆自动驾驶到可以维修自动驾驶车辆所检测到的问题的维护设施(例如，自动驾驶车辆可用的最近的维护设施)(步骤326)。这可以经由通过预填充指令和/或包括诊断信息所创建的工作指令来完成，类似于所上面讨论。然后可以将自动驾驶车辆从合乘可用性中移除(步骤320)。
53.如果对诊断数据的分析确定问题在低危急度级别内(步骤328)，则可以使用预填充的指令和诊断信息为将来预定工作订单(例如，工作订单可以预定在维护设施可用且自动驾驶车辆没有被乘客预订的时间)(步骤330)。这可以经由通过预填充指令和/或包括诊断信息所创建的工作指令来完成，类似于所上面讨论。在预定的工作订单时间，可以调度自动驾驶车辆以自动驾驶到可以维修自动驾驶车辆所检测到的问题的维护设施(例如，自动驾驶车辆可用的最近的维护设施)(步骤332)。当诊断数据的值低于指示问题不危急或十分紧急的阈值时，可以确定低危急度级别。
54.在一些实施例中，自动驾驶车辆可以重新校准其传感器。例如，相机可能无法正确检测或观察环境。这可能指示它没有正确校准。根据当前校准值偏离预期范围的程度，系统可以确定校准问题的危急度。然后可以调度自动驾驶车辆驾驶到最近的地方以重新校准其传感器。在一些实施例中，自动驾驶车辆可以被路由到高速公路上的检查广告牌，这使得自动驾驶车辆内的传感器能够重新校准。
55.图3b示出了根据一些实施例的检测到的问题的危急度确定的流程图表示。自动驾驶车辆可以开始诊断(步骤350)，诸如通过诊断服务的连续或定期诊断检查，该诊断服务可以检测自动驾驶车辆经历的或预期的一个或多个问题。如果诊断服务确定在启动和移动自动驾驶车辆的物理组件时存在任何问题(步骤352)，则将危急度级别归类为高(步骤354)。如果诊断服务确定传感器校准值超出后端(例如，远程网络)中的由服务器确定的可接受范围(步骤356)，则危急度级别也被归类为高(步骤354)。
56.然而，如果诊断服务未检测到上述情况，但检测到自动驾驶车辆内的硬件产生非危急警告(步骤358)，则危急度级别被归类为中等(步骤360)。
57.如果不是，并且诊断服务或远程后端服务器指示自动驾驶车辆应进行预防性维护(步骤362)，则将危急度级别被归类为低(步骤364)。在一些实施例中，是否需要预防性维护可以基于驾驶历史、传感器数据和/或整体车队性能和分析。如果没有检测到问题(步骤366)，则诊断可以结束或推迟到后续时间。
58.如本文所述，本技术的一方面是收集和使用可从各种来源获得的数据以提高质量和体验。本发明预期在某些情况下，该收集的数据可包括个人信息。本发明预期涉及此类个人信息的实体尊重并重视隐私政策和实践。
59.图4示出了计算系统400的示例，该计算系统400可以是例如构成内部计算系统110、远程计算系统150、执行合乘应用程序170的(潜在)乘客设备或其任何组件，其中，系统
的组件使用连接405彼此通信。连接405可以是经由总线的物理连接，或者是到处理器410的直接连接，诸如在芯片组架构中。连接405也可以是虚拟连接、网络连接或逻辑连接。
60.在一些实施例中，计算系统400是分布式系统，其中，本发明中描述的功能可以分布在数据中心、多个数据中心、对等网络等内。在一些实施例中，所描述的系统组件中的一个或多个代表许多此类组件，每个组件执行所描述的组件的一些或全部功能。在一些实施例中，组件可以是物理或虚拟设备。
61.示例系统400包括至少一个处理单元(cpu或处理器)410和连接405，该连接405将包括系统存储器415(诸如只读存储器(rom)420和随机存取存储器(ram)425)的各种系统组件耦合到处理器410。计算系统400可以包括高速存储器412的高速缓存，该高速存储器与处理器410直接连接、紧邻或集成为处理器410的一部分。
62.处理器410可以包括任何通用处理器和硬件服务或软件服务，诸如存储在存储设备430中的服务432、434和436，这些服务被配置为控制处理器410以及专用处理器，其中，软件指令被并入实际的处理器设计中。处理器410本质上可以是完全独立的计算系统，包含多个核或处理器、总线、存储器控制器、高速缓存等。多核处理器可以是对称的或非对称的。
63.为了实现用户交互，计算系统400包括输入设备445，该输入设备445可以代表任何数量的输入机制，诸如用于语音的麦克风、用于手势或图形输入的触敏屏幕、键盘、鼠标、运动输入、语音等。计算系统400还可以包括输出设备435，该输出设备435可以是本领域技术人员已知的多种输出机制中的一种或多种。在一些情况下，多模式系统可以使用户能够提供多种类型的输入/输出，以与计算系统400通信。计算系统400可以包括通信接口440，该通信接口440通常可以控制和管理用户输入和系统输出。对在任何特定硬件布置上的操作没有限制，因此此处的基本特征可以很容易地替换为改进的硬件或固件布置(当这些改进的硬件或固件布置被开发时)。
64.存储设备430可以是非易失性存储设备并且可以是硬盘或可以存储计算机可访问的数据的其他类型的计算机可读介质，诸如磁带、闪存卡、固态存储设备、数字多用磁盘、盒式磁带、随机存取存储器(ram)、只读存储器(rom)和/或这些设备的一些组合。
65.存储设备430可以包括软件服务、服务器、服务等，当定义这种软件的代码由处理器410执行时，使系统执行功能。在一些实施例中，执行特定功能的硬件服务可以包括存储在计算机可读介质中的软件组件与必要的硬件组件，诸如处理器410、连接405、输出设备435等，以执行功能。
66.为了解释的清楚，在一些情况下，本技术可以被呈现为包括单独的功能块，这些单独的功能块包括包含设备、设备组件、以软件体现的方法中的步骤或例程或硬件和软件的组合的功能块。
67.本文描述的任何步骤、操作、功能或过程可以由硬件和软件服务的组合单独或与其他设备组合来执行或实现。在一些实施例中，服务可以是驻留在客户端设备和/或内容管理系统的一个或多个服务器的存储器中并在处理器执行与该服务相关联的软件时执行一个或多个功能的软件。在一些实施例中，服务是执行特定功能的程序或程序集合。在一些实施例中，服务可以被认为是服务器。存储器可以是非暂时性计算机可读介质。
68.在一些实施例中，计算机可读存储设备、介质，并且存储器可以包括包含比特流等的电缆或无线信号。然而，当提及时，非暂时性计算机可读存储介质明确不包括诸如能量、
载波信号、电磁波和信号本身的介质。
69.根据上述示例的方法可以使用存储的或以其他方式从计算机可读介质中获取的计算机可执行指令来实现。此类指令可以包括例如使或以其他方式配置通用计算机、专用计算机或专用处理设备以执行特定功能或一组功能的指令和数据。使用的部分计算机资源可以通过网络访问。可执行计算机指令可以是例如二进制、中间格式指令，诸如汇编语言、固件或源代码。可用于存储指令、使用的信息和/或在根据所描述的示例的方法期间创建的信息的计算机可读介质的示例包括磁盘或光盘、固态存储设备、闪存、配备有非易失性存储器的usb设备、网络存储设备等。
70.实现根据这些公开的方法的设备可以包括硬件、固件和/或软件，并且可以采用多种外形尺寸中的任一种。此类外形尺寸的典型示例包括服务器、膝上型电脑、智能手机、小型外形尺寸个人计算机、个人数字助理等。本文描述的功能也可以体现在外围设备或插卡中。作为另外的示例，此种功能也可以在不同芯片或在单个设备中执行的不同过程之间的电路板上实现。
71.指令、用于传送此类指令的介质、用于执行它们的计算资源以及用于支持此类计算资源的其他结构是用于提供在这些公开中描述的功能的装置。
72.尽管使用了各种示例和其他信息来解释所附权利要求范围内的方面，但不应基于此类示例中的特定特征或布置来暗示对权利要求的限制，因为普通技术人员将能够使用这些示例推导各种实现。此外，尽管一些主题可能已经以特定于结构特征和/或方法步骤的示例的语言进行了描述，但是应当理解，所附权利要求中定义的主题未必限于这些描述的特征或动作。例如，此种功能可以不同地分布或在不同于本文所标识的组件的组件中执行。实际上，所描述的特征和步骤被公开为所附权利要求范围内的系统和方法的组件的示例。