機器診断装置、機器診断システム及び機器診断方法

本発明は、機器診断装置、機器診断システム及び機器診断方法に関する。

運転中の機器から取得した様々なセンサ値を診断することによって、機器の故障を予測し、本格的な故障を未然に防ぐ技術が一般的に普及している。当該技術においては、機器の異常の有無を判断する様々な診断モデルが使用されている。特許文献1の設備診断システムは、診断モデルとして、物理モデル、統計モデル及び知識モデルの3つを使用する。そして、特許文献1の設備診断システムは、ある1つの診断モデルが更新された場合、当該診断モデルに不足している診断ルールを他の診断モデルから補うことによって、全体としての診断モデルの信頼性を向上させている。

特開2009−53938号公報

特許文献1の設備診断システムの診断モデルのうち、統計モデル及び知識モデルは、過去に蓄積された多くの学習用データを使用して機械学習を行うことにより、その信頼性を徐々に向上させて行く。したがって、診断対象の機器の学習用データが容易に得られない場合、部品交換又は機器構成が変更される都度、これらのモデルの信頼性が一旦低下し、回復するまでに多くの時間を要する。また、特許文献1の設備診断システムは、ビルの設備、産業プラント等の固定された設備を対象としている。つまり、特許文献1の設備診断システムが複数の診断モデルを融合して生成する診断モデルは、機器の運転環境が変化することを想定していない。

このような固定された設備の対極にある機器の例として、自動車等の車両が存在する。自動車の運転環境とは、例えば、道路形状、道路勾配、路面状態、天候等である。これらの運転環境は、自動車が走行するにつれて、時々刻々と変化する。例えば、自動車の冷却装置(ラジエタ)が診断対象である場合を想定する。いま、自動車がトンネルを通過しようとしている。トンネルに入る前の地域の気候は、温暖であり、気温は高く湿度は低い。一方、トンネルを出た後の地域は、雪国であり、気温は極端に低く湿度は高い。

自動車は、トンネルに入る前にある程度の学習用データを蓄積している。しかしながら、このような学習用データは、トンネルを出た後には殆ど役に立たない。このような学習用データによって機械学習した診断モデルは、トンネルを出た途端に、診断結果として“冷却装置が異常である”を連発し、診断モデルの信頼度は低くなる。 そこで、本発明は、運転環境が時々刻々と変化する機器を高信頼度で診断することを 目的とする。

本発明の機器診断装置は、移動する機器の運転環境に応じて、機器を診断するための診断モデルを選択する診断モデル選択部と、選択された診断モデルに対して機器の稼働データを入力し、診断モデルから機器に対する診断結果の出力を受け取ることによって機器を診断する診断部と、を備えることを特徴とする。 その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、運転環境が時々刻々と変化する機器を高信頼度で診断できる。

運転環境を説明する図である。

統計モデルの生成を説明する図である。

統計モデルの使用を説明する図である。

統計モデルの使用を説明する図である。

物理モデルの使用を説明する図である。

機器診断装置の構成を説明する図である。

稼働・環境情報を説明する図である。

診断モデル割当情報を説明する図である。

診断結果情報を説明する図である。

(a)は、統計モデル生成処理手順のフローチャートであり、(b)は、物理モデル生成処理手順のフローチャートである。

(a)は、診断モデル選択処理手順のフローチャートであり、(b)は、診断処理手順のフローチャートである。

(a)は、成熟度判定処理手順のフローチャートであり、(b)は、端末・センタ協調処理手順のフローチャートである。

(a)、(b)及び(c)は、表示画面の一例である。

以降、本発明を実施するための形態(“本実施形態”と言う)を、図等を参照しながら詳細に説明する。具体的には、道路上を走行する自動車の各機器(制動系、動力系、操舵系、冷却系、・・・)が正常であるか否かを診断する例を説明する。なお、本発明は、自動車以外の車両、例えば、自動二輪車、大型バス、鉄道車両、航空機等にも適用可能である。さらに本発明は、人間等が搭乗しない機器にも適用可能である。本実施形態において“車両”と言う語は、“移動する機器”を意味する。

(用語) 稼働データとは、運転中の車両から取得され得る、車両の各機器についての任意の物理量である。多くの場合、稼働データは、車載のセンサが取得するセンサ値(測定値)である。センサが取得した一次的なデータの他に、一次的なデータを加工・演算した結果算出される二次データも稼働データに含まれる。稼働データの例として、車速、エンジン回転速度、制動時間、冷却水温度、ファン回転速度、冷却水流量等、多くの種類が存在する。

運転環境とは、車両が走行する外部環境についての任意の物理量である。運転環境は、車載のセンサによって取得されてもよいし、車載のセンサ以外によって取得されてもよい。運転環境は、天候及び道路属性の2つに分かれる。天候の例としては、気温、湿度、大気圧、風向、風速、降水量等が存在する。道路属性の例としては、勾配、標高、交通量、交差点数、車線数、幅員、路面状態、道路形状(トンネル、橋梁)等が存在する。

本実施形態の機器診断装置が診断の対象とするデータは、稼働データである。機器診断装置は、冷却水温度、冷却水流量等の、複数の種類の稼働データの値を診断モデル(詳細後記)に入力し、診断モデルから出力結果として“正常”又は“異常”を取得する。診断モデルは、稼働データを入力とし、診断結果を出力する。本実施形態においては、診断モデルの種類として、統計モデル及び物理モデルが存在する。

診断モデルとは、入力変数、出力変数及びパラメータ間の数量的関係を規定する数式(等式、不等式及び条件式)の集合である。パラメータとは、例えば、入力変数に対して乗算される係数である。パラメータは定数であり、その意味では入力変数及び出力変数とは異なる。しかしながら、パラメータは、入力変数及び出力変数とは独立して、自身の値を変化させる。当然のことながら、パラメータの値が変化すると、診断モデルの座標空間内の位置及び形状も変化する。入力変数の値が同じであっても、パラメータの値が異なれば、出力変数の値も異なる。本実施形態の前提として、運転環境が変化するとパラメータの値も変化し、したがって診断結果(正常/異常)も変化する、という考え方がある。

統計モデルとは、機器が正常又は異常であることが既知である場合に実際に取得された稼働データ(学習用データ)の集合に対し、診断対象の稼働データを適用するモデルである。いま、ある運転状態において、正常であることが既知である機器が、60分間運転を継続した結果、3つのセンサが1分周期で稼働データを学習用データとして取得したとする。すると、3次元の稼働データが時系列で60個取得されることになる。なお、稼働データが、その役割に応じて、学習用データになり、又は、診断対象にもなる。

60個の稼働データのそれぞれを示す点を、3次元の座標空間にドットすると、60個の点は座標空間のある領域に集中する。すると、60個の点を包絡する球の中心の座標値と及び半径を定義することができる。この中心の座標値及び半径が、統計モデルのパラメータに該当する。つまり、診断対象である稼働データを示す点と球の中心との間の距離が球の半径以下であれば、機器は正常であると診断される。

物理モデルとは、機器の設計条件、又は、運動方程式、エネルギ保存の法則等の自然法則から物理的に導出される上限又は下限の閾値に対して診断対象の稼働データを適用するモデルである。以下の式1は、車両の制動系を診断する物理モデルの例であり、1本の等式及び2本の条件式から構成される。式1は、入力変数としてvを有し、出力変数としてLを有し、パラメータとしてμ、θ及びThを有している。

L=v²/2g(μcosθ−sinθ) “L≦Th”である場合、“制動系は正常”である。 “L>Th”である場合、“制動系は異常”である。 (式1)

Lは、制動を開始してから車両が停止するまでに車両が走行した距離である。vは、制動を開始した時点の車両の速度である。gは、重力加速度(定数)である。μは、路面と車両のタイヤとの摩擦係数である。μは降水量によって大きく変化する。θは、道路勾配(傾斜角)である。Thは、Lに対して適用される閾値である。Thはμ及びθによって変化する。

μが一定である場合、道路勾配θが0から徐々に大きくなるにつれて、“μcosθ−sinθ”の値は徐々に小さくなる。すると、Lは徐々に大きくなる。θが一定である場合、摩擦係数μが徐々に大きくなるにつれて、“μcosθ−sinθ”の値は徐々に大きくなる。すると、Lは徐々に小さくなる。

物理モデルが、論理的に正常/異常を判断するのに対して、統計モデルは経験的に正常/異常を判断するといえる。ある運転環境においてある機器から取得された稼働データを、物理モデルと統計モデルの両者が診断するとする。このとき、物理モデルが“異常”と診断する一方で、統計モデルが“正常”と診断することもあり得る。逆もまたあり得る。

両者の診断結果が背反する場合、どちらの診断結果をより重視するべきであるかは、一概には言えない。しかしながら、本実施形態では、統計モデルの診断結果をより重視する。なぜならば、学習用データを蓄積する際に機器が正常であるか否かを判断するのは、現場にいる人間であり、機器を直接観察している人間の判断を重視したいからである。さらに、学習用データが蓄積されるほど、統計モデルの信頼性が高まるからである。ただし、充実した学習用データが取得されない場合、統計モデルの信頼性は低い。

なお、知識モデルは、運用保守経験及びノウハウに基づいて生成され、故障の発生原因及びその対策を、原因と結果の因果関係としてパターン化する。知識モデルの例として、FMEA(Failure Mode Effects Analysis)及びFTA(Failure Tree Analysis)が存在する。統計モデルと同様に、知識モデルもまた、知識を得るまでには膨大な経験(実データ)を必要とする。そこで、本実施形態においては、知識モデルを統計モデルに類するものとして扱う。

物理モデルについては、どのような場合であっても一応の診断結果を取得できるという点で、統計モデルより有意である場合もある。結局、統計モデルを優先的に使用し、学習を重ねることによって進化させつつも、機器の仕様変更等の特殊事情に起因して統計モデルが使用できない場合は、一時的に物理モデルを使用することが肝要である。

図1に沿って、運転環境を説明する。ある日の15時00分から20時00分までの期間、車両5(図6も参照)が走行している。15時00分から16時00分までの期間、道路勾配は±0度(平坦)であり、交通量(道路の車線当たり通行量)は、30台/分であった。また、気温は30℃であり、湿度は20%であった。なお、これらの値は、その1時間の平均値である。これらの数値は、機器診断装置が車両5から、又は、官公庁等の外部サーバから取得したものである。なお、当該期間は、15時00分を含み16時00分を含まないものとする(以下同様)。

ここでの道路勾配52、交通量53、気温54及び湿度55のそれぞれは、運転環境である。もちろん運転環境は、これら以外にも多くの例があり得る。これらの運転環境の値の組合せに対して、運転環境ID51が付与される。例えば、道路勾配“±0度”、交通量“30台/分”、気温“30℃”及び湿度“20%”の組合せに対して運転環境ID“RC01”が付与される。車両5が走行するにつれて、運転環境のそれぞれは独立的に変化する。図1では、1時間ごとに運転環境のそれぞれが変化している。すると、それぞれの時間帯における運転環境の値の組合せに対して、別の運転環境IDが付与される。

当然のことながら、実際には運転環境のそれぞれは、時々刻々と変化している。例えば、気温の値“30℃”(前記した平均値)が異なる期間において全く同じであるということは、通常あり得ない。したがって、ここでの値の組合せは、例えば30℃を中心に±2.5℃というような、範囲の組合せを省略的に表している。そして、以降では、“運転環境の値の組合せ”又は“運転環境の範囲の組合せ”を単に“運転環境”と呼ぶ。

図2に沿って、統計モデルの生成を説明する。機器診断装置は、車両5の例えば冷却装置を診断する。そのために、機器診断装置は、車両5のセンサから、学習用データとして、ファン回転速度(稼働データ1)、冷却液温度(稼働データ2)及び冷却液流量(稼働データ3)を取得する。なお、図2において、15時00分から20時00分までの期間、車両5の冷却装置が正常であることが既知であるとする。そして、機器診断装置は、20分ごとに稼働データを取得するものとする。

15時00分から16時00分までの期間、学習用データとして3次元の稼働データが3回取得される。機器診断装置は、ファン回転速度、冷却液温度及び冷却液流量を座標軸とする座標空間内に、3つの稼働データを示す点●を3つプロットする。そして、機器診断装置は、その3つの●を包絡する空間(本実施形態では、その空間の形状が球であるとして説明する)として球56aを生成する。この球は、複数の●をその内部又は表面に含む球のうち最も半径が小さいものである。

16時00分から17時00分までの期間についても、学習用データとして3次元の稼働データが3回取得される。そこで、機器診断装置は、前記したように球56bを生成する。機器診断装置は、その後の時間帯についても、同じ処理を繰り返す。すると、座標空間内に、5つの球56a、56b、56c、56d及び56eが生成される。2つ以上の球が同じ領域を共有する(一部が重なる)場合もある。しかしながら、ここでは、説明の単純化のために、球は、相互に重なることがないものとする。

18時00分から19時00分までの期間の運転環境“RC04”において、車両5は、気温が相対的に低い中で下り坂を走行している。したがって、冷却装置に対する負担も比較的小さい。このことは、当該時間帯に取得された稼働データによって生成(学習)された球56dが、座標空間の原点に比較的近い位置にあることに対応している。逆に、16時00分から17時00分までの期間の運転環境“RC02”において、車両5は、気温が相対的に高い中で登り坂を走行している。したがって、冷却装置に対する負担も比較的大きい。このことは、当該時間帯に取得された稼働データによって生成された球56bが、座標空間の原点から比較的遠い位置にあることに対応している。

このようにして、5つの運転環境のそれぞれについて1つの球が生成される。5つの球が座標空間内に散らばっていることは、同じ“正常”を示す稼働データであっても、そのセンサ値は、運転環境に応じて様々であることを意味している。

図3に沿って、統計モデルの使用を説明する。11月1日15時00から20時00分までの期間、車両5が走行し、その結果、機器診断装置は、座標空間内に5つの球を生成した。ここまでは、図2と同じである。11月2日15時00から20時00分までの期間、車両5は、前日と全く同じ行程を走行した。そして、この時間帯の1時間ごとの運転環境は、偶然にも前日と全く同じように、RC01→RC02→RC03→RC04→RC05と推移したとする。なお、図3において、11月2日15時00分から20時00分までの期間、車両5の冷却装置が正常であるか異常であるかは既知ではなく、それ故に、この時間帯において冷却装置が正常であるか否かを診断する必要があるとする。

11月2日15時00分、機器診断装置は、車両5のセンサから、診断対象としての稼働データを取得した。この稼働データは、図2と同じ3次元の稼働データである。機器診断装置は、この稼働データを示す点☆57aを座標空間内にプロットする。そして、機器診断装置は、☆57aと球56aの代表点(本実施形態では、中心を代表点とする)である中心との距離を算出し、さらに、算出した距離を球56aの半径(半径は、空間56aの大きさを示す代表値の一例である)と比較する。距離が空間56aの代表値以下、すなわち球56aの半径以下である場合、機器診断装置は、“11月2日15時00分、冷却装置は正常である”と診断する。距離が半径より大きい場合、機器診断装置は、“11月2日15時00分、冷却装置は異常である”と診断する。

ここで機器診断装置が、球56aを比較の基準とした理由は以下の通りである。 ・11月2日15時00分における運転環境は“RC01”である。 ・11月1日、運転環境“RC01”の稼働データが生成した球は、球56aである。

機器診断装置は、11月2日16時00分に取得した稼働データを示す☆57bと球56bの中心との間の距離が球56bの半径以下であるか否かを判断する。そして機器診断装置は、その判断の結果に応じて、“11月2日16時00分、冷却装置は正常である”又は“11月2日16時00分、冷却装置は異常である”と診断する。それ以降の時間帯についても同様である。なお、図3では、☆57cと球56cが、☆57dと球56dが、☆57eと球56eが、比較対象として対応している。

図4に沿って、統計モデルの使用を別の例で説明する。11月1日15時00から20時00分までの期間、車両5が走行し、その結果、機器診断装置は、座標空間内に5つの球を生成した。ここまでは、図2及び図3と同じである。11月2日15時00から20時00分までの期間、車両5は、前日とは異なる行程を走行した。そして、この時間帯の1時間ごとの運転環境は、当然前日とは異なり、RC02→RC01→RC03→RC05→RC04のように推移したとする。

11月2日15時00分、機器診断装置は、車両5のセンサから、診断対象としての稼働データを取得した。この稼働データは、図2及び図3と同じ3次元の稼働データである。機器診断装置は、この稼働データを示す点☆57aを座標空間内にプロットする。図4の☆57aの位置は、図3の☆57aの位置とは異なる。そして、機器診断装置は、☆57aと球56bの中心との距離を算出し、さらに、算出した距離を球56bの半径と比較する。距離が半径以下である場合、機器診断装置は、“11月2日15時00分、冷却装置は正常である”と診断する。距離が半径より大きい場合、機器診断装置は、“11月2日15時00分、冷却装置は異常である”と診断する。

ここで機器診断装置が球56bを比較の基準と理由は、以下通りである。 ・11月2日15時00分における運転環境は“RC02”である。 ・11月1日、運転環境“RC02”の稼働データが生成した球は、球56bである。

機器診断装置は、11月2日16時00分に取得した稼働データを示す☆57bと球56aの中心との間の距離が球56aの半径以下であるか否かを判断する。そして機器診断装置は、その判断の結果に応じて、“11月2日16時00分、冷却装置は正常である”又は“11月2日16時00分、冷却装置は異常である”と診断する。それ以降の時間帯についても同様である。なお、図4では、☆57cと球56cが、☆57dと球56eが、☆57eと球56dが、比較対象として対応している。

図5に沿って、物理モデルの使用を説明する。ここでの物理モデルは、以下の特徴を有している。 ・物理モデルは、ファン回転速度、冷却液温度及び冷却液流量を入力変数とする。 ・物理モデルは、冷却能力を出力変数とする。 ・物理モデルは、入力変数及び出力変数以外にパラメータを有する。 ・物理モデルは、冷却能力に対して、閾値(上限及び下限)を適用する。 ・パラメータの値及び閾値の値は、運転環境に応じて変化する。

物理モデルについては、学習データを使用して物理モデルを生成(学習)すると言う考え方が存在しない。つまり、物理モデルは、図3及び図4で説明したように、まず11月1日の学習データを使用して診断モデルを生成し、その結果を、後日活用するというある意味迂遠な処理を要しない。図5において、11月1日15時00分から20時00分までの期間、車両5の冷却装置が正常であるか異常であるかは既知ではなく、それ故に、この時間帯において冷却装置が正常であるか否かを診断する必要があるとする。このとき、物理モデルはリアルタイムで、冷却装置を診断する。

図5においても、図3及び図4と同様に、11月1日15時00分から20時00分までの期間において、車両5が走行している。運転環境も、図3及び図4と同様に、RC01→RC02→RC03→RC04→RC05と推移している。11月1日15時00分、機器診断装置は、車両5のセンサから、診断対象としての稼働データを取得した。この稼働データは、図2と同じ3次元の稼働データである。

すると、機器診断装置は、まず、運転環境“RC01”に応じて、物理モデル58のパラメータの値を設定したうえで、物理モデル58に、11月1日15時00分における稼働データ59a、59b及び59cを入力する。機器診断装置は、続いて、物理モデル58が出力した冷却能力59dが、運転環境“RC01”に応じた閾値(上限及び下限)の範囲60b内にあるか否かを判断する。

冷却能力59dが、閾値の範囲60b内にある場合、機器診断装置は、“11月1日15時00分、冷却装置は正常である”と診断する。冷却能力59dが、閾値の範囲60b内にない場合、機器診断装置は、“11月1日15時00分、冷却装置は異常である”と診断する。

図5の物理モデル58内には、冷却能力(横軸)の閾値の範囲60a、60b、60c、60d及び60eが設定されている。そしてこれらの横軸上の位置(上限及び下限)は、それぞれ、運転環境RC04、RC01、RC03、RC05及びRC02に対応している。なお、これらの閾値の範囲は、互いに重複していてもよい。図5では、分かり易さのために、閾値の範囲が重複しない例を記載している。因みに、図5では、冷却装置に対する負担が最も大きいと思われる運転環境RC02に、横軸の値が最も大きい閾値の範囲60eが対応している。冷却装置に対する負担が最も小さいと思われる運転環境RC04に、横軸の値が最も小さい閾値の範囲60aが対応している。

11月1日16時00分においても、機器診断装置は、同様の処理を行う。ただし、このとき機器診断装置は、物理モデル58が出力した冷却能力59dが、運転環境“RC02”に応じた閾値の範囲60e内にあるか否かを判断する。11月1日17時00分(18時00分、19時00分)においても、機器診断装置は、同様の処理を行う。

(機器診断装置の構成) 図6に沿って、機器診断装置1の構成を説明する。機器診断装置1は、一般的なコンピュータである。機器診断装置1は、中央制御装置11、入力装置12、出力装置13、主記憶装置14、補助記憶装置15、及び、通信装置16を備える。これらはバスで接続されている。補助記憶装置15は、稼働・環境情報31、診断モデル割当情報32、診断結果情報33、診断モデル34及び地図情報35を格納している。主記憶装置14における稼働データ取得部21、運転環境識別部22、診断モデル生成部23、診断モデル選択部24、診断部25、及び、成熟度判定部26は、プログラムである。以降の説明において、“○○部は”と動作主体を記した場合、それは、中央制御装置11が補助記憶装置15から○○部を読み出し、主記憶装置14にロードしたうえで○○部の機能(詳細後記)を実現することを意味する。

機器診断装置1は、ネットワーク6を介して、外部サーバ4及び稼働データ収集サーバ3と通信可能である。外部サーバ4は、官公庁等によって運営されるサーバである。外部サーバ4は、天候及び道路属性を位置情報に関連付けて記憶している。車両5は、端末装置2を搭載している。端末装置2は、車両5の各センサからセンサ値を収集し、GPS(Global Positioning System)衛星から電波を受信し、自身の位置情報(緯度及び経度)を算出することができる。稼働データ収集サーバ3は、無線技術を使用して端末装置2と通信可能である。以上から明らかなように、機器診断装置1は、ネットワーク6及び稼働データ収集サーバ3を介して車両5の稼働データ及び位置情報を取得することができる。さらに、機器診断装置1は、ネットワーク6及び稼働データ収集サーバ3を介して車両5の運転環境を取得することができる。機器診断装置1は、車両5の位置情報に基づいて、ネットワーク6を介して外部サーバ4から、車両5の運転環境を取得することもできる。

(稼働・環境情報) 図7に沿って、稼働・環境情報31を説明する。稼働・環境情報31においては、車両ID欄101に記憶された車両IDに関連付けて、位置欄102には位置が、時点欄103には時点が、稼働データ欄104には稼働データが、運転環境欄105には運転環境が記憶されている。 車両ID欄101の車両IDは、車両5を一意に特定する識別子である。 位置欄102の位置は、その時点における車両5の位置情報(経度及び緯度)である。 時点欄103の時点は、稼働データがセンサによって取得された時点の年月日時分秒である。

稼働データ欄104の稼働データは、前記した稼働データである。ここでの稼働データは、冷却液温度(欄104a)、冷却液流量(欄104b)及びファン回転速度(欄104c)の3種類であるが、機器の種類に応じて、稼働データの種類も変化する。 運転環境欄105の運転環境は、当該位置における当該時点の運転環境である。ここでの運転環境は、道路勾配(欄105a)、交通量(欄105b)、気温(欄105c)及び湿度(欄105d)の4種類であるが、他の種類であってもよい。例えば、交通量を所定区間の旅行時間、移動速度、渋滞度等の交通情報で代用しても構わない。また、運転環境として、道路形状(直線道路/カーブ道路、カーブ曲率等)、道路種別(高速道路/一般道路等)、道路属性(交差点、トンネル、橋上、勾配、踏切、道幅、車線数等)、道路付帯情報(信号機、横断歩道や停止線位置)等を用いることもある。

(診断モデル割当情報) 図8に沿って、診断モデル割当情報32を説明する。診断モデル割当情報32においては、運転環境ID欄111に記憶された運転環境IDに関連付けて、運転環境欄112には運転環境の範囲が、統計モデルID欄113には統計モデルIDが、物理モデルID欄114には物理モデルIDが、推奨モデルID欄115には推奨モデルIDが記憶されている。

運転環境ID欄111の運転環境IDは、前記した運転環境(運転環境の範囲の組合せ)を一意に特定する識別子である。 運転環境欄112の運転環境の範囲は、個々の運転環境が取り得る範囲を任意の数に分割した場合のそれぞれの区分である。例えば、道路勾配(欄112a)を“0”を境目として2つの区分に分けると、道路勾配の区分は、“正(登り)”と“負(下り)”の2つとなる。なお、平坦な道路を示す“±0”は、“負(下り)”に含まれるものとする。

交通量(欄112b)は、“10”を境目として“10未満”及び“10以上”の2つの区分に分かれている。同様に、気温(欄112c)は、“20未満”及び“20以上”の2つの区分に分かれ、湿度(欄112d)は、“60未満”及び“60以上”の2つの区分に分かれている。

統計モデルID欄113の統計モデルIDは、統計モデルを一意に特定する識別子である。例えば図2の球56a、・・・、56eのそれぞれが統計モデルに相当する。ここでの統計モデルIDは、その運転環境において取得された稼働データ(学習用データ)を使用して生成された統計モデルを特定している。当該欄に“なし(未学習)”が記憶されている場合、それは、機器が更新され充分な学習用データが得られていないこと等により、その運転環境についての統計モデルが未だ準備されていないことを意味する。

物理モデルID欄114の物理モデルIDは、物理モデルを一意に特定する識別子である。物理モデルは、すべての運転環境について準備される。その代わりに、物理モデルの種類は、統計モデルに比して少なく、図8においては、下り坂用の“MM01”及び登り坂用の“MM02”の2種類である。 推奨モデルID欄115の推奨モデルIDは、その運転環境において機器の診断のために使用することが推奨される診断モデルを一意に特定する識別子である。本実施形態では、統計モデル及び物理モデルの両者が準備されているレコード(行)の当該欄には、その統計モデルを特定する推奨モデルIDが記憶される。物理モデルのみが準備されているレコード(行)の当該欄には、その物理モデルを特定する推奨モデルIDが記憶される。

(診断結果情報) 図9に沿って、診断結果情報33を説明する。診断結果情報33においては、車両ID欄121に記憶された車両IDに関連付けて、位置欄122には位置が、時点欄123には時点が、稼働データ欄124には稼働データが、運転環境ID欄125には運転環境IDが、使用診断モデルID欄126には使用診断モデルIDが、モデル診断結果欄127にはモデル診断結果が、保守員診断結果欄128には保守員診断結果が、モデル評価欄129には評価フラグが記憶されている。

車両ID欄121の車両IDは、図7の車両IDと同じである。 位置欄122の位置は、図7の位置と同じである。 時点欄123の時点は、図7の時点と同じである。しかしながら、図7の時点が、学習データとして稼働データがセンサによって取得された時点である一方、図8の時点は、診断対象として稼働データがセンサによって取得された時点である。 稼働データ欄124の稼働データは、図7の稼働データと同じである。ただし、ここでの稼働データは、学習用データではなく、診断対象の稼働データである。なお、“(#,#,#)”は、レコードごとに値が変化する3次元の稼働データを省略的に示している。 運転環境ID欄125の運転環境IDは、図8の運転環境IDと同じである。

使用診断モデルID欄126の使用診断モデルIDは、診断のために実際に使用された診断モデルを特定する識別子である。通常、運転環境が同じであれば、使用診断モデルID(図9)は、推奨モデルID(図8)に等しい。 モデル診断結果欄127のモデル診断結果は、使用診断モデルIDが特定する診断モデルによる診断結果(正常/異常)である。 保守員診断結果欄128の保守員診断結果は、診断モデルが診断結果を下した後、その診断結果とは別に、保守員が実際に機器を観察したうえで下した診断結果(正常/異常)である。モデル診断結果が“正常”であっても、保守員診断結果が“異常”である場合もあり得る。また、その逆もあり得る。

モデル評価欄129の評価フラグは、“○”又は“×”の何れかである。“○”は、モデル診断結果が保守員診断結果と一致していることを示す。“×”は、モデル診断結果が保守員診断結果と一致していないことを示す。

図10〜図12に沿って、処理手順を説明する。処理手順には、統計モデル生成処理手順、物理モデル生成処理手順、診断モデル選択処理手順、診断処理手順、成熟度判定処理手順、及び、端末・センタ協調処理手順の6つが存在する。

(統計モデル生成処理手順) 図10(a)に沿って、統計モデル生成処理手順を説明する。統計モデル生成処理手順を開始する前提として、いま車両5が走行中であり、端末装置2は、車両5の稼働データ(学習用データ)及び位置情報をリアルタイムで機器診断装置1に送信しているものとする。 ステップS201において、機器診断装置1の稼働データ取得部21は、対象機器を受け付ける。具体的には、稼働データ取得部21は、機器診断装置1のユーザが、車両5が有する機器のうち、診断対象となる機器を入力装置12を介して入力するのを受け付ける。ここでの診断対象は、例えば、“制動系”、“エンジン系”、“操舵系”、“冷却系”等である。いま、“冷却系”が入力されたとする。

ステップS202において、稼働データ取得部21は、稼働データを読込む。具体的には、稼働データ取得部21は、機器診断装置1が受信する稼働データのうち、冷却装置に関するもの(冷却液温度、冷却液流量及びファン回転速度)を取得し、稼働・環境情報31(図7)のうち車両ID欄101〜稼働データ欄104の部分を作成する。

ステップS203において、機器診断装置1の運転環境識別部22は、地図情報35を読込む。具体的には、第1に、運転環境識別部22は、車両5の位置情報を検索キーとして、地図情報35を参照し、車両5の位置における道路勾配を取得する。 第2に、運転環境識別部22は、車両5の位置情報を検索キーとして、外部サーバ4を参照し、その時点における車両5の位置の交通量、気温及び湿度を取得する。 第3に、運転環境識別部22は、ステップS203の“第1”及び“第2”において取得した情報を使用して、稼働・環境情報31(図7)のうち、運転環境欄105の部分を作成する。

ステップS204において、運転環境識別部22は、運転環境を識別する。具体的には、運転環境識別部22は、ステップS203の“第1”及び“第2”において取得した、道路勾配、交通量、気温及び湿度の組合せを、診断モデル割当情報32(図8)の運転環境欄112に当てはめ、対応する運転環境IDを取得する。なお、補助記憶装置15は、診断モデル割当情報32のうち、運転環境ID欄111及び運転環境欄112の部分を事前に記憶しているものとする。

稼働データ取得部21及び運転環境識別部22は、ステップS202〜S204の処理を、稼働データが取得される都度繰り返す。このような処理を繰り返しながら例えば数時間が経過すると、稼働データ取得部21は、運転環境IDに関連付けて多数の稼働データ(冷却液温度、冷却液流量及びファン回転速度の3次元)を主記憶装置14に一時的に記憶していることになる。

ステップS205において、機器診断装置1の診断モデル生成部23は、統計モデルを生成する。具体的には、診断モデル生成部23は、図2で説明したように、学習用データとしての稼働データを座標平面にプロットし、球の中心の位置座標及び半径を求める。

ステップS206において、診断モデル生成部23は、統計モデルを記憶する。具体的には、第1に、診断モデル生成部23は、統計モデルIDを採番し、採番した統計モデルIDを、ステップS205において求めた中心の位置座標及び半径と関連付けて、診断モデル34(図6)として、補助記憶装置15に記憶する。 第2に、診断モデル生成部23は、診断モデル割当情報32(図8)の統計モデルID欄113に、統計モデルIDを記憶する。

診断モデル生成部23は、ステップS205及びS206の処理を、運転環境IDごとに繰り返す。その後、統計モデル生成処理手順は終了する。充分長い期間に渡って統計モデル生成処理手順が継続されると、運転環境のほぼすべての組合せについて、統計モデルIDが取得されることになる。つまり、診断モデル割当情報32において、統計モデルID欄113が“なし(未学習)”であるレコードはなくなることになる。 前記においては、予め運転環境の組合せを定義し、その組合せごと(類似している稼働データの集合ごと)に座標空間内に球を生成した。つまり、球の数は予めわかっていた(この例では16個)。しかしながら、診断モデル生成部23は、予め球の数を決めることなく、公知のk−means法等を活用し任意の数の球を生成してもよい。統計モデル生成処理手順は、対象機器ごとに繰り返される。

(物理モデル生成処理手順) 図10(b)に沿って、物理モデル生成処理手順を説明する。物理モデル生成処理手順を開始する前提として、いま車両5が走行中であり、端末装置2は、車両5の稼働データ及び位置情報をリアルタイムで機器診断装置1に送信しているものとする。 ステップS211において、機器診断装置1の稼働データ取得部21は、対象機器を受け付ける。当該ステップの内容は、ユーザが“冷却系”を入力したことも含めて、ステップS201と同じである。

ステップS212において、機器診断装置1の運転環境識別部22は、地図情報を読込む。具体的には、第1に、運転環境識別部22は、車両5の位置情報を検索キーとして、地図情報35を参照し、車両5の位置における道路情報(道路形状、道路属性、道路種別、道路付帯情報等)、本実施形態では道路勾配を取得する。 第2に、運転環境識別部22は、車両5の位置情報を検索キーとして、外部サーバ4を参照し、その時点における車両5の位置の交通量、気温及び湿度を取得する。

ステップS213において、運転環境識別部22は、運転環境を識別する。具体的には、運転環境識別部22は、ステップS212の“第1”及び“第2”において取得した、道路勾配、交通量、気温及び湿度の組合せを、診断モデル割当情報32(図8)の運転環境欄112に当てはめ、対応する運転環境IDを取得する。

ステップS214において、機器診断装置1の診断モデル生成部23は、物理式を読込む。ここでの物理式とは、例えば前記した式1のような数式の集合であり、補助記憶装置15は、診断対象の機器ごとに、このような物理式(この段階ではパラメータの値は未定)を記憶しているものとする。具体的には、診断モデル生成部23は、診断対象の機器に対応する物理式を取得する。

ステップS215において、診断モデル生成部23は、物理モデルを生成する。具体的には、第1に、診断モデル生成部23は、ユーザが、ステップS213において取得された運転環境IDが特定する運転環境に相応しい物理モデルのパラメータの値を入力装置12を介して入力するのを受け付ける。ここで、診断モデル生成部23は、ユーザが手動で入力するまでもなく、当該運転環境に相応しいパラメータの値を算出してもよい。 第2に、診断モデル生成部23は、ステップS214において取得した物理式のパラメータに、ステップS215の“第1”において受け付けたパラメータの値を代入する。

ステップS216において、診断モデル生成部23は、物理モデルを記憶する。具体的には、第1に、診断モデル生成部23は、物理モデルIDを採番し、採番した物理モデルIDを、ステップS215の“第2”においてパラメータの値が代入された物理式と関連付けて、診断モデル34(図6)として、補助記憶装置15に記憶する。 第2に、診断モデル生成部23は、診断モデル割当情報32(図8)の物理モデルID欄114に、物理モデルIDを記憶する。その後、物理モデル生成処理手順は終了する。

パラメータの値として特定の値が入力された物理式が“物理モデル”となり、その1つ1つに対して、物理モデルIDが付与(採番)される。物理モデルは、統計モデルと異なり、必ずしも運転環境IDごとに固有のものが生成されなくてもよい。なぜならば、もともと、物理モデルは統計モデルの一時的な欠落を補うものであるからである。

通常、診断対象の機器ごとに、1つの物理式が準備されている。運転環境が少しでも変化する都度、パラメータの値を細かく変化させる必要はない。本実施形態において診断モデル生成部23は、同じ1つの物理式に対して、道路勾配の正負に応じてパラメータの値を変化させている。図8の物理モデルID欄114の“MM01”及び“MM02”は、このことを示している。物理モデル生成処理手順は、対象機器ごとに繰り返される。

(診断モデル選択処理手順) 図11(a)に沿って、診断モデル選択処理手順を説明する。診断モデル選択処理手順を開始する前提として、補助記憶装置15において、診断モデル割当情報32(図8)が、推奨モデルID欄115のみが空欄である状態で記憶されているものとする。そして、診断モデル割当情報32の統計モデルID欄113又は物理モデルID欄114に変化が生じたことを契機として診断モデル選択処理手順は開始される。

ステップS221において、機器診断装置1の診断モデル選択部24は、対象機器を受け付ける。当該ステップの内容は、ステップS201と同じである。 ステップS222において、診断モデル選択部24は、診断モデル割当情報32(図8)のレコードを取得する。具体的には、診断モデル選択部24は、診断モデル割当情報32のレコード(行)のうち、未処理のものを1本取得する。ここで取得されたレコードを、以降“対象レコード”とも呼ぶ。

ステップS223において、診断モデル選択部24は、統計モデルが存在するか否かを判断する。具体的には、診断モデル選択部24は、対象レコードの統計モデルID欄113に“なし(未学習)”が記憶されている場合(ステップS223“No”)、ステップS225に進む。診断モデル選択部24は、対象レコードの統計モデルID欄113に“SM”を冠する統計モデルIDが記憶されている場合(ステップS223“Yes”)、ステップS224に進む。

ステップS223の変形例として、診断モデル選択部24は、対象レコードの運転環境の道路状況が所定の条件に当てはまる場合、ステップS224に進み、それ以外の場合、ステップS225に進んでもよい。所定の条件とは、例えば、交通量が所定の閾値以上である、車線数が所定の数以上である等である。

ステップS224において、診断モデル選択部24は、統計モデルを選択する。具体的には、診断モデル選択部24は、対象レコードの推奨モデルID欄115に、対象レコードの統計モデルIDを記憶する。 ステップS225において、診断モデル選択部24は、物理モデルを選択する。具体的には、診断モデル選択部24は、対象レコードの推奨モデルID欄115に、対象レコードの物理モデルIDを記憶する。その後、診断モデル選択処理手順は終了する。診断モデル選択処理手順は、対象機器ごとに繰り返される。

(診断処理手順) 図11(b)に沿って、診断処理手順を説明する。診断処理手順を開始する前提として、いま車両5が走行中であり、端末装置2は、車両5の診断対象としての稼働データ及び位置情報をリアルタイムで機器診断装置1に送信しているものとする。そして、新たな稼働データが送信されることを契機として、診断処理手順は開始される。 ステップS231において、機器診断装置1の稼働データ取得部21は、対象機器を受け付ける。当該ステップの内容は、ユーザが“冷却系”を入力したことも含めて、ステップS201と同じである。

ステップS232において、稼働データ取得部21は、稼働データを読込む。具体的には、第1に、稼働データ取得部21は、機器診断装置1が受信する稼働データのうち、冷却系に関するもの(冷却液温度、冷却液流量及びファン回転速度)を取得する。 第2に、稼働データ取得部21は、診断結果情報33(図9)の新たなレコードを作成し、新たなレコードの車両ID欄121〜稼働データ欄124の部分の値を記憶する。ここで作成されたレコードを、以降“診断結果レコード”とも呼ぶ。

ステップS233において、機器診断装置1の運転環境識別部22は、運転環境を識別する。具体的には、第1に、運転環境識別部22は、車両5の位置情報を検索キーとして、地図情報35を参照し、車両5の位置における道路情報(道路形状、道路属性、道路種別、道路付帯情報等)、本実施形態では道路勾配を取得する。 第2に、運転環境識別部22は、車両5の位置情報を検索キーとして、外部サーバ4を参照し、その時点における車両5の位置の交通量、気温及び湿度を取得する。

第3に、運転環境識別部22は、ステップS233の“第1”及び“第2”において取得した情報に基づいて、診断モデル割当情報32(図8)の運転環境欄112を参照し、該当するレコードの運転環境IDを取得する。 第4に、運転環境識別部22は、診断結果レコードの運転環境ID欄125に、ステップS233の“第3”において取得した運転環境IDを記憶する。

ステップS234において、機器診断装置1の診断モデル選択部24は、診断モデルを読込む。具体的には、第1に、診断モデル選択部24は、ステップS233の“第3”において取得した運転環境IDを検索キーとして診断モデル割当情報32を参照し、該当したレコードの推奨モデルIDを取得する。 第2に、診断モデル選択部24は、診断結果レコードの使用診断モデルID欄126に、ステップS234の“第1”において取得した推奨モデルIDを記憶する。

ステップS235において、機器診断装置1の診断部25は、診断を行う。具体的には、診断部25は、使用診断モデル(ステップS234の“第2”において、使用診断モデル欄126に記憶したモデル)を使用して、診断対象の稼働データを診断する。使用診断モデルが統計モデルである場合、図3及び図4で説明したように、診断結果として“正常”又は“異常”の何れかを決定する。使用診断モデルが物理モデルである場合、図5で説明したように、診断結果として“正常”又は“異常”の何れかを決定する。 ステップS236において、診断部25は、診断結果が正常であるか否かを判断する。具体的には、診断部25は、診断結果が“正常”である場合(ステップS236“Yes”)、ステップS238に進み、診断結果が“異常”である場合(ステップS236“No”)、ステップS237に進む。

ステップS237において、診断部25は、異常を報知する。具体的には、診断部25は、異常メッセージを車両5の端末装置2に送信する、又は、出力装置13に表示する。異常メッセージは、例えば“冷却装置が異常である”である。端末装置2が異常メッセージを受信した場合、端末装置2は、自身の出力装置に異常メッセージを表示する。 ステップS238において、診断部25は、診断結果を記憶する。具体的には、診断部25は、診断結果レコードのモデル診断結果欄127に、診断結果として“正常”又は“異常”の何れかを記憶する。その後、診断処理手順は終了する。なお、診断処理手順が終了した段階で、診断結果情報33の保守員診断結果欄128及びモデル評価欄129は、空欄のままである。診断処理手順は、対象機器ごとに繰り返される。

(成熟度判定処理手順) 図12(a)に沿って、成熟度判定処理を説明する。成熟度判定処理を開始する前提として、補助記憶装置15において、診断結果情報33(図9)が、保守員診断結果欄128及びモデル評価欄129のみが空欄である状態で記憶されているものとする。そして、任意のタイミングで、成熟度判定処理手順は開始される。

ステップS241において、機器診断装置1の成熟度判定部26は、保守記録を読込む。保守記録とは、保守員が実際に機器を観察したうえで下した診断結果である。保守記録は、車両ID及び時点に関連付けて、診断結果としての“正常”又は“異常”を記憶している。具体的には、第1に、成熟度判定部26は、診断結果情報33(図9)のレコードのうち未処理であるものを1本取得する。ここで取得されたレコードを、以降“評価レコード”とも呼ぶ。

第2に、成熟度判定部26は、評価レコードの車両ID及び時点を検索キーとして保守記録を参照し、対応する診断結果を取得する。 第3に、成熟度判定部26は、評価レコードの保守員診断結果欄128に、ステップS241の“第2”において取得した診断結果を記憶する。

ステップS242において、成熟度判定部26は、診断結果を比較する。具体的には、第1に、成熟度判定部26は、評価レコードのモデル診断結果及び保守員診断結果を比較する。 第2に、成熟度判定部26は、比較の結果両者が一致する場合、評価レコードのモデル評価欄129に評価フラグ“○”を記憶し、比較の結果両者が一致しない場合、評価レコードのモデル評価欄129に評価フラグ“×”を記憶する。 成熟度判定部26は、ステップS241及びS242の処理を未処理の評価レコードごとに繰り返す。

ステップS243において、成熟度判定部26は、正解率を算出する。具体的には、成熟度判定部26は、使用診断モデルIDごとに以下の正解率を算出する。 正解率=評価フラグが“○”であるレコードの数/ある使用診断モデルIDを有するレコードの数×100(%) ステップS244において、成熟度判定部26は、成熟度を判定する。成熟度は、診断モデルの正解率に応じて診断モデルごとに定義される評価値であり、正解率が大きいほど成熟度も高くなる。その後、成熟度判定処理手順は終了する。

(成熟度の活用方法) ある運転環境における統計モデルの成熟度が所定の閾値より小さく、かつ、当該運転環境における物理モデルの成熟度よりも小さい場合もある。この場合、診断モデル選択部24は、ステップS223“No”を経由してもよい。さらにこの場合、診断モデル生成部23は、成熟度が小さい統計モデルの球の半径を小さくしてもよい。

前記では、冷却装置を診断する場合の統計モデルは、入力変数として、冷却液温度、冷却液流量、及び、ファン回転速度を有していた。しかしながら、同じ冷却装置を診断する統計モデルの入力変数の全部又は一部が異なる変数(例えば、エンジン回転速度、冷却液濃度等)であってもよい。すると、ある1つの運転環境に対して複数の統計モデルが使用され得ることになる。そのうえで、ステップS224において、診断モデル選択部24は、対象レコードの推奨モデルID欄115に、同じ運転環境についての複数の統計モデルのうち、最も成熟度が大きいものを特定する統計モデルIDを記憶してもよい。

さらに、診断モデル選択部24は、対象レコードの推奨モデルID欄115に、同じ運転環境についての統計モデルのうち、成熟度が所定の閾値より大きい複数の統計モデルを特定する複数の統計モデルIDを記憶してもよい。この場合、診断部25は、複数の統計モデルごとに、ある稼働データに対する診断結果を決定することになる。診断部25は、複数の診断結果の論理積に基づき、診断結果を下してもよい。つまり、すべての診断結果が“正常”であれば“正常”と診断し、すべての診断結果が“異常”であれば“異常”と診断し、それ以外の場合は“診断不能”と診断してもよい。

(端末・センタ協調処理手順) 図12(b)に沿って、端末・センタ協調処理手順を説明する。前記では、稼働データを診断するのは、機器診断装置1であった。しかしながら、車両5に搭載された端末装置2が機器診断装置1の役割を果たしてもよい。さらに、診断対象である同じ稼働データに対して、端末装置2は概略の診断を行い、機器診断装置1は詳細の診断を行う、と言うような役割分担があってもよい。端末・センタ協調処理手順は、両者の間でこのような役割分担が行われる例である。端末装置2は、図6の機器診断装置1が有する構成を有し、ネットワーク6を介して機器診断装置1と通信する。端末装置2が有する構成は、番号の末尾に“b”を付して、同等の機能を有する機器診断装置1の構成と区別する。なお、機器診断装置1及び端末装置2は、機器診断システムを構成する。

図12(b)において、機器診断装置1が使用する詳細診断モデル及び端末装置2が使用する基本診断モデルの両者は、同じ運転環境において同種の機器の診断を行う統計モデルである。しかしながら、詳細診断モデルは、以下の点で基本診断モデルとは異なる。 ・詳細診断モデルの方が、より新しく、より豊富な稼働データ(学習用データ)を使用して生成されている。端末装置2は、自車両が取得した稼働データで基本診断モデルを学習することはもちろん可能である。機器診断装置1は、当該車両を含む多くの車両が取得した稼働データで詳細診断モデルを学習することができる。

・詳細診断モデルの方が、診断対象の機器についての粒度がより細かい。端末装置2が使用する基本診断モデルが、例えば、制動系全体を診断するのに対し、機器診断装置1が使用する詳細診断モデルは、制動系が含む各パーツ(ブレーキシリンダ、ブレーキパッド、ブレーキディスク等)を診断する。つまり、端末装置2がとりあえず“制動系が異常である”と警告を報知したうえで、その後、機器診断装置1が“ブレーキシリンダが異常である”とより詳細な警告を報知する。

ステップS251において、端末装置2の稼働データ取得部21bは、稼働データを取得する。 ステップS252において、端末装置2の診断部25bは、ステップS251において取得した稼働データに対して、基本診断モデルで診断を行う。 ステップS253において、端末装置2の診断部25bは、ステップS251において取得した稼働データ及び基本診断モデルによる診断結果(基本診断結果)を、機器診断装置1に送信する。なお、基本診断結果は、例えば、“制動系は正常である”又は“制動系は異常である”の何れかである。

ステップS254において、機器診断装置1の診断部25は、ステップS251において取得した稼働データ及び基本診断結果を、端末装置2から受信する。 ステップS255において、機器診断装置1の診断部25は、ステップS251において取得した稼働データに対して、詳細診断モデルで診断を行う。 ステップS256において、機器診断装置1の診断部25は、詳細診断モデルによる診断結果(詳細診断結果)及び詳細診断モデルを、端末装置2に送信する。なお、詳細診断結果は、例えば、“制動系のうち○○は正常である”又は“制動系のうち◎◎は異常である”の何れかである。

ステップS257において、端末装置2の診断部25bは、詳細診断結果及び詳細診断モデルを、機器診断装置1から受信する。 ステップS258において、端末装置2の診断部25bは、詳細診断結果を表示する。具体的には、診断部25bは、基本診断結果とともに詳細診断結果を出力装置13bに表示する。 ステップS259において、端末装置2の診断部25bは、基本診断モデルを詳細診断モデルで置換する。具体的には、診断部25bは、ステップS252において使用した基本診断モデルを、ステップS257において受信した詳細診断モデルで置換した後、ステップS251に戻る。

なお、図12(b)には、“開始”及び“終了”が記されていない。このことは、端末装置2の電源スイッチがオンになっており、端末装置2が稼働データを取得する都度このような処理が繰り返されることを意味する。

(表示画面) 図13に沿って、表示画面の例を説明する。図13(a)は、機器診断装置1の診断部25又は端末装置2の診断部25bが、出力装置13(13b)に表示する画面の一例である。診断部25(25b)は、ユーザが機器選択欄から診断対象の機器を選択するのを受け付けると、診断結果情報33(図9)のモデル診断結果を、地図情報35に重ねて表示する。図13(a)の道路61上に表示された“■”は、“制動系が異常である”ことを示す。“■”は、14個連続して表示されている。このことから、診断期間yyyy〜xxxxにおいて、連続的に制動系(ブレーキ)の効果が悪くなったことがわかる。

さらに診断部25(25b)は、ユーザが“■”のうちの何れかを指で押下するのを受け付けると、図13(b)のグラフ及び図13(c)のグラフを出力装置 13(13b)に表示する。図13(b)の横軸は道路勾配であり、縦軸は、診断期間における異常検知数(図13(a)の“■”の数)である。図13(b)からは、道路勾配が小さいほど(厳しい下り坂であるほど)異常検知数が大きいことがわかる。図13(c)の横軸は大気圧であり、縦軸は、診断期間における異常検知数である。図13(c)からは、大気圧が大きいほど(下り坂を下りるほど)異常検知数が小さいことがわかる。ユーザ(車両5の運転者)は、車両5の整備が実施されるまでの間、下り坂で制動系(ブレーキパッド等)を消耗するのを避けるべきであることを知る。

(本実施形態の効果) 本実施形態の機器診断装置の効果は以下の通りである。 (1)機器診断装置は、移動する機器の運転環境が変化するのに応じて診断モデルを変化させることができる。 (2)機器診断装置は、統計モデル及び物理モデルを併用することができる。 (3)機器診断装置は、統計モデルを優先的に選択するので、人間の経験が有効に活用できる。 (4)機器診断装置は、学習結果を蓄積しつつ、成熟度を向上させることができる。 (5)機器診断装置は、診断モデルの信頼性(成熟度)を人間の判断によって見直すことができる。

(6)機器診断装置は、移動する機器の位置さえわかれば、機器の運転環境を取得することができる。 (7)機器診断装置は、複数の診断モデルの診断結果に基づき、より慎重に機器を診断することができる。 (8)機器診断装置は、運転環境として身近で入手しやすい天候又は道路属性を使用することができる。 (9)機器診断装置は、運転環境の範囲の組合せに対応させて統計モデルを生成するので、個々の運転環境の細かな変化が生じても、正確な診断が可能になる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、又は、ICカード、SDカード、DVD等の記録媒体に置くことができる。 また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

1 機器診断装置 2 端末装置 3 稼働データ収集サーバ 4 外部サーバ 5 車両 6 ネットワーク 11 中央制御装置 12 入力装置 13 出力装置 14 主記憶装置 15 補助記憶装置 16 通信装置 21 稼働データ取得部 22 運転環境識別部 23 診断モデル生成部 24 診断モデル選択部 25 診断部 26 成熟度判定部 31 稼働・環境情報 32 診断モデル割当情報 33 診断結果情報 34 診断モデル 35 地図情報