JP2023110281A - 車両管理システム、及び車両検査方法 - Google Patents

Abstract

【課題】自動運転車両を管理するサーバの負荷を軽減しつつ自動運転車両のメンテナンスを適切に行なう。【解決手段】車両検査方法が、第１及び第２送信工程と第１及び第２判定工程とを含む。第１送信工程では、車両１が、自動運転中に、車両１に搭載された第１センサによって検出された第１状態をサーバ５００へ送信する。第１判定工程では、サーバ５００が、車両１から受信した第１状態を用いて、車両１について第１検査項目の良否を判定する。第２判定工程では、車両１が、自動運転中に、車両１に搭載された第２センサによって検出された第２状態を用いて第２検査項目の良否を判定する。第２送信工程では、第２検査項目について不良と判定された場合に、車両１が、第２検査項目の判定結果をサーバ５００へ送信する。【選択図】図１

Description

本開示は、車両管理システム、及び車両検査方法に関する。

特開２０１９－１３１１８７号公報（特許文献１）には、インターネットを利用したクラウドサービスによって車両の診断を行なう技術が開示されている。特許文献１に記載される技術では、車両が行なった一次診断によって異常があると診断され、かつ、その異常を運転者が感知できる場合に、その異常に関する二次診断が車両からクラウドサービス事業者のサーバへ要求される。この際、車両は、二次診断のためのデータをサーバへ送信する。特許文献１に記載される技術では、車両の異常が軽微（運転者が感知できない程度、又は車両走行に直ちに影響がない程度）である場合には、二次診断は実行されない。

特開２０１９－１３１１８７号公報

近年、ＭａａＳ（Mobility as a Service）が注目されている。ＭａａＳの利便性を向上させるために、カーシェアリングや自動運転のような技術を利用することが提案されている。

ユーザからの要求に応じて自動運転車両を提供できるように、サーバによって複数の自動運転車両を管理することが考えられる。自動運転車両を提供する事業者には、日常的な自動運転車両のメンテナンスを適切に行なうことが要求される。自動運転車両の異常を早期に発見するためには、自動運転中においても車両検査が実行されることが望ましい。

サーバが車両の状態を正確に把握するためには、車両で検出された車両の状態が車両からサーバへ逐次送信されることが望ましい。車両に異常が生じた場合には、その異常が軽微であっても、車両に異常が生じたことをサーバが把握していることが望ましい。しかしながら、管理される車両からサーバへ送信される情報量が多くなると、サーバの処理負荷（たとえば、情報処理のための演算量）が増大したり、通信コストが上昇したりする。

本開示は、上記課題を解決するためになされたものであり、その目的は、自動運転車両を管理するサーバの負荷を軽減しつつ自動運転車両のメンテナンスを適切に行なうことである。

本開示の第１の観点に係る車両管理システムは車両とサーバとを含む。サーバは、第１検査項目について良否を判定する第１検査を実行する第１検査装置を備える。車両は、制御装置と第２検査装置と第１センサと第２センサと通信装置とを備える。制御装置は、当該車両を自動運転で走行させるための制御を実行するように構成される。第２検査装置は、第１検査項目とは異なる第２検査項目について良否を判定する第２検査を実行するように構成される。第１センサは、第１検査項目に対応する第１状態を検出するように構成される。第２センサは、第２検査項目に対応する第２状態を検出するように構成される。通信装置は、車両の自動運転中に第１センサによって検出された第１状態をサーバへ逐次送信するように構成される。第１検査装置は、車両から逐次受信する第１状態を用いて、当該車両について第１検査を実行するように構成される。第２検査装置は、車両の自動運転中に第２センサによって検出された第２状態を用いて第２検査を実行する。そして、第２検査によって不良判定がなされた場合には、通信装置が第２検査の結果をサーバへ送信する。

上記構成によれば、第１検査項目に対応する第１状態は、車両からサーバへ逐次送信される。このため、サーバは、自動運転中の車両の状態（第１センサで検出された第１状態）を正確に把握できるとともに、自動運転中の車両から逐次受信する第１状態を用いて、第１検査項目の良否を判定できる。

また、上記構成によれば、第２検査項目の良否については車両で判定される。サーバは、自動運転中の車両に第２検査項目に関する異常が発生した場合には、車両に異常が生じた旨の連絡を車両から受けることができる。第２検査によって良判定がなされている間は、サーバが、第２検査の結果を受信しないことにより、自動運転中の車両に第２検査項目に関する異常が発生していないことを把握できる。第２検査によって良判定がなされている間は、第２状態と第２検査の結果とのいずれもが車両からサーバへ送信されないことで、車両からサーバへ送信される情報量を軽減できる。これにより、サーバの負荷が軽減される。

上記構成によれば、１台の車両について各検査項目に応じた情報をサーバが車両から受信し、サーバが自動運転中の車両の状態を正確に把握しやすくなる。これにより、自動運転車両のメンテナンスを適切に行なうことが可能になる。

なお、車両の通信装置は、当該車両の識別情報（車両ＩＤ）とともに車両に関する情報をサーバへ送信してもよい。車両における制御装置と第２検査装置とは、１つのコンピュータで具現化されてもよいし、個別のコンピュータで具現化されてもよい。車両の制御装置は、１つのコンピュータで構成されてもよいし、複数のコンピュータを含んでもよい。

上記の車両管理システムにおいて、第１検査項目よりも第２検査項目のほうが、要求されるリアルタイム性が高くてもよい。

検査項目に関しては、要求されるモニタリング間隔及び判定間隔が短いほど、要求されるリアルタイム性が高くなる。前述した構成を有する車両管理システムでは、第２検査項目については、車両でモニタリング（第２状態の検出）及び判定が行なわれるため、短い周期でモニタリング及び判定を行ないやすい。上記のように、要求されるリアルタイム性が低い検査項目を第１検査項目、要求されるリアルタイム性が高い検査項目を第２検査項目とすることで、各検査項目の要求に応えやすくなる。

第１検査項目は、経年劣化に起因した部品異常の有無を確認する項目を含んでもよい。第２検査項目は、タイヤの空気漏れの有無を確認する項目を含んでもよい。

経年劣化に起因した部品異常の有無を的確に判定するためには、高度な分析が必要になる傾向がある。一方、タイヤの空気漏れ（たとえば、スローリーク）の有無は、高度な分析を行なわずとも、タイヤの空気圧の推移から容易に判定可能である。一般に、車両の外部に設けられるサーバの情報処理能力を高くすることは、車両に搭載されるコンピュータの情報処理能力を高くすることよりも容易である。車両に搭載されるコンピュータは大きさ及びコスト面で設計上の制約を受ける。このため、車両よりもサーバのほうが高度な分析を行ないやすい。上記のように、高度な分析を要する検査項目を第１検査項目、高度な分析が不要な検査項目を第２検査項目とすることで、各検査項目について的確な判定を行ないやすくなる。

第１状態は、車両の重量と、車両の車速と、車両の停車回数と、車両の急ブレーキ回数と、車両の位置と、車両に搭載された蓄電装置のＳＯＣとの少なくとも１つを含んでもよい。第２状態はタイヤの空気圧を含んでもよい。

上記構成によれば、サーバが、車両に搭載された推進装置（たとえば、駆動用モータ）と制動装置とサスペンションと蓄電装置（たとえば、駆動用バッテリ）との少なくとも１つについて、経年劣化に起因した異常の有無を的確に判定しやすくなる。また、上記構成によれば、車両が、タイヤの空気圧に基づいて、タイヤの空気漏れ（たとえば、スローリーク）の有無を的確に判定しやすくなる。

通信装置は、車両の自動運転中に第１センサによって検出された第１状態と、直近に送信された第１状態との乖離度合いが、所定水準を超える場合には、第１センサによって検出された第１状態を前記サーバへ送信するように構成されてもよい。通信装置は、上記乖離度合いが上記所定水準を超えない場合には、第１センサによって検出された第１状態をサーバへ送信しないように構成されてもよい。

上記構成によれば、車両において第１センサが検出した現在の第１状態が、当該車両からサーバへ送信された直近の第１状態（すなわち、サーバが車両から受信した最も新しい第１状態）から大きく変化していない場合には、第１センサが検出した現在の第１状態をサーバへ送信しない。サーバは、車両から第１センサの検出値を受信しないことにより、第１状態に大きな変化が生じていないことを把握できる。第１センサの検出値が車両からサーバへ送信されないことで、車両からサーバへ送信される情報量を軽減できる。これにより、サーバの負荷が軽減される。

本開示の第２の観点に係る車両管理システムは、第１車両と第２車両とサーバとを含む。サーバは、第１検査項目について良否を判定する第１検査を実行する第１検査装置を備える。第１車両及び第２車両の各々は、以下に示す制御装置と第２検査装置と第１センサと第２センサと通信装置とを備える。制御装置は、当該車両を自動運転で走行させるための制御を実行するように構成される。第２検査装置は、第１検査項目とは異なる第２検査項目について良否を判定する第２検査を実行するように構成される。第１センサは、第１検査項目に対応する第１状態を検出するように構成される。第２センサは、第２検査項目に対応する第２状態を検出するように構成される。第１車両の通信装置は、第１車両の自動運転中に第１センサによって検出された第１状態をサーバへ逐次送信するように構成される。第１検査装置は、車両から逐次受信する第１状態を用いて、第１車両及び第２車両の各々について第１検査を実行するように構成される。第１車両及び第２車両の各々の第２検査装置は、当該車両において、自動運転中に第２センサによって検出された第２状態を用いて第２検査を実行し、第２検査によって不良判定がなされた場合には、第２検査の結果をサーバへ送信する。

上記構成では、第１車両からサーバへ逐次送信される第１状態（第１車両の第１センサによる検出値）を用いて、第２車両に関する第１検査が行なわれる。第２車両の第１センサによる検出値が第２車両からサーバへ送信されないことで、第２車両からサーバへ送信される情報量を軽減できる。上記構成によれば、各車両からサーバへ送信される情報量を軽減しつつ、多くの車両の検査を行なうことが可能になる。

上記の第１車両と第２車両とは、同時に自動運転で走行していてもよい。こうした構成によれば、第１車両と第２車両とで自動運転が行なわれる条件（気象条件など）が概ね共通し、自動運転中に各車両の部品が同じような傾向で劣化しやすくなる。このため、サーバは、第１車両の第１センサによる検出値を用いて、第２車両に関する第１検査を適切に行ないやすくなる。

上記の第１車両と第２車両とは同一車種であってもよい。こうした構成によれば、第１車両と第２車両とで車載部品が概ね共通しており、自動運転中に各車両の部品が同じような傾向で劣化しやすくなる。このため、サーバは、第１車両の第１センサによる検出値を用いて、第２車両に関する第１検査を適切に行ないやすくなる。

本開示の第３の観点に係る車両検査方法は、以下に示す第１及び第２送信工程と第１及び第２判定工程とを含む。

第１送信工程では、車両が、自動運転中に、当該車両に搭載された第１センサによって検出された第１状態をサーバへ送信する。第１判定工程では、サーバが、車両から受信した第１状態を用いて、車両について第１検査項目の良否を判定する。第２判定工程では、車両が、自動運転中に、当該車両に搭載された第２センサによって検出された第２状態を用いて第２検査項目の良否を判定する。第２送信工程では、第２検査項目について不良と判定された場合に、車両が、第２検査項目の判定結果をサーバへ送信する。

上記車両検査方法によっても、前述した車両管理システムと同様、自動運転車両を管理するサーバの負荷を軽減しつつ自動運転車両のメンテナンスを適切に行なうことが可能になる。

本開示によれば、自動運転車両を管理するサーバの負荷を軽減しつつ自動運転車両のメンテナンスを適切に行なうことが可能になる。

本開示の実施の形態に係る車両の概略構成を示す図である。 図１に示した車両の構成の詳細を示す図である。 本開示の実施の形態に係る自動運転制御の処理手順を示すフローチャートである。 本開示の実施の形態に係る第１検査及び第２検査の概要を示す表である。 本開示の実施の形態に係る車両が備える第１センサ及び第２センサについて説明するための図である。 本開示の実施の形態に係るサーバの構成について説明するための図である。 本開示の実施の形態に係る車両の制御装置によって実行される第１検査に係る処理を示すフローチャートである。 本開示の実施の形態に係る車両の制御装置によって実行される第２検査に係る処理を示すフローチャートである。 本開示の実施の形態に係るサーバによって実行される第１検査に係る処理を示すフローチャートである。 本開示の実施の形態に係るサーバによって実行される第２検査に係る処理を示すフローチャートである。 第１検査の変形例に関してサーバによって実行される要求処理を示すフローチャートである。 第１検査の変形例に関して車両によって実行される送信処理を示すフローチャートである。 第１検査の変形例に関してサーバによって実行される判定処理を示すフローチャートである。

以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一又は相当部分には同一符号を付してその説明は繰り返さない。

図１は、本開示の実施の形態に係る車両の概略構成を示す図である。図１を参照して、車両１は、自動運転キット（以下、「ＡＤＫ（Autonomous Driving Kit）」と表記する）２００と、車両プラットフォーム（以下、「ＶＰ（Vehicle Platform）」と表記する）２とを備える。

ＶＰ２は、ベース車両１００の制御システムと、ベース車両１００内に設けられた車両制御インターフェースボックス（以下、「ＶＣＩＢ（Vehicle Control Interface Box）」と表記する）１１１とを含む。ＶＣＩＢ１１１は、ＣＡＮ（Controller Area Network）のような車内ネットワークを通じてＡＤＫ２００と通信してもよい。なお、図１では、ベース車両１００とＡＤＫ２００とが離れた位置に示されているが、ＡＤＫ２００は、実際にはベース車両１００に取り付けられている。この実施の形態では、ベース車両１００のルーフトップにＡＤＫ２００が取り付けられる。ただし、ＡＤＫ２００の取り付け位置は適宜変更可能である。

ベース車両１００は、たとえば市販されるｘＥＶ（電動車）である。ｘＥＶは、電力を動力源の全て又は一部として利用する車両である。この実施の形態では、ベース車両１００としてＢＥＶ（電気自動車）を採用する。ただしこれに限られず、ベース車両１００は、ＢＥＶ以外のｘＥＶ（ＨＥＶ、ＰＨＥＶ、ＦＣＥＶなど）であってもよい。ベース車両１００が備える車輪の数は、たとえば４輪である。ただしこれに限られず、ベース車両１００が備える車輪の数は、３輪であってもよいし、５輪以上であってもよい。

ベース車両１００の制御システムは、統合制御マネージャ１１５に加えて、ベース車両１００を制御するための各種システムおよび各種センサを含む。統合制御マネージャ１１５は、ベース車両１００に含まれる各種センサからの信号（センサ検出信号）に基づいて、ベース車両１００の動作に関わる各種システムを統合して制御する。

この実施の形態では、統合制御マネージャ１１５が制御装置１５０を含む。制御装置１５０は、プロセッサ１５１、ＲＡＭ（Random Access Memory）１５２、及び記憶装置１５３を含む。プロセッサ１５１としては、たとえばＣＰＵ（Central Processing Unit）を採用できる。ＲＡＭ１５２は、プロセッサ１５１によって処理されるデータを一時的に記憶する作業用メモリとして機能する。記憶装置１５３は、格納された情報を保存可能に構成される。記憶装置１５３は、たとえばＲＯＭ（Read Only Memory）及び書き換え可能な不揮発性メモリを含む。記憶装置１５３には、プログラムのほか、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）が記憶されている。この実施の形態では、記憶装置１５３に記憶されているプログラムをプロセッサ１５１が実行することで、各種の車両制御（たとえば、ＡＤＫ２００からの指示に従う自動運転制御）及び後述する検査に係る処理（図７及び図８参照）が実行される。ただし、これらの処理は、ソフトウェアではなく、専用のハードウェア（電子回路）によって実行されてもよい。なお、制御装置１５０が備えるプロセッサの数は任意であり、所定の制御ごとにプロセッサが用意されてもよい。

ベース車両１００は、ブレーキシステム１２１と、ステアリングシステム１２２と、パワートレーンシステム１２３と、アクティブセーフティシステム１２５と、ボディシステム１２６とを含む。これらのシステムは、統合制御マネージャ１１５によって統合制御される。この実施の形態では、各システムがコンピュータを備える。そして、システムごとのコンピュータが車内ネットワーク（たとえば、ＣＡＮ）を通じて統合制御マネージャ１１５と通信する。以下では、各システムが備えるコンピュータを、「ＥＣＵ（Electronic Control Unit）」と称する。

ブレーキシステム１２１は、ベース車両１００の各車輪に設けられた制動装置と、制動装置を制御するＥＣＵとを含む。この実施の形態では、制動装置として油圧式ディスクブレーキ装置が採用される。ベース車両１００は、車輪速センサ１２７Ａ，１２７Ｂを備える。車輪速センサ１２７Ａは、ベース車両１００の前輪に設けられ、前輪の回転速度を検出する。車輪速センサ１２７Ｂは、ベース車両１００の後輪に設けられ、後輪の回転速度を検出する。ブレーキシステム１２１のＥＣＵは、車輪速センサ１２７Ａ，１２７Ｂで検出された各車輪の回転方向及び回転速度を統合制御マネージャ１１５へ出力する。

ステアリングシステム１２２は、ベース車両１００の操舵装置と、操舵装置を制御するＥＣＵとを含む。操舵装置は、たとえば、アクチュエータにより操舵角の調整が可能なラック＆ピニオン式のＥＰＳ（Electric Power Steering）を含む。ベース車両１００は、ピニオン角センサ１２８を備える。ピニオン角センサ１２８は、操舵装置を構成するアクチュエータの回転軸に連結されたピニオンギヤの回転角（ピニオン角）を検出する。ステアリングシステム１２２のＥＣＵは、ピニオン角センサ１２８で検出されたピニオン角を統合制御マネージャ１１５へ出力する。

パワートレーンシステム１２３は、ベース車両１００が備える車輪の少なくとも１つに設けられたＥＰＢ（Electric Parking Brake）と、ベース車両１００のトラッスミッションに設けられたＰ－Ｌｏｃｋ装置と、シフトレンジを選択可能に構成されるシフト装置と、ベース車両１００の駆動源と、パワートレーンシステム１２３に含まれる各装置を制御するＥＣＵとを含む。ＥＰＢは、前述の制動装置とは別に設けられ、電動アクチュエータによって車輪を固定状態にする。Ｐ－Ｌｏｃｋ装置は、たとえば、アクチュエータにより駆動可能なパーキングロックポールによってトランスミッションの出力軸の回転位置を固定状態にする。詳細は後述するが、この実施の形態では、ベース車両１００の駆動源として、バッテリから電力の供給を受けるモータを採用する（図５参照）。パワートレーンシステム１２３のＥＣＵは、ＥＰＢとＰ－Ｌｏｃｋ装置との各々による固定化の有無、シフト装置によって選択されたシフトレンジ、並びにバッテリ及びモータの各々の状態を、統合制御マネージャ１１５へ出力する。

アクティブセーフティシステム１２５は、走行中の車両１について衝突の可能性を判定するＥＣＵを含む。ベース車両１００は、車両１の前方及び後方を含む周辺状況を検出するカメラ１２９Ａ及びレーダセンサ１２９Ｂ，１２９Ｃを備える。アクティブセーフティシステム１２５のＥＣＵは、カメラ１２９Ａ及びレーダセンサ１２９Ｂ，１２９Ｃから受信した信号を用いて、衝突の可能性があるか否かを判定する。アクティブセーフティシステム１２５によって衝突の可能性があると判定された場合には、統合制御マネージャ１１５が、ブレーキシステム１２１に制動指令を出力して、車両１の制動力を増加させる。この実施の形態に係るベース車両１００が初期（出荷時）からアクティブセーフティシステム１２５を備える。しかしこれに限られず、ベース車両に対して後付け可能なアクティブセーフティシステムが採用されてもよい。

ボディシステム１２６は、ボディ系部品（たとえば、方向指示器、ホーン、及びワイパー）と、ボディ系部品を制御するＥＣＵとを備える。ボディシステム１２６のＥＣＵは、マニュアルモードでは、ユーザ操作に従ってボディ系部品を制御し、自律モードでは、ＡＤＫ２００からＶＣＩＢ１１１及び統合制御マネージャ１１５を経て受信する指令に従ってボディ系部品を制御する。

車両１は自動運転可能に構成される。ＶＣＩＢ１１１は、車両制御インターフェースとして機能する。車両１が自動運転で走行するときには、統合制御マネージャ１１５とＡＤＫ２００とがＶＣＩＢ１１１を介して相互に信号のやり取りを行ない、ＡＤＫ２００からの指令に従って統合制御マネージャ１１５が自律モード（Autonomous Mode）による走行制御（すなわち、自動運転制御）を実行する。なお、ＡＤＫ２００は、ベース車両１００から取り外すことも可能である。ベース車両１００は、ＡＤＫ２００が取り外された状態でも、ユーザの運転によりベース車両１００単体で走行することができる。ベース車両１００単体で走行する場合には、ベース車両１００の制御システムが、マニュアルモードによる走行制御（すなわち、ユーザ操作に応じた走行制御）を実行する。

この実施の形態では、ＡＤＫ２００が、通信される各信号を定義するＡＰＩ（Application Program Interface）に従ってＶＣＩＢ１１１との間で信号のやり取りを行なう。ＡＤＫ２００は、上記ＡＰＩで定義された各種信号を処理するように構成される。ＡＤＫ２００は、たとえば、車両１の走行計画を作成し、作成された走行計画に従って車両１を走行させるための制御を要求する各種コマンドを、上記ＡＰＩに従ってＶＣＩＢ１１１へ出力する。以下、ＡＤＫ２００からＶＣＩＢ１１１へ出力される上記各種コマンドの各々を、「ＡＰＩコマンド」とも称する。また、ＡＤＫ２００は、ベース車両１００の状態を示す各種信号を上記ＡＰＩに従ってＶＣＩＢ１１１から受信し、受信したベース車両１００の状態を走行計画の作成に反映する。以下、ＡＤＫ２００がＶＣＩＢ１１１から受信する上記各種信号の各々を、「ＡＰＩシグナル」とも称する。ＡＰＩコマンド及びＡＰＩシグナルはどちらも、上記ＡＰＩで定義された信号に相当する。ＡＤＫ２００の構成の詳細については後述する（図２参照）。

ＶＣＩＢ１１１は、ＡＤＫ２００から各種ＡＰＩコマンドを受信する。ＶＣＩＢ１１１は、ＡＤＫ２００からＡＰＩコマンドを受信すると、そのＡＰＩコマンドを、統合制御マネージャ１１５が処理可能な信号の形式に変換する。以下、統合制御マネージャ１１５が処理可能な信号の形式に変換されたＡＰＩコマンドを、「制御コマンド」とも称する。ＶＣＩＢ１１１は、ＡＤＫ２００からＡＰＩコマンドを受信すると、そのＡＰＩコマンドに対応する制御コマンドを統合制御マネージャ１１５へ出力する。

統合制御マネージャ１１５の制御装置１５０は、ベース車両１００の制御システムにおいて検出されたベース車両１００の状態を示す各種信号（たとえば、センサ信号、又はステータス信号）を、ＶＣＩＢ１１１を介してＡＤＫ２００へ送る。ＶＣＩＢ１１１は、ベース車両１００の状態を示す信号を統合制御マネージャ１１５から逐次受信する。ＶＣＩＢ１１１は、統合制御マネージャ１１５から受信した信号に基づいてＡＰＩシグナルの値を決定する。また、ＶＣＩＢ１１１は、必要に応じて、統合制御マネージャ１１５から受信した信号をＡＰＩシグナルの形式に変換する。そして、ＶＣＩＢ１１１は、得られたＡＰＩシグナルをＡＤＫ２００へ出力する。ＶＣＩＢ１１１からＡＤＫ２００へは、ベース車両１００の状態を示すＡＰＩシグナルがリアルタイムで逐次出力される。

この実施の形態において、統合制御マネージャ１１５とＶＣＩＢ１１１との間では、たとえば自動車メーカーによって定義された汎用性の低い信号がやり取りされ、ＡＤＫ２００とＶＣＩＢ１１１との間では、より汎用性の高い信号（たとえば、公開されたＡＰＩ（Ｏｐｅｎ ＡＰＩ）で定義された信号）がやり取りされる。ＶＣＩＢ１１１は、ＡＤＫ２００と統合制御マネージャ１１５との間で信号の変換を行なうことにより、ＡＤＫ２００からの指令に従って統合制御マネージャ１１５が車両制御を行なうことを可能にする。ただし、ＶＣＩＢ１１１の機能は、上記信号の変換を行なう機能のみには限定されない。たとえば、ＶＣＩＢ１１１は、所定の判断を行ない、その判断結果に基づく信号（たとえば、通知、指示、又は要求を行なう信号）を、統合制御マネージャ１１５とＡＤＫ２００との少なくとも一方へ送ってもよい。ＶＣＩＢ１１１の構成の詳細については後述する（図２参照）。

ベース車両１００は、通信装置１３０をさらに備える。通信装置１３０は、各種通信Ｉ／Ｆ（インターフェース）を含む。制御装置１５０は、通信装置１３０を通じて車両１の外部の装置（たとえば、後述するモバイル端末ＵＴ及びサーバ５００）と通信を行なうように構成される。通信装置１３０は、移動体通信網（テレマティクス）にアクセス可能な無線通信機（たとえば、ＤＣＭ（Data Communication Module））を含む。通信装置１３０は移動体通信網を介してサーバ５００と通信する。無線通信機は、５Ｇ（第５世代移動通信システム）対応の通信Ｉ／Ｆを含んでもよい。また、通信装置１３０は、車内又は車両周辺の範囲内に存在するモバイル端末ＵＴと直接通信するための通信Ｉ／Ｆを含む。通信装置１３０とモバイル端末ＵＴとは、無線ＬＡＮ（Local Area Network）、ＮＦＣ（Near Field Communication）、又はＢｌｕｅｔｏｏｔｈ（登録商標）のような近距離通信を行なってもよい。

モバイル端末ＵＴは、車両１のユーザによって携帯される端末である。この実施の形態では、モバイル端末ＵＴとして、タッチパネルディスプレイを具備するスマートフォンを採用する。ただしこれに限られず、モバイル端末ＵＴとしては、任意のモバイル端末を採用可能であり、ラップトップ、タブレット端末、ウェアラブルデバイス（たとえば、スマートウォッチ又はスマートグラス）、又は電子キーなども採用可能である。

上述の車両１は、ＭａａＳ（Mobility as a Service）システムの構成要素の１つとして採用され得る。ＭａａＳシステムは、たとえばＭＳＰＦ（Mobility Service Platform）を含む。ＭＳＰＦは、各種モビリティサービス（たとえば、ライドシェア事業者、カーシェア事業者、保険会社、レンタカー事業者、タクシー事業者等により提供される各種モビリティサービス）が接続される統一プラットフォームである。サーバ５００は、ＭＳＰＦにおいてモビリティサービスのための情報の管理及び公開を行なうコンピュータである。サーバ５００は、各種モビリティの情報を管理し、事業者からの要求に応じて情報（たとえば、ＡＰＩ、及び、モビリティ間の連携に関する情報）を提供する。サービスを提供する事業者は、ＭＳＰＦ上で公開されたＡＰＩを用いて、ＭＳＰＦが提供する様々な機能を利用することができる。たとえば、ＡＤＫの開発に必要なＡＰＩは、ＭＳＰＦ上に公開されている。

図２は、車両１の構成の詳細を示す図である。図１とともに図２を参照して、ＡＤＫ２００は、車両１の自動運転を行なうための自動運転システム（以下、「ＡＤＳ（Autonomous Driving System）」と表記する）２０２を含む。ＡＤＳ２０２は、コンピュータ２１０と、ＨＭＩ（Human Machine Interface）２３０と、認識用センサ２６０と、姿勢用センサ２７０と、センサクリーナ２９０とを含む。

コンピュータ２１０は、プロセッサと、ＡＰＩを利用した自動運転ソフトウェアを記憶する記憶装置とを備え、プロセッサによって自動運転ソフトウェアを実行可能に構成される。自動運転ソフトウェアにより、自動運転に関する制御（後述する図３参照）が実行される。自動運転ソフトウェアは、ＯＴＡ（Over The Air）によって逐次更新されてもよい。コンピュータ２１０は、通信モジュール２１０Ａ及び２１０Ｂをさらに備える。

ＨＭＩ２３０は、ユーザとコンピュータ２１０とが情報をやり取りするための装置である。ＨＭＩ２３０は、入力装置及び報知装置を含む。ユーザは、ＨＭＩ２３０を通じて、コンピュータ２１０に指示又は要求を行なったり、自動運転ソフトウェアで使用されるパラメータ（ただし、変更が許可されているものに限る）の値を変更したりすることができる。ＨＭＩ２３０は、入力装置及び報知装置の両方の機能を兼ね備えるタッチパネルディスプレイであってもよい。

認識用センサ２６０は、車両１の外部環境を認識するための情報（以下、「環境情報」とも称する）を取得する各種センサを含む。認識用センサ２６０は、車両１の環境情報を取得し、コンピュータ２１０へ出力する。環境情報は、自動運転制御に用いられる。この実施の形態では、認識用センサ２６０が、車両１の周囲（前方及び後方を含む）を撮像するカメラと、電磁波又は音波によって障害物を検知する障害物検知器（たとえば、ミリ波レーダ及び／又はライダー）とを含む。コンピュータ２１０は、たとえば、認識用センサ２６０から受信する環境情報を用いて、車両１から認識可能な範囲に存在する人、物体（他の車両、柱、ガードレールなど）、及び道路上のライン（たとえば、センターライン）を認識できる。認識のために、人工知能（ＡＩ）又は画像処理用プロセッサが用いられてもよい。

姿勢用センサ２７０は、車両１の姿勢に関する情報（以下、「姿勢情報」とも称する）を取得し、コンピュータ２１０へ出力する。姿勢用センサ２７０は、車両１の加速度、角速度、及び位置を検出する各種センサを含む。この実施の形態では、姿勢用センサ２７０が、ＩＭＵ（Inertial Measurement Unit）及びＧＰＳ（Global Positioning System）センサを含む。ＩＭＵは、車両１の前後方向、左右方向、及び上下方向の各々の加速度、並びに車両１のロール方向、ピッチ方向、及びヨー方向の各々の角速度を検出する。ＧＰＳセンサは、複数のＧＰＳ衛星から受信する信号を用いて車両１の位置を検出する。自動車及び航空機の分野においてＩＭＵとＧＰＳとを組み合わせて高い精度で姿勢を計測する技術が公知である。コンピュータ２１０は、たとえば、こうした公知の技術を利用して、上記姿勢情報から車両１の姿勢を計測してもよい。

センサクリーナ２９０は、車外で外気にさらされるセンサ（たとえば、認識用センサ２６０）の汚れを除去する装置である。たとえば、センサクリーナ２９０は、洗浄液及びワイパーを用いて、カメラのレンズ及び障害物検知器の出射口をクリーニングするように構成されてもよい。

車両１においては、安全性を向上させるため、所定の機能（たとえば、ブレーキ、ステアリング、及び車両固定）に冗長性を持たせている。ベース車両１００の制御システム１０２は、同等の機能を実現するシステムを複数備える。具体的には、ブレーキシステム１２１はブレーキシステム１２１Ａ及び１２１Ｂを含む。ステアリングシステム１２２はステアリングシステム１２２Ａ及び１２２Ｂを含む。パワートレーンシステム１２３は、ＥＰＢシステム１２３ＡとＰ－Ｌｏｃｋシステム１２３Ｂとを含む。各システムがＥＣＵを備える。同等の機能を実現する複数のシステムのうち、一方に異常が生じても、他方が正常に動作することで、車両１において当該機能は正常に働く。

ＶＣＩＢ１１１は、ＶＣＩＢ１１１ＡとＶＣＩＢ１１１Ｂとを含む。ＶＣＩＢ１１１Ａ及び１１１Ｂの各々はコンピュータを含む。コンピュータ２１０の通信モジュール２１０Ａ、２１０Ｂは、それぞれＶＣＩＢ１１１Ａ、１１１Ｂのコンピュータと通信可能に構成される。ＶＣＩＢ１１１とＶＣＩＢ１１１Ｂとは、相互に通信可能に接続されている。ＶＣＩＢ１１１Ａ及び１１１Ｂの各々は、単独で動作可能であり、一方に異常が生じても、他方が正常に動作することで、ＶＣＩＢ１１１は正常に動作する。ＶＣＩＢ１１１Ａ及び１１１Ｂはどちらも統合制御マネージャ１１５を介して上記各システムに接続されている。ただし、図２に示すように、ＶＣＩＢ１１１ＡとＶＣＩＢ１１１Ｂとでは接続先が一部異なっている。

この実施の形態では、車両１を加速させる機能については、冗長性を持たせていない。パワートレーンシステム１２３は、車両１を加速させるためのシステムとして、推進システム１２３Ｃを含む。

車両１は、自律モードとマニュアルモードとを切替え可能に構成される。ＡＤＫ２００がＶＣＩＢ１１１から受信するＡＰＩシグナルには、車両１が自律モードとマニュアルモードとのいずれの状態かを示す信号（以下、「自律ステート」と表記する）が含まれる。ユーザは、所定の入力装置（たとえば、ＨＭＩ２３０又はモバイル端末ＵＴ）を通じて、自律モードとマニュアルモードとのいずれかを選択できる。ユーザによっていずれかの運転モードが選択されると、選択された運転モードに車両１がなり、選択結果が自律ステートに反映される。ただし、車両１が自動運転可能な状態になっていなければ、ユーザが自律モードを選択しても自律モードに移行しない。車両１の運転モードの切替えは、統合制御マネージャ１１５によって行なわれてもよい。統合制御マネージャ１１５は、車両１の状況に応じて自律モードとマニュアルモードとを切り替えてもよい。

車両１が自律モードであるときには、コンピュータ２１０が、ＶＰ２から車両１の状態を取得して、車両１の次の動作（たとえば、加速、減速、及び曲がる）を設定する。そして、コンピュータ２１０は、設定された車両１の次の動作を実現するための各種指令を出力する。コンピュータ２１０がＡＰＩソフトウェア（すなわち、ＡＰＩを利用した自動運転ソフトウェア）を実行することにより、自動運転制御に関する指令がＡＤＫ２００からＶＣＩＢ１１１を通じて統合制御マネージャ１１５へ送信される。

図３は、この実施の形態に係る自動運転制御においてＡＤＫ２００が実行する処理を示すフローチャートである。このフローチャートに示される処理は、車両１が自律モードであるときに、ＡＰＩに対応する周期（ＡＰＩ周期）で繰り返し実行される。車両１の運転モードがマニュアルモードから自律モードに切り替わると、自動運転開始を示す開始信号が車両１の識別情報とともに車両１（通信装置１３０）からサーバ５００へ送信されるとともに、以下に説明する図３に示す一連の処理が開始される。以下では、フローチャート中の各ステップを、単に「Ｓ」と表記する。

図１及び図２とともに図３を参照して、Ｓ１０１では、コンピュータ２１０が現在の車両１の情報を取得する。たとえば、コンピュータ２１０は、認識用センサ２６０及び姿勢用センサ２７０から車両１の環境情報及び姿勢情報を取得する。さらに、コンピュータ２１０はＡＰＩシグナルを取得する。この実施の形態では、車両１が自律モード及びマニュアルモードのいずれである場合にも、車両１の状態を示すＡＰＩシグナルがＶＣＩＢ１１１からＡＤＫ２００へリアルタイムで逐次出力されている。自動運転制御の精度を向上させるために、自律モードにおいてはマニュアルモードよりも短い周期で統合制御マネージャ１１５からＡＤＫ２００に向けて車両１の状態が逐次送信されてもよい。コンピュータ２１０が取得するＡＰＩシグナルには、前述の自律ステートのほか、車輪速センサ１２７Ａ，１２７Ｂで検出された各車輪の回転方向及び回転速度を示す信号などが含まれる。

Ｓ１０２では、コンピュータ２１０が、Ｓ１０１で取得した車両１の情報に基づいて走行計画を作成する。たとえば、コンピュータ２１０が、車両１の挙動（たとえば、車両１の姿勢）を計算し、車両１の状態及び外部環境に適した走行計画を作成する。走行計画は、所定期間における車両１の挙動を示すデータである。すでに走行計画が存在する場合には、Ｓ１０２においてその走行計画が修正されてもよい。

Ｓ１０３では、コンピュータ２１０が、Ｓ１０２で作成された走行計画から制御的な物理量（加速度、タイヤ切れ角など）を抽出する。Ｓ１０４では、コンピュータ２１０が、Ｓ１０３で抽出された物理量をＡＰＩ周期ごとに分割する。Ｓ１０５では、コンピュータ２１０が、Ｓ１０４で分割された物理量を用いてＡＰＩソフトウェアを実行する。このようにＡＰＩソフトウェアが実行されることにより、走行計画に従う物理量を実現するための制御を要求するＡＰＩコマンド（推進方向コマンド、推進コマンド、制動コマンド、車両固定コマンドなど）がＡＤＫ２００からＶＣＩＢ１１１へ送信される。ＶＣＩＢ１１１は、受信したＡＰＩコマンドに対応する制御コマンドを統合制御マネージャ１１５へ送信し、統合制御マネージャ１１５は、その制御コマンドに従って車両１の自動運転制御を行なう。自動運転中の車両１の状態は、コンピュータ２１０の記憶装置に逐次記録される。

続くＳ１０６では、車両１が自律モードであるか否かを、コンピュータ２１０が判断する。自律モードが継続している間は（Ｓ１０６にてＹＥＳ）、上記Ｓ１０１～Ｓ１０５の処理が繰り返し実行されることにより、車両１の自動運転が実行される。他方、車両１がマニュアルモードになると（Ｓ１０６にてＮＯ）、Ｓ１０７において、自動運転終了を示す終了信号が車両１の識別情報とともに車両１（通信装置１３０）からサーバ５００へ送信された後、図３に示す一連の処理は終了する。この実施の形態では、コンピュータ２１０とＶＣＩＢ１１１と統合制御マネージャ１１５とが協働して車両１を自動運転で走行させるための制御を実行する。コンピュータ２１０とＶＣＩＢ１１１（より特定的には、ＶＣＩＢ１１１に含まれるコンピュータ）と統合制御マネージャ１１５（より特定的には、制御装置１５０）との各々は、本開示に係る「制御装置」の一例に相当する。この実施の形態では、車両１が有人の状態であるときに車両１の自動運転が行なわれることを想定している。しかしこれに限られず、車両１が無人の状態であるときに車両１の自動運転が行なわれるようにしてもよい。自動運転制御は、図３に示した制御に限られず、他の制御（公知の自動運転制御）が採用されてもよい。

この実施の形態では、サーバ５００が、第１検査項目について良否を判定する第１検査を実行する。また、車両１に搭載された制御装置１５０が、第１検査項目とは異なる第２検査項目について良否を判定する第２検査を実行する。サーバ５００においては、プロセッサ（後述するプロセッサ５０１）と、プロセッサにより実行されるプログラムとによって、本開示に係る「第１検査装置」の一例が具現化される。また、制御装置１５０においては、プロセッサ１５１と、プロセッサ１５１により実行されるプログラムとによって、本開示に係る「第２検査装置」の一例が具現化される。

図４は、この実施の形態に係る第１検査及び第２検査の概要を示す表である。図４を参照して、この実施の形態に係る第１検査及び第２検査に関しては、第１検査項目よりも第２検査項目のほうが、要求されるリアルタイム性が高い。すなわち、要求されるモニタリング間隔及び判定間隔は、第１検査項目よりも第２検査項目のほうが短い。具体的には、第１検査項目は、経年劣化に起因した部品異常の有無を確認する項目である。第２検査項目は、タイヤの空気漏れの有無を確認する項目である。

この実施の形態では、サーバ５００が、第１検査項目に対応する第１状態に基づいて第１検査を実行する。詳細は後述するが、第１状態は、車両１の自動運転中に車両１が備える第１センサによって検出され、車両１からサーバ５００へ逐次送信される。サーバ５００は、リモートで車両１の検査を行なう。この実施の形態に係る車両検査方法では、第１状態が、車両１の重量と、車両１の車速と、車両１の停車回数と、車両１の急ブレーキ回数と、車両１の位置と、車両１に搭載された蓄電装置（後述する図５に示すバッテリ１６０）のＳＯＣとを含む。上記第１状態と各種車載部品の経年劣化（第１検査項目）との関係については後述する。

この実施の形態では、車両１に搭載された制御装置１５０が、第２検査項目に対応する第２状態に基づいて第２検査を実行する。詳細は後述するが、第２状態は、車両１の自動運転中に車両１が備える第２センサによって検出される。この実施の形態では、第２状態としてタイヤの空気圧が採用される。タイヤの空気漏れが生じると、タイヤの空気圧が低下する。スローリークの場合はタイヤの空気圧が徐々に低下する。制御装置１５０は、タイヤの空気圧の推移に基づいて、タイヤの空気漏れが生じているか否かを判断することができる。

図５は、車両１が備える第１センサ及び第２センサについて説明するための図である。図１及び図２とともに図５を参照して、車両１は、推進システム１２３Ｃに電力を供給するバッテリ１６０を備える。バッテリ１６０としては、公知の車両用蓄電装置（たとえば、液式二次電池、全固体二次電池、又は組電池）を採用できる。車両用二次電池の例としては、リチウムイオン電池、ニッケル水素電池が挙げられる。

バッテリ１６０には、監視モジュール１６０ａが設けられている。監視モジュール１６０ａは、バッテリ１６０の状態（たとえば、電圧、電流、及び温度）を検出する各種センサを含み、検出結果を統合制御マネージャ１１５へ出力する。監視モジュール１６０ａは、上記センサ機能に加えて、ＳＯＣ（State Of Charge）推定機能をさらに有するＢＭＳ（Battery Management System）であってもよい。制御装置１５０は、監視モジュール１６０ａの出力に基づいてバッテリ１６０の状態（たとえば、温度、電流、電圧、及びＳＯＣ）を取得することができる。ＳＯＣは、蓄電残量を示し、たとえば、満充電状態の蓄電量に対する現在の蓄電量の割合を０～１００％で表わしたものである。

車両１は、車両１の重量を検出する重量センサ１７０ａをさらに備える。重量センサ１７０ａによって検出される車両１の重量は、車体の重量に、車両１に乗った人の重量と、車両１に積載した物の重量とを加えた総重量である。この実施の形態では、ベース車両１００が備えるサスペンション１７０に取り付けられた積載荷重センサを、重量センサ１７０ａとして採用する。ただしこれに限られず、積載荷重センサに代えて又は加えて、ベース車両１００内の各座席に設けられた圧力センサを、重量センサ１７０ａとして採用してもよい。重量センサ１７０ａが検出した車両１の重量は、統合制御マネージャ１１５へ出力される。

推進システム１２３Ｃは、ＭＧ（Motor Generator）２０と、ＥＣＵ２１と、ＰＣＵ（Power Control Unit）２２とを含む。推進システム１２３Ｃは、バッテリ１６０に蓄えられた電力を用いて車両１の走行駆動力を発生させる。ＭＧ２０は、たとえば三相交流モータジェネレータである。ＰＣＵ２２は、たとえば、インバータと、コンバータと、リレー（以下、「ＳＭＲ（System Main Relay）」と称する）とを含む。ＰＣＵ２２は、ＥＣＵ２１によって制御される。ＳＭＲは、バッテリ１６０からＭＧ２０までの電路の接続／遮断を切り替えるように構成される。ＳＭＲは、車両１の走行時に閉状態（接続状態）にされる。

ＭＧ２０は、ＰＣＵ２２によって駆動され、車両１の駆動輪Ｗを回転させる。また、ＭＧ２０は、回生発電を行ない、発電した電力をバッテリ１６０に供給する。ＰＣＵ２２は、バッテリ１６０から供給される電力を用いてＭＧ２０を駆動する。車両１が備える走行用のモータ（ＭＧ２０）の数は任意であり、１つでも２つでも３つ以上でもよい。走行用のモータはインホイールモータであってもよい。図５には、１つの駆動輪Ｗのみを模式的に示しているが、車両１における駆動輪Ｗの数及び駆動方式は任意である。車両１の駆動方式は、前輪駆動、後輪駆動、４輪駆動のいずれであってもよい。

車両１が備える各車輪（駆動輪Ｗを含む）には、車輪のタイヤの空気圧を検出する空気圧センサ２０ｂと、ブレーキシステム１２１に含まれる制動装置１８０と、制動装置１８０によって車輪に付与される制動力を検出するブレーキセンサ１８０ａとが設けられている。空気圧センサ２０ｂは、タイヤの空気圧とともにタイヤの温度も監視するＴＰＭＳ（Tire Pressure Monitoring System）であってもよい。ブレーキセンサ１８０ａは、ブレーキパッド（又は、ホイールシリンダ）に加わる油圧を検出する油圧センサであってもよい。４つの空気圧センサ２０ｂ及び４つのブレーキセンサ１８０ａによってそれぞれ検出された車輪ごとのタイヤ空気圧及び制動力（たとえば、制動力に対応する油圧）は統合制御マネージャ１１５へ出力される。

この実施の形態では、車輪速センサ１２７Ａ，１２７Ｂ（図１）、姿勢用センサ２７０（図２）、監視モジュール１６０ａ（図５）、重量センサ１７０ａ（図５）、及びブレーキセンサ１８０ａ（図５）の各々が、第１センサとして機能する。通信装置１３０は、車両１の自動運転中に第１センサによって検出された第１状態をサーバ５００へ逐次送信する。

この実施の形態では、４つの空気圧センサ２０ｂの各々が、第２センサとして機能する。制御装置１５０は、車両１の自動運転中に第２センサ（空気圧センサ２０ｂ）によって検出された第２状態（タイヤの空気圧）を用いて第２検査を実行する。そして、第２検査によって不良判定がなされた場合には、通信装置１３０が第２検査の結果を示す信号をサーバ５００へ送信する。

図６は、サーバ５００の構成について説明するための図である。図１及び図２とともに図６を参照して、サーバ５００は、プロセッサ５０１、ＲＡＭ５０２、及び記憶装置５０３を含む。記憶装置５０３は、格納された情報を保存可能に構成される。記憶装置５０３には、プログラムのほか、プログラムで使用される情報（たとえば、マップ、数式、及び各種パラメータ）が記憶されている。この実施の形態では、記憶装置５０３に記憶されているプログラムをプロセッサ５０１が実行することで、後述する検査に係る処理（図９及び図１０参照）が実行される。ただし、こうした処理は、ソフトウェアではなく、専用のハードウェア（電子回路）によって実行されてもよい。

記憶装置５０３は、推定アルゴリズムＥをさらに記憶している。推定アルゴリズムＥは、所定の入力情報と所定の出力情報との関係を規定する。推定アルゴリズムＥに所定の入力情報が入力されると、推定アルゴリズムＥは上記関係に従って所定の出力情報を出力する。

この実施の形態では、前述した第１状態、すなわち車両１の重量、車両１の車速、車両１の停車回数、車両１の急ブレーキ回数、車両１の位置、及びバッテリ１６０のＳＯＣが、推定アルゴリズムＥの上記入力情報に相当する。車両１の車速及び停車回数の各々は、たとえば車輪速センサ１２７Ａ，１２７Ｂによって検出される。また、車両１の重量、車両１の急ブレーキ回数、車両１の位置、バッテリ１６０のＳＯＣは、それぞれ重量センサ１７０ａ、ブレーキセンサ１８０ａ、姿勢用センサ２７０、監視モジュール１６０ａによって検出される。

この実施の形態では、車両１に搭載された所定の対象部品（たとえば、部品Ａ、部品Ｂ、部品Ｃ、部品Ｄ、・・・）の劣化進行度が、推定アルゴリズムＥの上記出力情報に相当する。詳しくは、第１状態が推定アルゴリズムＥに入力されると、その第１状態で車両１が自動運転を実行することによって対象部品の劣化が進行した程度（対象部品の劣化進行度）が、推定アルゴリズムＥから出力される。

この実施の形態では、車両１に搭載されたＭＧ２０（駆動用モータ）とバッテリ１６０（駆動用バッテリ）とサスペンション１７０と制動装置１８０との各々が、対象部品として採用される。具体的には、自動運転中の車両１の重量が大きいほど、ＭＧ２０、サスペンション１７０、及び制動装置１８０の各々の劣化が進行しやすくなる。車両１の急ブレーキ回数（積算回数）が増えるほど、サスペンション１７０及び制動装置１８０の各々の劣化が進行しやすくなる。バッテリ１６０のＳＯＣが適正範囲から外れている時間が長くなるほど、バッテリ１６０の劣化が進行しやすくなる。車両１の停車回数（積算回数）が増えるほど、制動装置１８０の劣化が進行しやすくなる。また、走行を継続する車両１は停車後に発進するため、車両１の停車回数が増えるほど、車両１の発進回数が増えてＭＧ２０の劣化が進行しやすくなる。

推定アルゴリズムＥの入力情報は、車両１の位置情報に基づいて取得される、気象情報（車両１が存在する地域の気象を示す情報）と、交通情報（車両１の周辺の交通状況を示す情報）と、路面情報（車両１が走行中の路面に関する情報）とをさらに含んでもよい。気象情報の例としては、気温、天気（たとえば、晴れ、くもり、雨、又は雪）が挙げられる。交通情報の例としては、渋滞情報が挙げられる。路面情報の例としては、平坦、上り坂、下り坂、悪路のような路面の種類が挙げられる。気温（又は、路面温度）が適正範囲から外れている時間が長くなるほど、ゴム製品（たとえば、タイヤ）は劣化しやすくなる。また、ゴム製品は、太陽光によっても劣化し得る。渋滞した道路を車両１が走行すると、ＭＧ２０及び制動装置１８０の各々が劣化しやすくなる。車両１が上り坂を走行すると、ＭＧ２０が劣化しやすくなる。車両１が下り坂を走行すると、制動装置１８０が劣化しやすくなる。車両１が悪路を走行すると、サスペンション１７０が劣化しやすくなる。

この実施の形態では、推定アルゴリズムＥとして、ＡＩ（人工知能）によるアルゴリズムを採用する。推定アルゴリズムＥは、ビッグデータ（たとえば、車両１と同一仕様の車両で実測されたデータ）を用いて機械学習された学習済みモデルであってもよい。ただしこれに限られず、推定アルゴリズムＥは、ルールベースのアルゴリズムであってもよい。推定アルゴリズムＥは、たとえば上述の関係（傾向）を示す数式又はマップであってもよい。推定アルゴリズムＥは、ＯＴＡによって逐次更新されてもよい。

サーバ５００は、車両に関する情報（以下、「車両情報」とも称する）を管理する。複数の車両の各々の車両情報が、サーバ５００の記憶装置５０３に記憶されている。具体的には、車両を識別するための識別情報（車両ＩＤ）が車両ごとに付与されており、サーバ５００は車両情報を車両ＩＤで区別して管理している。車両情報は、たとえば車種、仕様、及び車両状況（たとえば、自動運転中か否か）を含む。この実施の形態では、車両情報が各対象部品の劣化度をさらに含む。図６中の表Ｔ１は、各車両の車両情報を示す。表Ｔ１において、「Ｖ－１」は車両１の車両ＩＤに相当する。図６には、車両１（Ｖ－１）に関する車両情報（特に、対象部品ごとの劣化度）のみが示されているが、表Ｔ１は、サーバ５００に登録された全ての車両に関する車両情報を示す。

サーバ５００は、自動運転中の車両１から逐次受信する第１状態を推定アルゴリズムＥに逐次入力し、推定アルゴリズムＥから出力される対象部品ごとの劣化進行度を、表Ｔ１が示す対象部品ごとの劣化度に逐次加算する。自動運転中の各対象部品の劣化進行度は、推定アルゴリズムＥによって推定され、表Ｔ１における対応する対象部品の劣化度に加算される。これにより、表Ｔ１が更新される。サーバ５００は、推定アルゴリズムＥから出力される各対象部品の劣化進行度を積算することによって、車両１の自動運転中における各対象部品の劣化進行度を取得することができる。なお、自動運転中以外における各対象部品の劣化進行度の推定方法は任意である。サーバ５００は、たとえば所定のマップを用いて、自動運転中以外における各対象部品の劣化進行度を推定してもよい。

制御装置１５０は、所定の期間（以下、「運用期間」と称する）において車両１の自動運転を実行するように構成される。車両１の自動運転中は、図３に示した処理が実行され、制御装置１５０がＡＤＫ２００からの指令に従って車両１の各種システム（たとえば、図２に示したブレーキシステム１２１、ステアリングシステム１２２、パワートレーンシステム１２３、アクティブセーフティシステム１２５、及びボディシステム１２６）を制御する。車両１は、運用期間において、自動運転により所定のサービス（たとえば、物流サービス又は旅客輸送サービス）を提供してもよい。この実施の形態では、自動運転により旅客輸送サービスを提供する車両１が、運行領域内を予め決められた経路で巡回走行する。ただしこれに限られず、車両１は、都度の要求に応じて経路を決定し、決定された経路（オンデマンド経路）に従って自動運転による走行を実行してもよい。

図７は、車両１の制御装置１５０によって実行される第１検査に係る処理を示すフローチャートである。たとえば、車両１による自動運転が開始されると、図７に示す一連の処理が開始され、自動運転中は所定の第１周期で図７に示す一連の処理が繰り返し実行される。制御装置１５０は、たとえば、車両１の運転モードがマニュアルモードから自律モードに切り替わった場合に、車両１による自動運転が開始されたと判断する。

図１～図６とともに図７を参照して、Ｓ１１では、第１センサによって検出された現在の第１状態（より特定的には、車両１の重量、車両１の車速、車両１の停車回数、車両１の急ブレーキ回数、車両１の位置、及びバッテリ１６０のＳＯＣ）を、制御装置１５０が取得し、記憶装置１５３に保存する。

続くＳ１２では、Ｓ１１で取得された第１状態の少なくとも１つが前回送信（後述するＳ１３）から大きく変化したか否かを、制御装置１５０が判断する。具体的には、制御装置１５０は、Ｓ１１で検出された第１状態と、直近にサーバ５００へ送信された第１状態との乖離度合い（以下、「状態変化量」とも称する）が、所定水準を超えるか否かを判断する。前回値（直近に送信した値）と今回値（現在のセンサ検出値）との乖離度合い（状態変化量）は、たとえば差又は比率で表すことができる。差（絶対値）が大きいほど状態変化量が大きいことになる。また、比率が１に近いほど状態変化量が小さいことになる。所定水準は、第１状態ごとに任意に設定できる。

制御装置１５０は、第１状態ごとに状態変化量が所定水準を超えるか否かを判断し、少なくとも１つの第１状態の状態変化量が所定水準を超える場合には、Ｓ１２においてＹＥＳと判断し、いずれの第１状態の状態変化量も所定水準を超えない場合には、Ｓ１２においてＮＯと判断する。初回処理ルーチン（車両１が自動運転を開始した直後の処理ルーチン）では、前回値が存在しないため、Ｓ１２においてＹＥＳと判断される。

Ｓ１２においてＹＥＳと判断された場合には、通信装置１３０が、Ｓ１３において、Ｓ１１で取得された全ての第１状態を示す信号（以下、「第１検査信号」とも称する）を、車両１の車両ＩＤとともにサーバ５００へ送信する。その後、処理がＳ１４に進む。他方、Ｓ１２においてＮＯと判断された場合には、第１検査信号の送信（Ｓ１３）が行なわれることなく、処理がＳ１４に進む。

続くＳ１４では、車両１が自動運転中であるか否かを、制御装置１５０が判断する。たとえば、車両１が自律モードである場合には車両１が自動運転中であると制御装置１５０は判断し、車両１がマニュアルモードである場合には車両１が自動運転中ではないと制御装置１５０は判断する。車両１が自動運転中である場合には（Ｓ１４にてＹＥＳ）、処理が最初のステップ（Ｓ１１）に戻る。車両１が自動運転中ではない場合には（Ｓ１４にてＮＯ）、図７に示す一連の処理が終了する。

上記のように、車両１（通信装置１３０）は、車両１の自動運転中に第１センサによって検出された第１状態をサーバ５００へ逐次送信するように構成される。この実施の形態では、第１センサによって検出された第１状態を示す第１検査信号が、図７のＳ１３において、車両１からサーバ５００へ逐次送信される。

図８は、車両１の制御装置１５０によって実行される第２検査に係る処理を示すフローチャートである。たとえば、車両１による自動運転が開始されると、図８に示す一連の処理が開始され、自動運転中は、所定の第２周期で図８に示す一連の処理が繰り返し実行される。第２検査のリアルタイム性を高めるため、第２周期（第２検査の実行周期）を第１周期（第１状態の検出周期）よりも短くしてもよい。

図１～図６とともに図８を参照して、Ｓ２１では、第２センサ（空気圧センサ２０ｂ）によって検出された現在の第２状態（タイヤの空気圧）を、制御装置１５０が取得し、記憶装置１５３に保存する。続けて、制御装置１５０は、Ｓ２２において、Ｓ２１で取得された第２状態を用いて第２検査を実行する。第２検査においては、第２状態に異常が生じているか否かが判定される。具体的には、制御装置１５０は、タイヤの空気圧の推移に基づいて、車両１の車輪ごとにタイヤの空気漏れが生じているか否かを判断する。タイヤの空気漏れが生じていることは、タイヤ空気圧（第２状態）に異常が生じていることを意味する。制御装置１５０は、基準レベルを超えるタイヤ空気圧の低下がＳ２２において所定回連続で確認された場合にタイヤの空気漏れが生じていると判断してもよい。

車両１において少なくとも１つの車輪についてタイヤの空気漏れが生じている場合には、第２検査によって不良判定がなされ（Ｓ２２にてＹＥＳ）、処理がＳ２３に進む。Ｓ２３では、通信装置１３０が、第２検査の結果（タイヤ空気圧異常）を示す信号（以下、「第２検査信号」とも称する）を、車両１の車両ＩＤとともにサーバ５００へ送信する。その後、処理がＳ２４に進む。他方、車両１の全ての車輪についてタイヤの空気漏れが生じていない場合には、第２検査によって良判定がなされ（Ｓ２２にてＮＯ）、第２検査信号の送信（Ｓ２３）が行なわれることなく、処理がＳ２４に進む。

続くＳ２４では、制御装置１５０が、前述した図７のＳ１４と同様に、車両１が自動運転中であるか否かを判断する。そして、車両１が自動運転中である場合には（Ｓ２４にてＹＥＳ）、処理が最初のステップ（Ｓ２１）に戻る。車両１が自動運転中ではない場合には（Ｓ２４にてＮＯ）、図８に示す一連の処理が終了する。

上記のように、制御装置１５０は、車両１の自動運転中に第２センサによって検出された第２状態を用いて第２検査を実行し（Ｓ２１及びＳ２２）、第２検査によって不良判定がなされた場合に（Ｓ２２にてＹＥＳ）、通信装置１３０が第２検査信号（第２検査の結果を示す信号）をサーバ５００へ送信する（Ｓ２３）。

図９は、サーバ５００によって実行される第１検査に係る処理を示すフローチャートである。このフローチャートに示される処理は、車両１の自動運転中に繰返し実行される。たとえば車両１の自動運転開始を示す開始信号をサーバ５００が受信すると、以下に説明する図９に示す一連の処理が開始される。

図１～図６とともに図９を参照して、Ｓ３１では、サーバ５００が、車両１から逐次受信する第１状態（すなわち、図７のＳ１３で送信される第１検査信号が示す第１状態）を用いて、車両１の各対象部品（ＭＧ２０、バッテリ１６０、サスペンション１７０、制動装置１８０）の現在の劣化度を推定する。具体的には、サーバ５００は、推定アルゴリズムＥ（図６）を用いて、直近に受信した第１検査信号が示す現在の第１状態から、自動運転中の経年劣化に起因した各対象部品の劣化進行度を推定する。サーバ５００は、推定された各対象部品の劣化進行度を、表Ｔ１における対応する対象部品の劣化度に加算することによって、表Ｔ１（図６）を更新する。そして、サーバ５００は、更新された表Ｔ１から各対象部品の現在の劣化度を取得する。なお、サーバ５００は、次の第１検査信号を受信するまでの間は、直近に受信した第１検査信号が示す第１状態が維持されているものとみなす。

続くＳ３２では、車両１においていずれかの対象部品に異常が生じているか否かを、サーバ５００が判定する。具体的には、サーバ５００は、車両１に搭載された対象部品ごとに現在の劣化度が所定の閾値を超えるか否かを判断する。この実施の形態では、Ｓ３１及びＳ３２において実行される車載部品の検査が、車両１に関する第１検査に相当する。上記閾値は、対象部品ごとに任意に設定できる。少なくとも１つの対象部品の劣化度が閾値を超える場合には、第１検査によって不良判定がなされ（Ｓ３２にてＹＥＳ）、処理がＳ３３に進む。第１検査によって不良判定がなされたことは、いずれかの対象部品において経年劣化に起因した異常が生じたことを意味する。

Ｓ３３では、サーバ５００が、車両１について所定の交換処理を実行する。所定の交換処理では、第１検査の結果の記録、報知、及び送信の少なくとも１つが実行される。第１検査の結果は、交換が必要な部品（すなわち、劣化度が閾値を超える対象部品）を示す情報を含む。サーバ５００は、第１検査の結果を記憶装置５０３に記録してもよい。サーバ５００は、第１検査の結果を車両１又は所定の端末へ送信し、車両１のユーザに部品交換を促す報知処理を所定の報知装置（たとえば、ＨＭＩ２３０又はモバイル端末ＵＴ）に実行させてもよい。サーバ５００は、Ｓ３３において、車両１の運用を禁止し、代わりの車両を手配するための処理を実行してもよい。

上記Ｓ３３の処理が実行されると、処理がＳ３４に進む。他方、車両１においていずれの対象部品の劣化度も閾値を超えない場合には、第１検査によって良判定がなされ（Ｓ３２にてＮＯ）、交換処理（Ｓ３３）が行なわれることなく、処理がＳ３４に進む。Ｓ３４では、サーバ５００が、車両１が自動運転中であるか否かを判断する。サーバ５００は、たとえば車両１の自動運転終了を示す終了信号を受信した場合に、車両１の自動運転が終了したと判断する。車両１が自動運転中である場合には（Ｓ３４にてＹＥＳ）、処理が最初のステップ（Ｓ３１）に戻る。車両１が自動運転中ではない場合には（Ｓ３４にてＮＯ）、図９に示す一連の処理が終了する。

図１０は、サーバ５００によって実行される第２検査に係る処理を示すフローチャートである。このフローチャートに示される処理は、たとえばサーバ５００が車両１から第２検査信号を受信するたびに開始される。サーバ５００が車両１から第２検査信号を受信したことは、車両１においてタイヤの空気漏れ（パンク）が生じたことを意味する。

図１～図６とともに図１０を参照して、Ｓ４０では、サーバ５００が、車両１について所定の交換処理を実行する。Ｓ４０では、図９のＳ３３と同様に、検査結果（第２検査の結果）の記録、報知、及び送信の少なくとも１つが実行されてもよい。第２検査の結果は、交換又は修理が必要なタイヤ（空気漏れが生じたタイヤ）を示す情報を含む。Ｓ４０の処理が実行されると、図１０に示す一連の処理は終了する。

以上説明したように、この実施の形態に係る車両検査方法は、図７～図１０に示した処理を含む。図７のＳ１３（第１送信工程）では、車両１が、自動運転中に、車両１に搭載された第１センサによって検出された第１状態を示す信号（第１検査信号）をサーバ５００へ送信する。図９のＳ３２（第１判定工程）では、サーバ５００が、車両１から受信した第１検査信号が示す第１状態を用いて、車両１について第１検査項目の良否を判定する。図８のＳ２２（第２判定工程）では、車両１が、自動運転中に、車両１に搭載された第２センサによって検出された第２状態を用いて第２検査項目の良否を判定する。図８のＳ２３（第２送信工程）では、第２検査項目について不良と判定された場合に、車両１が、第２検査項目の判定結果を示す信号（第２検査信号）をサーバ５００へ送信する。こうした車両検査方法によれば、自動運転車両（たとえば、車両１）を管理するサーバ５００の負荷を軽減しつつ自動運転車両のメンテナンスを適切に行なうことが可能になる。

第１及び第２検査に係る処理は、上述した態様に限られない。たとえば、第１検査に係る処理は、以下に説明するように変形されてもよい。以下、図１１～図１３を用いて、第１検査の変形例について説明する。

以下に説明する変形例では、サーバ５００が、図１１に示す一連の処理を実行する。また、車両１の制御装置１５０が、図７に示した処理に代えて、図１２に示す一連の処理を実行する。さらに、サーバ５００が、図９に示した処理に代えて、図１３に示す一連の処理を実行する。

図１１は、第１検査の変形例に関してサーバ５００によって実行される要求処理を示すフローチャートである。このフローチャートに示される処理は、所定周期で繰り返し実行される。

図１～図６とともに図１１を参照して、Ｓ５１では、サーバ５００が、登録された複数の車両の中から自動運転中の車両を抽出する。この変形例では、サーバ５００に登録された各車両が、図１、図２、及び図５に示した構成を有し、図３に示した処理によって自動運転を行なうように構成される。サーバ５００は、前述した開始信号及び終了信号（図３参照）によって、各車両が自動運転中か否かを判断してもよい。

続くＳ５２では、サーバ５００が、車種に基づいて自動運転中の車両を分類する。同一車種の車両は、同じグループに分類される。図１１に示す表Ｔ２は、サーバ５００に登録された複数の車両のうち、車両ＩＤ「Ｖ－１２」、「Ｖ－１６」、「Ｖ－３７」、・・・で識別される各車両が、自動運転中であり、かつ、同じ車種（車種Ａ）であることを示している。また、表Ｔ２は、サーバ５００に登録された複数の車両のうち、車両ＩＤ「Ｖ－６」、「Ｖ－３５」、「Ｖ－５８」、・・・で識別される各車両が、自動運転中であり、かつ、同じ車種（車種Ｂ）であることを示している。車種の区分は、自動車メーカのカタログに従って定められてもよい。

続くＳ５３では、サーバ５００が、グループごと（車種ごと）に１台の代表車両を決定する。代表車両の決め方は任意である。ただし、いったん代表車両が決定されると、その代表車両が自動運転をやめるまでは、代表車両は変更されない。代表車両は、ランダムに決定されてもよいし、所定の基準に従って決定されてもよい。グループにおいて車両ＩＤが最も若い車両が、代表車両として選ばれてもよい。たとえば、車種Ａのグループにおいては車両ＩＤ「Ｖ－１２」で識別される車両、車種Ｂのグループにおいては車両ＩＤ「Ｖ－６」で識別される車両が、代表車両として選ばれてもよい。また、各グループにおいてセンシングに関するスペックが高い車両が、優先的に代表車両として選ばれてもよい。

続くＳ５４では、サーバ５００が、第１状態を要求する信号（以下、「要求信号」とも称する）を各グループの代表車両へ送信する。Ｓ５４の処理が実行されると、最初のステップ（Ｓ５１）に戻る。

図１２は、第１検査の変形例に関して代表車両によって実行される送信処理を示すフローチャートである。このフローチャートに示される処理は、たとえば代表車両がサーバ５００から要求信号を受信すると、開始される。

図１～図６とともに図１２を参照して、代表車両の制御装置１５０は、Ｓ１１Ａ、Ｓ１３Ａにおいてそれぞれ図７のＳ１１、Ｓ１３と同様の処理を行ない、代表車両に搭載された第１センサによって検出された第１状態を示す第１検査信号を、代表車両の車両ＩＤとともにサーバ５００へ送信する。代表車両に関する第１検査信号の送信（Ｓ１３Ａ）が完了すると、図１２に示す一連の処理は終了する。図１２に示す一連の処理は代表車両のみで実行される。上記の処理によって代表車両の電力が消費されるため、車両管理者から代表車両のユーザにインセンティブ（対価）が支払われてもよい。各ユーザのインセンティブは、サーバ５００で管理されてもよい。

図１３は、第１検査の変形例に関してサーバ５００によって実行される判定処理を示すフローチャートである。このフローチャートに示される処理は、たとえばサーバ５００が代表車両から第１検査信号を受信すると、開始される。

図１～図６とともに図１３を参照して、Ｓ３１Ａでは、サーバ５００が、図９のＳ３１と同様の処理を行ない、代表車両の各対象部品（ＭＧ２０、バッテリ１６０、サスペンション１７０、制動装置１８０）の現在の劣化度を推定する。続けて、サーバ５００は、Ｓ３２Ａにおいて図９のＳ３２と同様の処理を行ない、代表車両においていずれかの対象部品に異常が生じているか否かを判定する。この変形例では、Ｓ３１Ａ及びＳ３２Ａにおいて実行される車載部品の検査が、代表車両に関する第１検査に相当する。代表車両に関する第１検査によって不良判定がなされると（Ｓ３２ＡにてＹＥＳ）、処理がＳ３３Ａに進む。サーバ５００は、代表車両に関する第１検査によって不良判定がなされた場合に（Ｓ３２ＡにてＹＥＳ）、代表車両と同じグループに属する全ての車両において経年劣化に起因した部品異常が生じたと判定する。

Ｓ３３Ａでは、サーバ５００が、代表車両と同じグループに属する全ての車両について所定の交換処理を実行する。所定の交換処理は、図９のＳ３３と同様、第１検査の結果の記録、報知、及び送信の少なくとも１つであってもよい。ただし、Ｓ３３Ａでは、代表車両だけでなく、代表車両と同じグループに属する全ての車両について、所定の交換処理が実行される。たとえば、図１１に示した車種Ａのグループの代表車両（たとえば、車両ＩＤ「Ｖ－１２」で識別される車両）に関する第１検査によって不良判定がなされた場合には（Ｓ３２ＡにてＹＥＳ）、Ｓ３３Ａにおいて、車両ＩＤ「Ｖ－１２」、「Ｖ－１６」、「Ｖ－３７」、・・・で識別される各車両について、所定の交換処理が実行される。Ｓ３３Ａの処理が実行されると、図１３に示す一連の処理は終了する。

他方、代表車両においていずれの対象部品の劣化度も所定の閾値を超えない場合には、第１検査によって良判定がなされ（Ｓ３２ＡにてＮＯ）、交換処理（Ｓ３３Ａ）が行なわれることなく、図１３に示す一連の処理が終了する。

以上説明したように、上記変形例では、サーバ５００によって管理される複数の車両の各々が、制御装置１５０と第１センサ（たとえば、車輪速センサ１２７Ａ，１２７Ｂ、姿勢用センサ２７０、監視モジュール１６０ａ、重量センサ１７０ａ、及びブレーキセンサ１８０ａ）と第２センサ（たとえば、空気圧センサ２０ｂ）と通信装置１３０とを備える（図１、図２、及び図５参照）。車両に搭載された制御装置１５０は、当該車両を自動運転で走行させるための制御を実行するように構成される（図３参照）。サーバ５００は、複数の車両の中から代表車両（第１車両）を選ぶ（図１１参照）。代表車両の通信装置１３０は、代表車両の自動運転中に第１センサによって検出された第１状態をサーバ５００へ逐次送信する（図１１及び図１２参照）。サーバ５００は、代表車両から逐次受信する第１状態を用いて、代表車両と同じグループに属する複数の車両（第１車両及び第２車両）の各々について第１検査を実行する（図１３参照）。同じグループに属する各車両は、同一車種であり、かつ、同時に自動運転で走行している。サーバ５００は、本開示に係る「第１検査装置」の一例として機能する。

上記構成では、第１車両（代表車両）からサーバ５００へ逐次送信される第１状態を用いて、第２車両（代表車両と同じグループに属する代表車両以外の車両）に関する第１検査が行なわれる。第２車両の第１センサによる検出値が第２車両からサーバ５００へ送信されないことで、第２車両からサーバ５００へ送信される情報量を軽減できる。上記構成によれば、各車両からサーバ５００へ送信される情報量を軽減しつつ、多くの車両の検査を行なうことが可能になる。なお、各車両が分類される区分（グループ）は、車種ごとのグループに限られない。グループ分けの仕方は適宜変更である。

第２検査に関しては、上記変形例においても、前述した実施の形態と同様に行なわれる。すなわち、各車両の制御装置１５０が図８に示した処理を実行し、サーバ５００が図１０に示した処理を実行する。サーバ５００によって管理される各車両の制御装置１５０が、本開示に係る「第２検査装置」の一例として機能する。各車両の制御装置１５０は、当該車両において、自動運転中に第２センサによって検出された第２状態を用いて第２検査を実行し、第２検査によって不良判定がなされた場合には、第２検査の結果をサーバ５００へ送信する（図８参照）。車両ごとに図８に示した処理が実行され、各車両において第２検査が実行される。こうした構成により、前述の第１検査に加えて、リアルタイム性の高い第２検査（図４参照）を適切に行なうことが可能になる。

第１検査項目及び第２検査項目は、図４に示した項目に限られず適宜変更可能である。たとえば、タイヤの空気漏れの有無を確認する項目に代えて又は加えて、液漏れ（たとえば、ブレーキオイル漏れのようなオイル漏れ）の有無を確認する項目が、第２検査項目として採用されてもよい。エンジン（内燃機関）を備える車両では、エンジン冷却水温異常の有無を確認する項目が、第２検査項目として採用されてもよい。

車両の構成は、上記実施の形態で説明した構成（図１、図２、及び図５参照）に限られない。ベース車両が後付けなしの状態で自動運転機能を有してもよい。自動運転のレベルは、完全自動運転（レベル５）であってもよいし、条件付きの自動運転（たとえば、レベル４）であってもよい。車両の構成は、無人走行専用の構成に適宜変更されてもよい。たとえば、無人走行専用の車両は、人が車両を操作するための部品（ステアリングホイールなど）を備えなくてもよい。車両は、ソーラーパネルを備えてもよいし、飛行機能を備えてもよい。車両は、乗用車に限られず、バス又はトラックであってもよい。車両は、個人が所有する車両（ＰＯＶ）であってもよい。車両は、ユーザの使用目的に応じてカスタマイズされる多目的車両であってもよい。車両は、移動店舗車両、ロボタクシー、無人搬送車（ＡＧＶ）、又は農業機械であってもよい。車両は、無人又は１人乗りの小型ＢＥＶ（たとえば、マイクロパレット）であってもよい。

今回開示された実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本開示により示される技術的範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれることが意図される。

１ 車両、２０ ＭＧ、２０ｂ 空気圧センサ、１００ ベース車両、１０２ 制御システム、１１５ 統合制御マネージャ、１２７Ａ，１２７Ｂ 車輪速センサ、１３０ 通信装置、１５０ 制御装置、１５１ プロセッサ、１５３ 記憶装置、１６０ バッテリ、１６０ａ 監視モジュール、１７０ サスペンション、１７０ａ 重量センサ、１８０ 制動装置、１８０ａ ブレーキセンサ、２００ ＡＤＫ、２０２ ＡＤＳ、２１０ コンピュータ、２６０ 認識用センサ、２７０ 姿勢用センサ、５００ サーバ、５０１ プロセッサ、５０３ 記憶装置、Ｅ 推定アルゴリズム、ＵＴ モバイル端末。

Claims (12)

1. 車両とサーバとを含む車両管理システムであって、
   前記サーバは、第１検査項目について良否を判定する第１検査を実行する第１検査装置を備え、
   前記車両は、
   当該車両を自動運転で走行させるための制御を実行する制御装置と、
   前記第１検査項目とは異なる第２検査項目について良否を判定する第２検査を実行する第２検査装置と、
   前記第１検査項目に対応する第１状態を検出する第１センサと、
   前記第２検査項目に対応する第２状態を検出する第２センサと、
   通信装置と、
   を備え、
   前記通信装置は、前記車両の自動運転中に前記第１センサによって検出された前記第１状態を前記サーバへ逐次送信するように構成され、
   前記第１検査装置は、前記車両から逐次受信する前記第１状態を用いて、前記車両について前記第１検査を実行するように構成され、
   前記第２検査装置は、前記車両の自動運転中に前記第２センサによって検出された前記第２状態を用いて前記第２検査を実行し、前記第２検査によって不良判定がなされた場合に、前記通信装置が前記第２検査の結果を前記サーバへ送信する、車両管理システム。
2. 前記第１検査項目よりも前記第２検査項目のほうが、要求されるリアルタイム性が高い、請求項１に記載の車両管理システム。
3. 前記第１検査項目は、経年劣化に起因した部品異常の有無を確認する項目を含み、
   前記第２検査項目は、タイヤの空気漏れの有無を確認する項目を含む、請求項１又は２に記載の車両管理システム。
4. 前記第１状態は、前記車両の重量と、前記車両の車速と、前記車両の停車回数と、前記車両の急ブレーキ回数と、前記車両の位置と、前記車両に搭載された蓄電装置のＳＯＣとの少なくとも１つを含み、
   前記第２状態は、タイヤの空気圧を含む、請求項１～３のいずれか一項に記載の車両管理システム。
5. 前記通信装置は、
   前記車両の自動運転中に前記第１センサによって検出された前記第１状態と、直近に送信された前記第１状態との乖離度合いが、所定水準を超える場合には、前記第１センサによって検出された前記第１状態を前記サーバへ送信し、
   前記乖離度合いが前記所定水準を超えない場合には、前記第１センサによって検出された前記第１状態を前記サーバへ送信しない、請求項１～４のいずれか一項に記載の車両管理システム。
6. 第１車両と第２車両とサーバとを含む車両システムであって、
   前記サーバは、第１検査項目について良否を判定する第１検査を実行する第１検査装置を備え、
   前記第１車両及び前記第２車両の各々は、
   当該車両を自動運転で走行させるための制御を実行する制御装置と、
   前記第１検査項目とは異なる第２検査項目について良否を判定する第２検査を実行する第２検査装置と、
   前記第１検査項目に対応する第１状態を検出する第１センサと、
   前記第２検査項目に対応する第２状態を検出する第２センサと、
   通信装置と、
   を備え、
   前記第１車両の前記通信装置は、前記第１車両の自動運転中に前記第１車両の前記第１センサによって検出された前記第１状態を前記サーバへ逐次送信するように構成され、
   前記第１検査装置は、前記第１車両から逐次受信する前記第１状態を用いて、前記第１車両及び前記第２車両の各々について前記第１検査を実行するように構成され、
   前記第１車両及び前記第２車両の各々の前記第２検査装置は、当該車両において、自動運転中に前記第２センサによって検出された前記第２状態を用いて前記第２検査を実行し、前記第２検査によって不良判定がなされた場合に、前記第２検査の結果を前記サーバへ送信する、車両管理システム。
7. 前記第１車両と前記第２車両とは、同時に自動運転で走行している、請求項６に記載の車両管理システム。
8. 前記第１車両と前記第２車両とは同一車種である、請求項６又は７に記載の車両管理システム。
9. 車両が、自動運転中に、当該車両に搭載された第１センサによって検出された第１状態をサーバへ送信することと、
   前記サーバが、前記車両から受信した前記第１状態を用いて、前記車両について第１検査項目の良否を判定することと、
   前記車両が、自動運転中に、当該車両に搭載された第２センサによって検出された第２状態を用いて第２検査項目の良否を判定することと、
   前記第２検査項目について不良と判定された場合に、前記車両が、前記第２検査項目の判定結果を前記サーバへ送信することと、
   を含む、車両検査方法。
10. 前記第１検査項目よりも前記第２検査項目のほうが、要求されるリアルタイム性が高い、請求項９に記載の車両検査方法。
11. 前記第１検査項目は、経年劣化に起因した部品異常の有無を確認する項目を含み、
    前記第２検査項目は、タイヤの空気漏れの有無を確認する項目を含む、請求項９又は１０に記載の車両検査方法。
12. 前記第１状態は、前記車両の重量と、前記車両の車速と、前記車両の停車回数と、前記車両の急ブレーキ回数と、前記車両の位置と、前記車両に搭載された蓄電装置のＳＯＣとの少なくとも１つを含み、
    前記第２状態は、タイヤの空気圧を含む、請求項９～１１のいずれか一項に記載の車両検査方法。
    

Images