车辆管理装置以及车辆管理方法与流程

1.本公开涉及车辆管理装置以及车辆管理方法。


背景技术：

2.在日本特开2020－074169中公开了一种调度自动驾驶车辆的车辆系统。
3.可以认为在上述车辆系统中被调度的各自动驾驶车辆一边定期地接受性能检查一边被运用。并且，可以认为：在搭载于自动驾驶车辆的各种部件中的任一个在性能检查中被评价为性能不足的情况下，进行部件的更换。
4.然而，在运营商所管理的自动驾驶车辆的台数多的情况下，存在性能检查的次数过多这一问题。当性能检查的次数过多时，存在车辆的管理变得繁杂，或者需要大规模的检查设备，或者导致检查成本的上升的可能性。


技术实现要素：

5.本公开是为了解决上述问题而作出的，其目的在于减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
6.本公开的第一观点的车辆管理装置包括第一驾驶部、第二驾驶部、检查部以及保养部。第一驾驶部被配置为发送用于使车组中所包括的第一车辆在第一条件下自动驾驶的第一信号。第二驾驶部被配置为发送用于使车组中所包括的作为第一车辆以外的车辆的第二车辆在与第一条件相比车辆不易劣化的第二条件下自动驾驶的第二信号。检查部被配置为：在第一车辆结束了在第一条件下的自动驾驶之后，指示第一车辆的性能检查。保养部被配置为使用与第一车辆相关的性能检查的结果来决定第二车辆的维护时期。
7.在上述构成中，对第一车辆进行性能检查。性能检查可以是依照所谓的车检的检查。通过性能检查确认到性能异常(超过容许水平的性能下降)的部件可以被更换为新的部件。需要说明的是，在性能异常中，除了部件故障之外，还包括成为部件的劣化程度大于规定水准的状态等。
8.在上述构成中，使用与第一车辆相关的性能检查的结果来决定第二车辆的维护时期。在第一车辆在与第二车辆的驾驶条件(第二条件)相比车辆容易劣化的条件(第一条件)下被自动驾驶之后，执行与第一车辆相关的性能检查。因此，在与第一车辆相关的性能检查中判定为第一车辆的性能正常的情况下，可以推定为第二车辆的性能也正常。即，在通过与第一车辆相关的性能检查判定为第一车辆的性能正常的情况下，可以省略与第二车辆相关的性能检查。根据上述构成，能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
9.车辆管理装置既可以由一个计算机构成，也可以包括多个计算机。第一驾驶部和第二驾驶部可以向第一车辆和第二车辆分别发送第一信号和第二信号。或者，在包括对车组中所包括的各车辆的自动驾驶进行控制的服务器(以下，也称为“驾驶控制服务器”)的系统中，也可以从第一驾驶部和第二驾驶部向驾驶控制服务器发送第一信号和第二信号。检
查部可以向结束了在第一条件下的自动驾驶的第一车辆指示接受性能检查。或者，检查部也可以向驾驶控制服务器指示使结束了在第一条件下的自动驾驶的第一车辆前往检查场所。保养部可以发送请求部件的维护的信号(以下，也称为“维护信号”)。保养部也可以向规定的商家委托维护。作为维护的例子，可列举出检查、修理、更换。保养部也可以发送请求部件的更换的维护信号。保养部也可以将维护信号发送给车辆的管理者的终端(例如，车辆的管理者所携带的移动终端)。或者，保养部也可以将维护信号发送给车辆。接收到维护信号的车辆的计算机可以执行用于执行维护信号所请求的部件维护的处理(以下，也称为“维护处理”)。维护处理可以是将维护时期到来了与作为维护的对象的部件(例如，部件的名称或位置)一起报告给车辆的管理者的处理。或者，维护处理也可以是委托维护的处理。
10.也可以是，保养部被配置为：在第二车辆结束了在第二条件下的自动驾驶之后，使用与第一车辆相关的性能检查的结果来判断是否进行第二车辆的维护。根据这样的构成，易于适当地决定进行第二车辆的维护的定时。例如，可以对与在第一车辆中确认到异常的部件对应的部件进行第二车辆的部件维护。
11.也可以是，自动驾驶的行驶路线在第一条件和第二条件下相同。
12.通过自动驾驶在相同的路线中进行了行驶的各车辆容易在相同的部位劣化。不过，通过改变行驶路线以外的条件，能使由自动驾驶引起的劣化的进展度在第一车辆和第二车辆中不同。根据上述构成，第一车辆的劣化的进展度和第二车辆的劣化的进展度易于相关。因此，易于使用与第一车辆相关的性能检查的结果来适当地评价第二车辆的性能。
13.也可以是，自动驾驶的行驶目的在第一条件和第二条件下相同。
14.以相同的目的执行了自动驾驶的各车辆容易在相同的部位劣化。例如，在以移动办公室的用途执行了自动驾驶的车辆中，由于在移动中使用车载设备，因此蓄电装置的劣化容易进展。此外，在以旅客输送的用途执行了自动驾驶的车辆中，由于人的上下车，悬架的劣化容易进展。通过使自动驾驶的行驶目的在第一车辆和第二车辆中相同，第一车辆的劣化的进展度和第二车辆的劣化的进展度易于相关。因此，易于使用与第一车辆相关的性能检查的结果来适当地评价第二车辆的性能。
15.也可以是，第一条件中的行驶距离、重量以及车速中的至少一个被设定为使得与第二条件相比车辆容易劣化。
16.根据上述构成，易于设定与第二条件相比车辆容易劣化的第一条件。基于自动驾驶的车辆的行驶距离越长，车辆越容易劣化。自动驾驶中的车速越大，车辆越容易劣化。自动驾驶中的车辆的重量越大，车辆越容易劣化。上述重量可以是对车身的重量加上乘坐于车辆的人的重量和装载于车辆的物的重量而得到的总重量。或者，上述重量也可以是仅车身的重量。车辆的重量可以基于车辆的搭乘人数来推定。
17.也可以是，与第一车辆相关的性能检查的结果包括表示第一车辆的性能的第一数据。也可以是，保养部被配置为：进行用于将第一数据变换为表示第二车辆的性能的第二数据的运算，并基于第二数据来决定第二车辆的维护时期。
18.根据上述构成，能在不进行第二车辆的性能检查的情况下，通过运算来获取表示第二车辆的性能的第二数据。上述保养部可以使用规定的变换系数来将第一数据变换为第二数据。
19.也可以是，上述的任一个车辆管理装置还包括判断部，该判断部判断所请求的自
动驾驶条件符合第一条件和第二条件中的哪一个。并且，也可以是，在所请求的自动驾驶条件符合第一条件的情况下，第一驾驶部发送第一信号。此外，也可以是，在所请求的自动驾驶条件符合第二条件的情况下，第二驾驶部发送第二信号。
20.根据上述构成，能在所请求的自动驾驶条件符合第一条件的情况下，使第一车辆在第一条件下自动驾驶，在所请求的自动驾驶条件符合第二条件的情况下，使第二车辆在第二条件下自动驾驶。因此，能根据所请求的自动驾驶条件来适当地运用第一车辆和第二车辆中的每一个。
21.本公开的第二观点的车辆管理方法包括以下所示的第一自动驾驶过程、第二自动驾驶过程、性能检查过程以及维护过程。
22.在第一自动驾驶过程中，使第一车辆在第一条件下自动驾驶。在第二自动驾驶过程中，使第二车辆在与第一条件相比车辆不易劣化的第二条件下自动驾驶。在性能检查过程中，在第一车辆结束了在第一条件下的自动驾驶之后，进行第一车辆的性能检查。在维护过程中，在通过第一车辆的性能检查作出了不良判定的情况下，执行第二车辆的维护。
23.根据上述车辆管理方法，也与前述的车辆管理装置同样地，能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
24.本公开的第三观点的车辆管理方法包括以下所示的第一自动驾驶过程、第二自动驾驶过程、性能检查过程、变换过程以及维护过程。
25.在第一自动驾驶过程中，使第一车辆在第一条件下自动驾驶。在第二自动驾驶过程中，使第二车辆在与第一条件相比车辆不易劣化的第二条件下自动驾驶。在性能检查过程中，在第一车辆结束了在第一条件下的自动驾驶之后，进行第一车辆的性能检查，获取表示第一车辆的性能的第一数据。在变换过程中，将第一数据变换为表示第二车辆的性能的第二数据。在维护过程中，在第二数据表示第二车辆的性能不良的情况下，执行第二车辆的维护。
26.根据上述车辆管理方法，也与前述的车辆管理装置同样地，能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
27.根据本公开，能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
附图说明
28.以下，参照附图，对本发明的示例性实施例的特征、优点以及技术和工业意义进行说明，其中，相同的附图标记表示相同的元件，其中：
29.图1是表示本公开的实施方式1的车辆的概略构成的图。
30.图2是表示图1所示的车辆的构成的详情的图。
31.图3是表示本公开的实施方式1的自动驾驶控制的处理过程的流程图。
32.图4是用于对本公开的实施方式1的车辆管理装置的构成进行说明的图。
33.图5是表示在本公开的实施方式1的车辆管理方法中车辆管理装置为了代表车辆而执行的管理处理的流程图。
34.图6是表示在本公开的实施方式1的车辆管理方法中车辆管理装置为了普通车辆而执行的管理处理的流程图。
35.图7是表示本公开的实施方式2的车辆管理装置的构成的图。
36.图8是表示在本公开的实施方式2的车辆管理方法中车辆管理装置为了代表车辆而执行的管理处理的流程图。
37.图9是表示在本公开的实施方式2的车辆管理方法中车辆管理装置为了普通车辆而执行的管理处理的流程图。
38.图10是表示本公开的实施方式3的车辆管理装置的构成的图。
39.图11是表示在本公开的实施方式3的车辆管理方法中车辆管理装置为了运行车辆而执行的管理处理的流程图。
具体实施方式
40.以下，参照附图对本公开的实施方式详细地进行说明。需要说明的是，对图中相同或相当的部分标注相同的附图标记且不重复进行其说明。
41.[实施方式1]
[0042]
图1是表示本公开的实施方式的车辆的概略构成的图。参照图1，车辆1具备自动驾驶套件(以下，记为“adk(autonomous driving kit)”)200和车辆平台(以下，记为“vp(vehicle platform)”)2。
[0043]
vp2包括基础车辆100的控制系统和设于基础车辆100内的车辆控制接口盒(以下，记为“vcib(vehicle control interface box)”)111。vcib111可以通过can(controller area network：控制器局域网络)之类的车内网络与adk200通信。需要说明的是，在图1中，基础车辆100和adk200示出于分离的位置，但adk200实际上装配于基础车辆100。在该实施方式中，adk200装配于基础车辆100的车顶。不过，adk200的装配位置可以适当变更。
[0044]
基础车辆100例如是市售的xev(电动车)。xev是将电力用作动力源的全部或一部分的车辆。在该实施方式中，采用bev(battery electric vehicle)(电动汽车)来作为基础车辆100。不过，不限于此，基础车辆100也可以是bev以外的xev(hev(hybrid electric vehicle：混合动力汽车)、phev(plug-in hybrid electric vehicle：插电式混合动力汽车)、fcev(fuel cell electric vehicle：燃料电池电动汽车)等)。基础车辆100所具备的车轮的数量例如为四个。不过，不限于此，基础车辆100所具备的车轮的数量既可以为三个，也可以为五个以上。
[0045]
基础车辆100的控制系统除了综合控制管理器115之外，还包括用于对基础车辆100进行控制的各种系统和各种传感器。综合控制管理器115基于来自基础车辆100中所包括的各种传感器的信号(传感器检测信号)来综合地控制与基础车辆100的动作有关的各种系统。
[0046]
在该实施方式中，综合控制管理器115包括控制装置150。控制装置150包括处理器151、ram(random access memory：随机存取存储器)152以及存储装置153。作为处理器151，例如可以采用cpu(central processing unit：中央处理器)。ram152作为暂时地存储由处理器151处理的数据的作业用存储器发挥功能。存储装置153被配置为能保存所储存的信息。存储装置153例如包括rom(read only memory：只读存储器)和可重写的非易失性存储器。在存储装置153中，除了程序之外，还存储有在程序中使用的信息(例如，映射(map)、公式以及各种参数)。在该实施方式中，处理器151执行存储于存储装置153的程序，由此执行
各种车辆控制(例如，按照来自adk200的指示的自动驾驶控制)。不过，这些处理也可以由专用的硬件(电子电路)执行，而不是由软件执行。需要说明的是，控制装置150所具备的处理器的数量是任意的，可以按每个规定的控制来准备处理器。
[0047]
基础车辆100包括制动系统121、转向系统122、动力传动系统123、主动安全系统125以及车身系统126。这些系统由综合控制管理器115综合控制。在该实施方式中，各系统具备计算机。并且，每个系统的计算机通过车内网络(例如，can)与综合控制管理器115通信。以下，将各系统所具备的计算机称为“ecu(electronic control unit：电子控制单元)”。
[0048]
制动系统121包括设于基础车辆100的各车轮的制动装置和对制动装置进行控制的ecu。在该实施方式中，采用液压式盘式制动装置来作为制动装置。基础车辆100具备车轮速度传感器127a、127b。车轮速度传感器127a设于基础车辆100的前轮，检测前轮的转速。车轮速度传感器127b设于基础车辆100的后轮，检测后轮的转速。制动系统121的ecu将通过车轮速度传感器127a、127b检测到的各车轮的旋转方向和转速输出给综合控制管理器115。
[0049]
转向系统122包括基础车辆100的转向装置和对转向装置进行控制的ecu。转向装置例如包括能通过致动器来调整转向角的齿条(rack)&小齿轮(pinion)式的eps(electric power steering：电动助力转向系统)。基础车辆100具备小齿轮角传感器128。小齿轮角传感器128检测与构成转向装置的致动器的旋转轴连结的小齿轮的旋转角(小齿轮角)。转向系统122的ecu将通过小齿轮角传感器128检测到的小齿轮角输出给综合控制管理器115。
[0050]
动力传动系统123包括：epb(electric parking brake：电子驻车制动系统)，设于基础车辆100所具备的车轮中的至少一个；p－lock(驻车挡锁止)装置，设于基础车辆100的变速器；换挡装置，被配置为能选择挡位；基础车辆100的驱动源；以及ecu，对动力传动系统123中所包括的各装置进行控制。epb与前述的制动装置分开设置，通过电动致动器来使车轮成为固定状态。p－lock装置例如通过能由致动器驱动的驻车锁止爪来使变速器的输出轴的旋转位置成为固定状态。详情将在后文叙述，但在该实施方式中，采用从蓄电装置接受电力的供给的马达来作为基础车辆100的驱动源。动力传动系统123的ecu将由epb和p－lock装置中的每一个进行的固定化的有无、由换挡装置选择出的挡位以及蓄电装置和马达各自的状态输出给综合控制管理器115。
[0051]
主动安全系统125包括对行驶中的车辆1判定碰撞的可能性的ecu。基础车辆100具备检测包括车辆1的前方和后方的周边状况的摄像机129a和雷达传感器129b、129c。主动安全系统125的ecu使用从摄像机129a和雷达传感器129b、129c接收到的信号来判定是否存在碰撞的可能性。在通过主动安全系统125判定为存在碰撞的可能性的情况下，综合控制管理器115向制动系统121输出制动指令来使车辆1的制动力增加。该实施方式的基础车辆100从初始(出厂时)具备主动安全系统125。但是，不限于此，也可以采用能对基础车辆后装的主动安全系统。
[0052]
车身系统126具备车身系统部件(例如，方向指示器、喇叭以及擦拭器)和对车身系统部件进行控制的ecu。车身系统126的ecu在手动模式下，按照用户操作来控制车身系统部件，在自主模式下，按照从adk200经由vcib111和综合控制管理器115接收的指令来控制车身系统部件。
[0053]
车辆1被配置为能自动驾驶。vcib111作为车辆控制接口发挥功能。在车辆1通过自
field communication：近场通信)或bluetooth(蓝牙)(注册商标)之类的近距离通信。
[0059]
移动终端ut是由车辆1的用户携带的终端。在该实施方式中，作为移动终端ut，采用具备触摸面板显示器的智能手机。不过，不限于此，作为移动终端ut，可以采用任意的移动终端，也可以采用笔记本电脑(laptop)、平板终端、可穿戴设备(例如，智能手表或智能眼镜)或电子钥匙等。
[0060]
上述的车辆1能被用作maas(mobility as a service：出行即服务)系统的构成要素之一。maas系统例如包括mspf(mobility service platform：移动出行服务平台)。mspf是连接各种移动出行服务(例如，由拼车(ride sharing)运营商、共享汽车(car sharing)运营商、保险公司、租车(rental car)运营商、出租车运营商等提供的各种移动出行服务)的统一平台。服务器500是在mspf中进行用于移动出行服务的信息的管理和开放的计算机。服务器500管理各种移动出行的信息，并根据来自运营商的请求来提供信息(例如，api和与移动出行间的协作相关的信息)。提供服务的运营商能使用在mspf上开放的api来利用mspf所提供的各种各样的功能。例如，adk的开发所需的api在mspf上开放。
[0061]
图2是表示车辆1的构成的详情的图。参照图1的同时参照图2，adk200包括用于进行车辆1的自动驾驶的自动驾驶系统(以下，记为“ads(autonomous driving system)”)202。ads202包括计算机210、hmi(human machine interface：人机接口)230、识别用传感器260、姿势用传感器270以及传感器清洁器290。
[0062]
计算机210具备处理器和存储利用了api的自动驾驶软件的存储装置，被配置为能通过处理器来执行自动驾驶软件。通过自动驾驶软件来执行与自动驾驶相关的控制(参照后述的图3)。自动驾驶软件可以通过ota(over the air：空中下载)依次更新。计算机210还具备通信模块210a和210b。
[0063]
hmi230是用于用户与计算机210交换信息的装置。hmi230包括输入装置和报告装置。用户能通过hmi230向计算机210进行指示或请求，或者通过hmi230变更在自动驾驶软件中使用的参数(不过，限于被允许变更的参数)的值。hmi230可以是兼具输入装置和报告装置这两方的功能的触摸面板显示器。
[0064]
识别用传感器260包括获取用于识别车辆1的外部环境的信息(以下，也称为“环境信息”)的各种传感器。识别用传感器260获取车辆1的环境信息，并输出给计算机210。环境信息用于自动驾驶控制。在该实施方式中，识别用传感器260包括对车辆1的周围(包括前方和后方)进行拍摄的摄像机和通过电磁波或声波来感测障碍物的障碍物感测器(例如，毫米波雷达和/或激光雷达)。计算机210例如可以使用从识别用传感器260接收的环境信息来识别存在于从车辆1能识别的范围的人、物体(其他车辆、柱、护栏等)以及道路上的线(例如，中心线)。也可以将人工智能(ai：artificial intelligence)或图像处理用处理器用于识别。
[0065]
姿势用传感器270获取与车辆1的姿势相关的信息(以下，也称为“姿势信息”)，并输出给计算机210。姿势用传感器270包括检测车辆1的加速度、角速度以及位置的各种传感器。在该实施方式中，姿势用传感器270包括imu(inertial measurement unit：惯性测量单元)和gps(global positioning system：全球定位系统)传感器。imu检测车辆1的前后方向、左右方向和上下方向各自的加速度以及车辆1的侧倾(roll)方向、俯仰(pitch)方向和横摆(yaw)方向各自的角速度。gps传感器使用从多个gps卫星接收的信号来检测车辆1的位
置。在汽车和航空器的领域中，将imu与gps组合来以高的精度计测姿势的技术是公知的。计算机210例如也可以利用这样的公知的技术来根据上述姿势信息计测车辆1的姿势。
[0066]
传感器清洁器290是去除在车外暴露于外部空气的传感器(例如，识别用传感器260)的污垢的装置。例如，传感器清洁器290可以被配置为使用清洗液和擦拭器来清洁摄像机的镜头和障碍物感测器的出射口。
[0067]
在车辆1中，为了提高安全性，使规定的功能(例如，制动、转向以及车辆固定)具有冗余性。基础车辆100的控制系统102具备多个实现同等功能的系统。具体而言，制动系统121包括制动系统121a和121b。转向系统122包括转向系统122a和122b。动力传动系统123包括epb系统123a和p－lock系统123b。各系统具备ecu。在实现同等功能的多个系统中，即使在一方发生异常，另一方也正常地进行动作，由此在车辆1中该功能正常地工作。
[0068]
vcib111包括vcib111a和vcib111b。vcib111a和vcib111b中的每一个包括计算机。计算机210的通信模块210a、210b被配置为能分别与vcib111a、vcib111b的计算机通信。vcib111a和vcib111b被连接为能相互通信。vcib111a和vcib111b中的每一个能单独地进行动作，即使在一方发生异常，另一方也正常地进行动作，由此vcib111正常地进行动作。vcib111a和vcib111b均经由综合控制管理器115连接于上述各系统。不过，如图2所示，在vcib111a和vcib111b中，连接目标一部分不同。
[0069]
在该实施方式中，对于使车辆1加速的功能，未使其具有冗余性。动力传动系统123包括推进系统123c来作为用于使车辆1加速的系统。
[0070]
车辆1被配置为能在自主模式与手动模式之间进行切换。adk200从vcib111接收的api信号中包括表示车辆1是自主模式和手动模式中的哪一个状态的信号(以下，记为“自主状态”)。用户能通过规定的输入装置(例如，hmi230或移动终端ut)来选择自主模式和手动模式中的任一个。当由用户选择了任一个驾驶模式时，车辆1成为所选择的驾驶模式，选择结果被反映至自主状态。不过，如果车辆1未成为能自动驾驶的状态，则即使用户选择自主模式也不会转变为自主模式。车辆1的驾驶模式的切换可以由综合控制管理器115进行。综合控制管理器115可以根据车辆的状况在自主模式与手动模式之间进行切换。
[0071]
在车辆1是自主模式时，计算机210从vp2获取车辆1的状态，并设定车辆1的下一动作(例如，加速、减速以及转弯)。然后，计算机210输出用于实现所设定的车辆1的下一动作的各种指令。计算机210执行api软件(即，利用了api的自动驾驶软件)，由此与自动驾驶控制相关的指令从adk200通过vcib111被发送给综合控制管理器115。
[0072]
图3是表示在该实施方式的自动驾驶控制中adk200所执行的处理的流程图。在车辆1是自主模式时，以与api对应的周期(api周期)重复执行该流程图所示的处理。当车辆1的驾驶模式从手动模式切换为自主模式时，表示自动驾驶开始的开始信号与车辆1的标识信息一起从车辆1(通信装置130)被发送给服务器500，并且开始以下说明的图3所示的一系列的处理。以下，将流程图中的各步骤仅记为“s”。
[0073]
参照图1和图2的同时参照图3，在s101中，计算机210获取当前的车辆1的信息。例如，计算机210从识别用传感器260和姿势用传感器270获取车辆1的环境信息和姿势信息。进而，计算机210获取api信号。在该实施方式中，在车辆1是自主模式和手动模式中的任一个的情况下，都从vcib111向adk200实时地依次输出表示车辆1的状态的api信号。为了提高自动驾驶控制的精度，可以在自主模式下以比手动模式短的周期从综合控制管理器115朝
向adk200依次发送车辆1的状态。在计算机210所获取的api信号中，除了前述的自主状态之外，还包括表示通过车轮速度传感器127a、127b检测到的各车轮的旋转方向和转速的信号等。
[0074]
在s102中，计算机210基于在s101中获取到的车辆1的信息来制作行驶计划。例如，计算机210计算车辆1的行为(例如，车辆1的姿势)，并制作适于车辆1的状态和外部环境的行驶计划。行驶计划是表示规定期间内的车辆1的行为的数据。在已经存在行驶计划的情况下，可以在s102中修改该行驶计划。
[0075]
在s103中，计算机210从在s102中制作出的行驶计划提取控制上的物理量(加速度、轮胎转角等)。在s104中，计算机210按每个api周期划分在s103中提取出的物理量。在s105中，计算机210使用在s104中划分出的物理量来执行api软件。通过这样执行api软件，从adk200向vcib111发送请求用于实现按照行驶计划的物理量的控制的api命令(推进方向命令、推进命令、制动命令、车辆固定命令等)。vcib111将与接收到的api命令对应的控制命令发送给综合控制管理器115，综合控制管理器115按照该控制命令来进行车辆1的自动驾驶控制。自动驾驶中的车辆1的状态依次记录于计算机210的存储装置。
[0076]
在接下来的s106中，计算机210判断车辆1是否是自主模式。在自主模式持续的期间(在s106中为是)，重复执行上述s101～s105的处理，由此执行车辆1的自动驾驶。另一方面，当车辆1成为手动模式时(在s106中为否)，在s107中，在表示自动驾驶结束的结束信号与车辆1的标识信息一起从车辆1(通信装置130)被发送给服务器500之后，图3所示的一系列的处理结束。在该实施方式中，计算机210、vcib111以及综合控制管理器115协作地执行用于使车辆1通过自动驾驶来行驶的控制。车辆1在有人/无人中的任一个状态下都能进行自动驾驶。
[0077]
控制装置150被配置为在规定的期间(以下，称为“运用期间”)执行车辆1的自动驾驶。在车辆1的自动驾驶中，执行图3所示的处理，控制装置150按照来自adk200的指令来控制车辆1的各种系统(例如，图2所示的制动系统121、转向系统122、动力传动系统123、主动安全系统125以及车身系统126)。车辆1可以在运用期间通过自动驾驶来提供规定的服务(例如，物流服务或旅客输送服务)。
[0078]
在该实施方式中，服务器500管理包括车辆1的车组。以下，将由服务器500管理的各车辆(上述车组中所包括的车辆)也称为“管理车辆”。各管理车辆具有与前述的车辆1相同的构成。即，各管理车辆具有图1、图2以及图4所示的构成，被配置为通过图3所示的处理来进行自动驾驶。
[0079]
服务器500管理与管理车辆相关的信息(以下，也称为“车辆信息”)。各管理车辆的车辆信息存储于服务器500的存储装置503。具体而言，对每个车辆赋予用于标识车辆的标识信息(车辆id)，服务器500利用车辆id来区分并管理车辆信息。车辆信息例如包括各管理车辆的状况(例如，是否在自动驾驶中)。在该实施方式中，各管理车辆具有相同车型且相同规格的构成。存储装置503存储所有管理车辆共同的车型和规格。不过，不限于此，服务器500也可以管理具有不同规格的多种车辆，并将这些车辆用于规定的服务。在这样的方式中，存储于存储装置503的车辆信息可以包括各管理车辆的车型和规格。
[0080]
在该实施方式中，在多个管理车辆之中包括通过自动驾驶来提供旅客输送服务的车辆(以下，也称为“运行车辆”)。该实施方式的运行车辆在运行区域内按预先决定的路径
(行驶路线)巡回行驶。运行车辆从规定的出发地点出发，并按照规定的行驶路线来进行通过自动驾驶实现的行驶。将运行车辆从出发地点出发并通过设定于行驶路线上的各地点(以下，也称为“经由地点”)直至返回到出发地点为止设为一次运行。运行车辆既可以作为专线巴士发挥功能，也可以进行通过拼车实现的旅客输送。
[0081]
在该实施方式中，服务器500管理多个运行车辆。在运行开始前对各运行车辆设定运行必要条件。在该实施方式中，采用行驶路线(包括出发地点)、运行开始时刻(出发时刻)、运行结束时刻(返回到出发地点的时刻)以及运行次数来作为运行必要条件。在运行次数为两次以上的情况下，对运行车辆设定每次运行的运行开始时刻和运行结束时刻。
[0082]
服务器500将运行车辆分为普通车辆和代表车辆来进行管理。从多个运行车辆之中预先选择一台代表车辆。普通车辆相当于运行车辆中代表车辆以外的车辆。存储于存储装置503的代表车辆的车辆信息包括表示搭载于代表车辆的规定的对象部件(例如，部件a、部件b、部件c、部件d
……
)的状态的部件信息。部件信息表示针对各对象部件的代表车辆的性能检查的结果。在性能检查中，通过按照规定的过程的客观的检查，按每个对象部件(检查项目)确认车辆是否具有规定的基准以上的性能。作为对象部件的例子，可列举出推进装置(例如，马达)、制动装置、蓄电装置、epb、p－lock装置、悬架、轮胎。对于不具有基准以上的性能的对象部件，通过性能检查作出不良判定。性能检查可以使用检查设备(测试器)来进行。性能检查可以是依照所谓的车检的检查。
[0083]
每当代表车辆的性能检查被进行时，代表车辆的部件信息被更新，性能检查的结果被反映至部件信息。该实施方式中的部件信息表示每个对象部件的良否(正常/异常)。通过这样的部件信息来示出在代表车辆中发生了异常的对象部件(即，通过性能检查作出了不良判定的对象部件)。
[0084]
图4是用于对服务器500的构成进行说明的图。参照图1和图2的同时参照图4，服务器500包括处理器501、ram502、存储装置503以及hmi504。服务器500被配置为能与各运行车辆通信。服务器500例如可以被配置为经由移动通信网(telematics)与各运行车辆进行无线通信。该实施方式的服务器500相当于本公开的“车辆管理装置”的一个例子。
[0085]
存储装置503被配置为能保存所储存的信息。在存储装置503中，除了程序之外，还存储有在程序中使用的信息(例如，映射、公式以及各种参数)。hmi(human machine interface)504包括输入装置和显示装置。hmi504可以是触摸面板显示器。hmi504也可以包括受理语音输入的智能扬声器。
[0086]
图4中的表t1表示存储于存储装置503的代表车辆的部件信息。在表t1中，“v－1”相当于代表车辆的车辆id。在图4中仅示出代表车辆(v－1)的部件信息，但在存储装置503中存储有登记于服务器500的所有管理车辆的车辆信息。
[0087]
服务器500包括以下说明的第一驾驶部511、第二驾驶部512、检查部521以及保养部522。在服务器500中，这些各部例如通过处理器501和由处理器501执行的程序来具体实现。不过，不限于此，这些各部也可以通过专用的硬件(电子电路)来具体实现。
[0088]
第一驾驶部511被配置为发送用于使代表车辆(第一车辆)在规定的第一条件下自动驾驶的第一信号。第二驾驶部512被配置为发送用于使普通车辆(第二车辆)在规定的第二条件下自动驾驶的第二信号。第二条件被设定为使得与第一条件相比车辆不易劣化。在该实施方式中，自动驾驶的行驶路线在第一条件和第二条件下相同。以下，将第一条件和第
二条件共同的行驶路线也记为“行驶路线z”。此外，自动驾驶的行驶目的也在第一条件和第二条件下相同。第一条件和第二条件共同的行驶目的是旅客输送。另一方面，第一条件中的行驶距离被设定为使得与第二条件相比车辆容易劣化。具体而言，第一条件中的行驶距离比第二条件中的行驶距离长。在该实施方式中，将第一条件中的行驶距离设为第二条件中的行驶距离的2倍。不过，不限于此，第一条件中的行驶距离既可以为第二条件中的行驶距离的大于2倍且小于10倍，也可以为10倍以上。
[0089]
检查部521被配置为：在代表车辆结束了在第一条件下的自动驾驶之后，指示代表车辆的性能检查。保养部522被配置为使用与代表车辆相关的上述性能检查的结果来决定普通车辆的维护时期。
[0090]
服务器500能通过向各运行车辆指示自动驾驶来提供旅客输送服务。以下，有时将由“v－1”、“v－2”、“v－3”、“v－4”、“v－5”这样的车辆id标识的运行车辆(管理车辆)分别仅记为“v－1”、“v－2”、“v－3”、“v－4”、“v－5”。在该实施方式中，将v－1设为代表车辆，将v－2～v－5中的每一个设为普通车辆。在该实施方式中，对通过五台运行车辆来提供旅客输送服务的例子进行说明，但运行车辆的台数可以适当变更。例如，也可以通过10台以上的运行车辆来提供旅客输送服务。
[0091]
服务器500对代表车辆(v－1)指示在满足以下所示的运行必要条件的条件下的自动驾驶。
[0092]
在针对代表车辆(v－1)的自动驾驶条件中，将行驶路线设为行驶路线z，将运行次数设为两次/天。并且，关于第一次运行，将运行开始时刻设为上午10点，将运行结束时刻设为上午11点。关于第二次运行，将运行开始时刻设为上午11点，将运行结束时刻设为上午12点。满足这样的运行必要条件的自动驾驶条件(即，针对代表车辆的自动驾驶条件)相当于前述的第一条件。此外，在该实施方式中，服务器500将表示针对v－1的上述运行必要条件的v－1运行信号发送给v－1(参照后述的图5的s11)。v－1运行信号相当于前述的第一信号。
[0093]
服务器500对各普通车辆(v－2～v－5)指示在满足以下所示的运行必要条件的条件下的自动驾驶。
[0094]
在针对各普通车辆(v－2～v－5)的自动驾驶条件中，将行驶路线设为行驶路线z，将运行次数设为一次/天。并且，在针对v－2的自动驾驶条件中，将运行开始时刻设为下午12点，将运行结束时刻设为下午1点。在针对v－3的自动驾驶条件中，将运行开始时刻设为下午1点，将运行结束时刻设为下午2点。在针对v－4的自动驾驶条件中，将运行开始时刻设为下午2点，将运行结束时刻设为下午3点。在针对v－5的自动驾驶条件中，将运行开始时刻设为下午3点，将运行结束时刻设为下午4点。在该实施方式中，运行开始时刻和运行结束时刻按每个普通车辆不同。满足这样的运行必要条件的自动驾驶条件(即，针对各普通车辆的自动驾驶条件)相当于前述的第二条件。此外，在该实施方式中，服务器500将表示针对v－2、v－3、v－4、v－5的上述运行必要条件的v－2运行信号、v－3运行信号、v－4运行信号、v－5运行信号分别发送给v－2、v－3、v－4、v－5(参照后述的图6的s21)。v－2运行信号～v－5运行信号中的每一个相当于前述的第二信号。
[0095]
根据上述的运行必要条件，相对于各普通车辆在行驶路线z中每一天运行一次，代表车辆在行驶路线z(与普通车辆相同的行驶路线)中每一天运行两次。因此，一天中的代表
车辆的行驶距离成为一天中的各普通车辆的行驶距离的2倍。需要说明的是，运行必要条件不限定于上述，可以适当变更。例如，与第一条件和第二条件中的每一个相关的运行必要条件也可以还包括到行驶路线上的各经由地点的到达时刻。在该实施方式中，将单位期间设为一天，但单位期间可以适当变更。
[0096]
图5是表示服务器500为了代表车辆而执行的管理处理的流程图。在对代表车辆(v－1)规定的运行开始时刻(上午10点)之前开始该流程图所示的处理。例如，当成为从代表车辆的运行开始时刻倒退规定时间的时刻(例如，上午9点30分)时，可以开始以下说明的图5所示的一系列的处理。
[0097]
参照图1、图2以及图4的同时参照图5，在s11中，服务器500的第一驾驶部511将第一信号发送给代表车辆(v－1)。第一信号是表示针对代表车辆(v－1)的运行必要条件的v－1运行信号。当代表车辆接收到第一信号(v－1运行信号)时，对代表车辆设定第一信号所表示的运行必要条件，并且代表车辆的驾驶模式从手动模式切换为自主模式。由此，代表车辆的控制装置150开始图3所示的一系列的处理。然后，在图3的s102中，以满足第一信号所表示的运行必要条件的方式制作行驶计划。当成为运行开始时刻时，代表车辆开始行驶(运行)，并持续进行通过图3所示的处理实现的自动驾驶，直至结束第一信号所表示的两次运行为止。当第一信号所表示的两次运行完成时，代表车辆的驾驶模式从自主模式切换为手动模式。由此，代表车辆的自动驾驶结束。
[0098]
在接下来的s12中，第一驾驶部511判断代表车辆(v－1)的自动驾驶(在第一条件下的自动驾驶)是否结束。第一驾驶部511例如在接收到表示代表车辆的自动驾驶结束的结束信号的情况下，判断为代表车辆的自动驾驶结束。在代表车辆的自动驾驶结束之前(在s12中为否)，服务器500待机。然后，当代表车辆的自动驾驶结束时(在s12中为是)，处理进入s13。
[0099]
在s13中，检查部521指示代表车辆(v－1)的性能检查。具体而言，检查部521将指示接受性能检查的信号(以下，也称为“检查信号”)发送给代表车辆(v－1)。当代表车辆接收到检查信号时，代表车辆的驾驶模式从手动模式切换为自主模式，再次开始图3所示的一系列的处理。通过图3所示的处理，代表车辆通过自动驾驶朝向检查信号所表示的检查场所(设有检查设备的场所)行驶。当代表车辆到达检查场所时，由维修人员执行代表车辆的性能检查(各对象部件的检查)。服务器500受理检查结果的输入。然后，当代表车辆的性能检查的结果被输入至服务器500时，服务器500基于该性能检查的结果来更新存储于存储装置503的代表车辆的部件信息(参照图4中的表t1)。在代表车辆的性能检查完成之后，维修人员可以通过hmi504向服务器500输入代表车辆的性能检查的结果。对于通过性能检查确认到异常的代表车辆，可以由维修人员进行所需的维护(例如，修理或部件更换)。
[0100]
在接下来的s14中，检查部521判断代表车辆的部件信息是否基于上述性能检查的结果而被更新。在代表车辆的部件信息被更新之前(在s14中为否)，服务器500待机。在待机中，服务器500的hmi504可以进行提醒性能检查的结果的输入的报告。然后，当代表车辆的部件信息被更新时(在s14中为是)，图5所示的一系列的处理结束。在该实施方式中，当维修人员向服务器500输入代表车辆的性能检查的结果时，在s14中判断为是。
[0101]
图6是表示服务器500为了普通车辆而执行的管理处理的流程图。按每个普通车辆，在其运行开始时刻之前(例如，从运行开始时刻倒退规定时间的时刻)开始该流程图所
示的处理。例如，当成为从对v－2规定的运行开始时刻(上午12点)倒退规定时间的时刻(例如，上午11点30分)时，开始针对v－2的处理。此外，当成为从对v－3规定的运行开始时刻(下午1点)倒退规定时间的时刻(例如，下午12点30分)时，开始针对v－3的处理。在该实施方式中，在对v－2规定的运行结束时刻(下午1点)之前开始针对v－3的处理。即，在规定的期间中，对v－2和v－3中的每一个同时并行地执行以下说明的图6所示的一系列的处理。此外，在开始了针对v－3的处理之后，也依次开始针对v－4、v－5的处理。
[0102]
参照图1、图2以及图4的同时参照图6，在s21中，服务器500的第二驾驶部512向作为对象的普通车辆(v－2～v－5中的任一个)发送第二信号。第二信号根据作为对象的普通车辆而不同。针对v－2、v－3、v－4、v－5的第二信号分别是前述的v－2运行信号、v－3运行信号、v－4运行信号、v－5运行信号。
[0103]
当作为对象的普通车辆接收到第二信号(针对该普通车辆的运行信号)时，对该普通车辆设定第二信号所表示的运行必要条件，并且该普通车辆的驾驶模式从手动模式切换为自主模式。由此，普通车辆的控制装置150开始图3所示的一系列的处理。然后，在图3的s102中，以满足第二信号所表示的运行必要条件的方式制作行驶计划。普通车辆持续进行通过图3所示的处理实现的自动驾驶，直至结束第二信号所表示的一次运行为止。当第二信号所表示的一次运行完成时，普通车辆的驾驶模式从自主模式切换为手动模式。由此，普通车辆的自动驾驶结束。
[0104]
在接下来的s22中，第二驾驶部512判断普通车辆的自动驾驶(在第二条件下的自动驾驶)是否结束。第二驾驶部512例如在接收到表示普通车辆的自动驾驶结束的结束信号的情况下，判断为普通车辆的自动驾驶结束。在普通车辆的自动驾驶结束之前(在s22中为否)，服务器500待机。然后，当普通车辆的自动驾驶结束时(在s22中为是)，处理进入s23。
[0105]
在s23中，保养部522从存储装置503获取与代表车辆相关的性能检查的结果(参照图5的s13和s14)。在与代表车辆相关的性能检查(图5的s13)未完成的情况下，保养部522待机。然后，当在检查完成后数据被更新时(在图5的s14中为是)，保养部522从存储装置503获取最新的数据(代表车辆的性能检查的结果)。
[0106]
在接下来的s24中，保养部522判断是否通过代表车辆的性能检查在代表车辆的任一个部件确认到异常(超过容许水平的性能下降)。然后，在通过代表车辆的性能检查在代表车辆的任一个部件确认到异常的情况下(在s24中为是)，在s25中，保养部522对与确认到异常的代表车辆的部件对应的普通车辆的部件指示维护。例如，在代表车辆中确认到制动装置的异常的情况下，保养部522指示普通车辆的制动装置的维护。根据该指示，执行普通车辆的部件维护。
[0107]
在s25中，保养部522例如将请求对象部件(在代表车辆中确认到异常的部件)的维护(例如，检查、修理或更换)的维护信号发送给结束了自动驾驶的普通车辆。接收到维护信号的普通车辆的控制装置150将对象部件的维护时期到来了记录于存储装置153，并且使规定的报告装置(例如，hmi230或移动终端ut)执行对普通车辆的管理者提醒对象部件的维护的报告处理。此外，接收到维护信号的普通车辆的控制装置150既可以执行使该普通车辆通过自动驾驶向维护场所移动的处理，也可以向维护商家的终端发送委托维护的信号。
[0108]
当执行了上述s25的处理时，图6所示的一系列的处理结束。通过进行s25的处理来执行普通车辆的部件维护。另一方面，在通过代表车辆的性能检查在代表车辆的任一个部
件都未确认到异常的情况下(在s24中为否)，不进行普通车辆的部件维护(s25)，图6所示的一系列的处理结束。在该实施方式中，在普通车辆结束了在第二条件下的自动驾驶之后，保养部522使用与代表车辆相关的性能检查的结果来判断是否进行该普通车辆的维护。即，保养部522使用与代表车辆相关的性能检查的结果来决定普通车辆的维护时期。
[0109]
如以上说明的那样，实施方式1的车辆管理方法包括图3、图5以及图6中的每一个所示的处理。在图5的s11(第一自动驾驶过程)中，使车组中所包括的第一车辆(代表车辆)在第一条件下自动驾驶。在图6的s21(第二自动驾驶过程)中，使车组中所包括的作为第一车辆以外的车辆的第二车辆(普通车辆)在与第一条件相比车辆不易劣化的第二条件下自动驾驶。在图5的s13(性能检查过程)中，在第一车辆结束了在第一条件下的自动驾驶之后(在图5的s12中为是)，进行第一车辆的性能检查。在图6的s25(维护过程)中，在通过第一车辆的性能检查作出了不良判定的情况下(在图6的s24中为是)，执行第二车辆的维护。
[0110]
在上述的车辆管理方法中，使用与第一车辆相关的性能检查的结果来决定第二车辆的维护时期。在第一车辆在与第二车辆的驾驶条件(第二条件)相比车辆容易劣化的条件(第一条件)下被自动驾驶之后，执行与第一车辆相关的性能检查。因此，在与第一车辆相关的性能检查中判定为第一车辆的性能正常的情况下，可以推定为第二车辆的性能也正常。即，在通过与第一车辆相关的性能检查判定为第一车辆的性能正常的情况下，可以省略与第二车辆相关的性能检查。因此，根据上述的车辆管理方法，能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。
[0111]
[实施方式2]
[0112]
对本公开的实施方式2的车辆管理装置以及车辆管理方法进行说明。实施方式2与实施方式1共同的部分多，因此主要对不同点进行说明，省略对共同的部分的说明。
[0113]
图7是表示本公开的实施方式2的车辆管理装置的构成的图。在实施方式2中，采用服务器500a来代替实施方式1中的服务器500(图4)。在实施方式2中，服务器500a相当于本公开的“车辆管理装置”的一个例子。
[0114]
参照图7，服务器500a与服务器500同样地包括第一驾驶部511、第二驾驶部512、检查部521以及保养部522。不过，服务器500a的保养部522被配置为进行用于将表示第一车辆的性能的第一数据变换为表示第二车辆的性能的第二数据的运算。第一车辆、第二车辆分别相当于代表车辆、普通车辆。
[0115]
在实施方式1中的服务器500中，与普通车辆相关的部件信息未存储于存储装置503，但在实施方式2中的服务器500a的存储装置503中，不仅存储有与代表车辆相关的部件信息，还存储有与普通车辆相关的部件信息(参照图7中的表t2)。部件信息表示搭载于车辆的规定的对象部件(例如，部件a、部件b
……
)的状态。与代表车辆相关的部件信息包括前述的第一数据，与普通车辆相关的部件信息包括前述的第二数据。在该实施方式中，采用部件劣化度来作为第一数据和第二数据中的每一个。部件信息表示每个对象部件的劣化度。第一数据通过代表车辆的性能检查来获取，并保存于存储装置503。然后，服务器500a的保养部522进行规定的运算，根据第一数据来求出第二数据。所得到的第二数据保存于存储装置503。服务器500a的保养部522可以以搭载于代表车辆的部件a的劣化度(第一数据)与规定的变换系数相乘的结果来求出搭载于普通车辆的部件a的劣化度(第二数据)。作为部件a的例子，可列举出推进装置(例如，马达)、制动装置、蓄电装置、epb、p－lock装置、悬架、轮胎。
在规格在代表车辆和普通车辆中不同的方式中，服务器500a的保养部522可以使用代表车辆和普通车辆各自的车身重量和空气阻力(例如，空气阻力系数cd的值)中的至少一方来决定上述变换系数。
[0116]
在实施方式2中，采用v－11和v－12代替实施方式1中的v－1来作为代表车辆。此外，采用v－21～v－24代替实施方式1中的v－2～v－5来作为普通车辆。在针对v－11的自动驾驶条件中，将行驶路线设为行驶路线z，将运行次数设为一次/天，将运行开始时刻设为上午9点30分，将运行结束时刻设为上午10点。针对v－12的自动驾驶条件与实施方式1中的针对v－1的自动驾驶条件相同。针对v－21～v－24的自动驾驶条件分别与实施方式1中的针对v－2～v－5的自动驾驶条件相同。
[0117]
相对于各普通车辆(v－21～v－24)在行驶路线z中以一小时运行一次，v－11在行驶路线z中以30分钟运行一次。因此，v－11的车速成为各普通车辆的车速的2倍。如此，v－11的自动驾驶条件(第一条件)中的车速被设定为使得与各普通车辆的自动驾驶条件(第二条件)中的车速相比车辆容易劣化。此外，相对于各普通车辆(v－21～v－24)在行驶路线z中每一天运行一次，v－12在行驶路线z中每一天运行两次。因此，一天中的v－12的行驶距离成为一天中的各普通车辆的行驶距离的2倍。如此，v－12的自动驾驶条件(第一条件)中的行驶距离被设定为使得与各普通车辆的自动驾驶条件(第二条件)中的行驶距离相比车辆容易劣化。
[0118]
图8是表示服务器500a为了代表车辆而执行的管理处理的流程图。按每个代表车辆执行该流程图所示的处理。根据运行开始时刻，依次开始针对v－11、v－12的处理。图8所示的一系列的处理基本上与图5所示的一系列的处理相同。
[0119]
参照图7的同时参照图8，在s11中，服务器500a的第一驾驶部511向作为对象的代表车辆(v－11或v－12)发送第一信号。第一信号根据作为对象的代表车辆而不同。针对v－11、v－12的第一信号分别是表示针对v－11、v－12的运行必要条件的v－11运行信号、v－12运行信号。通过s11的处理，作为对象的代表车辆以满足运行必要条件的方式执行自动驾驶(参照图3)。之后，与图5所示的处理同样地执行s12～s14的处理。不过，在根据s13的指示而进行的性能检查中，对作为对象的代表车辆测定每个对象部件的劣化度(第一数据)。然后，在作为对象的代表车辆的性能检查完成之后，包括每个对象部件的劣化度的代表车辆的性能检查的结果被输入至服务器500a，与代表车辆相关的部件信息(参照图7中的表t2)被更新。对于通过性能检查确认到异常的代表车辆，可以由维修人员进行所需的维护。
[0120]
图9是表示服务器500a为了普通车辆而执行的管理处理的流程图。按每个普通车辆执行该流程图所示的处理。根据运行开始时刻，依次开始针对v－21、v－22、v－23、v－24的处理。
[0121]
参照图7的同时参照图9，与图6所示的处理同样地执行s21和s22的处理。在接下来的s23a中，服务器500a的保养部522从存储装置503获取与代表车辆相关的性能检查的结果(参照图8的s13和s14)。具体而言，服务器500a的保养部522获取v－11和v－12各自的部件劣化度(每个对象部件的劣化度)。
[0122]
在接下来的s23b中，服务器500a的保养部522根据v－11和v－12各自的部件劣化度来求出作为对象的普通车辆(v－21～v－24中的任一个)的部件劣化度。具体而言，服务器500a的保养部522通过将对v－11和v－12中的每一个测定出的部件劣化度的平均值与规
定的变换系数相乘来求出作为对象的普通车辆的部件劣化度。变换系数既可以是所有普通车辆共同的，也可以按每个普通车辆而不同。按每个对象部件计算普通车辆的部件劣化度。变换系数既可以是所有对象部件共同的，也可以按每个对象部件而不同。在该实施方式中，对多个代表车辆测定出的第一数据(部件劣化度)的平均值被变换为表示普通车辆的性能的第二数据(部件劣化度)。但是，不限于此，也可以是，对一台代表车辆测定出的第一数据通过规定的变换系数变换为第二数据。
[0123]
在接下来的s24a中，服务器500a的保养部522判断在作为对象的普通车辆的任一个部件是否发生了异常(超过容许水平的性能下降)。具体而言，保养部522按搭载于普通车辆的每个对象部件判断当前的劣化度(第二数据)是否超过规定的阈值。阈值可以按每个对象部件任意设定。在至少一个对象部件的劣化度超过阈值的情况下，在s24a中判断为是，处理进入s25a。
[0124]
在s25a中，服务器500a的保养部522对发生了异常的普通车辆的对象部件指示维护。根据s25a的指示，执行普通车辆的部件维护。在该实施方式中，在普通车辆结束了在第二条件下的自动驾驶之后，保养部522使用表示代表车辆的性能的第一数据来计算表示该普通车辆的性能的第二数据，并基于第二数据来判断是否进行该普通车辆的维护。即，保养部522基于第二数据来决定普通车辆的维护时期。
[0125]
如以上说明的那样，实施方式2的车辆管理方法包括图3、图8以及图9中的每一个所示的处理。在图8的s11(第一自动驾驶过程)中，使车组中所包括的第一车辆(代表车辆)在第一条件下自动驾驶。在图9的s21(第二自动驾驶过程)中，使车组中所包括的作为第一车辆以外的车辆的第二车辆(普通车辆)在与第一条件相比车辆不易劣化的第二条件下自动驾驶。在图8的s13(性能检查过程)中，在第一车辆结束了在第一条件下的自动驾驶之后，进行第一车辆的性能检查，获取表示第一车辆的性能的第一数据。在图9的s23a和s23b(变换过程)中，将第一数据变换为表示第二车辆的性能的第二数据。在图9的s25a(维护过程)中，在第二数据表示第二车辆的性能不良的情况下(在图9的s24a中为是)，执行第二车辆的维护。根据这样的车辆管理方法，也能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。此外，在实施方式2中，通过采用多种第一车辆，易于使用与各第一车辆相关的性能检查的结果来适当地评价第二车辆的性能。
[0126]
[实施方式3]
[0127]
对本公开的实施方式3的车辆管理装置以及车辆管理方法进行说明。实施方式3与实施方式1共同的部分多，因此主要对不同点进行说明，省略对共同的部分的说明。
[0128]
图10是表示本公开的实施方式3的车辆管理装置的构成的图。在实施方式3中，采用服务器500b来代替实施方式1中的服务器500(图4)。在实施方式3中，服务器500b相当于本公开的“车辆管理装置”的一个例子。
[0129]
参照图10，服务器500b除了第一驾驶部511、第二驾驶部512、检查部521以及保养部522之外，还包括判断部513。在服务器500b中，这些各部例如通过处理器501和由处理器501执行的程序来具体实现。不过，不限于此，这些各部也可以通过专用的硬件(电子电路)来具体实现。
[0130]
由实施方式3的服务器500b管理的车辆(管理车辆)也作为运行车辆发挥功能。不过，实施方式3的运行车辆根据每次的请求来决定路径，并按照决定出的路径(按需路径)来
执行通过自动驾驶实现的行驶。运行车辆可以作为自动驾驶出租车发挥功能。规定台数的管理车辆预先被规定为代表车辆。并且，代表车辆以外的管理车辆被视为普通车辆。
[0131]
服务器500b获取用户所指定的运行必要条件，并向管理车辆(运行车辆)指示按照该运行必要条件(所请求的自动驾驶条件)的自动驾驶。判断部513被配置为判断所请求的自动驾驶条件符合第一条件和第二条件中的哪一个。关于该判断处理的详情，将在后文叙述(参照图11的s32)。
[0132]
图11是表示服务器500b为了运行车辆而执行的管理处理的流程图。当服务器500b从用户的终端(例如，服务利用者或车辆管理者的移动终端)接收到运行请求时，开始该流程图所示的处理。
[0133]
参照图10的同时参照图11，在s31中，服务器500b的判断部513获取用户所指定的运行必要条件。用户所指定的运行必要条件包括在上述运行请求中。
[0134]
在接下来的s32中，判断部513判断在s31中获取到的运行必要条件是否苛刻。具体而言，判断部513使用运行必要条件所表示的行驶距离、重量以及车速中的至少一个来判断该运行必要条件是否苛刻。判断部513可以基于运行必要条件所表示的行驶距离(例如，从用户的上车位置到目的地的距离)是否为规定值以上来判断该运行必要条件是否苛刻。判断部513也可以基于运行必要条件所表示的搭乘人数是否为规定值以上来判断该运行必要条件是否苛刻。判断部513也可以基于运行必要条件所表示的装载重量是否为规定值以上来判断该运行必要条件是否苛刻。判断部513也可以基于运行必要条件所表示的车速是否为规定值以上来判断该运行必要条件是否苛刻。例如，在根据运行必要条件请求了快速行驶的情况下，可以判断为运行必要条件苛刻。需要说明的是，被认定为运行必要条件苛刻的必要条件(苛刻工作必要条件)可以任意设定。例如，判断部513也可以基于运行必要条件所表示的行驶路线来判断该运行必要条件是否苛刻。在行驶路线中包括恶劣道路的情况或行驶路线中包括陡坡的情况下，可以判断为运行必要条件苛刻。
[0135]
在运行必要条件苛刻的情况下(在s32中为是)，在s331中，判断部513从可利用的状态的管理车辆之中选择代表车辆。在多台代表车辆为可利用的状态的情况下，优先地从使用频度少(劣化程度小)的代表车辆中选择。在s32中判断为是意味着所请求的自动驾驶条件符合第一条件。
[0136]
在运行必要条件不苛刻的情况下(在s32中为否)，在s332中，判断部513从可利用的状态的管理车辆之中选择普通车辆。在多台普通车辆为可利用的状态的情况下，优先地从使用频度少(劣化程度小)的普通车辆中选择。在s32中判断为否意味着所请求的自动驾驶条件符合第二条件。
[0137]
以下，将在s331或s332中选择出的车辆(代表车辆或普通车辆)称为“选择车辆”。在接下来的s34中，服务器500b向选择车辆指示满足在s31中获取到的运行必要条件的自动驾驶。具体而言，在选择车辆是代表车辆的情况下，服务器500b的第一驾驶部511向选择车辆发送用于使选择车辆在第一条件(满足苛刻工作必要条件的条件)下自动驾驶的第一信号。在选择车辆是普通车辆的情况下，服务器500b的第二驾驶部512向选择车辆发送用于使选择车辆在第二条件(不满足苛刻工作必要条件的条件)下自动驾驶的第二信号。
[0138]
s34的处理依照图5的s11的处理。通过s34的处理，选择车辆以满足运行必要条件的方式执行自动驾驶(参照图3)。在接下来的s35中，服务器500b判断选择车辆的自动驾驶
是否结束。当选择车辆的自动驾驶结束时(在s35中为是)，在s36中，服务器500b的检查部521判断选择车辆是否是代表车辆。在选择车辆是代表车辆的情况下(在s36中为是)，在s37中，检查部521指示该代表车辆的性能检查。s37的处理依照图5的s13的处理。根据s37的指示，执行代表车辆的性能检查(各对象部件的检查)。
[0139]
在接下来的s38中，服务器500b的保养部522判断是否通过代表车辆的性能检查在代表车辆的任一个部件确认到异常(超过容许水平的性能下降)。s38的处理依照图6的s24的处理。在通过代表车辆的性能检查在代表车辆的任一个部件确认到异常的情况下(在s38中为是)，在s39中，保养部522对车组中所包括的所有代表车辆和普通车辆(所有管理车辆)指示部件维护。作为维护的对象的部件是在代表车辆中确认到异常的部件。维护处理依照图6的s25的处理。
[0140]
当执行了上述s39的处理时，图11所示的一系列的处理结束。通过进行s39的处理来执行各管理车辆的部件维护。另一方面，在通过代表车辆的性能检查在代表车辆的任一个部件都未确认到异常的情况下(在s38中为否)，不进行部件维护(s39)，图11所示的一系列的处理结束。此外，在选择车辆是普通车辆的情况下(在s36中为否)，既不进行性能检查(s37)也不进行部件维护(s39)，图11所示的一系列的处理结束。
[0141]
如以上说明的那样，实施方式3的车辆管理方法包括图3和图11中的每一个所示的处理。在图11所示的处理中，在s32中，判断用户所指定的自动驾驶条件符合第一条件和第二条件中的哪一个。在该自动驾驶条件符合第一条件的情况下(在s32中为是)，在s34中，使车组中所包括的第一车辆(代表车辆)在第一条件下自动驾驶。另一方面，在该自动驾驶条件符合第二条件的情况下(在s32中为否)，在s34中，使车组中所包括的作为第一车辆以外的车辆的第二车辆(普通车辆)在与第一条件相比车辆不易劣化的第二条件下自动驾驶。在图11的s37中，在第一车辆结束了在第一条件下的自动驾驶之后，进行第一车辆的性能检查。在图11的s39中，在通过第一车辆的性能检查作出了不良判定的情况下(在图11的s38中为是)，执行第一车辆和第二车辆各自的维护。根据这样的车辆管理方法，也能减少在管理多个自动驾驶车辆的系统中被管理的各自动驾驶车辆的性能检查的合计次数。此外，能根据所请求的自动驾驶条件来适当地运用第一车辆和第二车辆中的每一个。
[0142]
[其他实施方式]
[0143]
上述各实施方式的服务器的功能也可以通过云计算在云上提供。自动驾驶的等级既可以是完全自动驾驶(5级)，也可以是带条件的自动驾驶(例如，4级)。第一条件和第二条件中的每一个条件下的自动驾驶的行驶目的不限于旅客输送，可以适当变更。例如，自动驾驶的行驶目的既可以是移动办公室，也可以是物流，还可以是医疗。
[0144]
车辆的构成不限于在上述各实施方式说明的构成(参照图1和图2)。基础车辆也可以在无后装的状态下具有自动驾驶功能。车辆的构成也可以适当变更为无人行驶专用的构成。例如，无人行驶专用的车辆也可以不具备用于供人对车辆进行操作的部件(方向盘等)。车辆既可以具备太阳能电池板，也可以具备飞行功能。车辆不限于乘用车，也可以是巴士或卡车。车辆也可以是个人拥有的车辆(pov：privately owned vehicle)。车辆也可以是根据用户的使用目的而定制的多用途车辆。车辆也可以是移动店铺车辆、无人输送车(agv：automated guided vehicle)或农业机械。车辆也可以是无人或一人乘坐的小型bev(例如，小型配送机器人(micro palette))。
[0145]
上述的各实施方式和各变形例可以任意组合来实施。
[0146]
应该认为本次公开的实施方式在所有方面都是示例而不是限制性的。由本公开示出的技术范围不是由上述的实施方式的说明示出，而是由权利要求书示出，意图在于包括与权利要求书等同的含义和范围内的所有变更。

技术特征：
1.一种车辆管理装置，包括：第一驾驶部，发送用于使车组中所包括的第一车辆在第一条件下自动驾驶的第一信号；第二驾驶部，发送用于使所述车组中所包括的作为所述第一车辆以外的车辆的第二车辆在与所述第一条件相比车辆不易劣化的第二条件下自动驾驶的第二信号；检查部，在所述第一车辆结束了在所述第一条件下的自动驾驶之后，指示所述第一车辆的性能检查；以及保养部，使用与所述第一车辆相关的所述性能检查的结果来决定所述第二车辆的维护时期。2.根据权利要求1所述的车辆管理装置，其中，所述保养部被配置为：在所述第二车辆结束了在所述第二条件下的自动驾驶之后，使用与所述第一车辆相关的所述性能检查的结果来判断是否进行所述第二车辆的维护。3.根据权利要求1或2所述的车辆管理装置，其中，自动驾驶的行驶路线在所述第一条件和所述第二条件下相同。4.根据权利要求1～3中任一项所述的车辆管理装置，其中，自动驾驶的行驶目的在所述第一条件和所述第二条件下相同。5.根据权利要求1～4中任一项所述的车辆管理装置，其中，所述第一条件中的行驶距离、重量以及车速中的至少一个被设定为使得与所述第二条件相比车辆容易劣化。6.根据权利要求1～5中任一项所述的车辆管理装置，其中，与所述第一车辆相关的所述性能检查的结果包括表示所述第一车辆的性能的第一数据，所述保养部被配置为：进行用于将所述第一数据变换为表示所述第二车辆的性能的第二数据的运算，并基于所述第二数据来决定所述第二车辆的维护时期。7.根据权利要求1～6中任一项所述的车辆管理装置，还包括判断部，所述判断部判断所请求的自动驾驶条件符合所述第一条件和所述第二条件中的哪一个，在所述所请求的自动驾驶条件符合所述第一条件的情况下，所述第一驾驶部发送所述第一信号，在所述所请求的自动驾驶条件符合所述第二条件的情况下，所述第二驾驶部发送所述第二信号。8.一种车辆管理方法，包括：使第一车辆在第一条件下自动驾驶；使第二车辆在与所述第一条件相比车辆不易劣化的第二条件下自动驾驶；在所述第一车辆结束了在所述第一条件下的自动驾驶之后，进行所述第一车辆的性能检查；以及在通过所述第一车辆的所述性能检查作出了不良判定的情况下，执行所述第二车辆的维护。9.根据权利要求8所述的车辆管理方法，
还包括判断用户所指定的自动驾驶条件符合所述第一条件和所述第二条件中的哪一个，在所述自动驾驶条件符合所述第一条件的情况下，执行在所述第一条件下的所述第一车辆的自动驾驶，在所述自动驾驶条件符合所述第二条件的情况下，执行在所述第二条件下的所述第二车辆的自动驾驶。10.根据权利要求8或9所述的车辆管理方法，其中，自动驾驶的行驶路线在所述第一条件和所述第二条件下相同。11.根据权利要求8～10中任一项所述的车辆管理方法，其中，自动驾驶的行驶目的在所述第一条件和所述第二条件下相同。12.根据权利要求8～11中任一项所述的车辆管理方法，其中，所述第一条件中的行驶距离、重量以及车速中的至少一个被设定为使得与所述第二条件相比车辆容易劣化。13.一种车辆管理方法，包括：使第一车辆在第一条件下自动驾驶；使第二车辆在与所述第一条件相比车辆不易劣化的第二条件下自动驾驶；在所述第一车辆结束了在所述第一条件下的自动驾驶之后，进行所述第一车辆的性能检查，获取表示所述第一车辆的性能的第一数据；将所述第一数据变换为表示所述第二车辆的性能的第二数据；以及在所述第二数据表示所述第二车辆的性能不良的情况下，执行所述第二车辆的维护。14.根据权利要求13所述的车辆管理方法，其中，自动驾驶的行驶路线在所述第一条件和所述第二条件下相同。15.根据权利要求13或14所述的车辆管理方法，其中，自动驾驶的行驶目的在所述第一条件和所述第二条件下相同。16.根据权利要求13～15中任一项所述的车辆管理方法，其中，所述第一条件中的行驶距离、重量以及车速中的至少一个被设定为使得与所述第二条件相比车辆容易劣化。

技术总结
本公开涉及车辆管理装置以及车辆管理方法。车辆管理装置包括第一驾驶部、第二驾驶部、检查部以及保养部。第一驾驶部发送用于使车组中所包括的第一车辆在第一条件下自动驾驶的第一信号。第二驾驶部发送用于使车组中所包括的作为第一车辆以外的车辆的第二车辆在与第一条件相比车辆不易劣化的第二条件下自动驾驶的第二信号。检查部在第一车辆结束了在第一条件下的自动驾驶之后，指示第一车辆的性能检查。保养部使用与第一车辆相关的性能检查的结果来决定第二车辆的维护时期。果来决定第二车辆的维护时期。果来决定第二车辆的维护时期。


技术研发人员：小林亮介 真屋朋和 冈田强志 藤井宏光
受保护的技术使用者：丰田自动车株式会社
技术研发日：2022.12.27
技术公布日：2023/7/26