CN116513220A - 车辆管理***和车辆检查方法 - Google Patents

Abstract

本公开涉及车辆管理***和车辆检查方法。车辆检查方法包括第一发送过程和第二发送过程以及第一判定过程和第二判定过程。在第一发送过程中，车辆向服务器发送在自动驾驶中通过搭载于车辆的第一传感器检测到的第一状态。在第一判定过程中，服务器使用从车辆接收到的第一状态，对车辆判定第一检查项目的良否。在第二判定过程中，车辆使用在自动驾驶中通过搭载于车辆的第二传感器检测到的第二状态来判定第二检查项目的良否。在第二发送过程中，在对第二检查项目判定为不良的情况下，车辆向服务器发送第二检查项目的判定结果。

Description

车辆管理***和车辆检查方法

技术领域

本公开涉及车辆管理***和车辆检查方法。

背景技术

日本特开2019－131187中公开了一种通过利用互联网的云服务来进行车辆的诊断的技术。在日本特开2019－131187所记载的技术中，在通过车辆所进行的一次诊断而诊断为存在异常，并且驾驶员能感知该异常的情况下，从车辆向云服务提供商的服务器请求与该异常相关的二次诊断。此时，车辆向服务器发送用于二次诊断的数据。在日本特开2019－131187所记载的技术中，在车辆的异常较轻微(驾驶员无法感知的程度或未立即影响车辆行驶的程度)的情况下，不执行二次诊断。

近年，MaaS(Mobility as a Service：出行即服务)备受关注。为了提高MaaS的便利性，提出了利用汽车共享、自动驾驶这样的技术。

考虑通过服务器来管理多个自动驾驶车辆，以便能根据来自用户的请求提供自动驾驶车辆。要求提供自动驾驶车辆的提供商适当地进行日常的自动驾驶车辆的维护。为了尽早发现自动驾驶车辆的异常，希望在自动驾驶中也执行车辆检查。

为了使服务器准确地掌握车辆的状态，希望在车辆中检测到的车辆的状态从车辆被依次发送向服务器。在车辆产生了异常的情况下，即使该异常较轻微，也希望服务器掌握车辆产生了异常。然而，当从被管理的车辆向服务器发送的信息量变多时，服务器的处理负荷(例如用于信息处理的运算量)会增大或通信成本会上升。

发明内容

本公开是为了解决上述问题而完成的，其目的在于，减轻对自动驾驶车辆进行管理的服务器的负荷，并且适当地进行自动驾驶车辆的维护。

本公开的第一观点的车辆管理***包括车辆和服务器。服务器具备第一检查装置，该第一检查装置执行对第一检查项目判定良否的第一检查。车辆具备控制装置、第二检查装置、第一传感器、第二传感器以及通信装置。控制装置被配置为执行用于使该车辆通过自动驾驶进行行驶的控制。第二检查装置被配置为执行对与第一检查项目不同的第二检查项目判定良否的第二检查。第一传感器被配置为检测与第一检查项目对应的第一状态。第二传感器被配置为检测与第二检查项目对应的第二状态。通信装置被配置为向服务器依次发送在车辆的自动驾驶中通过第一传感器检测到的第一状态。第一检查装置被配置为使用从车辆依次接收的第一状态，对该车辆执行第一检查。第二检查装置使用在车辆的自动驾驶中通过第二传感器检测到的第二状态来执行第二检查。然后，在通过第二检查判定为不良的情况下，通信装置向服务器发送第二检查的结果。

根据上述构成，与第一检查项目对应的第一状态从车辆被依次发送向服务器。因此，服务器能准确地掌握自动驾驶中的车辆的状态(通过第一传感器检测到的第一状态)，并且能使用从自动驾驶中的车辆依次接收的第一状态来判定第一检查项目的良否。

此外，根据上述构成，在车辆中对第二检查项目的良否进行判定。服务器能在自动驾驶中的车辆产生了与第二检查项目相关的异常的情况下，从车辆接受车辆产生了异常的意思的联络。在通过第二检查判定为良好的期间，服务器不接收第二检查的结果，由此能掌握在自动驾驶中的车辆中未产生与第二检查项目相关的异常。在通过第二检查判定为良好的期间，第二状态和第二检查的结果均不从车辆被发送向服务器，由此能减少从车辆向服务器发送的信息量。由此服务器的负荷被减轻。

根据上述构成，服务器从车辆接收关于一台车辆的与各检查项目相应的信息，从而服务器易于准确地掌握自动驾驶中的车辆的状态。由此，能适当地进行自动驾驶车辆的维护。

需要说明的是，车辆的通信装置可以将与车辆相关的信息与该车辆的辨别信息(车辆ID)一起发送向服务器。车辆中的控制装置和第二检查装置可以通过一台计算机来具体实现，也可以通过单独的计算机来具体实现。车辆的控制装置可以由一台计算机构成，也可以包括多台计算机。

在上述的车辆管理***中，也可以是，与第一检查项目相比，第二检查项目要求的实时性更高。

关于检查项目，要求的监控间隔和判定间隔越短，则要求的实时性越高。在具有上述的构成的车辆管理***中，在车辆中对第二检查项目进行监控(第二状态的检测)和判定，因此易于以短周期进行监控和判定。如上所述，通过将要求的实时性低的检查项目设为第一检查项目，将要求的实时性高的检查项目设为第二检查项目，易于满足各检查项目的要求。

第一检查项目可以包括确认起因于经年劣化的零件异常的有无的项目。第二检查项目可以包括确认轮胎的漏气的有无的项目。

存在为了精确地判定起因于经年劣化的零件异常的有无而需要高度的分析的倾向。另一方面，对于轮胎的漏气(例如缓慢泄露)的有无，即使不进行高度的分析，也能根据轮胎的气压的推移容易地进行判定。一般来说，提高设于车辆的外部的服务器的信息处理能力比提高搭载于车辆的计算机的信息处理能力更容易。搭载于车辆的计算机在大小和成本方面受设计上的制约。因此，与车辆相比，服务器更容易进行高度的分析。如上所述，通过将需要高度的分析的检查项目设为第一检查项目，将不需要高度的分析的检查项目设为第二检查项目，易于对各检查项目进行精确的判定。

第一状态可以包括车辆的重量、车辆的车速、车辆的停车次数、车辆的急制动次数、车辆的位置以及搭载于车辆的蓄电装置的SOC中的至少一个。第二状态可以包括轮胎的气压。

根据上述构成，服务器易于对搭载于车辆的推进装置(例如驱动用马达)、制动装置、悬架以及蓄电装置(例如驱动用电池)中的至少一个，精确地判定起因于经年劣化的异常的有无。此外，根据上述构成，车辆易于基于轮胎的气压精确地判定轮胎的漏气(例如缓慢泄露)的有无。

通信装置可以被配置为在车辆的自动驾驶中通过第一传感器检测到的第一状态与最近发送的第一状态的偏离程度超过规定水准的情况下，向服务器发送通过第一传感器检测到的第一状态。通信装置也可以被配置为在上述偏离程度不超过上述规定水准的情况下，不向服务器发送通过第一传感器检测到的第一状态。

根据上述构成，在车辆中第一传感器所检测到的当前的第一状态与从该车辆向服务器发送的最近的第一状态(即，服务器从车辆接收到的最新的第一状态)相比未大幅变化的情况下，不向服务器发送第一传感器所检测到的当前的第一状态。服务器不从车辆接收第一传感器的检测值，由此能掌握第一状态未产生大幅的变化。第一传感器的检测值不从车辆被发送向服务器，由此能减少从车辆向服务器发送的信息量。由此服务器的负荷被减轻。

本公开的第二观点的车辆管理***包括：第一车辆、第二车辆以及服务器。服务器具备第一检查装置，该第一检查装置执行对第一检查项目判定良否的第一检查。第一车辆和第二车辆分别具备以下所示的控制装置、第二检查装置、第一传感器、第二传感器以及通信装置。控制装置被配置为执行用于使该车辆通过自动驾驶进行行驶的控制。第二检查装置被配置为执行对与第一检查项目不同的第二检查项目判定良否的第二检查。第一传感器被配置为检测与第一检查项目对应的第一状态。第二传感器被配置为检测与第二检查项目对应的第二状态。第一车辆的通信装置被配置为向服务器依次发送在第一车辆的自动驾驶中通过第一传感器检测到的第一状态。第一检查装置被配置为使用从车辆依次接收的第一状态，分别对第一车辆和第二车辆执行第一检查。第一车辆和第二车辆各自的第二检查装置使用在该车辆的自动驾驶中通过第二传感器检测到的第二状态来执行第二检查，在通过第二检查判定为不良的情况下，向服务器发送第二检查的结果。

在上述构成中，使用从第一车辆向服务器依次发送的第一状态(通过第一车辆的第一传感器得到的检测值)来进行与第二车辆相关的第一检查。通过第二车辆的第一传感器得到的检测值不从第二车辆被发送向服务器，由此能减少从第二车辆向服务器发送的信息量。根据上述构成，能减少从各车辆向服务器发送的信息量，并且能进行许多车辆的检查。

上述的第一车辆和第二车辆可以同时通过自动驾驶进行行驶。根据这样的构成，在第一车辆和第二车辆中进行自动驾驶的条件(气象条件等)大致通用，并且在自动驾驶中各车辆的零件容易以相同的倾向劣化。因此，服务器易于使用通过第一车辆的第一传感器得到的检测值适当地进行与第二车辆相关的第一检查。

上述的第一车辆和第二车辆可以是同一车型。根据这样的构成，在第一车辆和第二车辆中车载零件大致通用，在自动驾驶中各车辆的零件容易以相同的倾向劣化。因此，服务器易于使用通过第一车辆的第一传感器得到的检测值适当地进行与第二车辆相关的第一检查。

本公开的第三观点的车辆检查方法包括以下所示的第一发送过程和第二发送过程以及第一判定过程和第二判定过程。

在第一发送过程中，车辆向服务器发送在自动驾驶中通过搭载于该车辆的第一传感器检测到的第一状态。在第一判定过程中，服务器使用从车辆接收到的第一状态，对车辆判定第一检查项目的良否。在第二判定过程中，车辆使用在自动驾驶中通过搭载于该车辆的第二传感器检测到的第二状态来判定第二检查项目的良否。在第二发送过程中，在对第二检查项目判定为不良的情况下，车辆向服务器发送第二检查项目的判定结果。

通过上述车辆检查方法，也能与上述的车辆管理***同样地，减轻对自动驾驶车辆进行管理的服务器的负荷，并且适当地进行自动驾驶车辆的维护。

根据本公开，能减轻对自动驾驶车辆进行管理的服务器的负荷，并且能适当地进行自动驾驶车辆的维护。

附图说明

以下，参照附图，对本发明的示例性实施例的特征、优点以及技术和工业意义进行说明，其中，相同的附图标记表示相同的元件，其中：

图1是表示本公开的实施方式的车辆的概略构成的图。

图2是表示图1所示的车辆的构成的详细内容的图。

图3是表示本公开的实施方式的自动驾驶控制的处理过程的流程图。

图4是表示本公开的实施方式的第一检查和第二检查的概要的表。

图5是用于对本公开的实施方式的车辆所具备的第一传感器和第二传感器进行说明的图。

图6是用于对本公开的实施方式的服务器的构成进行说明的图。

图7是表示由本公开的实施方式的车辆的控制装置执行的涉及第一检查的处理的流程图。

图8是表示由本公开的实施方式的车辆的控制装置执行的涉及第二检查的处理的流程图。

图9是表示由本公开的实施方式的服务器执行的涉及第一检查的处理的流程图。

图10是表示由本公开的实施方式的服务器执行的涉及第二检查的处理的流程图。

图11是表示关于第一检查的变形例，由服务器执行的请求处理的流程图。

图12是表示关于第一检查的变形例，由车辆执行的发送处理的流程图。

图13是表示关于第一检查的变形例，由服务器执行的判定处理的流程图。

具体实施方式

以下，参照附图对本公开的实施方式详细进行说明。需要说明的是，对图中相同或相当部分标注相同的附图标记，并不重复其说明。

图1是表示本公开的实施方式的车辆的概略构成的图。参照图1，车辆1具备自动驾驶套件(以下表述为“ADK(Autonomous Driving Kit)”)200和车辆平台(以下表述为“VP(Vehicle Platform)”)2。

VP2包括基础车辆(base vehicle)100的控制***和设于基础车辆100内的车辆控制接口箱(以下表述为“VCIB(Vehicle Control Interface Box)”)111。VCIB111可以通过CAN(Controller Area Network：控制器局域网)这样的车内网络与ADK200进行通信。需要说明的是，虽然在图1中基础车辆100和ADK200被示于分离的位置，但实际上ADK200装配于基础车辆100。在本实施方式中，ADK200装配于基础车辆100的车顶。不过，ADK200的装配位置可以适当地变更。

基础车辆100例如是市售的xEV(电动车)。xEV是利用电力作为动力源的全部或一部分的车辆。在本实施方式中，采用BEV(纯电动汽车)来作为基础车辆100。不过不限于此，基础车辆100也可以是BEV以外的xEV(HEV、PHEV、FCEV等)。基础车辆100所具备的车轮的数量例如是四轮。不过不限于此，基础车辆100所具备的车轮的数量也可以是三轮，还可以是五轮以上。

除了综合控制管理器115之外，基础车辆100的控制***还包括用于对基础车辆100进行控制的各种***和各种传感器。综合控制管理器115基于来自基础车辆100中所包括的各种传感器的信号(传感器检测信号)来对与基础车辆100的动作有关的各种***进行综合控制。

在本实施方式中，综合控制管理器115包括控制装置150。控制装置150包括处理器151、RAM(Random Access Memory：随机存取存储器)152以及存储装置153。作为处理器151，例如可以采用CPU(Central Processing Unit：中央处理器)。RAM152作为临时存储由处理器151处理的数据的作业用存储器发挥功能。存储装置153被配置为能保存所储存的信息。存储装置153例如包括ROM(Read Only Memory：只读存储器)和可重写的非易失性存储器。在存储装置153中，除了程序之外，还存储有在程序中使用的信息(例如映射图、公式以及各种参数)。在本实施方式中，通过处理器151执行存储于存储装置153的程序来执行各种车辆控制(例如，按照来自ADK200的指示的自动驾驶控制)和后述的涉及检查的处理(参照图7和图8)。不过，这些处理也可以不通过软件执行，而通过专用的硬件(电子电路)来执行。需要说明的是，控制装置150所具备的处理器的数量是任意的，可以按每个规定的控制来准备处理器。

基础车辆100包括制动器***121、操舵***122、动力传动***123、主动安全(active safety)***125以及车身***126。这些***由综合控制管理器115综合控制。在本实施方式中，各***具备计算机。并且，每个***的计算机通过车内网络(例如CAN)与综合控制管理器115进行通信。以下，将各***所具备的计算机称为“ECU(ElectronicControl Unit：电子控制单元)”。

制动器***121包括设于基础车辆100的各车轮的制动装置和对制动装置进行控制的ECU。在本实施方式中，采用液压式盘形制动器装置来作为制动装置。基础车辆100具备车轮速度传感器127A、127B。车轮速度传感器127A设于基础车辆100的前轮，检测前轮的转速。车轮速度传感器127B设于基础车辆100的后轮，检测后轮的转速。制动器***121的ECU向综合控制管理器115输出通过车轮速度传感器127A、127B检测到的各车轮的旋转方向和转速。

操舵***122包括基础车辆100的转向装置和对转向装置进行控制的ECU。转向装置例如包括能通过致动器进行转向角的调整的齿轮齿条式EPS(Electric PowerSteering：电动助力转向)。基础车辆100具备小齿轮角传感器128。小齿轮角传感器128对连结于构成转向装置的致动器的旋转轴的小齿轮的旋转角(小齿轮角)进行检测。操舵***122的ECU向综合控制管理器115输出通过小齿轮角传感器128检测到的小齿轮角。

动力传动***123包括：EPB(Electric Parking Brake：电动驻车制动器)，设于基础车辆100所具备的车轮中的至少一个；P－Lock装置，设于基础车辆100的变速器；换挡装置，被配置为能选择挡位；基础车辆100的驱动源；以及ECU，对动力传动***123中所包括的各装置进行控制。EPB与上述的制动装置分开设置，通过电动致动器使车轮成为固定状态。P－Lock装置例如通过能由致动器驱动的驻车锁止爪使变速器的输出轴的旋转位置成为固定状态。详细内容将在后文加以叙述，但在本实施方式中，采用从电池接受电力的供给的马达来作为基础车辆100的驱动源(参照图5)。动力传动***123的ECU向综合控制管理器115输出由EPB和P－Lock装置分别实现的固定化的有无、通过换挡装置选择出的挡位以及电池和马达各自的状态。

主动安全***125包括对行驶中的车辆1判定碰撞的可能性的ECU。基础车辆100具备对包括车辆1的前方和后方的周边状况进行检测的摄像机129A和雷达传感器129B、129C。主动安全***125的ECU使用从摄像机129A和雷达传感器129B、129C接收到的信号来判定是否存在碰撞的可能性。在通过主动安全***125判定为存在碰撞的可能性的情况下，综合控制管理器115对制动器***121输出制动指令来使车辆1的制动力增加。本实施方式的基础车辆100从初始(出厂时)起具备主动安全***125。但不限于此，也可以采用能加装至基础车辆的主动安全***。

车身***126具备车身***零件(例如方向指示器、喇叭以及刮水器)和对车身***零件进行控制的ECU。车身***126的ECU在手动模式下按照用户操作来控制车身***零件，在自主模式下，按照经由VCIB111和综合控制管理器115从ADK200接收的指令来控制车身***零件。

车辆1被配置为能进行自动驾驶。VCIB111作为车辆控制接口发挥功能。在车辆1通过自动驾驶进行行驶时，综合控制管理器115和ADK200经由VCIB111相互进行信号的交换，并且综合控制管理器115按照来自ADK200的指令执行通过自主模式(Autonomous Mode)实现的行驶控制(即自动驾驶控制)。需要说明的是，ADK200也能从基础车辆100拆下。即使在ADK200被拆下的状态下，基础车辆100也能通过用户的驾驶以基础车辆100单体进行行驶。在以基础车辆100单体进行行驶的情况下，基础车辆100的控制***执行通过手动模式实现的行驶控制(即与用户操作相应的行驶控制)。

在本实施方式中，ADK200按照对通信的各信号进行定义的API(ApplicationProgram Interface：应用程序接口)，在与VCIB111之间进行信号的交换。ADK200被配置为对通过上述API定义出的各种信号进行处理。ADK200例如制作车辆1的行驶计划，并按照上述API，向VCIB111输出请求用于使车辆1按照所制作的行驶计划进行行驶的控制的各种命令。以下，也将从ADK200向VCIB111输出的上述各种命令的每一个称为“API命令”。此外，ADK200按照上述API从VCIB111接收表示基础车辆100的状态的各种信号，并将接收到的基础车辆100的状态反映至行驶计划的制作。以下，也将ADK200从VCIB111接收的上述各种信号的每一个称为“API信号”。API命令和API信号均相当于通过上述API定义出的信号。在后文对ADK200的构成的详细内容加以叙述(参照图2)。

VCIB111从ADK200接收各种API命令。当从ADK200接收到API命令时，VCIB111将该API命令转换成综合控制管理器115能处理的信号的形式。以下，也将被转换成综合控制管理器115能处理的信号的形式的API命令称为“控制命令”。当从ADK200接收到API命令时，VCIB111综合控制管理器115输出与该API命令对应的控制命令。

综合控制管理器115的控制装置150经由VCIB111向ADK200发送表示在基础车辆100的控制***中检测到的基础车辆100的状态的各种信号(例如传感器信号或状况信号)。VCIB111从综合控制管理器115依次接收表示基础车辆100的状态的信号。VCIB111基于从综合控制管理器115接收到的信号来决定API信号的值。此外，VCIB111根据需要将从综合控制管理器115接收到的信号转换成API信号的形式。然后，VCIB111向ADK200输出得到的API信号。从VCIB111向ADK200实时地依次输出表示基础车辆100的状态的API信号。

在本实施方式中，在综合控制管理器115与VCIB111之间例如交换由汽车制造商定义出的通用性低的信号，在ADK200与VCIB111之间交换通用性更高的信号(例如，通过公开的API(Open API)定义出的信号)。VCIB111能通过在ADK200与综合控制管理器115之间进行信号的转换使综合控制管理器115按照来自ADK200的指令进行车辆控制。不过，VCIB111的功能不仅限定于进行上述信号的转换的功能。例如，VCIB111也可以进行规定的判断，并将基于该判断结果的信号(例如，进行通知、指示或请求的信号)送向综合控制管理器115和ADK200中的至少一方。在后文对VCIB111的构成的详细内容加以叙述(参照图2)。

基础车辆100还具备通信装置130。通信装置130包括各种通信I/F(接口)。控制装置150被配置为通过通信装置130与车辆1的外部的装置(例如，后述的移动终端UT和服务器500)进行通信。通信装置130包括能访问移动通信网(车载信息服务)的无线通信器(例如，DCM(Data Communication Module：数据通信模块))。通信装置130经由移动通信网与服务器500进行通信。无线通信器可以包括与5G(第五代移动通信***)对应的通信I/F。此外，通信装置130包括用于与存在于车内或车辆周边的范围内的移动终端UT直接进行通信的通信I/F。通信装置130和移动终端UT可以进行无线LAN(Local Area Network：局域网)、NFC(Near Field Communication：近场通信)或蓝牙(Bluetooth；注册商标)这样的近距离通信。

移动终端UT是由车辆1的用户携带的终端。在本实施方式中，采用具备触摸面板显示器的智能手机来作为移动终端UT。但不限于此，作为移动终端UT，可以采用任意的移动终端，也可以采用笔记本电脑、平板终端、可穿戴设备(例如智能手表或智能眼镜)或电子钥匙等。

上述的车辆1可以作为MaaS(Mobility as a Service)***的构成要素之一被采用。MaaS***例如包括MSPF(Mobility Service Platform：出行服务平台)。MSPF是连接有各种出行服务(例如，由拼车提供商、汽车共享提供商、保险公司、汽车租赁提供商、出租车提供商等提供的各种出行服务)的统一平台。服务器500是在MSPF中进行用于出行服务的信息的管理和公开的计算机。服务器500对各种出行的信息进行管理，并根据来自提供商的请求提供信息(例如，API和与出行间的合作相关的信息)。提供服务的提供商能使用在MSPF上公开的API来利用MSPF所提供的各种各样的功能。例如，ADK的开发所需的API在MSPF上被公开。

图2是表示车辆1的构成的详细内容的图。参照图1和图2，ADK200包括用于进行车辆1的自动驾驶的自动驾驶***(以下表述为“ADS(Autonomous Driving System)”)202。ADS202包括计算机210、HMI(Human Machine Interface：人机接口)230、识别用传感器260、姿势用传感器270以及传感器清洁器290。

计算机210具备处理器和存储利用了API的自动驾驶软件的存储装置，并被配置为能通过处理器执行自动驾驶软件。通过自动驾驶软件执行与自动驾驶相关的控制(参照后述的图3)。自动驾驶软件可以通过OTA(Over The Air：空中下载)依次更新。计算机210还具备通信模块210A和210B。

HMI230是用于供用户与计算机210交换信息的装置。HMI230包括输入装置和报告装置。用户能通过HMI230对计算机210进行指示或请求，或者变更在自动驾驶软件中使用的参数(不过仅限于允许变更的参数)的值。HMI230可以是兼具输入装置和报告装置两方的功能的触摸面板显示器。

识别用传感器260包括获取用于识别车辆1的外部环境的信息(以下也称为“环境信息”)的各种传感器。识别用传感器260获取车辆1的环境信息，并向计算机210输出该环境信息。环境信息用于自动驾驶控制。在本实施方式中，识别用传感器260包括拍摄车辆1的周围(包括前方和后方)的摄像机和通过电磁波或声波来感测障碍物的障碍物感测器(例如毫米波雷达和/或激光雷达)。计算机210例如能使用从识别用传感器260接收的环境信息来识别存在于能从车辆1识别的范围内的人、物体(其他的车辆、柱、护栏等)以及道路上的线(例如中心线)。为了进行识别，也可以使用人工智能(AI)或图像处理用处理器。

姿势用传感器270获取与车辆1的姿势相关的信息(以下也称为“姿势信息”)，并向计算机210输出该信息。姿势用传感器270包括检测车辆1的加速度、角速度以及位置的各种传感器。在本实施方式中，姿势用传感器270包括IMU(Inertial Measurement Unit：惯性测量单元)和GPS(Global Positioning System：全球定位***)传感器。IMU对车辆1的前后方向、左右方向以及上下方向的各个加速度和车辆1的侧倾方向、俯仰方向以及偏航方向的各个角速度进行检测。GPS传感器使用从多个GPS卫星接收的信号来检测车辆1的位置。在汽车和飞机的领域中，将IMU与GPS进行组合来以高精度计测姿势的技术是公知的。计算机210例如可以利用这样的公知的技术，根据上述姿势信息来计测车辆1的姿势。

传感器清洁器290是去除在车外暴露于外部空气的传感器(例如识别用传感器260)的污垢的装置。例如，传感器清洁器290可以被配置为使用清洗液和擦拭器来对摄像机的镜头和障碍物感测器的射出口进行清洁。

在车辆1中，为了提高安全性，使规定的功能(例如制动、操舵以及车辆固定)具有冗余性。基础车辆100的控制***102具备多个实现同等的功能的***。具体而言，制动器***121包括制动器***121A和121B。操舵***122包括操舵***122A和122B。动力传动***123包括EPB***123A和P－Lock***123B。各***具备ECU。即使实现同等的功能的多个***中的一方产生异常，另一方也正常动作，由此，在车辆1中该功能正常工作。

VCIB111包括VCIB111A和VCIB111B。VCIB111A和VCIB111B的每一个包括计算机。计算机210的通信模块210A、210B被配置为能分别与VCIB111A、VCIB111B的计算机进行通信。VCIB111A和VCIB111B以能相互通信的方式连接。VCIB111A和VCIB111B的每一个能单独地动作，即使一方产生异常，另一方也正常地动作，由此VCIB111正常地动作。VCIB111A和VCIB111B均经由综合控制管理器115连接于上述各***。不过，如图2所示，在VCIB111A和VCIB111B中，连接目的地有一部分不同。

在本实施方式中，使车辆1加速的功能不具有冗余性。动力传动***123包括推进***123C来作为用于使车辆1加速的***。

车辆1被配置为能在自主模式与手动模式之间进行切换。ADK200从VCIB111接收的API信号中包括表示车辆1为自主模式和手动模式中的哪一个状态的信号(以下表述为“自主状态”)。用户能通过规定的输入装置(例如HMI230或移动终端UT)来选择自主模式和手动模式中的任一个。当由用户选择任一个驾驶模式时，车辆1成为所选择出的驾驶模式，并且选择结果被反映至自主状态。不过，如果车辆1未成为能自动驾驶的状态，则即使用户选择自主模式也不会转移至自主模式。车辆1的驾驶模式的切换可以通过综合控制管理器115来进行。综合控制管理器115也可以根据车辆1的状况在自主模式与手动模式之间进行切换。

在车辆1为自主模式时，计算机210从VP2获取车辆1的状态，并对车辆1的下一个动作(例如加速、减速以及转弯)进行设定。然后，计算机210输出用于实现所设定的车辆1的下一个动作的各种指令。通过计算机210执行API软件(即，利用了API的自动驾驶软件)，与自动驾驶控制相关的指令从ADK200通过VCIB111被发送向综合控制管理器115。

图3是表示在本实施方式的自动驾驶控制中ADK200所执行的处理的流程图。该流程图所示的处理在车辆1为自主模式时，以与API对应的周期(API周期)被反复执行。当车辆1的驾驶模式从手动模式被切换至自主模式时，表示自动驾驶开始的开始信号与车辆1的辨别信息一起从车辆1(通信装置130)被发送向服务器500，并且开始以下说明的图3所示的一系列的处理。以下，将流程图中的各步骤仅表述为“S”。

参照图1、图2以及图3，在S101中，计算机210获取当前的车辆1的信息。例如，计算机210从识别用传感器260和姿势用传感器270获取车辆1的环境信息和姿势信息。而且，计算机210获取API信号。在本实施方式中，在车辆1为自主模式和手动模式中的任一个的情况下，也从VCIB111向ADK200实时地依次输出表示车辆1的状态的API信号。为了提高自动驾驶控制的精度，也可以在自主模式下，以比手动模式短的周期从综合控制管理器115朝向ADK200依次发送车辆1的状态。在计算机210所获取的API信号中，除了上述的自主状态以外，还包括表示通过车轮速度传感器127A、127B检测到的各车轮的旋转方向和转速的信号等。

在S102中，计算机210基于在S101中获取到的车辆1的信息来制作行驶计划。例如，计算机210计算车辆1的行为(例如车辆1的姿势)，并制作适合车辆1的状态和外部环境的行驶计划。行驶计划是表示规定期间内的车辆1的行为的数据。在行驶计划已存在的情况下，也可以在S102中修改该行驶计划。

在S103中，计算机210从在S102中制作出的行驶计划中提取控制性的物理量(加速度、轮胎转角等)。在S104中，计算机210按每个API周期对在S103中提取出的物理量进行分割。在S105中，计算机210使用在S104中被分割的物理量来执行API软件。如此，通过API软件被执行，请求用于实现按照行驶计划的物理量的控制的API命令(推进方向命令、推进命令、制动命令、车辆固定命令等)从ADK200被发送向VCIB111。VCIB111向综合控制管理器115发送与接收到的API命令对应的控制命令，综合控制管理器115按照该控制命令来进行车辆1的自动驾驶控制。自动驾驶中的车辆1的状态被依次记录于计算机210的存储装置。

在接下来的S106中，计算机210对车辆1是否为自主模式进行判断。在自主模式持续的期间(在S106中为“是(YES)”)，通过反复执行上述S101～S105的处理来执行车辆1的自动驾驶。另一方面，当车辆1成为手动模式时(在S106中为“否(NO)”)，在S107中，在将表示自动驾驶结束的结束信号与车辆1的辨别信息一起从车辆1(通信装置130)发送向服务器500之后，图3所示的一系列的处理结束。在本实施方式中，计算机210、VCIB111以及综合控制管理器115协作来执行用于使车辆1通过自动驾驶进行行驶的控制。计算机210、VCIB111(更确定地说，VCIB111中所包括的计算机)以及综合控制管理器115(更确定地说，控制装置150)分别相当于本公开的“控制装置”的一个例子。在本实施方式中，假定在车辆1为有人的状态时进行车辆1的自动驾驶。但不限于此，也可以设为在车辆1为无人的状态时进行车辆1的自动驾驶。自动驾驶控制不限于图3所示的控制，也可以采用其他的控制(公知的自动驾驶控制)。

在本实施方式中，服务器500执行对第一检查项目判定良否的第一检查。此外，搭载于车辆1的控制装置150执行对与第一检查项目不同的第二检查项目判定良否的第二检查。在服务器500中，通过处理器(后述的处理器501)和由处理器执行的程序来具体实现本公开的“第一检查装置”的一个例子。此外，在控制装置150中，通过处理器151和由处理器151执行的程序来具体实现本公开的“第二检查装置”的一个例子。

图4是表示本实施方式的第一检查和第二检查的概要的表。参照图4，关于本实施方式的第一检查和第二检查，与第一检查项目相比，第二检查项目要求的实时性更高。即，与第一检查项目相比，第二检查项目要求的监控间隔和判定间隔更短。具体而言，第一检查项目是确认起因于经年劣化的零件异常的有无的项目。第二检查项目是确认轮胎的漏气的有无的项目。

在本实施方式中，服务器500基于与第一检查项目对应的第一状态来执行第一检查。详细内容将在后文加以叙述，但第一状态在车辆1的自动驾驶中通过车辆1所具备的第一传感器来检测，并从车辆1被依次发送向服务器500。服务器500通过远程进行车辆1的检查。在本实施方式的车辆检查方法中，第一状态包括车辆1的重量、车辆1的车速、车辆1的停车次数、车辆1的急制动次数、车辆1的位置以及搭载于车辆1的蓄电装置(后述的图5所示的电池160)的SOC。在后文对上述第一状态与各种车载零件的经年劣化(第一检查项目)的关系加以叙述。

在本实施方式中，搭载于车辆1的控制装置150基于与第二检查项目对应的第二状态来执行第二检查。详细内容将在后文加以叙述，但第二状态在车辆1的自动驾驶中通过车辆1所具备的第二传感器来检测。在本实施方式中，采用轮胎的气压来作为第二状态。当发生轮胎的漏气时，轮胎的气压下降。在缓慢泄露的情况下，轮胎的气压慢慢下降。控制装置150能基于轮胎的气压的推移来判断是否发生了轮胎的漏气。

图5是用于对车辆1所具备的第一传感器和第二传感器进行说明的图。参照图1、图2以及图5，车辆1具备对推进***123C供给电力的电池160。作为电池160，可以采用公知的车辆用蓄电装置(例如，液式二次电池、全固体二次电池或电池组)。作为车辆用二次电池的例子，可以举出锂离子电池、镍氢电池。

在电池160设有监视模块160a。监视模块160a包括检测电池160的状态(例如电压、电流以及温度)的各种传感器，并向综合控制管理器115输出检测结果。监视模块160a也可以是除了上述传感器功能之外还具有SOC(State Of Charge：荷电状态)推定功能的BMS(Battery Management System：电池管理***)。控制装置150能基于监视模块160a的输出来获取电池160的状态(例如温度、电流、电压以及SOC)。SOC表示蓄电余量，例如以0％～100％表示当前的蓄电量相对于充满电状态的蓄电量的比例。

车辆1还具备检测车辆1的重量的重量传感器170a。通过重量传感器170a检测的车辆1的重量是车身的重量加上乘坐车辆1的人的重量和装载于车辆1的物品的重量而得到的总重量。在本实施方式中，采用装配于基础车辆100所具备的悬架170的装载载荷传感器来作为重量传感器170a。但不限于此，作为重量传感器170a，也可以采用设于基础车辆100内的各座位的压力传感器来代替装载载荷传感器或者除了装载载荷传感器之外还采用设于基础车辆100内的各座位的压力传感器。重量传感器170a所检测到的车辆1的重量被输出向综合控制管理器115。

推进***123C包括MG(Motor Generator：电动发电机)20、ECU21以及PCU(PowerControl Unit：功率控制单元)22。推进***123C使用蓄存于电池160的电力来产生车辆1的行驶驱动力。MG20例如是三相交流电动发电机。PCU22例如包括逆变器、转换器以及继电器(以下称为“SMR(System Main Relay：***主继电器)”)。PCU22由ECU21控制。SMR被配置为切换从电池160到MG20的电路的连接/断开。SMR在车辆1行驶时被设为闭合状态(连接状态)。

MG20由PCU22驱动，使车辆1的驱动轮W旋转。此外，MG20进行再生发电，并将发电所产生的电力供给至电池160。PCU22使用从电池160供给的电力来驱动MG20。车辆1所具备的行驶用的马达(MG20)的数量是任意的，可以是一个也可以是两个还可以是三个以上。行驶用的马达可以是轮内马达。图5中仅示意性地示出了一个驱动轮W，但车辆1中的驱动轮W的数量和驱动方式是任意的。车辆1的驱动方式可以是前轮驱动、后轮驱动、四轮驱动中的任一个。

在车辆1所具备的各车轮(包括驱动轮W)设有：气压传感器20b，对车轮的轮胎的气压进行检测；制动装置180，包括在制动器***121中；以及制动器传感器180a，对通过制动装置180赋予至车轮的制动力进行检测。气压传感器20b可以是与监视轮胎的气压一起也监视轮胎的温度的TPMS(Tire Pressure Monitoring System：胎压监测***)。制动器传感器180a可以是对施加于制动垫块(或轮缸)的液压进行检测的液压传感器。通过四个气压传感器20b和四个制动器传感器180a分别检测到的每个车轮的轮胎气压和制动力(例如，与制动力对应的液压)被输出向综合控制管理器115。

在本实施方式中，车轮速度传感器127A、127B(图1)、姿势用传感器270(图2)、监视模块160a(图5)、重量传感器170a(图5)以及制动器传感器180a(图5)分别作为第一传感器发挥功能。通信装置130向服务器500依次发送在车辆1的自动驾驶中通过第一传感器检测到的第一状态。

在本实施方式中，四个气压传感器20b分别作为第二传感器发挥功能。控制装置150使用在车辆1的自动驾驶中通过第二传感器(气压传感器20b)检测到的第二状态(轮胎的气压)来执行第二检查。然后，在通过第二检查判定为不良的情况下，通信装置130向服务器500发送表示第二检查的结果的信号。

图6是用于对服务器500的构成进行说明的图。参照图1、图2以及图6，服务器500包括处理器501、RAM502以及存储装置503。存储装置503被配置为能保存所储存的信息。在存储装置503中，除了程序以外，还存储有在程序中使用的信息(例如映射图、公式以及各种参数)。在本实施方式中，通过处理器501执行存储于存储装置503的程序来执行后述的涉及检查的处理(参照图9和图10)。不过，这样的处理也可以不通过软件执行，而通过专用的硬件(电子电路)来执行。

存储装置503还存储有推定算法E。推定算法E对规定的输入信息与规定的输出信息的关系进行规定。当对推定算法E输入规定的输入信息时，推定算法E按照上述关系来输出规定的输出信息。

在本实施方式中，上述的第一状态，即车辆1的重量、车辆1的车速、车辆1的停车次数、车辆1的急制动次数、车辆1的位置以及电池160的SOC相当于推定算法E的上述输入信息。车辆1的车速和停车次数例如分别通过车轮速度传感器127A、127B来检测。此外，车辆1的重量、车辆1的急制动次数、车辆1的位置、电池160的SOC分别通过重量传感器170a、制动器传感器180a、姿势用传感器270、监视模块160a来检测。

在本实施方式中，搭载于车辆1的规定的对象零件(例如，零件A、零件B、零件C、零件D、……)的劣化进度相当于推定算法E的上述输出信息。详细而言，当第一状态被输入至推定算法E时，从推定算法E输出由于车辆1在该第一状态下执行自动驾驶而使对象零件的劣化进展的程度(对象零件的劣化进度)。

在本实施方式中，搭载于车辆1的MG20(驱动用马达)、电池160(驱动用电池)、悬架170以及制动装置180分别作为对象零件被采用。具体而言，自动驾驶中的车辆1的重量越大，则MG20、悬架170以及制动装置180各自的劣化越容易进展。车辆1的急制动次数(累计次数)越增加，则悬架170和制动装置180各自的劣化越容易进展。电池160的SOC偏离适当范围的时间越长，则电池160的劣化越容易进展。车辆1的停车次数(累计次数)越增加，则制动装置180的劣化越容易进展。此外，继续行驶的车辆1在停车后起步，因此，车辆1的停车次数越增加，则车辆1的起步次数越增加而MG20的劣化越容易进展。

推定算法E的输入信息还可以包括基于车辆1的位置信息而获取的气象信息(表示车辆1所在的地区的气象的信息)、交通信息(表示车辆1的周边的交通状况的信息)以及路面信息(与车辆1正在行驶的路面相关的信息)。作为气象信息的例子，可以举出气温、天气(例如晴天、阴天、雨或雪)。作为交通信息的例子，可以举出拥堵信息。作为路面信息的例子，可以举出平坦、上坡、下坡、恶劣道路这样的路面的种类。气温(或路面温度)偏离适当范围的时间越长，则橡胶制品(例如轮胎)越容易劣化。此外，橡胶制品也可能会因阳光而劣化。当车辆1在拥堵的道路行驶时，MG20和制动装置180分别容易劣化。当车辆1在上坡行驶时，MG20容易劣化。当车辆1在下坡行驶时，制动装置180容易劣化。当车辆1在恶劣道路行驶时，悬架170容易劣化。

在本实施方式中，采用通过AI(人工智能)进行的算法来作为推定算法E。推定算法E可以是使用大数据(例如，在与车辆1同一技术规格的车辆中实测出的数据)进行了机器学习的学习完毕模型。但不限于此，推定算法E也可以是基于规则的算法。推定算法E例如也可以是表示上述的关系(倾向)的公式或映射图。推定算法E可以通过OTA依次更新。

服务器500对与车辆相关的信息(以下也称为“车辆信息”)进行管理。多个车辆各自的车辆信息存储于服务器500的存储装置503。具体而言，用于辨别车辆的辨别信息(车辆ID)被赋予至每个车辆，服务器500通过车辆ID对车辆信息进行区别管理。车辆信息例如包括车型、技术规格以及车辆状况(例如是否为自动驾驶中)。在本实施方式中，车辆信息还包括各对象零件的劣化度。图6中的表T1表示各车辆的车辆信息。在表T1中，“V－1”相当于车辆1的车辆ID。在图6中仅示出了与车辆1(V－1)相关的车辆信息(特别是每个对象零件的劣化度)，但表T1表示与登记到服务器500的所有车辆相关的车辆信息。

服务器500将从自动驾驶中的车辆1依次接收的第一状态依次输入至推定算法E，并将从推定算法E输出的每个对象零件的劣化进度依次与表T1所示的每个对象零件的劣化度相加。自动驾驶中的各对象零件的劣化进度通过推定算法E来推定，并与表T1中的对应的对象零件的劣化度相加。由此表T1被更新。服务器500能通过对从推定算法E输出的各对象零件的劣化进度进行累计来获取车辆1的自动驾驶中的各对象零件的劣化进度。需要说明的是，自动驾驶中以外的各对象零件的劣化进度的推定方法是任意的。服务器500例如可以使用规定的映射图来推定自动驾驶中以外的各对象零件的劣化进度。

控制装置150被配置为在规定的期间(以下称为“运用期间”)中执行车辆1的自动驾驶。在车辆1的自动驾驶中，执行图3所示的处理，控制装置150按照来自ADK200的指令对车辆1的各种***(例如，图2所示的制动器***121、操舵***122、动力传动***123、主动安全***125以及车身***126)进行控制。车辆1也可以在运用期间通过自动驾驶提供规定的服务(例如物流服务或旅客输送服务)。在本实施方式中，通过自动驾驶提供旅客输送服务的车辆1在运行区域内按预先决定的路径进行巡回行驶。但不限于此，车辆1也可以根据每次的请求来决定路径，并按照决定出的路径(按需路径)来执行通过自动驾驶进行的行驶。

图7是表示通过车辆1的控制装置150执行的涉及第一检查的处理的流程图。例如，当开始由车辆1进行的自动驾驶时，图7所示的一系列的处理开始，在自动驾驶中以规定的第一周期反复执行图7所示的一系列的处理。控制装置150例如在车辆1的驾驶模式从手动模式被切换至自主模式的情况下，判断为由车辆1进行的自动驾驶开始了。

参照图1～图6以及图7，在S11中，控制装置150获取通过第一传感器检测到的当前的第一状态(更确定地说，车辆1的重量、车辆1的车速、车辆1的停车次数、车辆1的急制动次数、车辆1的位置以及电池160的SOC)，并将该第一状态保存于存储装置153。

在接下来的S12中，控制装置150判断在S11中获取到的第一状态中的至少一个是否从上一次发送(后述的S13)起大幅变化了。具体而言，控制装置150判断在S11中检测到的第一状态与最近被发送向服务器500的第一状态的偏离程度(以下也称为“状态变化量”)是否超过规定水准。上一次的值(最近发送的值)与本次的值(当前的传感器检测值)的偏离程度(状态变化量)例如能通过差或比率来表示。差(绝对值)越大则状态变化量越大。此外，比率越接近1则状态变化量越小。规定水准能按每个第一状态任意地设定。

控制装置150按每个第一状态来判断状态变化量是否超过规定水准，并在至少一个第一状态的状态变化量超过规定水准的情况下，在S12中判断为“是”，在任一个第一状态的状态变化量均未超过规定水准的情况下，在S12中判断为“否”。在初次处理例程(车辆1开始自动驾驶紧后的处理例程)中，不存在上一次的值，因此，在S12中判断为“是”。

在S12中判断为“是”的情况下，通信装置130在S13中将在S11中获取到的所有的表示第一状态的信号(以下也称为“第一检查信号”)与车辆1的车辆ID一起发送向服务器500。之后，处理进入S14。另一方面，在S12中判断为“否”的情况下，处理进入S14而不进行第一检查信号的发送(S13)。

在接下来的S14中，控制装置150判断车辆1是否为自动驾驶中。例如，在车辆1为自主模式的情况下，控制装置150判断为车辆1为自动驾驶中，在车辆1为手动模式的情况下，控制装置150判断为车辆1不为自动驾驶中。在车辆1为自动驾驶中的情况下(在S14中为“是”)，处理返回至最初的步骤(S11)。在车辆1不为自动驾驶中的情况下(在S14中为“否”)，图7所示的一系列的处理结束。

如上所述，车辆1(通信装置130)被配置为向服务器500依次发送在车辆1的自动驾驶中通过第一传感器检测到的第一状态。在本实施方式中，在图7的S13中，从车辆1向服务器500依次发送通过第一传感器检测到的表示第一状态的第一检查信号。

图8是表示通过车辆1的控制装置150执行的涉及第二检查的处理的流程图。例如，当由车辆1进行的自动驾驶开始时，图8所示的一系列的处理开始，在自动驾驶中，以规定的第二周期反复执行图8所示的一系列的处理。为了提高第二检查的实时性，也可以使第二周期(第二检查的执行周期)比第一周期(第一状态的检测周期)短。

参照图1～图6以及图8，在S21中，控制装置150获取通过第二传感器(气压传感器20b)检测到的当前的第二状态(轮胎的气压)，并将该第二状态保存于存储装置153。接下来，控制装置150在S22中使用在S21中获取到的第二状态来执行第二检查。在第二检查中，判定第二状态是否产生了异常。具体而言，控制装置150基于轮胎的气压的推移，按车辆1的每个车轮来判断是否产生了轮胎的漏气。产生了轮胎的漏气意味着轮胎气压(第二状态)产生了异常。控制装置150也可以在S22中连续规定次确认到超过基准水平的轮胎气压的下降的情况下判断为产生了轮胎的漏气。

在车辆1中至少一个车轮产生了轮胎的漏气的情况下，通过第二检查做出不良判定(在S22中为“是”)，处理进入S23。在S23中，通信装置130将表示第二检查的结果(轮胎气压异常)的信号(以下也称为“第二检查信号”)与车辆1的车辆ID一起发送向服务器500。之后，处理进入S24。另一方面，在车辆1的所有的车轮均未产生轮胎的漏气的情况下，通过第二检查做出良好判定(在S22中为“否”)，处理进入S24而不进行第二检查信号的发送(S23)。

在接下来的S24中，与上述的图7的S14同样地，控制装置150判断车辆1是否为自动驾驶中。然后，在车辆1为自动驾驶中的情况下(在S24中为“是”)，处理返回至最初的步骤(S21)。在车辆1不为自动驾驶中的情况下(在S24中为“否”)，图8所示的一系列的处理结束。

如上所述，控制装置150使用在车辆1的自动驾驶中通过第二传感器检测到的第二状态来执行第二检查(S21和S22)，在通过第二检查判定为不良的情况下(在S22中为“是”)，通信装置130向服务器500发送第二检查信号(表示第二检查的结果的信号)(S23)。

图9是表示通过服务器500执行的涉及第一检查的处理的流程图。该流程图所示的处理在车辆1的自动驾驶中被反复执行。例如，当服务器500接收到表示车辆1的自动驾驶开始的开始信号时，以下说明的图9所示的一系列的处理开始。

参照图1～图6以及图9，在S31中，服务器500使用从车辆1依次接收的第一状态(即，在图7的S13中发送的第一检查信号所示的第一状态)来推定车辆1的各对象零件(MG20、电池160、悬架170、制动装置180)的当前的劣化度。具体而言，服务器500使用推定算法E(图6)，根据最近接收到的第一检查信号所示的当前的第一状态来推定起因于自动驾驶中的经年劣化的各对象零件的劣化进度。服务器500通过将推定出的各对象零件的劣化进度与表T1中的对应的对象零件的劣化度相加来更新表T1(图6)。然后，服务器500从更新后的表T1中获取各对象零件的当前的劣化度。需要说明的是，服务器500视为在接收到下一个第一检查信号为止的期间，最近接收到的第一检查信号所示的第一状态被维持。

在接下来的S32中，服务器500判定在车辆1中任一个对象零件是否产生了异常。具体而言，服务器500按搭载于车辆1的每个对象零件来判断当前的劣化度是否超过规定的阈值。在本实施方式中，在S31和S32中执行的车载零件的检查相当于与车辆1相关的第一检查。上述阈值能按每个对象零件任意地设定。在至少一个对象零件的劣化度超过阈值的情况下，通过第一检查做出不良判定(在S32中为“是”)，处理进入S33。通过第一检查判定为不良意味着在任一个对象零件中产生了起因于经年劣化的异常。

在S33中，服务器500对车辆1执行规定的更换处理。在规定的更换处理中，执行第一检查的结果的记录、报告以及发送中的至少一个。第一检查的结果包括表示需要更换的零件(即，劣化度超过阈值的对象零件)的信息。服务器500也可以将第一检查的结果记录于存储装置503。服务器500也可以向车辆1或规定的终端发送第一检查的结果，并使规定的报告装置(例如HMI230或移动终端UT)执行促使车辆1的用户进行零件更换的报告处理。服务器500也可以在S33中禁止车辆1的运用，并执行用于安排代替的车辆的处理。

当上述S33的处理被执行时，处理进入S34。另一方面，在车辆1中任一个对象零件的劣化度均未超过阈值的情况下，通过第一检查做出良好判定(在S32中为“否”)，处理进入S34而不进行更换处理(S33)。在S34中，服务器500判断车辆1是否为自动驾驶中。服务器500例如在接收到表示车辆1的自动驾驶结束的结束信号的情况下，判断为车辆1的自动驾驶结束了。在车辆1为自动驾驶中的情况下(在S34中为“是”)，处理返回至最初的步骤(S31)。在车辆1不为自动驾驶中的情况下(在S34中为“否”)，图9所示的一系列的处理结束。

图10是表示由服务器500执行的涉及第二检查的处理的流程图。该流程图所示的处理例如在每次服务器500从车辆1接收到第二检查信号时开始。服务器500从车辆1接收到第二检查信号意味着在车辆1中产生了轮胎的漏气(爆胎)。

参照图1～图6以及图10，在S40中，服务器500对车辆1执行规定的更换处理。在S40中，也可以与图9的S33同样地执行检查结果(第二检查的结果)的记录、报告以及发送中的至少一个。第二检查的结果包括表示需要更换或修理的轮胎(产生了漏气的轮胎)的信息。当S40的处理被执行时，图10所示的一系列的处理结束。

如以上说明的那样，本实施方式的车辆检查方法包括图7～图10所示的处理。在图7的S13(第一发送过程)中，车辆1向服务器500发送表示在自动驾驶中通过搭载于车辆1的第一传感器检测到的第一状态的信号(第一检查信号)。在图9的S32(第一判定过程)中，服务器500使用从车辆1接收到的第一检查信号所示的第一状态，对车辆1判定第一检查项目的良否。在图8的S22(第二判定过程)中，车辆1使用在自动驾驶中通过搭载于车辆1的第二传感器检测到的第二状态来判定第二检查项目的良否。在图8的S23(第二发送过程)中，在对第二检查项目判定为不良的情况下，车辆1向服务器500发送表示第二检查项目的判定结果的信号(第二检查信号)。根据这样的车辆检查方法，能减轻对自动驾驶车辆(例如车辆1)进行管理的服务器500的负荷，并且能适当地进行自动驾驶车辆的维护。

涉及第一检查和第二检查的处理不限于上述的方案。例如，涉及第一检查的处理也可以如以下说明的那样进行变形。以下，使用图11～图13对第一检查的变形例进行说明。

在以下说明的变形例中，服务器500执行图11所示的一系列的处理。此外，车辆1的控制装置150执行图12所示的一系列的处理来代替图7所示的处理。而且，服务器500执行图13所示的一系列的处理来代替图9所示的处理。

图11是表示关于第一检查的变形例，由服务器500执行的请求处理的流程图。该流程图所示的处理以规定周期被反复执行。

参照图1～图6以及图11，在S51中，服务器500从所登记的多个车辆中提取自动驾驶中的车辆。在该变形例中，登记到服务器500的各车辆具有图1、图2以及图5所示的构成，并被配置为通过图3所示的处理来进行自动驾驶。服务器500也可以根据上述的开始信号和结束信号(参照图3)来判断各车辆是否为自动驾驶中。

在接下来的S52中，服务器500基于车型来对自动驾驶中的车辆进行分类。同一车型的车辆被分类为相同的组。图11所示的表T2示出了登记到服务器500的多个车辆中，通过车辆ID“V－12”、“V－16”、“V－37”、……辨别的各车辆为自动驾驶中，并且为相同的车型(车型A)。此外，表T2示出了登记到服务器500的多个车辆中，通过车辆ID“V－6”、“V－35”、“V－58”、……辨别的各车辆为自动驾驶中，并且为相同的车型(车型B)。车型的划分也可以按照汽车厂商的产品目录来确定。

在接下来的S53中，服务器500按每个组(按每个车型)决定一台代表车辆。代表车辆的决定方法是任意的。不过，若一旦代表车辆被决定，则不变更代表车辆直到该代表车辆停止自动驾驶为止。代表车辆可以随机地决定，也可以按照规定的基准来决定。可以将组中车辆ID最小的车辆选为代表车辆。例如，可以将车型A的组中通过车辆ID“V－12”辨别的车辆、车型B的组中通过车辆ID“V－6”辨别的车辆选为代表车辆。此外，也可以将各组中与感测(sensing)相关的规格高的车辆优先选为代表车辆。

在接下来的S54中，服务器500向各组的代表车辆发送请求第一状态的信号(以下也称为“请求信号”)。当S54的处理被执行时，返回至最初的步骤(S51)。

图12是表示关于第一检查的变形例，由代表车辆执行的发送处理的流程图。例如当代表车辆从服务器500接收到请求信号时，该流程图所示的处理开始。

参照图1～图6以及图12，代表车辆的控制装置150在S11A、S13A中分别进行与图7的S11、S13同样的处理，将通过搭载于代表车辆的第一传感器检测到的表示第一状态的第一检查信号与代表车辆的车辆ID一起发送向服务器500。当与代表车辆相关的第一检查信号的发送(S13A)完成时，图12所示的一系列的处理结束。图12所示的一系列的处理仅由代表车辆执行。由于上述的处理，代表车辆的电力被消耗，因此，可以由车辆管理者向代表车辆的用户支付激励(报酬)。各用户的激励可以由服务器500来管理。

图13是表示关于第一检查的变形例，由服务器500执行的判定处理的流程图。例如当服务器500从代表车辆接收到第一检查信号时，该流程图所示的处理开始。

参照图1～图6以及图13，在S31A中，服务器500进行与图9的S31同样的处理，推定代表车辆的各对象零件(MG20、电池160、悬架170、制动装置180)的当前的劣化度。接下来，服务器500在S32A中进行与图9的S32同样的处理，判定在代表车辆中任一个对象零件是否产生了异常。在该变形例中，在S31A和S32A中执行的车载零件的检查相当于与代表车辆相关的第一检查。当通过与代表车辆相关的第一检查做出不良判定时(在S32A中为“是”)，处理进入S33A。服务器500在通过与代表车辆相关的第一检查判定为不良的情况下(在S32A中为“是”)，判定为在与代表车辆属于相同的组的所有的车辆中产生了起因于经年劣化的零件异常。

在S33A中，服务器500对与代表车辆属于相同的组的所有的车辆执行规定的更换处理。与图9的S33同样地，规定的更换处理可以是第一检查的结果的记录、报告以及发送中的至少一个。不过，在S33A中，不仅对代表车辆执行规定的更换处理，也对与代表车辆属于相同的组的所有的车辆执行规定的更换处理。例如，在通过与图11所示的车型A的组的代表车辆(例如，通过车辆ID“V－12”辨别的车辆)相关的第一检查判定为不良的情况下(在S32A中为“是”)，在S33A中，对通过车辆ID“V－12”、“V－16”、“V－37”、……辨别的各车辆执行规定的更换处理。当S33A的处理被执行时，图13所示的一系列的处理结束。

另一方面，在代表车辆中任一个对象零件的劣化度均未超过规定的阈值的情况下，通过第一检查做出良好判定(在S32A中为“否”)，图13所示的一系列的处理结束而不进行更换处理(S33A)。

如以上说明的那样，在上述变形例中，由服务器500管理的多个车辆分别具备控制装置150、第一传感器(例如，车轮速度传感器127A、127B、姿势用传感器270、监视模块160a、重量传感器170a以及制动器传感器180a)、第二传感器(例如气压传感器20b)以及通信装置130(参照图1、图2以及图5)。搭载于车辆的控制装置150被配置为执行用于使该车辆通过自动驾驶进行行驶的控制(参照图3)。服务器500从多个车辆中选择代表车辆(第一车辆)(参照图11)。代表车辆的通信装置130向服务器500依次发送在代表车辆的自动驾驶中通过第一传感器检测到的第一状态(参照图11和图12)。服务器500使用从代表车辆依次接收的第一状态，对与代表车辆属于相同的组的多个车辆(第一车辆和第二车辆)分别执行第一检查(参照图13)。属于相同的组的各车辆为同一车型，并且同时通过自动驾驶进行行驶。服务器500作为本公开的“第一检查装置”的一个例子发挥功能。

在上述构成中，使用从第一车辆(代表车辆)向服务器500依次发送的第一状态来进行与第二车辆(与代表车辆属于相同的组的代表车辆以外的车辆)相关的第一检查。能通过不从第二车辆向至服务器500发送通过第二车辆的第一传感器得到的检测值来减少从第二车辆向服务器500发送的信息量。根据上述构成，能减少从各车辆向服务器500发送的信息量，并且能进行许多车辆的检查。需要说明的是，各车辆被分类的划分(组)不限于按每个车型的组。分组的方法可以适当变更。

关于第二检查，在上述变形例中也与上述的实施方式同样地进行。即，各车辆的控制装置150执行图8所示的处理，并且服务器500执行图10所示的处理。由服务器500管理的各车辆的控制装置150作为本公开的“第二检查装置”的一个例子发挥功能。各车辆的控制装置150使用在该车辆的自动驾驶中通过第二传感器检测到的第二状态来执行第二检查，在通过第二检查判定为不良的情况下，向服务器500发送第二检查的结果(参照图8)。按每个车辆执行图8所示的处理，并在各车辆中执行第二检查。通过这样的构成，除了上述的第一检查之外，还能适当地进行实时性高的第二检查(参照图4)。

第一检查项目和第二检查项目不限于图4所示的项目，可以适当进行变更。例如，作为第二检查项目，也可以采用确认漏液(例如，制动器漏油这样的漏油)的有无的项目来代替确认轮胎的漏气的有无的项目，或者除了确认轮胎的漏气的有无的项目之外还采用确认漏液(例如，制动漏油这样的漏油)的有无的项目。在具备发动机(内燃机)的车辆中，也可以采用确认发动机冷却水温异常的有无的项目来作为第二检查项目。

车辆的构成不限于在上述实施方式中进行了说明的构成(参照图1、图2以及图5)。基础车辆也可以在无加装的状态下具有自动驾驶功能。自动驾驶的等级既可以是完全自动驾驶(等级5)，也可以是附加条件的自动驾驶(例如等级4)。车辆的构成也可以适当地变更为无人行驶专用的构成。例如，无人行驶专用的车辆也可以不具备用于供人对车辆进行操作的零件(方向盘等)。车辆可以具备太阳能板，也可以具备飞行功能。车辆不限于轿车，也可以是公共汽车或卡车。车辆也可以是个人所有的车辆(POV)。车辆也可以是根据用户的使用目的定制的多目的车辆。车辆也可以是移动店铺车辆、自动驾驶出租车(robotaxi)、无人输送车(AGV)或农业机械。车辆也可以是无人或单人乘坐的小型BEV(例如微型托盘车(Micro Pallet))。

本次公开的实施方式应该被认为在所有方面都是示例性的，而不是限制性的。通过本公开示出的技术的范围通过权利要求书来示出而不通过上述的实施方式的说明示出，意图在于包括与权利要求书等同的意思和范围内的所有的变更。

Claims (12)

1.一种车辆管理***，包括车辆和服务器，其中，

所述服务器具备第一检查装置，该第一检查装置执行对第一检查项目判定良否的第一检查，

所述车辆具备：

控制装置，执行用于使该车辆通过自动驾驶进行行驶的控制；

第二检查装置，执行对与所述第一检查项目不同的第二检查项目判定良否的第二检查；

第一传感器，检测与所述第一检查项目对应的第一状态；

第二传感器，检测与所述第二检查项目对应的第二状态；以及

通信装置，

所述通信装置被配置为向所述服务器依次发送在所述车辆的自动驾驶中通过所述第一传感器检测到的所述第一状态，

所述第一检查装置被配置为使用从所述车辆依次接收的所述第一状态，对所述车辆执行所述第一检查，

所述第二检查装置使用在所述车辆的自动驾驶中通过所述第二传感器检测到的所述第二状态来执行所述第二检查，在通过所述第二检查判定为不良的情况下，所述通信装置向所述服务器发送所述第二检查的结果。

2.根据权利要求1所述的车辆管理***，其中，

与所述第一检查项目相比，所述第二检查项目要求的实时性更高。

3.根据权利要求1或2所述的车辆管理***，其中，

所述第一检查项目包括确认起因于经年劣化的零件异常的有无的项目，

所述第二检查项目包括确认轮胎的漏气的有无的项目。

4.根据权利要求1～3中任一项所述的车辆管理***，其中，

所述第一状态包括所述车辆的重量、所述车辆的车速、所述车辆的停车次数、所述车辆的急制动次数、所述车辆的位置以及搭载于所述车辆的蓄电装置的SOC中的至少一个，

所述第二状态包括轮胎的气压。

5.根据权利要求1～4中任一项所述的车辆管理***，其中，

在所述车辆的自动驾驶中通过所述第一传感器检测到的所述第一状态与最近发送的所述第一状态的偏离程度超过规定水准的情况下，所述通信装置向所述服务器发送通过所述第一传感器检测到的所述第一状态，

在所述偏离程度不超过所述规定水准的情况下，所述通信装置不向所述服务器发送通过所述第一传感器检测到的所述第一状态。

6.一种车辆管理***，包括第一车辆、第二车辆以及服务器，其中，

所述服务器具备第一检查装置，该第一检查装置执行对第一检查项目判定良否的第一检查，

所述第一车辆和所述第二车辆分别具备：

控制装置，执行用于使该车辆通过自动驾驶进行行驶的控制；

第二检查装置，执行对与所述第一检查项目不同的第二检查项目判定良否的第二检查；

第一传感器，检测与所述第一检查项目对应的第一状态；

第二传感器，检测与所述第二检查项目对应的第二状态；以及

通信装置，

所述第一车辆的所述通信装置被配置为向所述服务器依次发送在所述第一车辆的自动驾驶中通过所述第一车辆的所述第一传感器检测到的所述第一状态，

所述第一检查装置被配置为使用从所述第一车辆依次接收的所述第一状态，分别对所述第一车辆和所述第二车辆执行所述第一检查，

所述第一车辆和所述第二车辆各自的所述第二检查装置使用在该车辆的自动驾驶中通过所述第二传感器检测到的所述第二状态来执行所述第二检查，在通过所述第二检查判定为不良的情况下，向所述服务器发送所述第二检查的结果。

7.根据权利要求6所述的车辆管理***，其中，

所述第一车辆和所述第二车辆同时通过自动驾驶进行行驶。

8.根据权利要求6或7所述的车辆管理***，其中，

所述第一车辆和所述第二车辆为同一车型。

9.一种车辆检查方法，包括：

车辆向服务器发送在自动驾驶中通过搭载于该车辆的第一传感器检测到的第一状态；

所述服务器使用从所述车辆接收到的所述第一状态，对所述车辆判定第一检查项目的良否；

所述车辆使用在自动驾驶中通过搭载于该车辆的第二传感器检测到的第二状态来判定第二检查项目的良否；以及

在对所述第二检查项目判定为不良的情况下，所述车辆向所述服务器发送所述第二检查项目的判定结果。

10.根据权利要求9所述的车辆检查方法，其中，

与所述第一检查项目相比，所述第二检查项目要求的实时性更高。

11.根据权利要求9或10所述的车辆检查方法，其中，

所述第一检查项目包括确认起因于经年劣化的零件异常的有无的项目，

所述第二检查项目包括确认轮胎的漏气的有无的项目。

12.根据权利要求9～11中任一项所述的车辆检查方法，其中，

所述第一状态包括所述车辆的重量、所述车辆的车速、所述车辆的停车次数、所述车辆的急制动次数、所述车辆的位置以及搭载于所述车辆的蓄电装置的SOC中的至少一个，

所述第二状态包括轮胎的气压。