JP6380169B2 - 故障診断装置および端末装置 - Google Patents

Description

本発明は、診断対象装置の故障診断を行う故障診断装置、および故障診断装置とともに用いられる端末装置に関する。

上記の故障診断装置として、ユーザから送信された車両データ（録音データ）を解析することによって車両の故障診断を行うものが知られている（例えば特許文献１参照）。

特許第４７０６８９０号公報

しかしながら、上記の故障診断装置では、ユーザが送信したデータに基づく故障診断を行うことはできるが、そもそも故障診断に適切なデータがどのようなデータなのかがユーザに分からないことがある。このため、故障診断を適切に実施できない場合がある。

そこでこのような問題点を鑑み、診断対象装置の故障診断を行う故障診断装置において、ユーザから故障診断に適切なデータを取得し、故障診断を適切に実施できるようにすることを本発明の目的とする。

本発明の故障診断装置において、絞り込み情報要求手段は、ユーザが所持する端末装置に対して診断対象装置の故障状態の絞り込みを行うための絞り込み情報を要求する。また、診断用データ収集要求手段は、端末装置からユーザによって入力された絞り込み情報を取得し、ユーザに対して該絞り込み情報の内容に対応する予め設定された診断用データを診断対象装置から収集するよう要求する。そして、診断用データ取得手段は、ユーザが端末装置を用いて収集した診断用データを端末装置から取得する。また、故障判定手段は、診断用データと予め準備されたモデルとに基づいて、診断対象装置の故障の有無を判定する。

このような故障診断装置によれば、ユーザによって入力された絞り込み情報に対応する診断用データを要求することができるので、故障診断に必要なデータを確実に収集することができる。よって、故障診断を適切に実施することができる。

なお、各請求項の記載は、可能な限りにおいて任意に組み合わせることができる。この際、一部構成を除外してもよい。

第１実施形態の故障診断システム１の概略構成を示すブロック図である。 決定木モデル６２の生成例を示す説明図である。 決定木モデル６２を用いた故障判定処理の概要を示す説明図である。 携帯端末１０のＣＰＵ１１が実行する端末診断処理を示すフローチャートである。 サーバ４０のＣＰＵ４１が実行するサーバ診断処理を示すフローチャートである。 第２実施形態の故障診断システム２の概略構成を示すブロック図である。 携帯端末１０のＣＰＵ１１が実行する端末更新処理を示すフローチャートである。 サーバ４０のＣＰＵ４１が実行するサーバ更新処理を示すフローチャートである。 学習データの蓄積状態を示す説明図である。

以下に本発明にかかる実施の形態を図面と共に説明する。
［第１実施形態］
［本実施形態の構成］
本発明が適用された故障診断システム１は、車両のユーザに故障判定に必要なデータを入力または取得させ、ユーザによって得られたデータを用いて車両の故障を診断する機能を有する。詳細には、故障診断システム１は、図１に示すように、携帯端末１０とサーバ４０とを備える。

携帯端末１０は、例えば、ユーザが所持するスマートフォンに、故障診断用のアプリケーションをインストールした構成とされる。携帯端末１０は、ＣＰＵ１１、メモリ１２、ＨＭＩ部１５、通信部２０、およびデータ収集部２５を備える。

ＣＰＵ１１およびメモリ１２は、周知のコンピュータを構成する。メモリ１２としては、ＲＯＭやＲＡＭを備え、ＣＰＵ１１は、メモリ１２に格納されたプログラムによる処理を実施する。

ＨＭＩ部１５は、ユーザと携帯端末１０との間で情報の入出力を行うためのユーザインタフェースを構成する。なお、ＨＭＩはHuman Machine Interfaceの略である。ＨＭＩ部１５としては、画像出力部１６、回答入力部１７、質問出力部１８を備える。

画像出力部１６は、画像を表示させるディスプレイとして構成され、ＣＰＵ１１からの指令に応じた画像をユーザに提供する。回答入力部１７は、タッチパネルやボタンとして構成され、ユーザが表示された画像や出力された音声に対する回答や指令を入力するための入力装置として機能する。

質問出力部１８は、音声を出力するスピーカとして構成され、画像出力部１６とともに、ユーザに対する質問等の各種情報を音声で出力する。
データ収集部２５は、目的のデータを収集するためのハードウェアとして構成されている。データ収集部２５としては、ＣＡＮ取得部２６、音源取得部２７、振動取得部２８、温度取得部２９、臭気取得部３０、および画像取得部３１を備えている。

ＣＡＮ取得部２６は、車両内のネットワークを形成するＣＡＮ通信線からＣＡＮ通信線を流れるデータを取得する。
音源取得部２７は、周知のマイクとして構成され、エンジン等の音源から発せられる音を取得する。振動取得部２８は、周知の加速度センサとして構成され、振動の発生源に携帯端末１０が接触させられたときに振動状態を検出できるよう構成される。

温度取得部２９は、周知の温度センサとして構成されており、周囲の温度または対象物の温度を測定する。臭気取得部３０は、周知の臭気センサとして構成されており、周囲の臭気の程度を検出する。

画像取得部３１は、周知のカメラとして構成されている。
通信部２０は、インターネット網８を介して携帯端末１０がサーバ４０と通信を行うための周知の通信モジュールとして構成されている。通信部２０は、図示しない無線基地局を介してインターネット網８に無線接続される。

また、通信部２０は、質問受信部２１、車両データ送信部２２、および回答送信部２３としてのそれぞれの機能を有する。質問受信部２１としての機能では、サーバ４０から送られた質問を受信し、ＨＭＩ部１５に送る。

また、車両データ送信部２２としての機能では、データ収集部２５にて得られたデータをサーバ４０に対して送信する。また、回答送信部２３としての機能では、ＨＭＩ部１５を用いてユーザが入力した回答をサーバ４０に対して送信する。

次に、サーバ４０は、携帯端末１０に対してインターネット網８を介して接続されている。サーバ４０は、故障の判定に必要となる質問（データ要求を含む）を生成し、この質問の回答に基づいて、新たな質問を生成したり、故障判定を行ったりする故障判定機能を備える。

サーバ４０は、ＣＰＵ４１、メモリ４２、通信部４５、データ処理部５０、データベース６３を備えている。ＣＰＵ４１およびメモリ４２は、周知のコンピュータを構成する。メモリ４２としては、ＲＯＭやＲＡＭを備え、ＣＰＵ４１は、メモリ４２に格納されたプログラムによる処理を実施する。なお、メモリ４２には、運転パターン識別モデル６１および決定木モデル６２が格納されている。

通信部４５は、データ受信部４６、回答受信部４７、質問送信部４８としての機能を備えている。データ受信部４６としての機能では、携帯端末１０から送信されたデータを受信し、データ処理部５０に送る。

回答受信部４７としての機能では、携帯端末１０から送信されたユーザによる回答を受信し、データ処理部５０に送る。質問送信部４８としての機能では、データ処理部５０にて生成された質問を携帯端末１０に送る。

データ処理部５０は、運転パターン識別部５１、車両データ選定部５２、特徴抽出部５３、推定処理部５４、質問生成部５５としての機能を備えている。
運転パターン識別部５１の機能では、事前に学習した運転パターン識別モデル６１を参照して、車両データを取得した際の各時刻での運転パターンを識別する。具体的には、アクセル開度、ブレーキオイル圧、車速、加速度等の車両状態の組み合わせを用いて複数準備された運転パターンの１つが選択されるよう設計されている。

車両データ選定部５２は、故障診断に適した運転パターンであるときの車両データ（部分車両データ）を抽出する。つまり、車両（携帯端末１０）から取得されたＣＡＮデータ、音、振動、温度、臭気等の車両データにおいて、故障の症状を検出しやすい運転パターンの部分のみを抽出する。

特徴抽出部５３の機能では、ユーザから得られたデータや回答の特徴量を抽出する。データにおいては平均値、極大値、極小値、分散等、回答においては肯定、否定等を特徴量として抽出する。抽出した特徴量は、特徴量ＤＢ６３に格納される。

推定処理部５４は、特徴量ＤＢ６３に格納された特徴量と、決定木モデル６２とに基づいて、故障状態を推定する。例えば、決定木モデル６２には、ユーザに対する質問（質問
項目または要求項目）がツリー状の階層構造で準備されている。質問生成部５５は、ユーザから得られた情報に従って上階層から順に質問（または要求）項目を選択することになる。

質問生成部５５は、決定木モデル６２に従って質問項目を進める際に、必要に応じて故障状態をより詳細に特定するためのユーザに対する質問を生成する。
ここで、決定木モデル６２においては、各項目において故障確率が故障の種別毎に対応付けられており、下階層に進むに従って、ある故障の種別に対する故障確率が高くなるよう設定されている。つまり、決定木モデル６２に従って下階層に進むにつれて、故障の種別を特定しやすくされる。

決定木モデル６２は、例えば以下のようにして生成される。
まず、データＸｎを準備する。

ｎはデータ番号を示し、ｋ次元のデータ由来の特徴量を有する。また、（ｄ−ｋ）次元のユーザの回答に基づく特徴量を有する。

また、診断結果の種別を表すラベルｙｎを以下のように定義する。

これらを用いて、Ｎ個の（Ｘｎ，Ｙｎ）の集合として学習データを以下のように定義する。

続いて、図２に示すように、このような学習データを例えばＣＨＡＩＤ（CHi-squared Automatic Integration Detector）を用いて処理することで、決定木モデル６２が生成される。

決定木モデル６２は以下のように定義される。

すなわち、上位の質問（変数番号ｍｉ）の回答結果（各条件式の値：True/False）に応じて下位の質問が特定される（Ｐ^ｊ _ｉが選定されて次ノードが決定する）ことになる。一方で、各ノードの評価変数番号ｍに対応するデータ種別ID(m)を参照し、ID(m)=0の場合はユーザへの直接質問を行う。また、データ毎に「データ収集フラグ」を用意しておき、ID(m)≠0の場合であってデータ収集フラグがFalseの場合、ユーザにデータ種別ID(m)のデータ収集を要求する。この場合、算出した特徴量を特徴量ＤＢ６３に格納する。そして、データ収集フラグをTrueに更新することで、ユーザによるデータ収集作業の重複を防ぐことができる。

より具体的には、図３に示すように、アイドル（アイドリング）不調か否かの質問に対してＹＥＳとの回答が得られた場合、例えば、ユーザに振動データを収集させ、この振動データから特徴量の抽出等を実施する。その後、この特徴量等に基づいて、以降の質問や回答を自動生成する。なお、ユーザに質問に対する回答やデータ収集を求める場合には、さらなる質問やデータ収集の指示が生成される。

つまり、データから得られる特徴量に基づいて客観的に質問に対する回答を自動生成することで、回答の手間を省くとともに、ユーザの主観による回答のばらつきを抑制できるようにしている。

［本実施形態の処理］
このように構成された故障診断システム１において、具体的に実施される処理について以下に説明する。携帯端末１０は、図４に示す端末診断処理を実施する。端末診断処理は、例えば携帯端末１０において故障診断を実施する旨が入力されると開始される処理である。

端末診断処理では、図４に示すように、まず、診断要求をサーバ４０に送信する（Ｓ１１０）。続いて、診断結果、質問、およびデータ収集要求の何れかを受信したか否かを判定する（Ｓ１２０、Ｓ１３０、Ｓ１４０）。

診断結果とは、故障診断の結果を示し、また、質問とは、車両の故障状態の絞り込みを行うため選択式で回答を可能なものを示す。診断結果、質問、またはデータ収集要求を受信していなければ（Ｓ１２０、Ｓ１３０、Ｓ１４０の全てでＮＯ）、Ｓ１２０、Ｓ１３０、Ｓ１４０の処理を順に繰り返す。

また、診断結果を受信していれば（Ｓ１２０：ＹＥＳ）、受信した診断結果に基づく画像を画像出力部１６に表示させ（Ｓ３１０）、端末診断処理を終了する。また、質問を受信していれば（Ｓ１２０：ＮＯかつＳ１３０：ＹＥＳ）、受信内容を画像出力部１６に表示させる（Ｓ２１０）。

続いて、受信内容（質問）に対する回答がユーザによって入力されたか否かを判定する（Ｓ２２０）。回答が入力されていなければ（Ｓ２２０：ＮＯ）、Ｓ２２０の処理を繰り返す。

また、回答が入力されていれば（Ｓ２２０：ＹＥＳ）、入力された回答をサーバ４０に送信し（Ｓ２３０）、Ｓ１２０の処理に戻る。
また、Ｓ１４０の処理においてデータ収集要求を受信していれば（Ｓ１２０：ＮＯ、Ｓ１３０：ＮＯ、かつＳ１４０：ＹＥＳ）、受信内容を画像出力部１６に表示させる（Ｓ２６０）。続いて、受信内容に従ってユーザによって車両データの収集がされたか否かを判定する（Ｓ２７０）。

車両データの収集がされていなければ（Ｓ２７０：ＮＯ）、Ｓ２７０の処理を繰り返す。また、車両データの収集がされていれば（Ｓ２７０：ＹＥＳ）、収集された車両データをサーバ４０に送信し（Ｓ２８０）、Ｓ１２０の処理に戻る。

このような端末診断処理に対応して、サーバ４０（ＣＰＵ４１）は図５に示すサーバ診断処理を実施する。サーバ診断処理は、例えば、サーバ４０の電源が投入されると開始される処理である。

サーバ診断処理では、図５に示すように、まず、携帯端末１０から診断要求、回答、および車両データの何れかを受信したか否かを判定する（Ｓ４１０、Ｓ４２０、Ｓ４３０）。診断要求、回答、または車両データを受信していなければ（Ｓ４１０、Ｓ４２０、Ｓ４３０の全てでＮＯ）、Ｓ４１０、Ｓ４２０、Ｓ４３０の処理を順に繰り返す。

診断要求を受信していれば（Ｓ４１０：ＹＥＳ）、質問を生成する（Ｓ４４０）。質問は前述の決定木モデル６２に従って生成される。そして、生成した質問を送信し（Ｓ４５０）、サーバ診断処理を終了する。

回答を受信していれば（Ｓ４１０：ＮＯ、かつＳ４２０：ＹＥＳ）、受信した回答を分析する（Ｓ５１０）。すなわち、回答で入力された内容に基づく特徴量を抽出し、特徴量ＤＢ６３に格納する。そして、決定木モデル６２に従って下位の階層に移行する。

続いて、診断可能か否かを判定する（Ｓ５２０）。ここで、診断可能か否かについては、質問回数（自動的に回答されたものを含む）や得られた車両データ数が閾値を超えるか否か、或いは、決定木モデル６２が持つ各診断種別の確率Ｐｂ^ｋ _ｉ（数4）を用いる等によって判定する。

診断可能であれば（Ｓ５２０：ＹＥＳ）、後述するＳ５７２の処理に移行する。また、診断不可能であれば（Ｓ５２０：ＮＯ）、さらなる質問が必要か、或いはデータが必要かを判定する（Ｓ５３０）。

さらなる質問が必要であれば（Ｓ５３０：ＹＥＳ）、前述のＳ４４０の処理に移行する。また、データが必要であれば（Ｓ５３０：ＮＯ）、データ収集要求を送信する（Ｓ５４０）。ここで、データ収集要求には要求するデータの種別が含まれる。このデータの種別は、質問を生成する処理と同様に、決定木モデル６２に従って選択される。

このような処理が終了するとサーバ診断処理を終了する。
また、Ｓ４１０、Ｓ４２０、Ｓ４３０の処理において、車両データを受信していれば（Ｓ４１０：ＮＯ、Ｓ４２０：ＮＯ、かつＳ４３０：ＹＥＳ）、受信した車両データから特
徴量を抽出し、この特徴量を特徴量ＤＢ６３に格納する（Ｓ５６０）。この際、特徴量取得後の質問項目を自動生成し、車両データの特徴量に基づいて回答可能な項目については回答を自動生成する（図３参照）。

続いて、Ｓ５２０の処理と同様に、診断可能か否かを判定する（Ｓ５７０）。診断不可能であれば（Ｓ５７０：ＮＯ）、Ｓ５３０の処理に移行する。また、診断可能であれば（Ｓ５７０：ＹＥＳ）、運転パターンを識別し（Ｓ５７２）、部分車両データを抽出する（Ｓ５７４）。そして、得られたデータを用いて故障診断を実施する（Ｓ５８０）。この処理では、前述のように特徴量と決定木モデル６２とに基づいて故障に該当するか否かを判定する。

続いて、診断結果を携帯端末１０に送信し（Ｓ５９０）、サーバ診断処理を終了する。
［本実施形態による効果］
以上のように詳述した故障診断システム１においてサーバ４０は、ユーザが所持する携帯端末１０に対して車両の故障状態の絞り込みを行うための絞り込み情報を要求する（Ｓ４５０）。また、サーバ４０は、携帯端末１０からユーザによって入力された絞り込み情報を取得し、ユーザに対して該絞り込み情報の内容に対応する予め設定された診断用データを車両から収集するよう要求する（Ｓ５４０）。そして、サーバ４０は、ユーザが携帯端末１０を用いて収集した診断用データを携帯端末１０から取得する（Ｓ４３０）。また、サーバ４０は、診断用データと予め準備されたモデルとに基づいて、車両の故障の有無を判定する（Ｓ５９０）。具体的には、診断データを用いてそれぞれの故障種別を求めるモデルにおいて、診断データが何れの項目に該当するかに基づいて故障の種別を推定する。

このような故障診断システム１によれば、ユーザによって入力された絞り込み情報に対応する診断用データを要求することができるので、故障診断に必要なデータを確実に収集することができる。よって、故障診断を適切に実施することができる。

特に、本実施形態の構成では、ＣＡＮ等の車両ネットワークを流れないデータである車両不取得データ（具体的には、音、振動、臭気等）を診断用データとして要求する。要求するデータは、スマートフォン等の携帯端末１０において搭載されているセンサで検出可能な情報とされる。この構成では、ユーザが所持する携帯端末１０を用いてユーザに適切な診断用データを取得させることができるので、安価にシステムを構成できる。

また、上記の故障診断システム１においてサーバ４０は、診断用データが取得されると、診断用データを解析し、取得された診断用データ解析結果に応じて、予め設定された新たな診断用データが必要か否か、或いは、ユーザに質問に回答させる必要があるか否かを判定する。また、新たな診断用データまたは質問への回答を表す新データが必要である場合、新データを携帯端末１０に対して要求する。そして、ユーザによって準備された新データを携帯端末１０から取得する。

このような故障診断システム１によれば、診断用データを解析することでさらに必要になるデータや質問への回答を取得することができる。よって、故障診断の精度を向上させることができる。

特に、本実施形態の構成では、ＣＡＮデータ等の車両データも利用して新データ（新たな診断用データ、或いは質問への回答）の必要性を判定して、質問項目の選択（決定木）を進める。この構成では、故障判定のためにユーザに適切な質問を行うことができる。

また、上記の故障診断システム１においてサーバ４０は、ユーザに要求される診断用デ
ータおよび新データは、予めツリー状の階層構造で準備された複数の質問項目または要求項目のそれぞれに対応付けられており、ユーザから得られた情報に従って上階層から順に質問項目または要求項目を選択することでユーザに対する質問または要求する診断用データおよび新データが選択されるよう構成されている。

このような故障診断システム１によれば、診断用データおよび新データを予めツリー状の階層構造で準備してあるので、ユーザが診断する際の手数を削減することができる。
また、上記のサーバ４０においては、車両の運転パターンを識別し、診断用データのうち診断に適する運転パターン時の部分のみを抽出する。そして、診断用データとして部分車両データを用いて車両の故障の有無を判定する。

このような故障診断システム１によれば、診断用データとして予め設定された運転パターンが対応する部分車両データを用いるので、診断に適した運転パターンで取得されたデータを用いて故障診断を実施することができる。

また、故障診断システム１において携帯端末１０は、車両の故障診断をするための情報をユーザが入力するための装置である。携帯端末１０は、サーバ４０からの要求をユーザに伝え、要求に対するユーザによる回答を受け付ける。そして、携帯端末１０は、受け付けた内容をサーバ４０に送信することで車両の故障診断をサーバ４０に実施させる。

このような故障診断システム１によれば、携帯端末１０がサーバ４０と協働することで車両の故障診断を良好に実施することができる。
［第２実施形態］
次に、別形態の故障診断システム２について説明する。本実施形態（第２実施形態）では、第１実施形態の故障診断システム１と異なる箇所のみを詳述し、第１実施形態の故障診断システム１と同様の箇所については、同一の符号を付して説明を省略する。

本実施形態の故障診断システム２では、図６に示すように、整備士による診断結果を利用して決定木モデル６２を更新するよう構成されている。詳細には、携帯端末１０が有する回答送信部２３に換えて、回答・診断送信部２４を備え、通信部４５が有する回答受信部４７に換えて、回答・診断受信部４９を備えている。また、データ処理部５０には、更新処理部５６の機能が備えられている。

回答・診断送信部２４は、整備士による回答および診断の内容をサーバ４０に送る機能を備えている。また、回答・診断受信部４９は、整備士による回答および診断の内容をサーバ４０から受信する機能を備えている。

また、更新処理部５６の機能では、整備士による回答および診断の内容に基づいて決定木モデル６２を更新する処理を実施する。詳細には、携帯端末１０およびサーバ４０において下記の処理を実施することでモデルを更新する。まず、携帯端末１０では、図７に示す端末更新処理を実施する。

端末更新処理は、例えば、携帯端末１０において整備士による入力が実施される旨が入力されると開始される処理である。ここで、整備士による診断が入力される際には、携帯端末１０が整備士による入力を受け付けるモードに切り替えられ、このモードにおいて整備士が質問に対する回答やデータの取得等を行うことで携帯端末１０に対する入力を行う。

詳細には、図７に示すように、まず、整備士による診断結果が入力されたか否かを判定する（Ｓ７１０）。この処理では、予め準備された全ての質問やデータの取得の全てが整
備士によって実施されるようにし、全ての質問に対する回答やデータの取得が完了すると、Ｓ７１０の処理にて肯定判定される。

整備士による診断結果が入力されていなければ（Ｓ７１０：ＮＯ）、Ｓ７１０の処理を繰り返す。また、整備士による診断結果が入力されていれば（Ｓ７１０：ＹＥＳ）、診断結果による特徴量を記録する（Ｓ７２０）。この特徴量には、それぞれの質問に対する回答（中間結果）および最終的な故障内容（最終結果）を含む。

続いて、最終結果および中間結果を含むモデル更新要求をサーバ４０に送信し（Ｓ７４０）、端末更新処理を終了する。
端末更新処理に対応して、サーバ４０ではサーバ更新処理が実施される。サーバ更新処理は、例えばサーバ診断処理と並行して繰り返し実施される処理である。

サーバ更新処理では、図８に示すように、まず、携帯端末１０からモデル更新要求を受信したか否かを判定する（Ｓ８１０）。モデル更新要求を受信していなければ（Ｓ８１０：ＮＯ）、Ｓ８１０の処理を繰り返す。

また、モデル更新要求を受信していれば（Ｓ８１０：ＹＥＳ）、新規データを生成する（Ｓ８２０）。ここで新規データとは、必要となるデータベースのうちのモデル更新要求に含まれる携帯端末１０から得られたデータを示す。この処理では、図９に示すように、整備士による入力にて生成された回答を新たなデータとして蓄積することになる。

続いて、これらのデータを用いて、決定木モデル６２を更新する（Ｓ８３０）。この処理では、これらの新たなデータを追加し更新された学習データに対してＣＨＡＩＤを用いた処理を実施することによって決定木モデル６２を更新する。更新されたモデルは、メモリ４２に記録される。

このような処理が終了すると、サーバ更新処理を終了する。
すなわち、上記の故障診断システム２においては、故障判定のスペシャリストである整備士による故障診断情報の入力結果を取得し、故障診断情報に基づいて、決定木モデル６２を更新する。具体的には、各ノードが保持する情報（次ノードポインタ・条件式・診断種別の確率）が変更される。

このような故障診断システム２によれば、故障判定のスペシャリストによるデータの入力パターンに応じて決定木モデル６２を最適化することができる。
［その他の実施形態］
本発明は、上記の実施形態によって何ら限定して解釈されない。また、上記の実施形態の説明で用いる符号を特許請求の範囲にも適宜使用しているが、各請求項に係る発明の理解を容易にする目的で使用しており、各請求項に係る発明の技術的範囲を限定する意図ではない。上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合させたりしてもよい。また、上記実施形態の構成の少なくとも一部を、同様の機能を有する公知の構成に置き換えてもよい。また、上記実施形態の構成の一部を、課題を解決できる限りにおいて省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。なお、特許請求の範囲に記載した文言のみによって特定される技術思想に含まれるあらゆる態様が本発明の実施形態である。

上述した故障診断システム１の他、当該故障診断システム１を構成する携帯端末１０やサーバ４０、当該故障診断システム１としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体、故障診断方法など、種々の形態で本発明を実現するこ
ともできる。

また、上記実施形態においては、決定木を用いて診断結果を絞り込むよう構成したが、その他の手法を用いてもよい。例えば、診断に必要となる可能性がある全てのデータおよび全ての質問に対する回答をユーザに準備させ、これらのデータに対して多クラスＳＶＭを用いて一括診断してもよい。

［実施形態の構成と本発明の手段との対応関係］
上記実施形態において、サーバ４０は本発明でいう故障診断装置に相当し、上記実施形態において、携帯端末１０は本発明でいう端末装置に相当する。また、上記実施形態において車両は診断対象装置に相当する。

また、サーバ４０が実行する処理のうちの、Ｓ４２０、Ｓ４３０の処理は本発明でいう新データ取得手段に相当し、上記実施形態におけるＳ４３０の処理は本発明でいう診断用データ取得手段に相当する。さらに、上記実施形態におけるＳ４５０の処理は本発明でいう絞り込み情報要求手段に相当し、上記実施形態におけるＳ４５０、Ｓ５４０の処理は本発明でいう新データ要求手段に相当する。

また、上記実施形態におけるＳ５４０の処理は本発明でいう診断用データ収集要求手段に相当し、上記実施形態におけるＳ５７２の処理は本発明でいう運転パターン識別手段に相当する。さらに、上記実施形態におけるＳ５７４の処理は本発明でいう部分車両データ抽出手段に相当し、上記実施形態におけるＳ５９０の処理は本発明でいう故障判定手段に相当する。

また、上記実施形態におけるＳ５７０の処理は本発明でいう新データ必要性判定手段に相当し、上記実施形態におけるＳ７１０の処理は本発明でいう入力取得手段に相当する。さらに、上記実施形態におけるＳ８３０の処理は本発明でいうモデル更新手段に相当する。

また、上記実施形態において携帯端末１０が実施する処理のうちの、Ｓ２１０、Ｓ２６０の処理は本発明でいう要求伝達手段に相当する。また、上記実施形態におけるＳ２２０、Ｓ２７０の処理は本発明でいう受付手段に相当し、上記実施形態におけるＳ２３０、Ｓ２８０の処理は本発明でいう受付内容送信手段に相当する。

１，２…故障診断システム、８…インターネット網、１０…携帯端末、１１…ＣＰＵ、１２…メモリ、１５…ＨＭＩ部、１６…画像出力部、１７…回答入力部、１８…質問出力部、２０…通信部、２１…質問受信部、２２…車両データ送信部、２３…回答送信部、２４…回答・診断送信部、２５…データ収集部、２６…ＣＡＮ取得部、２７…音源取得部、２８…振動取得部、２９…温度取得部、３０…臭気取得部、３１…画像取得部、４０…サーバ、４１…ＣＰＵ、４２…メモリ、４５…通信部、４６…データ受信部、４７…回答受信部、４８…質問送信部、４９…回答・診断受信部、５０…データ処理部、５１…運転パターン識別部、５２…車両データ選定部、５３…特徴抽出部、５４…推定処理部、５５…質問生成部、５６…更新処理部、６１…運転パターン識別モデル、６２…決定木モデル、６３…特徴量ＤＢ。

Claims (7)

1. 診断対象となる車両である診断対象装置の故障診断を行う故障診断装置（４０）であって、
   ユーザが所持する端末装置（１０）に対して診断対象装置の故障状態の絞り込みを行うための絞り込み情報を要求する絞り込み情報要求手段（Ｓ４５０）と、
   前記端末装置からユーザによって入力された絞り込み情報を取得し、ユーザに対して該絞り込み情報の内容に対応する、前記端末装置に備えられたセンサを用いて検出する診断用データを診断対象装置から収集するよう要求する診断用データ収集要求手段（Ｓ５４０）と、
   ユーザが前記端末装置に備えられたセンサを用いて収集した診断用データを前記端末装置から取得する診断用データ取得手段（Ｓ４３０）と、
   前記診断用データと複数の質問項目及び複数の要求項目がツリー状の階層構造で表された決定木モデルとに基づいて、前記診断対象装置の故障の有無を判定する故障判定手段（Ｓ５９０）と、
   を備えたことを特徴とする故障診断装置。
2. 請求項１に記載の故障診断装置において、
   前記診断用データが取得されると、該診断用データを解析し、取得された診断用データ解析結果に応じて、予め設定された新たな診断用データが必要か否か、或いは、ユーザに質問に回答させる必要があるか否かを判定する新データ必要性判定手段（Ｓ５７０）と、
   前記新たな診断用データまたは前記質問への回答を表す新データが必要である場合、該新データを前記端末装置に対して要求する新データ要求手段（Ｓ４５０、Ｓ５４０）と、
   ユーザによって準備された新データを前記端末装置から取得する新データ取得手段（Ｓ４２０、Ｓ４３０）と、
   を備え、
   前記故障判定手段は、前記新データも用いて前記診断対象装置の故障の有無を判定すること
   を特徴とする故障診断装置。
3. 請求項２に記載の故障診断装置において、
   ユーザに要求される診断用データおよび新データは、前記複数の質問項目または前記複数の要求項目のそれぞれに対応付けられており、ユーザから得られた情報に従って上階層から順に前記質問項目または前記要求項目を選択することでユーザに対する質問または要求する診断用データおよび新データが選択されるよう構成されていること
   を特徴とする故障診断装置。
4. 請求項１〜請求項３の何れか１項に記載の故障診断装置において、
   故障判定のスペシャリストによる故障診断情報の入力結果を取得する入力取得手段（Ｓ７１０）と、
   前記故障診断情報に基づいて、前記複数の質問項目及び前記複数の要求項目の少なくとも一方の更新を行うモデル更新手段（Ｓ８３０）、
   を備えたことを特徴とする故障診断装置。
5. 請求項１〜請求項４の何れか１項に記載の故障診断装置において、
   当該故障診断装置は、車両を診断対象装置とし、
   該車両の運転パターンを識別する運転パターン識別手段（Ｓ５７２）と、
   前記診断用データのうちの診断に適する運転パターン時の部分を表す部分車両データを抽出する部分車両データ抽出手段（Ｓ５７４）と、
   を備え、
   前記故障判定手段は、前記診断用データとして前記部分車両データを用いて前記診断対象装置の故障の有無を判定すること
   を備えたことを特徴とする故障診断装置。
6. 請求項１〜請求項５の何れか１項に記載の故障診断装置において、
   前記診断用データには、音、振動、温度、臭気のデータのうち、少なくとも一つが含まれる、ことを特徴とする故障診断装置。
7. 診断対象装置の故障診断をするための情報をユーザが入力するための端末装置（１０）であって、
   故障診断装置からの要求をユーザに伝える要求伝達手段（Ｓ２１０、Ｓ２６０）と、
   前記要求に対するユーザによる回答を受け付ける受付手段（Ｓ２２０、Ｓ２７０）と、
   該受け付けた内容を前記故障診断装置に送信することで診断対象装置の故障診断を前記故障診断装置に実施させる受付内容送信手段（Ｓ２３０、Ｓ２８０）と、
   を備え、
   前記受付内容送信手段は、前記端末装置に備えられたセンサから得られた情報を前記診断用データとして送信し、
   前記故障診断装置は、請求項１〜請求項５の何れか１項に記載の故障診断装置として構成されていること
   を特徴とする端末装置。