JP2018092406A - 機器診断装置、機器診断システム及び機器診断方法 - Google Patents

Abstract

【課題】運転環境が時々刻々と変化する機器を高信頼度で診断する。【解決手段】本発明の機器診断装置は、移動する機器の運転環境に応じて、機器を診断するための診断モデルを選択する診断モデル選択部と、選択された診断モデルに対して機器の稼働データを入力し、診断モデルから機器に対する診断結果の出力を受け取ることによって機器を診断する診断部と、を備えることを特徴とする。【選択図】図４

Description

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

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

特開２００９−５３９３８号公報

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

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

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

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

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

運転環境を説明する図である。 統計モデルの生成を説明する図である。 統計モデルの使用を説明する図である。 統計モデルの使用を説明する図である。 物理モデルの使用を説明する図である。 機器診断装置の構成を説明する図である。 稼働・環境情報を説明する図である。 診断モデル割当情報を説明する図である。 診断結果情報を説明する図である。 （ａ）は、統計モデル生成処理手順のフローチャートであり、（ｂ）は、物理モデル生成処理手順のフローチャートである。 （ａ）は、診断モデル選択処理手順のフローチャートであり、（ｂ）は、診断処理手順のフローチャートである。 （ａ）は、成熟度判定処理手順のフローチャートであり、（ｂ）は、端末・センタ協調処理手順のフローチャートである。 （ａ）、（ｂ）及び（ｃ）は、表示画面の一例である。

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

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

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

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

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

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

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

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

Ｌ＝ｖ^２／２ｇ（μｃｏｓθ−ｓｉｎθ）
“Ｌ≦Ｔｈ”である場合、“制動系は正常”である。
“Ｌ＞Ｔｈ”である場合、“制動系は異常”である。 （式１）

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

μが一定である場合、道路勾配θが０から徐々に大きくなるにつれて、“μｃｏｓθ−ｓｉｎθ”の値は徐々に小さくなる。すると、Ｌは徐々に大きくなる。θが一定である場合、摩擦係数μが徐々に大きくなるにつれて、“μｃｏｓθ−ｓｉｎθ”の値は徐々に大きくなる。すると、Ｌは徐々に小さくなる。

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

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

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

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

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

ここでの道路勾配５２、交通量５３、気温５４及び湿度５５のそれぞれは、運転環境である。もちろん運転環境は、これら以外にも多くの例があり得る。これらの運転環境の値の組合せに対して、運転環境ＩＤ５１が付与される。例えば、道路勾配“±０度”、交通量“３０台／分”、気温“３０℃”及び湿度“２０％”の組合せに対して運転環境ＩＤ“ＲＣ０１”が付与される。車両５が走行するにつれて、運転環境のそれぞれは独立的に変化する。図１では、１時間ごとに運転環境のそれぞれが変化している。すると、それぞれの時間帯における運転環境の値の組合せに対して、別の運転環境ＩＤが付与される。

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

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

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

１６時００分から１７時００分までの期間についても、学習用データとして３次元の稼働データが３回取得される。そこで、機器診断装置は、前記したように球５６ｂを生成する。機器診断装置は、その後の時間帯についても、同じ処理を繰り返す。すると、座標空間内に、５つの球５６ａ、５６ｂ、５６ｃ、５６ｄ及び５６ｅが生成される。２つ以上の球が同じ領域を共有する（一部が重なる）場合もある。しかしながら、ここでは、説明の単純化のために、球は、相互に重なることがないものとする。

１８時００分から１９時００分までの期間の運転環境“ＲＣ０４”において、車両５は、気温が相対的に低い中で下り坂を走行している。したがって、冷却装置に対する負担も比較的小さい。このことは、当該時間帯に取得された稼働データによって生成（学習）された球５６ｄが、座標空間の原点に比較的近い位置にあることに対応している。逆に、１６時００分から１７時００分までの期間の運転環境“ＲＣ０２”において、車両５は、気温が相対的に高い中で登り坂を走行している。したがって、冷却装置に対する負担も比較的大きい。このことは、当該時間帯に取得された稼働データによって生成された球５６ｂが、座標空間の原点から比較的遠い位置にあることに対応している。

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

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

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

ここで機器診断装置が、球５６ａを比較の基準とした理由は以下の通りである。
・１１月２日１５時００分における運転環境は“ＲＣ０１”である。
・１１月１日、運転環境“ＲＣ０１”の稼働データが生成した球は、球５６ａである。

機器診断装置は、１１月２日１６時００分に取得した稼働データを示す☆５７ｂと球５６ｂの中心との間の距離が球５６ｂの半径以下であるか否かを判断する。そして機器診断装置は、その判断の結果に応じて、“１１月２日１６時００分、冷却装置は正常である”又は“１１月２日１６時００分、冷却装置は異常である”と診断する。それ以降の時間帯についても同様である。なお、図３では、☆５７ｃと球５６ｃが、☆５７ｄと球５６ｄが、☆５７ｅと球５６ｅが、比較対象として対応している。

図４に沿って、統計モデルの使用を別の例で説明する。１１月１日１５時００から２０時００分までの期間、車両５が走行し、その結果、機器診断装置は、座標空間内に５つの球を生成した。ここまでは、図２及び図３と同じである。１１月２日１５時００から２０時００分までの期間、車両５は、前日とは異なる行程を走行した。そして、この時間帯の１時間ごとの運転環境は、当然前日とは異なり、ＲＣ０２→ＲＣ０１→ＲＣ０３→ＲＣ０５→ＲＣ０４のように推移したとする。

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

ここで機器診断装置が球５６ｂを比較の基準と理由は、以下通りである。
・１１月２日１５時００分における運転環境は“ＲＣ０２”である。
・１１月１日、運転環境“ＲＣ０２”の稼働データが生成した球は、球５６ｂである。

機器診断装置は、１１月２日１６時００分に取得した稼働データを示す☆５７ｂと球５６ａの中心との間の距離が球５６ａの半径以下であるか否かを判断する。そして機器診断装置は、その判断の結果に応じて、“１１月２日１６時００分、冷却装置は正常である”又は“１１月２日１６時００分、冷却装置は異常である”と診断する。それ以降の時間帯についても同様である。なお、図４では、☆５７ｃと球５６ｃが、☆５７ｄと球５６ｅが、☆５７ｅと球５６ｄが、比較対象として対応している。

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

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

図５においても、図３及び図４と同様に、１１月１日１５時００分から２０時００分までの期間において、車両５が走行している。運転環境も、図３及び図４と同様に、ＲＣ０１→ＲＣ０２→ＲＣ０３→ＲＣ０４→ＲＣ０５と推移している。１１月１日１５時００分、機器診断装置は、車両５のセンサから、診断対象としての稼働データを取得した。この稼働データは、図２と同じ３次元の稼働データである。

すると、機器診断装置は、まず、運転環境“ＲＣ０１”に応じて、物理モデル５８のパラメータの値を設定したうえで、物理モデル５８に、１１月１日１５時００分における稼働データ５９ａ、５９ｂ及び５９ｃを入力する。機器診断装置は、続いて、物理モデル５８が出力した冷却能力５９ｄが、運転環境“ＲＣ０１”に応じた閾値（上限及び下限）の範囲６０ｂ内にあるか否かを判断する。

冷却能力５９ｄが、閾値の範囲６０ｂ内にある場合、機器診断装置は、“１１月１日１５時００分、冷却装置は正常である”と診断する。冷却能力５９ｄが、閾値の範囲６０ｂ内にない場合、機器診断装置は、“１１月１日１５時００分、冷却装置は異常である”と診断する。

図５の物理モデル５８内には、冷却能力（横軸）の閾値の範囲６０ａ、６０ｂ、６０ｃ、６０ｄ及び６０ｅが設定されている。そしてこれらの横軸上の位置（上限及び下限）は、それぞれ、運転環境ＲＣ０４、ＲＣ０１、ＲＣ０３、ＲＣ０５及びＲＣ０２に対応している。なお、これらの閾値の範囲は、互いに重複していてもよい。図５では、分かり易さのために、閾値の範囲が重複しない例を記載している。因みに、図５では、冷却装置に対する負担が最も大きいと思われる運転環境ＲＣ０２に、横軸の値が最も大きい閾値の範囲６０ｅが対応している。冷却装置に対する負担が最も小さいと思われる運転環境ＲＣ０４に、横軸の値が最も小さい閾値の範囲６０ａが対応している。

１１月１日１６時００分においても、機器診断装置は、同様の処理を行う。ただし、このとき機器診断装置は、物理モデル５８が出力した冷却能力５９ｄが、運転環境“ＲＣ０２”に応じた閾値の範囲６０ｅ内にあるか否かを判断する。１１月１日１７時００分（１８時００分、１９時００分）においても、機器診断装置は、同様の処理を行う。

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

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

（稼働・環境情報）
図７に沿って、稼働・環境情報３１を説明する。稼働・環境情報３１においては、車両ＩＤ欄１０１に記憶された車両ＩＤに関連付けて、位置欄１０２には位置が、時点欄１０３には時点が、稼働データ欄１０４には稼働データが、運転環境欄１０５には運転環境が記憶されている。
車両ＩＤ欄１０１の車両ＩＤは、車両５を一意に特定する識別子である。
位置欄１０２の位置は、その時点における車両５の位置情報（経度及び緯度）である。
時点欄１０３の時点は、稼働データがセンサによって取得された時点の年月日時分秒である。

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

（診断モデル割当情報）
図８に沿って、診断モデル割当情報３２を説明する。診断モデル割当情報３２においては、運転環境ＩＤ欄１１１に記憶された運転環境ＩＤに関連付けて、運転環境欄１１２には運転環境の範囲が、統計モデルＩＤ欄１１３には統計モデルＩＤが、物理モデルＩＤ欄１１４には物理モデルＩＤが、推奨モデルＩＤ欄１１５には推奨モデルＩＤが記憶されている。

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

交通量（欄１１２ｂ）は、“１０”を境目として“１０未満”及び“１０以上”の２つの区分に分かれている。同様に、気温（欄１１２ｃ）は、“２０未満”及び“２０以上”の２つの区分に分かれ、湿度（欄１１２ｄ）は、“６０未満”及び“６０以上”の２つの区分に分かれている。

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

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

（診断結果情報）
図９に沿って、診断結果情報３３を説明する。診断結果情報３３においては、車両ＩＤ欄１２１に記憶された車両ＩＤに関連付けて、位置欄１２２には位置が、時点欄１２３には時点が、稼働データ欄１２４には稼働データが、運転環境ＩＤ欄１２５には運転環境ＩＤが、使用診断モデルＩＤ欄１２６には使用診断モデルＩＤが、モデル診断結果欄１２７にはモデル診断結果が、保守員診断結果欄１２８には保守員診断結果が、モデル評価欄１２９には評価フラグが記憶されている。

車両ＩＤ欄１２１の車両ＩＤは、図７の車両ＩＤと同じである。
位置欄１２２の位置は、図７の位置と同じである。
時点欄１２３の時点は、図７の時点と同じである。しかしながら、図７の時点が、学習データとして稼働データがセンサによって取得された時点である一方、図８の時点は、診断対象として稼働データがセンサによって取得された時点である。
稼働データ欄１２４の稼働データは、図７の稼働データと同じである。ただし、ここでの稼働データは、学習用データではなく、診断対象の稼働データである。なお、“（＃,＃,＃）”は、レコードごとに値が変化する３次元の稼働データを省略的に示している。
運転環境ＩＤ欄１２５の運転環境ＩＤは、図８の運転環境ＩＤと同じである。

使用診断モデルＩＤ欄１２６の使用診断モデルＩＤは、診断のために実際に使用された診断モデルを特定する識別子である。通常、運転環境が同じであれば、使用診断モデルＩＤ（図９）は、推奨モデルＩＤ（図８）に等しい。
モデル診断結果欄１２７のモデル診断結果は、使用診断モデルＩＤが特定する診断モデルによる診断結果（正常／異常）である。
保守員診断結果欄１２８の保守員診断結果は、診断モデルが診断結果を下した後、その診断結果とは別に、保守員が実際に機器を観察したうえで下した診断結果（正常／異常）である。モデル診断結果が“正常”であっても、保守員診断結果が“異常”である場合もあり得る。また、その逆もあり得る。

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

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

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

ステップＳ２０２において、稼働データ取得部２１は、稼働データを読込む。具体的には、稼働データ取得部２１は、機器診断装置１が受信する稼働データのうち、冷却装置に関するもの（冷却液温度、冷却液流量及びファン回転速度）を取得し、稼働・環境情報３１（図７）のうち車両ＩＤ欄１０１〜稼働データ欄１０４の部分を作成する。

ステップＳ２０３において、機器診断装置１の運転環境識別部２２は、地図情報３５を読込む。具体的には、第１に、運転環境識別部２２は、車両５の位置情報を検索キーとして、地図情報３５を参照し、車両５の位置における道路勾配を取得する。
第２に、運転環境識別部２２は、車両５の位置情報を検索キーとして、外部サーバ４を参照し、その時点における車両５の位置の交通量、気温及び湿度を取得する。
第３に、運転環境識別部２２は、ステップＳ２０３の“第１”及び“第２”において取得した情報を使用して、稼働・環境情報３１（図７）のうち、運転環境欄１０５の部分を作成する。

ステップＳ２０４において、運転環境識別部２２は、運転環境を識別する。具体的には、運転環境識別部２２は、ステップＳ２０３の“第１”及び“第２”において取得した、道路勾配、交通量、気温及び湿度の組合せを、診断モデル割当情報３２（図８）の運転環境欄１１２に当てはめ、対応する運転環境ＩＤを取得する。なお、補助記憶装置１５は、診断モデル割当情報３２のうち、運転環境ＩＤ欄１１１及び運転環境欄１１２の部分を事前に記憶しているものとする。

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

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

ステップＳ２０６において、診断モデル生成部２３は、統計モデルを記憶する。具体的には、第１に、診断モデル生成部２３は、統計モデルＩＤを採番し、採番した統計モデルＩＤを、ステップＳ２０５において求めた中心の位置座標及び半径と関連付けて、診断モデル３４（図６）として、補助記憶装置１５に記憶する。
第２に、診断モデル生成部２３は、診断モデル割当情報３２（図８）の統計モデルＩＤ欄１１３に、統計モデルＩＤを記憶する。

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

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

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

ステップＳ２１３において、運転環境識別部２２は、運転環境を識別する。具体的には、運転環境識別部２２は、ステップＳ２１２の“第１”及び“第２”において取得した、道路勾配、交通量、気温及び湿度の組合せを、診断モデル割当情報３２（図８）の運転環境欄１１２に当てはめ、対応する運転環境ＩＤを取得する。

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

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

ステップＳ２１６において、診断モデル生成部２３は、物理モデルを記憶する。具体的には、第１に、診断モデル生成部２３は、物理モデルＩＤを採番し、採番した物理モデルＩＤを、ステップＳ２１５の“第２”においてパラメータの値が代入された物理式と関連付けて、診断モデル３４（図６）として、補助記憶装置１５に記憶する。
第２に、診断モデル生成部２３は、診断モデル割当情報３２（図８）の物理モデルＩＤ欄１１４に、物理モデルＩＤを記憶する。その後、物理モデル生成処理手順は終了する。

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

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

（診断モデル選択処理手順）
図１１（ａ）に沿って、診断モデル選択処理手順を説明する。診断モデル選択処理手順を開始する前提として、補助記憶装置１５において、診断モデル割当情報３２（図８）が、推奨モデルＩＤ欄１１５のみが空欄である状態で記憶されているものとする。そして、診断モデル割当情報３２の統計モデルＩＤ欄１１３又は物理モデルＩＤ欄１１４に変化が生じたことを契機として診断モデル選択処理手順は開始される。

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

ステップＳ２２３において、診断モデル選択部２４は、統計モデルが存在するか否かを判断する。具体的には、診断モデル選択部２４は、対象レコードの統計モデルＩＤ欄１１３に“なし（未学習）”が記憶されている場合（ステップＳ２２３“Ｎｏ”）、ステップＳ２２５に進む。診断モデル選択部２４は、対象レコードの統計モデルＩＤ欄１１３に“ＳＭ”を冠する統計モデルＩＤが記憶されている場合（ステップＳ２２３“Ｙｅｓ”）、ステップＳ２２４に進む。

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

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

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

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

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

第３に、運転環境識別部２２は、ステップＳ２３３の“第１”及び“第２”において取得した情報に基づいて、診断モデル割当情報３２（図８）の運転環境欄１１２を参照し、該当するレコードの運転環境ＩＤを取得する。
第４に、運転環境識別部２２は、診断結果レコードの運転環境ＩＤ欄１２５に、ステップＳ２３３の“第３”において取得した運転環境ＩＤを記憶する。

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

ステップＳ２３５において、機器診断装置１の診断部２５は、診断を行う。具体的には、診断部２５は、使用診断モデル（ステップＳ２３４の“第２”において、使用診断モデル欄１２６に記憶したモデル）を使用して、診断対象の稼働データを診断する。使用診断モデルが統計モデルである場合、図３及び図４で説明したように、診断結果として“正常”又は“異常”の何れかを決定する。使用診断モデルが物理モデルである場合、図５で説明したように、診断結果として“正常”又は“異常”の何れかを決定する。
ステップＳ２３６において、診断部２５は、診断結果が正常であるか否かを判断する。具体的には、診断部２５は、診断結果が“正常”である場合（ステップＳ２３６“Ｙｅｓ”）、ステップＳ２３８に進み、診断結果が“異常”である場合（ステップＳ２３６“Ｎｏ”）、ステップＳ２３７に進む。

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

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

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

第２に、成熟度判定部２６は、評価レコードの車両ＩＤ及び時点を検索キーとして保守記録を参照し、対応する診断結果を取得する。
第３に、成熟度判定部２６は、評価レコードの保守員診断結果欄１２８に、ステップＳ２４１の“第２”において取得した診断結果を記憶する。

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

ステップＳ２４３において、成熟度判定部２６は、正解率を算出する。具体的には、成熟度判定部２６は、使用診断モデルＩＤごとに以下の正解率を算出する。
正解率＝評価フラグが“○”であるレコードの数／ある使用診断モデルＩＤを有するレコードの数×１００（％）
ステップＳ２４４において、成熟度判定部２６は、成熟度を判定する。成熟度は、診断モデルの正解率に応じて診断モデルごとに定義される評価値であり、正解率が大きいほど成熟度も高くなる。その後、成熟度判定処理手順は終了する。

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

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

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

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

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

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

ステップＳ２５１において、端末装置２の稼働データ取得部２１ｂは、稼働データを取得する。
ステップＳ２５２において、端末装置２の診断部２５ｂは、ステップＳ２５１において取得した稼働データに対して、基本診断モデルで診断を行う。
ステップＳ２５３において、端末装置２の診断部２５ｂは、ステップＳ２５１において取得した稼働データ及び基本診断モデルによる診断結果（基本診断結果）を、機器診断装置１に送信する。なお、基本診断結果は、例えば、“制動系は正常である”又は“制動系は異常である”の何れかである。

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

ステップＳ２５７において、端末装置２の診断部２５ｂは、詳細診断結果及び詳細診断モデルを、機器診断装置１から受信する。
ステップＳ２５８において、端末装置２の診断部２５ｂは、詳細診断結果を表示する。具体的には、診断部２５ｂは、基本診断結果とともに詳細診断結果を出力装置１３ｂに表示する。
ステップＳ２５９において、端末装置２の診断部２５ｂは、基本診断モデルを詳細診断モデルで置換する。具体的には、診断部２５ｂは、ステップＳ２５２において使用した基本診断モデルを、ステップＳ２５７において受信した詳細診断モデルで置換した後、ステップＳ２５１に戻る。

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

（表示画面）
図１３に沿って、表示画面の例を説明する。図１３（ａ）は、機器診断装置１の診断部２５又は端末装置２の診断部２５ｂが、出力装置１３（１３ｂ）に表示する画面の一例である。診断部２５（２５ｂ）は、ユーザが機器選択欄から診断対象の機器を選択するのを受け付けると、診断結果情報３３（図９）のモデル診断結果を、地図情報３５に重ねて表示する。図１３（ａ）の道路６１上に表示された“■”は、“制動系が異常である”ことを示す。“■”は、１４個連続して表示されている。このことから、診断期間ｙｙｙｙ〜ｘｘｘｘにおいて、連続的に制動系（ブレーキ）の効果が悪くなったことがわかる。

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

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

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

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

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

１ 機器診断装置
２ 端末装置
３ 稼働データ収集サーバ
４ 外部サーバ
５ 車両
６ ネットワーク
１１ 中央制御装置
１２ 入力装置
１３ 出力装置
１４ 主記憶装置
１５ 補助記憶装置
１６ 通信装置
２１ 稼働データ取得部
２２ 運転環境識別部
２３ 診断モデル生成部
２４ 診断モデル選択部
２５ 診断部
２６ 成熟度判定部
３１ 稼働・環境情報
３２ 診断モデル割当情報
３３ 診断結果情報
３４ 診断モデル
３５ 地図情報

Claims (13)

1. 移動する機器の運転環境に応じて、前記機器を診断するための診断モデルを選択する診断モデル選択部と、
   前記選択された診断モデルに対して前記機器の稼働データを入力し、前記診断モデルから前記機器に対する診断結果の出力を受け取ることによって前記機器を診断する診断部と、
   を備えることを特徴とする機器診断装置。
2. 前記診断モデルは、
   前記機器の設計条件又は自然法則から導出される物理モデル、及び、前記機器が正常又は異常であることが既知である場合に取得される稼働データの集合に対し、前記機器についての診断対象の稼働データを適用する統計モデルを含むこと、
   を特徴とする請求項１に記載の機器診断装置。
3. 前記診断モデル選択部は、
   ある運転状況について前記統計モデル及び前記物理モデルの両者が使用可能である場合、前記統計モデルを優先的に選択し、
   ある運転状況について前記統計モデルが使用不可能である場合、前記物理モデルを選択すること、
   を特徴とする請求項２に記載の機器診断装置。
4. 前記機器の稼働データを学習データとして使用し、前記機器の運転環境ごとに、前記統計モデルを生成する診断モデル生成部を備えること、
   を特徴とする請求項３に記載の機器診断装置。
5. 前記機器に対する前記診断モデルによる診断結果と、前記機器に対する人間による診断結果とを比較することによって、前記診断モデルの成熟度を算出する成熟度判定部を備えること、
   を特徴とする請求項４に記載の機器診断装置。
6. 前記機器の位置情報に基づいて、地図情報又は外部サーバから、前記機器の運転環境を取得する運転環境識別部を備えること、
   を特徴とする請求項５に記載の機器診断装置。
7. 前記診断部は、
   複数の前記診断モデルによる診断結果の論理積に基づき前記機器を診断すること、
   を特徴とする請求項６に記載の機器診断装置。
8. 前記運転環境は、
   天候又は道路属性を含み、
   前記天候は、
   気温、湿度、大気圧、風向、風速及び降水量のうちの少なくとも１つを含み、
   前記道路属性は、
   勾配、標高、交通量、交差点数、車線数、幅員、路面状態及び道路形状のうちの少なくとも１つを含むこと、
   を特徴とする請求項７に記載の機器診断装置。
9. 前記診断モデル生成部は、
   複数の前記運転環境の範囲の組合せに対応させて前記統計モデルを生成すること、
   を特徴とする請求項８に記載の機器診断装置。
10. 移動する機器を前記機器から離れた位置で診断する機器診断装置と、前記機器とともに移動し前記機器診断装置と通信可能な端末装置と、を備える機器診断システムであって、
    前記機器診断装置及び前記端末装置のそれぞれは、
    前記機器の運転環境に応じて、前記機器を診断するための診断モデルを選択する診断モデル選択部を備えるとともに、前記選択された診断モデルに対して前記機器の稼働データを入力し、前記診断モデルから前記機器に対する診断結果の出力を受け取ることによって前記機器を診断する診断部と、を備え、
    前記端末装置の診断部は、
    自身の診断モデルによって前記機器を診断し、
    前記機器診断装置の診断部は、
    前記端末装置の診断モデルとは異なる診断モデルによって別途前記機器を診断し、
    前記異なる診断モデルによって前記機器を診断した診断結果を、前記端末装置に送信すること、
    を特徴とする機器診断システム。
11. 前記端末装置の診断モデルは、
    前記機器が正常又は異常であることが既知である場合に取得される稼働データの集合に対し、前記機器についての診断対象の稼働データを適用し、前記機器を診断する統計モデルであり、
    前記異なる診断モデルは、
    前記機器が正常又は異常であることが既知である場合に取得される稼働データの集合に対し、前記機器についての診断対象の稼働データを適用し、前記機器を構成する部分を診断する統計モデルであること、
    を特徴とする請求項１０に記載の機器診断システム。
12. 機器診断装置の診断モデル選択部は、
    移動する機器の運転環境に応じて、前記機器を診断するための診断モデルを選択し、
    前記機器診断装置の診断部は、
    前記選択された診断モデルに対して前記機器の稼働データを入力し、前記診断モデルから前記機器に対する診断結果の出力を受け取ることによって前記機器を診断すること、
    を特徴とする機器診断装置の機器診断方法。
13. 前記診断モデルは、
    前記機器の設計条件又は自然法則から導出される物理モデル、及び、前記機器が正常又は異常であることが既知である場合に取得される稼働データの集合に対し、前記機器についての診断対象の稼働データを適用する統計モデルを含むこと、
    を特徴とする請求項１２に記載の機器診断方法。