JPWO2020213024A1 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents

Abstract

情報取得部（１０１）は、車両の走行中の挙動の履歴が示される挙動履歴情報を取得する。影響推定部（１０５）は、車両の要素である車両要素への車両の走行による影響を、挙動履歴情報に示される車両の走行中の挙動の履歴に基づき推定する。診断部（１０６）は、影響推定部（１０５）により推定された、車両の走行による車両要素への影響に基づき、車両要素の状態を診断する。

Description

本発明は、車両の要素である車両要素の状態を診断する技術に関する。

車両の走行中に車両の要素（以下、「車両要素」又は単に「要素」という）に異常が発生した場合は、車両のユーザーに異常が通知される。例えば、メーターパネルの警告灯の点灯、表示灯の点灯、警告音の出力などの方法によりユーザーに車両要素の異常が通知される。ユーザーは、異常が通知されると、車両点検又は異常のあった車両要素の交換を行う。また、ユーザーは、日常点検又は定期点検を通じて、車両要素の状態を診断し、必要であれば要素の交換を行う。
なお、車両要素とは、車両に搭載、付加、装着、組込み、充填、塗布されている要素である。車両要素は、車両の走行による影響を受ける。例えば、車両要素は、車両の走行によって消耗する。車両要素には、エンジン、ドア、ライト、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）、ミラー、ガラス、サスペンション等の他、タイヤ、バッテリ、エンジンオイル、冷却水、ブレーキパッド等も含まれる。
車両要素のうち、エンジンオイル、タイヤ等の消耗品の交換は、一般的に予め決められた走行距離又は使用期間を目安に行われる。しかしながら、急発進、急ブレーキ、短距離走行の繰り返しなどの特殊な走行が頻繁に行われると、消耗品の寿命が早まることが知られている。
このため、具体的な走行環境及び走行状況に基づいて車両要素の状態診断が行なわれることが望ましい。

特許文献１では、車両状態解析システムが開示されている。より具体的には、特許文献１では、車両の走行環境データ、走行状態データ及びエンジン制御に関する基準制御データが収集される。そして、収集された走行環境データ、走行状態データ及び基準制御データが車両管理センタに通知される。車両管理センタでは、車両から通知された基準制御データと、当該車両の標準制御データとを比較して、車両に異常があるか否かを診断する。そして、車両管理センタが、診断結果に応じて、ユーザーに車両の点検又は故障の修理を依頼する。

特開２００７−７６４０２号公報

特許文献１では、車両要素に対する制御量を標準値と比較することで、車両要素が異常であるか否かを判定する。しかし、特許文献１の技術を、タイヤ及びブレーキパッドのように制御量を算出することができない車両要素に適用することは難しい。特に、エンジンオイル及び冷却水のように、状態を直接観測できない車両要素に対しては、診断の基準となる標準値を定めることが難しい。
他の手法として、車両要素にセンサを取り付けることで、車両要素の異常に伴う振動又は異音の発生を検出する方法も検討されている。しかしながら、センサを取り付けるのが難しい車両要素もあり、全ての車両要素に当該手法を適用するのは難しい。

本発明は、このような事情に鑑みたものであり、車両要素の状態を正確に診断できる構成を得ることを主な目的とする。

本発明に係る情報処理装置は、
車両の走行中の挙動の履歴が示される挙動履歴情報を取得する情報取得部と、
前記車両の要素である車両要素への前記車両の走行による影響を、前記挙動履歴情報に示される前記車両の走行中の挙動の履歴に基づき推定する影響推定部と、
前記影響推定部により推定された、前記車両の走行による前記車両要素への影響に基づき、前記車両要素の状態を診断する診断部とを有する。

本発明によれば、車両要素の状態を正確に診断することができる。

実施の形態１に係る診断システムの構成例を示す図。 実施の形態１に係るサーバ装置のハードウェア構成例を示す図。 実施の形態１に係る車載装置のハードウェア構成例を示す図。 実施の形態１に係るサーバ装置の機能構成例を示す図。 実施の形態１に係る車載装置の機能構成例を示す図。 実施の形態１に係る車両管理情報の例を示す図。 実施の形態１に係る要素通知情報の例を示す図。 実施の形態１に係る挙動履歴情報の例を示す図。 実施の形態１に係る診断結果情報の例を示す図。 実施の形態１に係る車両要素管理情報の例を示す図。 実施の形態１に係る要素状態情報の例を示す図。 実施の形態１に係るサーバ装置の動作例を示すフローチャート。 実施の形態１に係る学習処理の例を示すフローチャート。 実施の形態１に係るモデル生成処理の例を示すフローチャート。 実施の形態１に係る走行状況情報、走行環境情報及び車両固有情報の例を示す図。 実施の形態１に係る診断モデル情報の例を示す図。 実施の形態１に係る診断処理の例を示すフローチャート。 実施の形態１に係る要素状態診断処理（走行前）の例を示すフローチャート。 実施の形態１に係る要素状態診断処理（走行後）の例を示すフローチャート。 実施の形態２に係るサーバ装置の機能構成例を示す図。 実施の形態２に係る車載装置の機能構成例を示す図。 実施の形態２に係る車載装置の動作例を示すフローチャート。 実施の形態２に係るモデル取得処理の例を示すフローチャート。 実施の形態２に係る車両情報の例を示す図。 実施の形態２に係る車両要素情報の例を示す図。 実施の形態２に係る診断処理の例を示すフローチャート。 実施の形態３に係る診断処理の例を示すフローチャート。 実施の形態４に係る挙動履歴情報（車速）の例を示す図。 実施の形態４に係るカテゴリ分類結果を示す図。 実施の形態４に係る走行情報の例を示す図。 実施の形態４に係る分析結果情報の例を示す図。

以下、本発明の実施の形態について、図を用いて説明する。以下の実施の形態の説明及び図面において、同一の符号を付したものは、同一の部分又は相当する部分を示す。

実施の形態１．
＊＊＊構成の説明＊＊＊
＊＊診断システム５００の説明＊＊
図１は、本実施の形態に係る診断システム５００の構成例を示す。
図１に示すように、診断システム５００は、サーバ装置１００と複数の車載装置３００で構成される。車載装置３００は、車両２００に搭載されている。
なお、図１では、２台の車両２００のみが描画されているが、車両２００の台数は２台に限らない。
サーバ装置１００は、情報処理装置の例である。また、サーバ装置１００により行われる動作は、情報処理方法及び情報処理プログラムの例である。
サーバ装置１００と車載装置３００とは通信を行う。例えば、サーバ装置１００と車載装置３００は、Ｗｉ−Ｆｉなどの無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）（登録商標）等の移動体通信網を用いて通信を行う。
サーバ装置１００は、車両２００の走行中の挙動の履歴が示される挙動履歴情報を車載装置３００から受信する。車両２００の走行中の挙動とは、ドライバーの操作に対する車両２００の反応、路面等の走行環境からの作用に対する車両２００の反応である。サーバ装置１００は、挙動履歴情報を用いた解析を行って、車両要素の状態を診断し、診断結果を車載装置３００に通知する。挙動履歴情報の詳細は後述する。

＊＊サーバ装置１００のハードウェア構成例の説明＊＊
図２は、サーバ装置１００のハードウェア構成例を示す。
サーバ装置１００は、コンピュータである。
サーバ装置１００は、ハードウェアとして、プロセッサ９１１、主記憶装置９１２、補助記憶装置９１３及び通信装置９１４を備える。
また、サーバ装置１００は、図４に示すように、機能構成として、情報取得部１０１、情報記憶部１０２、診断モデル生成部１０３、診断モデル記憶部１０４、影響推定部１０５及び診断部１０６を備える。サーバ装置１００の機能構成は後述する。
補助記憶装置９１３には、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５及び診断部１０６の機能を実現するプログラムが記憶されている。
これらプログラムは、補助記憶装置９１３から主記憶装置９１２にロードされる。そして、プロセッサ９１１がこれらプログラムを実行して、後述する情報取得部１０１、診断モデル生成部１０３、影響推定部１０５及び診断部１０６の動作を行う。
図２では、プロセッサ９１１が情報取得部１０１、診断モデル生成部１０３、影響推定部１０５及び診断部１０６の機能を実現するプログラムを実行している状態を模式的に表している。
情報記憶部１０２及び診断モデル記憶部１０４は、主記憶装置９１２又は補助記憶装置９１３により実現される。

＊＊車載装置３００のハードウェア構成例の説明＊＊
図３は、車載装置３００のハードウェア構成例を示す。
車載装置３００は、コンピュータである。
車載装置３００は、ハードウェアとして、プロセッサ９３１、主記憶装置９３２、補助記憶装置９３３及び通信装置９３４を備える。
また、車載装置３００は、図５に示すように、機能構成として、通信部３０１、診断通知表示部３０２、要素通知情報取得部３０３、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６及び記憶部３０７を備える。車載装置３００の機能構成は後述する。
補助記憶装置９３３には、通信部３０１、診断通知表示部３０２、要素通知情報取得部３０３、挙動履歴情報生成部３０４、センサ情報収集部３０５及び車両制御部３０６の機能を実現するプログラムが記憶されている。
これらプログラムは、補助記憶装置９３３から主記憶装置９３２にロードされる。そして、プロセッサ９３１がこれらプログラムを実行して、後述する通信部３０１、診断通知表示部３０２、要素通知情報取得部３０３、挙動履歴情報生成部３０４、センサ情報収集部３０５及び車両制御部３０６の動作を行う。
図３では、プロセッサ９３１が通信部３０１、診断通知表示部３０２、要素通知情報取得部３０３、挙動履歴情報生成部３０４、センサ情報収集部３０５及び車両制御部３０６の機能を実現するプログラムを実行している状態を模式的に表している。
記憶部３０７は、主記憶装置９３２又は補助記憶装置９３３により実現される。

＊＊サーバ装置１００の機能構成例の説明＊＊
図４は、サーバ装置１００の機能構成例を示す。

情報取得部１０１は、車載装置３００から車両管理情報と要素通知情報と挙動履歴情報を取得する。
車両管理情報は、例えば、図６に示す情報である。車両管理情報の詳細は後述する。
要素通知情報は、例えば、図７に示す情報である。要素通知情報の詳細は後述する。
挙動履歴情報は、例えば、図８に示す情報である。挙動履歴情報の詳細は後述する。
なお、情報取得部１０１により行われる処理は、情報取得処理に相当する。

情報記憶部１０２は、情報取得部１０１により取得された車両管理情報と要素通知情報と挙動履歴情報を記憶する。
また、情報記憶部１０２は、診断部１０６の診断の度に診断部１０６により生成される診断結果情報と車両要素管理情報を記憶する。
診断結果情報は、例えば、図９に示す情報である。診断結果情報の詳細は後述する。
車両要素管理情報は、例えば図１０に示す情報である。車両要素管理情報の詳細は後述する。

診断モデル生成部１０３は、挙動履歴情報と要素状態情報とを用いて診断モデルを生成する。要素状態情報には、車両要素の状態が示される。要素状態情報は、例えば、図１１に示す情報である。
診断モデル生成部１０３は、車両２００の走行状況と車両２００の走行環境とが車両要素に与える影響を学習することにより診断モデルを生成する。なお、走行状況とは、急発進が多い／少ない、急ブレーキが多い／少ない等の車両２００の走行上の特徴である。また、走行環境とは、悪路走行、登降坂路走行、夜間走行等の車両２００が走行する環境である。
診断モデル生成部１０３は、診断モデルの生成ルールを参照して、走行状況情報、走行環境情報及び車両固有情報と、要素状態情報の相関性を分析し、診断モデルを生成する。走行状況情報、走行環境情報及び車両固有情報の詳細は後述する。
診断モデル生成部１０３は、ランダムフォレスト、ＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）、ニューラルネットワークなどの一般的な機械学習手法等を用いて、相関性の分析を行う。診断モデルの生成ルールは、診断モデルの生成単位を示す。診断モデルの生成単位は、車両２００が利用される地域、車両要素の種別、車種、車両２００の年式等である。地域は、車両２００が利用される国、都市等である。車両要素の種別には、車両要素の製造者、車両要素の製品名、製造年月日等が含まれる。
診断モデルは、影響推定部１０５が車両２００の走行による車両要素への影響を推定する際に用いられる。
診断モデルの詳細は後述する。

診断モデル記憶部１０４は、診断モデル生成部１０３により生成された診断モデルを記憶する。

影響推定部１０５は、挙動履歴情報に示される車両２００の走行中の挙動の履歴に基づき、車両２００の走行による車両要素への影響を推定する。車両２００の走行による車両要素への影響とは、車両要素に関連する物理量の変化である。物理量の変化には、温度、電流値、電圧値、寸法の変化が含まれる。以下では、影響推定部１０５が推定する車両要素に関連する物理量の変化を、車両要素の状態値の変化といい、状態値の変化量を状態変化量という。例えば、タイヤ溝の深さがタイヤの状態値であり、タイヤ溝の深さの変化量がタイヤの状態変化量である。また、ブレーキパッドの厚さがブレーキパッドの状態値であり、ブレーキパッドの厚さの変化量がブレーキパッドの状態変化量である。また、バッテリ液の残量がバッテリ液の状態値であり、バッテリ液の残量の変化量がバッテリ液の状態変化量である。
影響推定部１０５は、診断モデル記憶部１０４に格納されている診断モデルを用いて、車両要素の状態変化量を導出する。
影響推定部１０５により行われる処理は、影響推定処理に相当する。

診断部１０６は、影響推定部１０５により導出された車両要素の状態変化量に基づき、車両要素の状態を診断する。そして、診断部１０６は、診断結果が示される診断通知を車載装置３００に送信する。
診断部１０６により行われる処理は、診断処理に相当する。

＊＊車載装置３００の機能構成例の説明＊＊
通信部３０１は、サーバ装置１００と通信を行う。
具体的には、通信部３０１は、サーバ装置１００に車両管理情報と要素通知情報と挙動履歴情報とを送信する。また、通信部３０１は、サーバ装置１００から診断通知を受信する。

診断通知表示部３０２は、通信部３０１により受信された診断通知を表示する。
この結果、車両２００のユーザーは、車両要素の点検又は交換が必要か否かを知ることができる。診断通知表示部３０２は、例えば、カーナビゲーション装置により実現されてもよい。

要素通知情報取得部３０３は、サーバ装置１００に送信する車両管理情報及び要素通知情報を記憶部３０７から読み出す。要素通知情報取得部３０３は、読み出した車両管理情報及び要素通知情報を通信部３０１に出力する。

挙動履歴情報生成部３０４は、サーバ装置１００に送信する挙動履歴情報を生成する。挙動履歴情報生成部３０４は、生成した挙動履歴情報を通信部３０１に出力する。

センサ情報収集部３０５は、車両２００に配置されているセンサ（不図示）からセンサ情報を収集する。センサ情報収集部３０５は、車両前方カメラ、車両後方カメラ、ＬＩＤＡＲ、ソナー、Ｖ２Ｘ車載器、照度センサ、レインセンサ、ロケータ等のセンサからセンサ情報を収集する。

車両制御部３０６は、車両２００の制御を行う。例えば、車両制御部３０６は、エンジン制御、ブレーキ制御、ステアリング制御、ヘッドライト制御等の制御を行う。

記憶部３０７は、車両管理情報及び要素通知情報を記憶する。

車両管理情報は、例えば、図６に示す情報である。
車両管理情報には、車両ＩＤ、地域及びスペック情報が含まれる。車両ＩＤは、車両２００を一意に識別可能な識別子である。車両ＩＤは、例えば、車両識別番号である。地域は、車両２００の走行地域である。地域は、都市名で特定されていてもよいし、緯度及び経度などの位置情報で特定されていてもよい。スペック情報には、例えば、車両２００の車重、車長、車幅、ホイールアライメント等が示される。

要素通知情報は、例えば、図７に示す情報である。
要素通知情報には、要素ＩＤ及び要素種別ＩＤと、車両要素の利用開始日が示される。要素ＩＤは、車両要素を一意に識別可能な識別子である。要素種別ＩＤは、車両要素として車両２００に配置されている製品を一意に識別する情報である。要素ＩＤは、例えば、タイヤ、バッテリ、ブレーキなどの車両要素の名称である。要素種別ＩＤは、車両要素の製造会社、製品名などを識別するための識別子である。要素種別ＩＤは、例えば、製品番号である。利用開始日は、車両要素の利用が開始された日時を示す。
要素通知情報は、例えば、車両２００の製造時又は車両要素の交換時に記憶部３０７に書き込まれる

＊＊＊動作の説明＊＊＊
次に、本実施の形態に係る診断システム５００における動作を説明する。
以下では、サーバ装置１００の動作を中心に説明する。

図１２は、サーバ装置１００の動作の概要を示す。
サーバ装置１００の動作は、学習処理（ステップＳ１１）と診断処理（ステップＳ１２）とに分けられる。

学習処理（ステップＳ１１）では、診断モデル生成部１０３が、車両２００の走行状況と車両２００の走行環境とが車両要素に与える影響を学習することにより診断モデルを生成する。
診断処理（ステップＳ１２）では、影響推定部１０５が、診断モデルを用いて車両要素の状態変化量を導出する。また、診断処理（ステップＳ１２）では、診断部１０６が状態変化量に基づき車両要素の状態を診断し、診断結果を車載装置３００に通知する。

図１３は、学習処理（ステップＳ１１）の詳細を示す。

先ず、情報取得部１０１が、車載装置３００から、要素状態情報（走行前）を取得する（ステップＳ１１１）。そして、情報取得部１０１は、取得した要素状態情報（走行前）を診断モデル生成部１０３に出力する。要素状態情報（走行前）は、車両２００の走行前に得られた要素状態情報である。

要素状態情報は、例えば、図１１に示す情報である。
要素状態情報には、車両２００内の車両要素が記述される。図１１の例では、タイヤ、バッテリ、ブレーキパッド及びエンジンオイルが記述されている。なお、車両要素は、これらに限らない。
また、要素状態情報には、車両要素の状態量が記述される。図１１の例では、タイヤの状態量として、タイヤ溝の深さの値が記述される。状態量としては、他に、ブレーキパッドの厚さ、バッテリの劣化状態（Ｓｔａｔｅ ｏｆ Ｈｅａｌｔｈ、ＳＯＨ）、充電状態（Ｓｔａｔｅ ｏｆ Ｃｈａｒｇｅ、ＳＯＣ）、エンジンオイル及び冷却水の量及び成分等がある。なお、状態量は、これらに限らない。
また、要素状態情報には、車両要素の利用開始日及び状態量の収集日時も含まれる。
要素状態情報は、車載装置３００の挙動履歴情報生成部３０４により生成される。
挙動履歴情報生成部３０４は、センサ情報収集部３０５により収集されたセンサ情報又はユーザーが計測した計測値を用いて要素状態情報を生成する。挙動履歴情報生成部３０４は、センサで計測可能な状態値についてはセンサ情報収集部３０５により収集されたセンサ情報を用いる。一方、センサで計測できない状態値についてはユーザーが計測した計測値を用いる。ユーザーは、例えば、ゲージ等を用いて車両要素の状態値を計測する。
通信部３０１が要素状態情報（走行前）をサーバ装置１００に送信し、サーバ装置１００では、情報取得部１０１が要素状態情報（走行前）を受信する。

次に、情報取得部１０１が、挙動履歴情報を取得する（ステップＳ１１２）。
そして、情報取得部１０１は、取得した挙動履歴情報を診断モデル生成部１０３に出力する。

挙動履歴情報は、例えば、図８に示す情報である。
挙動履歴情報では、走行中の車両２００の走行中の挙動の履歴が示される。
挙動履歴情報には、車両２００の挙動の履歴として、ヘッドライト状態、ウィンカー状態、アクセル位置、ブレーキ位置、シフトレバー位置等の状態値の経時変化が記述される。また、挙動履歴情報には、車両２００の挙動の履歴として、車速、ステアリング駆動角等の経時変化も記述される。また、挙動履歴情報には、車両２００の挙動の履歴として、車高センサ、加速度センサ等で計測されたセンサ値の経時変化も記述される。更に、挙動履歴情報には、車両前方カメラ等で検出した障害物、歩行者、ロケータで取得した現在位置、カーナビゲーション装置から出力される地図情報、ドライバーモニタリング装置から出力される搭乗者の状態等が含まれていてもよい。
なお、挙動履歴情報は、図８に示すように、時系列データであり、車載装置３００では、項目ごとに定められた周期で状態が収集される。例えば、ヘッドライト状態、ウィンカー状態、アクセル位置、ブレーキ位置、シフトレバー位置等の状態値は１００ｍｓ周期で収集される。一方、ステアリング、ステアリング駆動角等の状態値は、例えば、１０ｍｓ周期で収集される。
車両２００では、挙動履歴情報生成部３０４が挙動履歴情報を生成する。挙動履歴情報生成部３０４は、例えば、センサ情報収集部３０５により収集されたセンサ情報を用いて挙動履歴情報を生成する。また、挙動履歴情報生成部３０４は、車両制御部３０６が車両２００の制御のために出力する制御値を用いて挙動履歴情報を生成する。
そして、車載装置３００の通信部３０１が挙動履歴情報を送信し、サーバ装置１００の情報取得部１０１が挙動履歴情報を受信する。

次に、情報取得部１０１が、車載装置３００から、要素状態情報（走行後）を取得する（ステップＳ１１３）。そして、情報取得部１０１は、取得した要素状態情報（走行後）を診断モデル生成部１０３に出力する。
ステップＳ１１３で取得する要素状態情報（走行後）には、走行後の車両要素の状態が記述される。ステップＳ１１３で取得する要素状態情報（走行後）は、構成自体は、ステップＳ１１１で取得する要素状態情報（走行前）と同じである。但し、要素状態情報（走行後）に示される状態量は、要素状態情報（走行前）の状態量とは異なっている可能性がある。例えば、タイヤ溝の深さは、要素状態情報（走行後）では、走行によって浅くなっている可能性がある。

サーバ装置１００では、以上のステップＳ１１１〜Ｓ１１３を複数の車両２００に対して行う。複数の車両２００の車載装置３００から得られた要素状態情報（走行前）、挙動履歴情報及び要素状態情報（走行後）は、診断モデル生成部１０３に割り当てられた記憶領域に蓄積される。
そして、診断モデルの生成のための学習に必要なサンプル数が得られた場合に、ステップＳ１１４が行われる。
ステップＳ１１４では、診断モデル生成部１０３は、要素状態情報（走行前）と挙動履歴情報と要素状態情報（走行後）の相関性を分析し、診断モデルを生成する。
診断モデルの生成処理の詳細は、図１４を参照して説明する。

先ず、診断モデル生成部１０３は、車両２００ごとに、挙動履歴情報から、走行情報、環境情報及び車両固有情報を生成する（ステップＳ１１５１）。

走行情報には、車両２００の車速変化量、加速度、総走行距離等が記述される。
環境情報には、車両２００の振動量、路面の傾斜角等が記述される。
車両固有情報には、車両総重量等が記述される。
診断モデル生成部１０３は、例えば、単位時間での車速の差を求めることにより、車速変化量を得ることができる。また、診断モデル生成部１０３は、車高センサ、加速度センサの計測値から車両２００の車高の変化度合を求めて、車両２００の振動量を得ることができる。また、診断モデル生成部１０３は、車両２００の搭乗者数と搭乗者一人の平均的な体重値を利用して搭乗者の総重量を求め、求めた総重量を車重値に加算することで、車両総重量を得ることができる。また、サーバ装置１００において車高センサの出力値の変化量と積載量の関係情報を保持しておけば、診断モデル生成部１０３は、車高センサの出力値から搭乗者の総重量を求めることができる。なお、走行情報、環境情報及び車両固有情報は、時系列データである挙動履歴情報を一定時間ごとにサンプリングして得られる変化量の情報である。つまり、走行情報、環境情報及び車両固有情報も時系列データである。

次に、診断モデル生成部１０３は、車両２００ごとに、走行状況情報及び走行環境情報を生成する（ステップＳ１１５２）。

診断モデル生成部１０３は、挙動履歴情報とステップＳ１１５２で生成された走行情報及び環境情報より、車両２００の走行状況及び走行環境を判定する。
走行状況とは、例えば、急発進頻度、急ブレーキ頻度、急カーブ頻度、低速走行頻度、短距離走行頻度等の車両２００の走行における特徴である。また、走行環境とは、悪路走行頻度、登降坂路走行頻度、夜間走行頻度等の車両２００が走行する環境における特徴である。
例えば、診断モデル生成部１０３は、アクセルペダル操作時の車速変化量により急発進頻度を求めることができる。また、診断モデル生成部１０３は、ブレーキペダル操作時の車速変化量により急ブレーキ頻度を求めることができる。また、診断モデル生成部１０３は、ステアリング操作時の水平方向への加速度により急カーブ頻度を求めることができる。また、診断モデル生成部１０３は、振動量より悪路走行時間を判定し、総走行時間における悪路走行時間の割合を算出することで悪路走行頻度を求めることができる。また、診断モデル生成部１０３は、路面傾斜率より登降坂路走行時間を判定し、総走行時間における登降坂路走行時間の割合を算出することで登降坂路走行頻度求めることができる。また、診断モデル生成部１０３は、ヘッドライト使用時間を判定し、総走行時間におけるヘッドライト使用時間の割合を算出することで夜間走行頻度を求めることができる。
診断モデル生成部１０３は、以上のようにして算出した急発進頻度、急ブレーキ頻度、急カーブ頻度等を示す情報を走行状況情報として生成する。また、診断モデル生成部１０３は、以上のようにして算出した悪路走行頻度、登降坂路走行頻度、夜間走行頻度等を示す情報を走行環境情報として生成する。
走行状況情報及び走行環境情報は、頻度又は割合を示す情報であり、時系列データではない。
なお、急発進頻度、急ブレーキ頻度及び急カーブ頻度の各々を、程度の大きさにより、大、中、小などの複数のカテゴリに分類してもよい。

そして、診断モデル生成部１０３は、図１５に示すように、車両２００ごとに、ステップＳ１１５１で得られた車両固有情報と、ステップＳ１１５２で得られた走行状況情報と走行環境情報を対応付ける。

次に、診断モデル生成部１０３は、情報を分類する（ステップＳ１１５３）。
具体的には、診断モデル生成部１０３は、走行状況情報、走行環境情報、車両固有情報、要素状態情報（走行前）及び要素状態情報（走行後）を、要素種別ＩＤを基にして要素種別ごとに分類する。
また、診断モデル生成部１０３は、各車両２００の走行地域に基づき、走行状況情報、走行環境情報、車両固有情報、要素状態情報（走行前）及び要素状態情報（走行後）を地域ごとに分類する。例えば、図１３のステップＳ１１１において要素状態情報（走行前）とともに図６に示す車両管理情報を受信しておけば、診断モデル生成部１０３は、車両２００の走行地域を得ることができる。
このように、診断モデル生成部１０３は、複数の車両２００で収集した情報を、要素種別−地域ごとに分類する。
なお、本実施の形態では、診断モデル生成部１０３は、要素種別−地域ごとに情報を分類するが、要素種別のみで情報を分類してもよい。また、診断モデル生成部１０３は、別の分類方法で情報を分類してもよい。例えば、診断モデル生成部１０３は、車両ＩＤより車種又は年式を識別し、情報を車種又は年式ごとに分類してもよい。

次に、診断モデル生成部１０３は、診断モデルを生成する（ステップＳ１１５４）。
具体的には、診断モデル生成部１０３は、ステップＳ１１５３で行った分類に従って、診断モデルを生成する。前述の例では、診断モデル生成部１０３は、要素種別−地域ごとの分類に従って、診断モデルを生成する。
診断モデル生成部１０３は、走行状況情報、走行環境情報及び車両固有情報と、要素状態情報（走行前）及び要素状態情報（走行後）との相関関係を分析して、診断モデルを生成する。診断モデル生成部１０３は、ランダムフォレストやＳＶＭ、ニューラルネットワークなどの一般的な機械学習手法を用いて相関関係を分析する。
診断モデル生成部１０３は、診断モデルとして、走行状況情報、走行環境情報、車両固有情報が入力されると車両要素の状態変化量が出力されるモデルを生成する。例えば、タイヤが診断対象であれば、急発進頻度、急ブレーキ頻度、急カーブ頻度（走行状況情報）、悪路走行頻度（走行環境情報）、車両総重量（車両固有情報）が入力されるとタイヤ溝の変化量（状態変化量）が出力される診断モデルを生成する。

診断モデル生成部１０３は、要素状態情報（走行前）と要素状態情報（走行後）との間の状態値の変化量（数値）をそのまま用いて学習を行ってもよい。また、診断モデル生成部１０３は、要素状態情報（走行前）と要素状態情報（走行後）との間の状態値の変化量を大、中、小などのカテゴリに分類した上で学習を行ってもよい。診断モデル生成部１０３は、相関性の分析結果に基づいて、車両要素ごとに適した手法を適用することができる。

また、他の方法として、診断モデル生成部１０３は、走行状況情報、走行環境情報、車両固有情報を元に主成分分析を行った後に、要素状態情報（走行前）と要素状態情報（走行後）との間の状態値の変化量と主成分分析結果との相関関係を学習してもよい。例えば、診断モデル生成部１０３は、走行状況情報、走行環境情報、車両固有情報ごとに主成分分析を実施した結果を用いて学習することができる。より具体的には、診断モデル生成部１０３は、複数の車両２００より取得した走行状況情報の、急発進頻度、急ブレーキ頻度、急カーブ頻度を元に主成分分析を行い、走行状況を示す値を求める。そして、診断モデル生成部１０３は、求めた走行状況を示す値と、要素状態情報（走行前）と要素状態情報（走行後）との間の状態値の変化量との相関関係を学習する。
他の方法として、診断モデル生成部１０３は、急ブレーキ頻度及び急カーブ頻度を元に主成分分析を行い、制駆動力影響度を求めてもよい。この場合は、診断モデル生成部１０３は、制駆動力影響度と、要素状態情報（走行前）と要素状態情報（走行後）との間の状態値の変化量との相関関係を学習する。

診断モデル生成部１０３は、生成した診断モデルを診断モデル記憶部１０４に格納する。また、診断モデル生成部１０３は、図１６に示す診断モデル情報を生成し、生成した診断モデル情報を診断モデル記憶部１０４に格納する。
診断モデル情報は、車種、年式、車両要素、地域等におけるカテゴリごとに適用する診断モデルを管理するための情報である。図１６の例では、２０１７年製の車種：ＸＸＸＸに適用する診断モデルが示される。図１６の例では、車両要素−地域ごとに適用する診断モデルが示されている。
後述する診断処理において診断部１０６は診断モデル情報を参照することで、適用する診断モデルを特定することができる。

図１７は、診断処理（図１２のＳ１２）の詳細を示す。
ステップＳ１２１とステップＳ１２２は、車両２００の走行前に行われる処理である。また、ステップＳ１２３とステップＳ１２４は、車両２００の走行後に行われる処理である。

車両２００では、走行開始前の処理として、例えばエンジン始動又はドア開錠をトリガーに要素通知情報取得部３０３が記憶部３０７から車両管理情報と要素通知情報を読み出す。そして、要素通知情報取得部３０３は車両管理情報と要素通知情報を通信部３０１に出力する。そして、通信部３０１が車両管理情報と要素通知情報をサーバ装置１００に送信する。
車両管理情報は、図６に示す情報である。要素通知情報は、図７に示す情報である。

サーバ装置１００では、情報取得部１０１が車載装置３００から送信された車両管理情報と要素通知情報を受信する（ステップＳ１２１）。
情報取得部１０１は、受信した車両管理情報と要素通知情報を情報記憶部１０２に格納するとともに、影響推定部１０５に出力する。

次に、診断部１０６が要素状態診断（走行前）を行う（ステップＳ１２２）。
診断部１０６は、情報記憶部１０２が保持する前回診断時の車両要素管理情報とステップＳ１２１で受信した要素通知情報とを用いて、要素状態診断（走行前）を行う。
車両要素管理情報は、図１０に示す情報である。車両要素管理情報には、要素ＩＤと要素種別ＩＤと利用開始日と最終診断日と診断モデルバージョンが示される。要素ＩＤと要素種別ＩＤと利用開始日は図７の要素通知情報に示されるものと同じである。最終診断日には、対象の車両２００に対して診断部１０６が最後に車両要素の診断をした日時が示される。診断モデルバージョンには、車両要素ごとに適用する診断モデルのバージョンが示される。
要素状態診断処理（走行前）の詳細を図１８を参照して説明する。

先ず、診断部１０６は、車両要素ごとに、ステップＳ１２１で受信された要素通知情報（図７）の利用開始日と車両要素管理情報（図１０）の最終診断日とを比較する（ステップＳ１２２１）。

いずれかの車両要素で利用開始日が最終診断日よりも新しい場合（ステップＳ１２２１でＹＥＳ）は、診断部１０６は、診断結果情報（図９）の該当する車両要素の累積変化量を初期化する（ステップＳ１２２２）。
利用開始日が最終診断日よりも新しい場合は、該当する車両要素が交換されていると考えられる。このため、診断部１０６は、診断結果情報（図９）の累積変化量を初期化する。
累積変化量は、車両２００の初回走行又は車両要素の交換からの状態変化量の累積値である。例えば、タイヤの累積変化量は、車両２００の初回走行又はタイヤの交換からのタイヤ溝の総減少量である。

一方、いずれの車両要素においても利用開始日が最終診断日よりも新しくない場合（ステップＳ１２２１でＮＯ）は、ステップＳ１２２３の処理が行われる。また、ステップＳ１２２２の処理が行われた後にもステップＳ１２２３の処理が行われる。

ステップＳ１２２３では、診断部１０６は、車両要素ごとに診断結果情報（図９）の累積変化量が閾値を超過しているか否かを判定する。
つまり、診断部１０６は、診断結果情報（図９）の保守点検閾値又は交換閾値が「超過」となっているか否かを判定する。

いずれの車両要素も累積変化量が閾値を超過していなければ（ステップＳ１２２３でＮＯ）、診断部１０６は処理を終了する。

一方、いずれかの車両要素で累積変化量が閾値を超過している場合（ステップＳ１２２３でＹＥＳ）は、診断部１０６は、診断通知（走行前）を車載装置３００に送信する。
図９のように、右前のタイヤの保守点検閾値が「超過」になっている場合は、診断部１０６は「右前のタイヤの点検を行いましょう」というメッセージが示される診断通知（走行前）を車載装置３００に送信する。

車載装置３００では、通信部３０１が診断通知（走行前）を受信し、診断通知表示部３０２が診断通知（走行前）のメッセージを表示する。

要素状態診断処理（走行前）（ステップＳ１２２）が完了し、また、車両２００が走行を終了すると、図１７のステップＳ１２３において、情報取得部１０１が挙動履歴情報を取得する。つまり、情報取得部１０１は、車載装置３００から挙動履歴情報を受信する。
車載装置３００では、車両２００の走行中に、車両制御部３０６の制御値及びセンサ情報収集部３０５により収集されたセンサ情報に基づき、挙動履歴情報生成部３０４が一定周期で挙動履歴情報を生成する。また、挙動履歴情報生成部３０４は、生成した挙動履歴情報を既定の記憶領域に蓄積しておく。そして、車両２００の走行が終了した際に、通信部３０１が、蓄積されていた挙動履歴情報をまとめてサーバ装置１００に送信する。通信部３０１は、例えば、エンジン停止、ブレーキペダルの操作、またはサイドブレーキ操作により車両２００の走行終了を判定する。
これに代えて、挙動履歴情報生成部３０４が一定周期で挙動履歴情報を生成し、通信部３０１が、挙動履歴情報が生成される度に、生成された挙動履歴情報を送信するようにしてもよい。
挙動履歴情報は、図８に示す情報である。
情報取得部１０１は、受信した挙動履歴情報を情報記憶部１０２に格納する。

次に、影響推定部１０５及び診断部１０６が、要素状態診断処理（走行後）を行う（ステップＳ１２４）。
つまり、影響推定部１０５が診断モデルを用いて、車両要素ごとに状態変化量を導出する。また、診断部１０６が、影響推定部１０５により導出された状態変化量を用いて、車両要素ごとに診断を行う。
以下、図１９を参照して、要素状態診断処理（走行後）の詳細を説明する。

先ず、影響推定部１０５が、挙動履歴情報から、走行情報、環境情報及び車両固有情報を生成する（ステップＳ１２４１）。
走行情報、環境情報及び車両固有情報の生成方法は、上述の通りである。つまり、診断モデル生成時の診断モデル生成部１０３による走行情報、環境情報及び車両固有情報の生成方法と同じ方法で影響推定部１０５は走行情報、環境情報及び車両固有情報を生成する。

次に、影響推定部１０５は、走行状況情報及び走行環境情報を生成する（ステップＳ１２４２）。
走行状況情報及び走行環境情報の生成方法は、上述の通りである。つまり、診断モデル生成時の診断モデル生成部１０３による走行状況情報及び走行環境情報の生成方法と同じ方法で影響推定部１０５は走行状況情報及び走行環境情報を生成する。

また、影響推定部１０５は、図１５に示すように、ステップＳ１２４１で得られた車両固有情報と、ステップＳ１２４２で得られた走行状況情報と走行環境情報を対応付ける。

次に、影響推定部１０５が、車両要素ごとに状態変化量を導出する（ステップＳ１２４３）。

影響推定部１０５は、走行状況情報、走行環境情報及び車両固有情報と、診断モデル記憶部１０４で記憶されている診断モデルとを用いて、車両要素ごとに状態変化量を導出する。つまり、影響推定部１０５は、診断モデル情報（図１６）に記述されている診断モデルを診断モデル記憶部１０４から取得し、取得した診断モデルを用いて、車両要素ごとに状態変化量を導出する。
適用する診断モデルが、カテゴリ分類に基づいて得られた診断モデルであれば、診断モデルから出力される状態変化量は、大、中、小などのカテゴリで表現される。
以下では、説明の簡明化のため、状態変化量として数値が得られる例を用いて説明を進める。
影響推定部１０５は、得られた各車両要素の状態変化量を診断部１０６に出力する。

次に、診断部１０６が、車両要素ごとに状態を診断する（ステップＳ１２４４）。

診断部１０６は、影響推定部１０５により導出された状態変化量を、診断結果情報（図９）の累積変化量に加算する。診断結果情報（図９）の累積変化量は、前回の診断時、つまり、車両２００の走行開始前に得られている累積変化量である。つまり、診断結果情報（図９）の累積変化量は、車両２００の初回走行から前回の診断までの車両要素の状態変化量の累積値である。影響推定部１０５により導出された状態変化量と診断結果情報（図９）の累積変化量とを加算することで、車両２００の初回走行から前回の診断までの車両要素の状態変化量の累積値（以下、「新たな累積変化量」という）を得ることができる。
次に、診断部１０６は、新たな累積変化量と既定の保守点検閾値及び交換閾値とを比較する。保守点検閾値は、車両２００のユーザーに車両要素の保守点検を促すメッセージを送信するための閾値である。また、交換閾値は、車両２００のユーザーに車両要素の交換を促すメッセージを送信するための閾値である。
例えば、車両要素がタイヤである場合に、タイヤ溝の初期値を８ｍｍと仮定する。そして、保守点検閾値を５ｍｍ（残りのタイヤ溝が３ｍｍ）、交換閾値を６ｍｍ（残りのタイヤ溝が２ｍｍ）と仮定する。新たな累積変化量が５ｍｍを超過している場合は、診断部１０６は、タイヤの保守点検が必要と判定する。更に、新たな累積変化量が６ｍｍを超過している場合は、診断部１０６は、タイヤの交換が必要と判定する。

また、診断部１０６は、新たな累積変化量が保守点検閾値を超過していない場合は、車両要素の保守点検が必要になるタイミングを予測する。診断部１０６は、例えば、車両要素の保守点検が必要になるタイミングとして、車両要素の交換が必要になるまでの走行距離及び期間の少なくともいずれかを予測する。
例えば、車両要素がタイヤである場合に、新たな累積変化量が４．９８ｍｍであるとする。また、今回の状態変化量が０．２μｍ／ｋｍであるとする。この場合、保守点検閾値までの残量は０．０２ｍｍである。今回の状態変化量が０．２μｍ／ｋｍであることから、今回と同様の走行が行われた場合は、診断部１０６は、１００ｋｍを走行した段階で保守点検が必要になると判定する。また、車両２００の一日の平均走行距離が判明している場合は、診断部１０６は、１００ｋｍを平均走行距離で除算して、保守点検が必要なるまでの日数を求めてもよい。
以上は、車両要素の保守点検が必要になるまでの走行距離又は期間を算出する例を説明したが、診断部１０６は、同様の手順にて、車両要素の交換が必要になるまでの走行距離又は期間を予測することができる。

診断モデルからの出力が大、中、小などの状態変化量のカテゴリで表現されている場合は、診断部１０６は、例えば、以下のようにして車両要素の状態の診断を行う。

車両要素がタイヤである場合に、タイヤ溝の変化量が大、中、小のカテゴリで分類されていると仮定する。この場合に、診断部１０６は、カテゴリと数値との変換テーブルを保持しているものとする。変換テーブルでは、例えば、カテゴリ「大」に対応する数値として０．３μｍ／ｋｍが定義されている。また、カテゴリ「中」に対応する数値として０．２μｍ／ｋｍが定義されている。また、カテゴリ「小」に対応する数値として０．１μｍ／ｋｍが定義されている。診断部１０６は、影響推定部１０５から通知されたカテゴリの値と、挙動履歴情報から得られた走行距離と、変換テーブルとを用いて、状態変化量の数値を得る。その後は、診断部１０６は、得られた状態変化量の数値を診断結果情報（図９）の累積変化量に加算する。

次に、診断部１０６は、診断結果を通知する診断通知（走行後）を生成する。そして、診断部１０６は、生成した診断通知を車載装置３００に送信する。
例えば、タイヤ（右前）の新たな累積変化量が保守点検閾値を超過している場合は、診断部１０６は、「右前のタイヤの点検を行いましょう」というメッセージが示される診断通知（走行後）を生成する。また、例えば、タイヤ（右前）の新たな累積変化量が交換閾値を超過している場合は、診断部１０６は、「右前のタイヤの交換を行いましょう」というメッセージが示される診断通知（走行後）を生成する。
また、例えば、タイヤ（右前）の新たな累積変化量が保守点検閾値を超過していない場合は、診断部１０６は、「あと１００ｋｍ走行したら、右前のタイヤの点検を行いましょう」というメッセージが示される診断通知（走行後）を生成する。また、例えば、タイヤ（右前）の新たな累積変化量が交換閾値を超過していない場合は、診断部１０６は、「あと１５０ｋｍ走行したら、右前のタイヤの交換を行いましょう」というメッセージが示される診断通知（走行後）を生成する。
また、今回の状態変化量が他の車両２００の状態変化量よりも多い場合は、診断部１０６は、運転方法の改善を促すメッセージが示される診断通知（走行後）を生成してもよい。例えば、タイヤの摩耗量が大きい場合は、「タイヤへの影響が大きい走行でした。急発進、急ブレーキが多い傾向にあるため注意しましょう」というメッセージが示される診断通知（走行後）を生成する。つまり、診断部１０６は、車両２００の走行による車両要素への影響を減少させる運転方法を車両２００のユーザに通知する。
そして、診断部１０６は、生成した診断通知（走行後）を車載装置３００に送信する。

車載装置３００では、通信部３０１が診断通知（走行後）を受信し、診断通知表示部３０２が診断通知（走行後）のメッセージを表示する。

以上では、サーバ装置１００から車載装置３００にのみ診断通知が送信される例を説明した。
例えば、サーバ装置１００は、車両２００のユーザーが保持するユーザー端末に診断通知を送信してもよい。ユーザー端末は、例えば、スマートフォン、タブレット端末等である。

また、サーバ装置１００は、車両２００のディーラーのサーバ装置に診断通知を送信してもよい。この場合は、ディーラーは、診断通知に基づき車両要素の状態を把握することができるため、ユーザーへの点検時期の通知を適切に行うことができる。また、ディーラーは、必要となる交換部品の準備を適切に行うことができる。

また、車両２００の保守点検時に、ディーラーの保守点検員が使用する診断端末を車載装置３００に接続し、車載装置３００から診断端末に診断通知を送信するようにしてもよい。診断端末と車載装置３００とは、例えば、ＯＢＤ（Ｏｎ−Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ）インタフェースを用いて接続可能である。
また、診断端末が、保守点検時に検出した車両要素の異常又は保守点検時に得られた測定結果をサーバ装置１００に送信してもよい。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態によれば、車両要素の状態を正確に診断することができる。
また、本実施の形態によれば、車両走行中に状態を直接観測できない車両要素に対しても診断を行うことができる。
また、本実施の形態によれば、車両の走行前に診断を行うことで、走行により発生する故障を未然に防止することができる。
また、本実施の形態で行われる診断は車両要素の状態変化量に基づいた診断であるため、走行距離又は使用期間を目安とする交換時期の判断よりも高精度に交換時期を判断することができる。
また、本実施の形態では、車両要素の種別ごとに診断を行うことができるため、車両要素の種別ごとの状態変化量のばらつきを考慮した診断を行うことができる。
また、本実施の形態では、地域ごとに診断を行うことができるため、車両の走行地域の気候の違いによる状態変化量のばらつきを考慮した診断を行うことができる。
また、本実施の形態では、車種又は年式ごとに診断を行うことができるため、車種又は年式による状態変化量のばらつきを考慮した診断を行うことができる。

実施の形態２．
本実施の形態では、車載装置３００において車両要素の診断を行う例を説明する。
なお、以下では、主に実施の形態１との差異を説明する。
なお、以下で説明していない事項は、実施の形態１と同様である。

＊＊＊構成の説明＊＊＊
図２０は、本実施の形態に係るサーバ装置１００の機能構成例を示す。

図２０では、図４の構成と比較して、影響推定部１０５及び診断部１０６が省略されて、診断モデル送信部１０７が追加されている。
診断モデル送信部１０７は、車載装置３００から依頼があった場合に、診断モデル記憶部１０４で保持されている診断モデルを車載装置３００に送信する。
なお、診断モデル送信部１０７の機能も、情報取得部１０１等と同様にプログラムで実現される。診断モデル送信部１０７の機能を実現するプログラムは、プロセッサ９１１により実行される。

図２１は、本実施の形態に係る車載装置３００の機能構成例を示す。

図２１では、図５に示す構成と比較して、要素通知情報取得部３０３が省略されて、診断モデル記憶部３０８、影響推定部３０９及び診断部３１０が追加されている。
影響推定部３０９及び診断部３１０の機能も、通信部３０１等と同様にプログラムで実現される。影響推定部３０９及び診断部３１０の機能を実現するプログラムは、プロセッサ９３１により実行される。
診断モデル記憶部３０８は、主記憶装置９３２又は補助記憶装置９３３により実現される。
なお、本実施の形態では、車載装置３００が情報処理装置に相当する。また、本実施の形態では、車載装置３００により行われる動作が、情報処理方法及び情報処理プログラムに相当する。

診断モデル記憶部３０８は、サーバ装置１００から送信され、通信部３０１により受信された診断モデルを記憶する。
影響推定部３０９は、実施の形態１で説明した影響推定部１０５と同様の動作を行う。つまり、影響推定部３０９は、診断モデルを用いて、車両要素の状態変化量を導出する。
診断部３１０は、実施の形態１で説明した診断部１０６と同様の動作を行う。つまり、診断部３１０は、影響推定部３０９により導出された車両要素の状態変化量に基づき、車両要素の状態を診断する。

＊＊＊動作の説明＊＊＊
サーバ装置１００では、図１２に示す処理のうち、学習処理（Ｓ１１）のみが行われる。
学習処理（Ｓ１１）の詳細は、図１３及び図１４に示す通りである。
また、サーバ装置１００では、学習処理（Ｓ１１）の後は、車載装置３００から診断モデルの送信が依頼された場合に、診断モデル送信部１０７が、診断モデル記憶部１０４で保持されている診断モデルを車載装置３００に送信する。

図２２は、本実施の形態に係る車載装置３００の動作の概要を示す。
車載装置３００の動作は、モデル取得処理（ステップＳ３１）と診断処理（ステップＳ３２）に分けられる。

モデル取得処理（ステップＳ３１）では、診断部３１０が診断モデルの送信をサーバ装置１００に依頼する。そして、通信部３０１がサーバ装置１００から送信された診断モデルを受信し、受信した診断モデルを診断モデル記憶部３０８に格納する。
診断処理（ステップＳ３２）では、影響推定部３０９が、診断モデルを用いて車両要素の状態変化量を導出する。また、診断処理（ステップＳ１２）では、診断部３１０が状態変化量に基づき車両要素の状態を診断し、診断通知表示部３０２が診断通知を表示する。

図２３は、モデル取得処理（ステップＳ３１）の詳細を示す。
モデル取得処理（ステップＳ３１）は、車両２００の走行開始前に行われる。

先ず、診断部３１０が診断モデルの送信を依頼するモデル送信依頼を生成し、通信部３０１がモデル送信依頼をサーバ装置１００に送信する（ステップＳ３１１）。

モデル送信依頼には、図２４に示す車両情報及び図２５に示す車両要素情報が含まれる。
車両情報には、車両ＩＤと車種と年式と地域が記述される。
車両要素情報には、要素ＩＤと要素種別ＩＤと利用開始日と最終診断日と診断モデルバージョンが記述される。
最終診断日は、診断部３１０が最後に車両要素の診断を行った日時が記述される。診断モデルバージョンは、診断モデル記憶部３０８で保持している診断モデルのバージョンが記述される。診断モデル記憶部３０８で診断モデルが保持されていない場合は、診断モデルバージョンの欄にはヌル値が記述される。要素ＩＤ、要素種別ＩＤ、利用開始日は、車両２００の製造時又は車両要素の交換時に設定される。

サーバ装置１００では、情報取得部１０１がモデル送信依頼を受信し、受信したモデル送信依頼を診断モデル生成部１０３に出力する。
診断モデル生成部１０３は、車両情報及び車両要素情報により特定される車種、年式、都市及び車両要素に対応する診断モデルを特定する。また、診断モデル生成部１０３は、特定した診断モデルのバージョンが車両要素情報に示されるバージョンよりも新しいか否かを判定する。特定した診断モデルのバージョンが車両要素情報に示されるバージョンよりも新しい場合は、診断モデル生成部１０３は、当該診断モデルを車載装置３００に送信するよう診断モデル送信部１０７に指示する。診断モデル送信部１０７は、診断モデル生成部１０３の指示に基づき、診断モデルを車載装置３００に送信する。
また、診断モデル生成部１０３は、車両要素情報の利用開始日と最終診断日とを比較する。利用開始日が最終診断日よりも後の車両要素がある場合は、診断モデル生成部１０３は、当該車両要素の交換が行われていると判定する。交換された車両要素が存在する場合は、診断モデル生成部１０３は、当該車両要素の累積変化量の初期化を診断モデル送信部１０７に指示する。診断モデル送信部１０７は、診断モデル生成部１０３からの指示に基づき、車両要素の累積変化量の初期化を指示するメッセージを車載装置３００に送信する。

車載装置３００では、図２３のステップＳ３１２において、通信部３０１が診断モデルを受信する。
そして、通信部３０１は、ステップＳ３１３において、受信した診断モデルを診断モデル記憶部３０８に格納する。
なお、サーバ装置１００から、いずれかの車両要素の累積変化量の初期化を指示するメッセージを受信した場合は、診断部３１０は、該当する車両要素の累積変化量を初期化する。本実施の形態では、車載装置３００で車両要素の診断が行われるため、記憶部３０７が図９の診断結果情報を保持している。診断部３１０は、記憶部３０７が保持している診断結果情報の累積変化量の値を初期化する。

図２６は、診断処理（ステップＳ３２）の詳細を示す。
ステップＳ３２１は、車両２００の走行前に行われる処理である。また、ステップＳ３２２は、車両２００の走行中に行われる処理である。ステップＳ３２３は、車両２００の走行後に行われる処理である。

先ず、診断部３１０が要素状態診断処理（走行前）を行う（ステップＳ３２１）。
診断部３１０は、記憶部３０７が保持する前回診断時の診断結果情報（図９）を用いて、要素状態診断処理（走行前）を行う。具体的には、診断部３１０は、車両要素ごとに診断結果情報（図９）の累積変化量が閾値を超過しているか否かを判定する。つまり、診断部３１０は、診断結果情報（図９）の保守点検閾値又は交換閾値が「超過」となっているか否かを判定する。
いずれの車両要素も累積変化量が閾値を超過していなければ、診断部３１０は処理を終了する。
一方、いずれかの車両要素で累積変化量が閾値を超過している場合は、診断部３１０は、診断通知（走行前）を診断通知表示部３０２に出力する。診断通知表示部３０２は、診断通知（走行前）のメッセージを表示する。
なお、上記では、サーバ装置１００からの初期化の指示に従って、診断部３１０が診断結果情報（図９）の累積変化量を初期化する例を説明したが、診断部３１０がステップＳ３２１において車両要素情報の利用開始日と最終診断日を比較してもよい。この場合に、利用開始日と最終診断日との比較の結果、交換されている車両要素が存在する場合は、診断部３１０は、該当する車両要素の累積変化量の値を初期化する。

次に、車両２００の走行中に、挙動履歴情報生成部３０４が、挙動履歴情報を生成し、生成した挙動履歴情報を蓄積する（ステップＳ３２２）。
挙動履歴情報生成部３０４は、車両制御部３０６の制御値及びセンサ情報収集部３０５により収集されたセンサ情報に基づき、一定周期で挙動履歴情報を生成する。また、挙動履歴情報生成部３０４は、生成した挙動履歴情報を既定の記憶領域に蓄積しておく。

次に、影響推定部３０９及び診断部３１０が、要素状態診断処理（走行後）を行う（ステップＳ３２３）。
つまり、影響推定部３０９が診断モデルを用いて、車両要素ごとに状態変化量を導出する。また、診断部３１０が、影響推定部３０９により導出された状態変化量を用いて、車両要素ごとに診断を行う。
実施の形態１の影響推定部１０５は、車載装置３００から送信された挙動履歴情報を用いているが、影響推定部３０９は挙動履歴情報生成部３０４から出力された挙動履歴情報を用いる。この点を除けば、影響推定部３０９の動作は、実施の形態１で説明した影響推定部１０５の動作と同じである。また、診断部３１０の動作は、実施の形態１で説明した診断部１０６の動作と同じである。このため、ステップＳ３２３の詳細な説明は省略する。
診断部３１０は、診断が完了すると、診断結果を通知する診断通知を診断通知表示部３０２に出力する。診断通知表示部３０２は、診断通知を表示する。

なお、車載装置３００は、実施の形態１で説明したユーザー端末、ディーラーのサーバ装置及びディーラーの保守作業員の診断端末に診断通知を送信してもよい。ユーザー端末、ディーラーのサーバ装置及びディーラーの保守作業員の診断端末に診断通知を送信することによる利点は、実施の形態１に示した通りである。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態によれば、実施の形態１で示した効果に加えて、車載装置３００において車両要素の状態を正確に診断することができるという効果を得ることができる。

なお、上記では、車両２００の走行後に車両要素の診断を行う例を示した。これに代えて、車両２００の走行中に車両要素の診断を行ってもよい。車両２００の走行中に診断を行う場合は、影響推定部３０９は、例えば、１分などの周期で状態変化量を導出する。そして、車両２００の走行終了後に、診断部３１０が周期的に得られた状態変化量の各々を累積変化量に加算して診断を行う。

＊＊診断モデルの別の生成方法＊＊
実施の形態１及び２では、診断モデル生成部１０３が、挙動履歴情報から、走行状況情報、走行環境情報及び車両固有情報を生成し、こられ情報と車両要素の状態値の変化量との相関関係を学習し、診断モデルを生成する例を説明した。
診断モデル生成部１０３は、別の方法で診断モデルを生成してもよい。例えば、診断モデル生成部１０３は、走行情報、環境情報及び車両固有情報と車両要素の状態値の変化量との相関関係を学習し、診断モデルを生成してもよい。診断モデル生成部１０３は、例えば、時系列データを扱うことができる、ＲＮＮ（Ｒｅｃｕｒｒｅｎｔ Ｎｅｕｒａｌ Ｎｅｔｗｏｒｋ）などの手法を用いて相関関係の学習を行ってもよい。

＊＊変形例＊＊
実施の形態１及び実施の形態２に代えて、以下にてサーバ装置１００及び車載装置３００が処理を分担してもよい。
（１）車載装置３００が影響推定まで行い、サーバ装置１００が診断を行う。
この場合のサーバ装置１００の構成は、図４の構成から影響推定部１０５を省略したものとなる。また、車載装置３００の構成は、図２１の構成から診断部３１０を省略したものとなる。診断の流れは実施の形態２とほぼ同様である。
車載装置３００では、通信部３０１が、影響推定部３０９により抽出された、車両要素の状態変化量をサーバ装置１００に通知する。
サーバ装置１００では、診断部１０６が、通知された状態変化量と以前までの状態変化量とを用いて診断を実施する。
このような方式とすることで、サーバ装置１００と車載装置３００との間の通信量を低減できる効果がある。
（２）サーバ装置１００が基本的に診断を行うが、簡易的な診断を車載装置３００が行う。
この場合のサーバ装置１００の構成は、図４に示す通りであり、車載装置３００の構成は、図２１に示す通りである。
診断の流れは実施の形態１及び実施の形態２とほぼ同様である。
ただし、車載装置３００での診断では、診断モデルに入力する情報を実施の形態２よりも少なくする。
タイヤを例とすると、急ブレーキ頻度と急カーブ頻度のみが診断モデルに入力される。
この方式では、車載装置３００では、前述の「運転方法の改善を促すメッセージ」（「タイヤへの影響が大きい走行でした。急発進、急ブレーキが多い傾向にあるため注意しましょう」等）を出力するのに必要な診断のみを車載装置３００で行う。

実施の形態３．
本実施の形態では、実施の形態１及び２と異なる診断モデルの生成方法及び車両要素の診断方法を説明する。
本実施の形態では、主に実施の形態１及び２との差異を説明する。
なお、以下で説明していない事項は、実施の形態１又は２と同様である。

＊＊＊構成の説明＊＊＊
本実施の形態では、サーバ装置１００及び車載装置３００の構成は、実施の形態１及び２のいずれの構成であってもよい。
以下では、実施の形態１の構成を前提に説明を進める。

＊＊＊動作の説明＊＊＊
本実施の形態では、診断モデル生成部１０３は、挙動履歴情報の各項目の平均値及び標準偏差及び中央値、標準偏差等の統計量を算出する。図８の例では、診断モデル生成部１０３は、車速、加速度等の各項目について平均値と標準偏差を算出する。
次に、診断モデル生成部１０３は、算出した平均値及び標準偏差等の統計量と要素状態情報における状態値の変化量との相関分析を行い、診断モデルを生成する。診断モデルの生成方法は、実施の形態１と同様である。

次に、図２７を参照して、本実施の形態に係る要素状態診断処理（走行後）を説明する。

本実施の形態でも、車載装置３００は、車両２００の走行が終了した後に挙動履歴情報をサーバ装置１００に送信する。

サーバ装置１００では、影響推定部１０５が、挙動履歴情報の時系列データを一定周期（例えば１０秒）ごとに区切り、一定周期ごとに各項目の平均値と標準偏差を算出する（ステップＳ１３１）。
図８の例では、影響推定部１０５は、車速、加速度等の各項目について一定周期ごとに平均値と標準偏差を算出する。

次に、影響推定部１０５は、一定周期ごとの各項目の平均値と標準偏差を診断モデルに入力して、一定周期ごとの状態変化量を導出する。

最後に、診断部１０６が、一定周期ごとの状態変化量を累積変化量に加算して、車両要素の状態を診断する（ステップＳ１３３）。
ステップＳ１３３は、図１９のステップＳ１２４４と同じであるため、説明を省略する。

なお、以上では、実施の形態１の構成に基づいて説明を行ったため、影響推定部１０５及び診断部１０６が診断を行うことになっている。実施の形態２の構成に、本実施の形態に係る手法を適用する場合は、以上の手順にて影響推定部３０９及び診断部３１０が診断を行う。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態によれば、実施の形態１及び２と比べて少ない計算負荷で診断モデルを生成することができ、また、診断を行うことができる。

＊＊統計量の別の算出方法＊＊
上記では、影響推定部１０５は、一定周期（例えば１０秒）の間の各項目の値で統計量を算出している。これに代えて、影響推定部１０５は、一定周期（例えば１０秒）ごとの各項目の値で統計量を算出してもよい。つまり、影響推定部１０５は、０秒時の値、１０秒経過時の値、２０秒経過時の値・・・等を用いて統計量を算出するようにしてもよい。
通常は、車両の挙動が短時間に度々変化することは無い。このため、データを間引いて統計量を算出して学習及び診断を行っても精度は低下しない。このようなデータを間引いて統計量を算出することで、必要な演算リソース、記憶リソースを低減できる効果がある。

また、影響推定部１０５は、車両要素の変化（劣化など）への影響度合の高い特徴的な走行状況（急カーブ、急ブレーキなど）が行われた時間帯の値のみを用いて統計量を算出するようにしてもよい。
この場合も、必要な演算リソース、記憶リソースを低減できる効果がある。

＊＊診断モデルの別の生成方法＊＊
ここでは、本実施の形態１〜３で説明した学習方法と異なる学習方法にて診断モデルを生成する例を説明する。

以下では、一例として、タイヤ摩耗についての学習を説明する。
タイヤ摩耗速度は、横力、制動力、駆動力より算出できることが広く知られている。タイヤ摩耗速度は、例えば、下記の式にて求めることができる。

なお、上記式における各パラメータは下記の通りである。

上述のタイヤ摩耗速度の計算式において、車両２００の加速度は挙動履歴情報から取得可能である。また、ホイールのトー角、タイヤの加重などの値は、車両２００のスペック情報（図６）に含ませることが考えられる。一方で、スティフネスなどの値は挙動履歴情報より求めることは困難である。そこで、車両２００で収集可能なパラメータを変数としたタイヤ摩耗速度の算出式として下記を用いる。

ここで、「Ａ」、「Ｂ」及び「Ｃ」は、横力、制動力及び駆動力によるタイヤ摩耗速度を算出する係数値である。診断モデル生成部１０３は、これら「Ａ」、「Ｂ」及び「Ｃ」の係数値を、挙動履歴情報と車両要素の状態値の変化量を用いて学習する。

実施の形態４．
実施の形態１〜３では、挙動履歴情報がそのまま用いられる。本実施の形態では、挙動履歴情報の記号化により情報量を低減する例を説明する。
本実施の形態では、主に実施の形態１〜３との差異を説明する。
なお、以下で説明していない事項は、実施の形態１〜３と同様である。

＊＊＊構成の説明＊＊＊
本実施の形態では、サーバ装置１００及び車載装置３００の構成は、実施の形態１及び２のいずれの構成であってもよい。
以下では、実施の形態１の構成を前提に説明を進める。

＊＊＊動作の説明＊＊＊
本実施の形態では、図１７の要素状態診断処理（走行後）（ステップＳ１２４）について説明する。

影響推定部１０５は、車載装置３００から受信した挙動履歴情報の値をカテゴリに分類し、記号化する。
例えば、影響推定部１０５は、車速の値を速度域により複数のカテゴリに分類する。速度域を３段階に分類するとすれば、例えば、影響推定部１０５は、３０ｋｍ／ｈ未満の速度域を「Ｃ」と分類する。また、影響推定部１０５は、３０ｋｍ／ｈ〜５０ｋｍ／ｈの速度域を「Ｂ」と分類する。また、影響推定部１０５は、５０ｋｍ／ｈ〜８０ｋｍ／ｈの速度域を「Ａ」と分類する。

次に、影響推定部１０５は、挙動履歴情報の値の変化方向と変化量を算出する。
車速であれば、影響推定部１０５は、車速の変化方向を、増加（Ｕｐ，Ｕ）、減少（Ｄｏｗｎ，Ｄ）及び変化無（Ｋｅｅｐ，Ｋ）で分類する。
また、影響推定部１０５は、車速の変化量を、変化量大（Ｌａｒｇｅ，Ｌ）、変化量小（Ｓｍａｌｌ，Ｓ）及び変化無（Ｎｏｒｍａｌ，Ｎ）で分類する。
そして、影響推定部１０５は、分類結果が反映された走行情報を生成する。

次に、影響推定部１０５は、走行情報を用いて分析結果情報を生成する。
例えば、影響推定部１０５は、走行情報の値を条件属性とし、挙動履歴情報に示される項目を決定属性とする分析結果情報を生成する。
例えば、挙動履歴情報に項目「ブレーキ度合」が含まれており、この項目「ブレーキ度合」を用いた分析結果情報を生成する場合には、影響推定部１０５は、車速、車速の変化方向、車速の変化量を条件属性とし、ブレーキ度合を決定属性とする分析結果情報を生成する。

そして、影響推定部１０５は、分析結果情報の決定属性を用いて走行状況情報を生成する。走行状況情報の生成後の処理は、実施の形態１又は２に示す通りであるので、説明を省略する。

以上の手順を具体例を用いて説明する。

図２８は、挙動履歴情報に記述される車速の経時変化を示す。
図２８の例では、最も遅い速度域は「Ｅ」に分類され、最も速い速度域は「Ａ」に分類される。
図２９は、図２８に示す車速の経時変化を「Ａ」〜「Ｅ」の記号で表したカテゴリ分類結果を示す。
図３０は、図２９に示すカテゴリ分類結果と、車速の変化方向と車速の変化量のカテゴリ分類結果とが組み合わされた走行情報を示す。前述したように、車速の変化方向は、「Ｕ」、「Ｄ」及び「Ｋ」のいずれかで表される。また、車速の変化量は、「Ｌ」、「Ｓ」及び「Ｎ」のいずれかで表される。
図３１は、分析結果情報を示す。
図３１の例では、図３０の走行情報の車速、変化方向及び変化量が条件属性として表され、挙動履歴情報に示される項目「ブレーキ度合」が決定属性として表される。また、図３１の例では、車速「Ａ」〜「Ｅ」の順に各行が表記されている。図３１の例の場合、影響推定部１０５は、例えば、ブレーキ度合「２：ｂｅｌｏｗ ａｖｅｒａｇｅ」及び「１：ｐｏｏｒ」の場合に、急ブレーキが発生したと判定する。
影響推定部１０５は、図３１の分析結果情報のブレーキ度合「２：ｂｅｌｏｗ ａｖｅｒａｇｅ」及び「１：ｐｏｏｒ」の発生回数を計数して、走行状況情報（図１５）の急ブレーキ頻度の値を得る。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態によれば、挙動履歴情報の記号化により情報量を低減することができる。このため、少ない計算負荷及び記憶容量で、診断を行うことができる。

以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、２つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、１つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、２つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。

＊＊＊ハードウェア構成の説明＊＊＊
最後に、サーバ装置１００及び車載装置３００のハードウェア構成の補足説明を行う。

プロセッサ９１１及びプロセッサ９３１は、それぞれ、プロセッシングを行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）である。
プロセッサ９１１及びプロセッサ９３１は、それぞれ、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）等である。
主記憶装置９１２及び主記憶装置９３２は、それぞれ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。
補助記憶装置９１３及び補助記憶装置９３３は、それぞれ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等である。
通信装置９１４及び通信装置９３４は、それぞれ、データの通信処理を実行する電子回路である。
通信装置９１４及び通信装置９３４は、それぞれ、例えば、通信チップ又はＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である。

また、補助記憶装置９１３及び補助記憶装置９３３には、それぞれ、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）も記憶されている。
そして、プロセッサ９１１及びプロセッサ９３１は、それぞれ、ＯＳの少なくとも一部を実行する。
プロセッサ９１１はＯＳの少なくとも一部を実行しながら、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５、診断部１０６及び診断モデル送信部１０７の機能を実現するプログラムを実行する。
プロセッサ９１１がＯＳを実行することで、タスク管理、メモリ管理、ファイル管理、通信制御等が行われる。
また、プロセッサ９３１はＯＳの少なくとも一部を実行しながら、通信部３０１、診断通知表示部３０２、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６、影響推定部３０９及び診断部３１０の機能を実現するプログラムを実行する。
プロセッサ９３１がＯＳを実行することで、タスク管理、メモリ管理、ファイル管理、通信制御等が行われる。

また、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５、診断部１０６及び診断モデル送信部１０７の処理の結果を示す情報、データ、信号値及び変数値の少なくともいずれかが、主記憶装置９１２、補助記憶装置９１３、プロセッサ９１１内のレジスタ及びキャッシュメモリの少なくともいずれかに記憶される。
また、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５、診断部１０６及び診断モデル送信部１０７の機能を実現するプログラムは、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の可搬記録媒体に格納されていてもよい。そして、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５、診断部１０６及び診断モデル送信部１０７の機能を実現するプログラムが格納された可搬記録媒体を商業的に流通させてもよい。

また、通信部３０１、診断通知表示部３０２、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６、影響推定部３０９及び診断部３１０の処理の結果を示す情報、データ、信号値及び変数値の少なくともいずれかが、主記憶装置９３２、補助記憶装置９３３、プロセッサ９３１内のレジスタ及びキャッシュメモリの少なくともいずれかに記憶される。
また、通信部３０１、診断通知表示部３０２、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６、影響推定部３０９及び診断部３１０の機能を実現するプログラムは、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ等の可搬記録媒体に格納されていてもよい。そして、通信部３０１、診断通知表示部３０２、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６、影響推定部３０９及び診断部３１０の機能を実現するプログラムが格納された可搬記録媒体を商業的に流通させてもよい。

また、情報取得部１０１、診断モデル生成部１０３、影響推定部１０５、診断部１０６及び診断モデル送信部１０７の「部」を、「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。
また、サーバ装置１００は、処理回路により実現されてもよい。処理回路は、例えば、ロジックＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＧＡ（Ｇａｔｅ Ａｒｒａｙ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）である。

また、通信部３０１、診断通知表示部３０２、挙動履歴情報生成部３０４、センサ情報収集部３０５、車両制御部３０６、影響推定部３０９及び診断部３１０の「部」を、「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。
また、車載装置３００も、処理回路により実現されてもよい。

なお、本明細書では、プロセッサと処理回路との上位概念を、「プロセッシングサーキットリー」という。
つまり、プロセッサと処理回路とは、それぞれ「プロセッシングサーキットリー」の具体例である。

１００ サーバ装置、１０１ 情報取得部、１０２ 情報記憶部、１０３ 診断モデル生成部、１０４ 診断モデル記憶部、１０５ 影響推定部、１０６ 診断部、１０７ 診断モデル送信部、２００ 車両、３００ 車載装置、３０１ 通信部、３０２ 診断通知表示部、３０３ 要素通知情報取得部、３０４ 挙動履歴情報生成部、３０５ センサ情報収集部、３０６ 車両制御部、３０７ 記憶部、３０８ 診断モデル記憶部、３０９ 影響推定部、３１０ 診断部、５００ 診断システム、９１１ プロセッサ、９１２ 主記憶装置、９１３ 補助記憶装置、９１４ 通信装置、９３１ プロセッサ、９３２ 主記憶装置、９３３ 補助記憶装置、９３４ 通信装置。

Claims (16)

1. 車両の走行中の挙動の履歴が示される挙動履歴情報を取得する情報取得部と、
   前記車両の要素である車両要素への前記車両の走行による影響を、前記挙動履歴情報に示される前記車両の走行中の挙動の履歴に基づき推定する影響推定部と、
   前記影響推定部により推定された、前記車両の走行による前記車両要素への影響に基づき、前記車両要素の状態を診断する診断部とを有する情報処理装置。
2. 前記影響推定部は、
   前記挙動履歴情報に示される前記車両の走行中の挙動の履歴を解析して、前記車両の走行状況と前記車両の走行環境とを推定し、推定した前記車両の走行状況と前記車両の走行環境とに基づき、前記車両の走行による前記車両要素への影響を推定する請求項１に記載の情報処理装置。
3. 前記挙動履歴情報には、前記車両の走行中の挙動の履歴として、前記車両の状態値の経時変化が示され、
   前記影響推定部は、
   前記挙動履歴情報から、前記車両の状態値の単位時間ごとの統計量を算出し、算出した前記車両の状態値の単位時間ごとの統計量を用いて、前記車両の走行による前記車両要素への影響を推定する請求項１に記載の情報処理装置。
4. 前記挙動履歴情報には、前記車両の走行中の挙動の履歴として、前記車両の状態値の経時変化が示され、
   前記影響推定部は、
   前記挙動履歴情報に示される前記車両の状態値を記号化し、記号化された状態値を用いて前記車両の走行による前記車両要素への影響を推定する請求項１に記載の情報処理装置。
5. 前記影響推定部は、
   前記車両の走行による前記車両要素への影響として、前記車両の走行による前記車両要素に関連する物理量の変化を推定する請求項１に記載の情報処理装置。
6. 前記診断部は、
   前記車両の走行前に得られていた前記車両要素の物理量の変化の累積値と前記影響推定部により推定された前記車両要素の物理量の変化との加算値を用いて、前記車両要素の状態を診断する請求項５に記載の情報処理装置。
7. 前記診断部は、
   前記車両要素の状態が前記車両要素の点検及び交換の少なくともいずれかが必要な状態であるか否かを診断し、
   前記車両要素の状態が前記車両要素の点検及び交換の少なくともいずれかが必要な状態である場合に、前記車両要素の状態が前記車両要素の点検及び交換の少なくともいずれかが必要な状態である旨を前記車両のユーザーに通知する請求項１に記載の情報処理装置。
8. 前記診断部は、
   前記車両要素の状態が前記車両要素の点検及び交換の少なくともいずれかが必要な状態であるか否かを診断し、
   前記車両要素の状態が前記車両要素の点検が必要な状態ではない場合に、前記車両要素の点検が必要になるまでの走行距離及び期間の少なくともいずれかを予測し、予測した前記車両要素の点検が必要になるまでの走行距離及び期間の少なくともいずれかを前記車両のユーザーに通知し、
   前記車両要素の状態が前記車両要素の交換が必要な状態ではない場合に、前記車両要素の交換が必要になるまでの走行距離及び期間の少なくともいずれかを予測し、予測した前記車両要素の交換が必要になるまでの走行距離及び期間の少なくともいずれかを前記車両のユーザーに通知する請求項１に記載の情報処理装置。
9. 前記診断部は、
   前記車両の走行による前記車両要素への影響を減少させる運転方法を前記車両のユーザーに通知する請求項１に記載の情報処理装置。
10. 前記影響推定部は、
    車両の走行状況と車両の走行環境とが車両要素に与える影響を学習することにより得られた診断モデルを用いて、前記車両の走行による前記車両要素への影響を推定する請求項２に記載の情報処理装置。
11. 前記影響推定部は、
    地域、車種及び車両の年式の少なくともいずれかに従って分類された診断モデルを用いて、前記車両の走行による前記車両要素への影響を推定する請求項１０に記載の情報処理装置。
12. 前記情報処理装置は、更に、
    複数の車両から収集された、各車両の走行中の挙動の履歴が示される挙動履歴情報を用いて、車両の走行状況と車両の走行環境とが車両要素に与える影響を学習して、車両の走行による車両要素への影響を推定可能な診断モデルを生成するモデル生成部を有する請求項２に記載の情報処理装置。
13. 前記情報処理装置は、
    前記車両に搭載されており、
    前記影響推定部は、
    サーバ装置から提供された前記診断モデルを用いて、前記車両の走行による前記車両要素への影響を推定する請求項１０に記載の情報処理装置。
14. 前記情報取得部と前記影響推定部とが前記車両に存在し、
    前記診断部が前記車両外に存在する請求項１に記載の情報処理装置。
15. コンピュータが、車両の走行中の挙動の履歴が示される挙動履歴情報を取得し、
    前記コンピュータが、前記車両の要素である車両要素への前記車両の走行による影響を、前記挙動履歴情報に示される前記車両の走行中の挙動の履歴に基づき推定し、
    前記コンピュータが、推定された、前記車両の走行による前記車両要素への影響に基づき、前記車両要素の状態を診断する情報処理方法。
16. 車両の走行中の挙動の履歴が示される挙動履歴情報を取得する情報取得処理と、
    前記車両の要素である車両要素への前記車両の走行による影響を、前記挙動履歴情報に示される前記車両の走行中の挙動の履歴に基づき推定する影響推定処理と、
    前記影響推定処理により推定された、前記車両の走行による前記車両要素への影響に基づき、前記車両要素の状態を診断する診断処理とをコンピュータに実行させる情報処理プログラム。

Images