JP5434448B2 - 車両用故障検出装置、電子制御ユニット、車両用故障検出方法 - Google Patents

Description

本発明は、車両の部品の故障を検出する車両用故障検出装置、電子制御ユニット及び車両用故障検出方法に関する。

車両には、各種のセンサ、アクチュエータ、及び、これらと接続されたマイコン（以下、ＥＣＵ（electronic control unit）という）が数多く搭載されているが、ＥＣＵにはセンサやアクチュエータ、又は、ＥＣＵ自身の異常を検出する自己診断装置が搭載されている。自己診断装置は、ＥＣＵや電気回路の所定の端子の電圧や電流を監視し（以下、信号という）、この信号値と閾値の比較結果に応じて異常を検出する。この閾値は、同一の車両では同一の値に設定されることが多い。

したがって、信号値が閾値を超えれば（又は、閾値未満になれば）自己診断装置は故障を検出し、それ以外は故障を検出しないというように、画一的な診断を行うことになる。このため、故障を検出しやすい側に閾値を設定すれば、故障は確実に検出できる反面、故障の誤検出が多くなってしまい、故障を検出しにくい側に閾値を設定すれば、故障の検出が困難になるという傾向がある。

例えば、信号値が瞬間的に閾値を超える（又は閾値未満になる）ことがあるが、瞬間的な現象を全て故障として検出する必要はないと考えらえる反面、瞬間的な現象の中にも故障の直前の状態や既に修理すべき故障に陥っている状態が存在する。このように、従来の画一的な判定では、瞬間的な現象を故障検知の情報として把握することは困難であった。

この点について、閾値を変更する技術が知られている（例えば、特許文献１参照。）。特許文献１には、ディーラから各車両に対して、故障履歴情報（プレダイアグ情報）の送信要求をおこなうと、車両の自己診断装置が閾値を故障を検出しやすい側に変更し、故障履歴情報（プレダイアグ情報）をディーラに送信する車両状況監視システムが開示されている。ディーラは、各車両から送信された複数の故障履歴情報（プレダイアグ情報）に基づいて、車両不良の発生傾向を総合的に解析する。

また、一時的な異常をトリガーに、異常が所定期間継続的に検出されると、それを真の故障として検知するデータ記録装置が提案されている（例えば、特許文献２参照。）。

特開２００５−１４６９０５号公報 特開２００６−０１７４６８号公報

しかしながら、特許文献１記載の車両状況監視システムでは、ディーラが収集する故障履歴情報（プレダイアグ情報）には、真の異常（故障）も含まれているものの、誤検出となる異常も含まれている。また、ディーラが複数の車両から得た故障履歴情報（プレダイアグ情報）を統計的に解析するものなので、具体的な故障を検出するには相当数のデータが必要であるなど、故障のある部品を特定するのは困難である。

また、特許文献２記載のデータ記録装置では、故障を特定するために、異常が所定期間継続的に検出される必要があるので、瞬間的な故障は検出できないという問題がある。

本発明は、上記課題に鑑み、誤検知を抑制しながら、信号値が閾値との関係において基準を満たさなくても故障を特定可能な車両用故障検出装置、電子制御ユニット及び車両用故障検出方法を提供することを目的とする。

上記課題に鑑み、本発明は、乗員の状態を監視する乗員状態監視手段と、車両に搭載される制御装置の故障の兆候を、乗員の状態から検出する故障兆候検出手段と、予め定められている閾値と制御装置に入力される信号値を比較して故障を検出する故障検出手段と、故障兆候検出手段が前記兆候を検出した場合、異常を検出しやすい側に前記閾値を変更する閾値変更手段と、を有することを特徴とする車両用故障検出装置を提供する。

誤検知を抑制しながら、誤検知を抑制しながら、信号値が閾値との関係において基準を満たさなくても故障を特定可能な車両用故障検出装置、電子制御ユニット及び車両用故障検出方法を提供することができる。

車両用故障検出装置の概略を説明する図の一例である。 車両用故障検出装置のハードウェア構成図の一例である。 車両用故障検出装置の機能ブロック図の一例である。 ドライバ監視装置の一例を示す図である。 部品登録ＤＢに登録された部品推定情報の一例を示す図である。 閾値の変更を説明するための図である。 車両用故障検出装置が動作する手順を示すフローチャート図の一例である。 車両用故障検出装置が動作する手順を示すフローチャート図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図１は、本実施形態の車両用故障検出装置１００の概略を説明する図の一例である。車両２００は、車両用故障検出装置１００を搭載している。まず、車両用故障検出装置１００は、車両に乗車しているドライバのドライバ監視情報を継続的に監視している。ドライバ監視情報は、例えば顔の表情、音声、生体信号等である。車両に何らかの異常がある場合、それは異音や振動等になって現れ、ドライバが五感で検知できることが多い。以下、ドライバが不具合を検知した際に部品に生じている異常を仮異常という。仮異常は、故障の兆候ともいうべきものであり、既に修理すべき故障が生じているか、近い将来に故障となる異常であると考えられる。
Ｉ．そこで、車両用故障検出装置１００は、仮異常を検出すると、ＦＦＤ（Freeze Frame Data）を記録する。
ＩＩ．また、車両用故障検出装置１００は、仮異常を検出すると、異常を検出するための閾値を、異常を検出しやすい側に変更する。

閾値を変更することで、車両用故障検出装置１００は故障を検出しやすくなる。閾値を変更したが、車両用故障検出装置１００が故障を検出しなかった場合でも、仮異常の検出時にＦＦＤが記録されているので、サービスマンはＦＦＤを手がかりに故障箇所を特定しやすくなる。

なお、車両用故障検出装置１００は、閾値を変更する前に異常を検出することと、閾値を変更した後に異常を検出すること（以下、後者の異常を本異常という）がある。本実施形態ではいずれの場合も故障として扱う。

〔車両用故障検出装置１００の構成〕
図２は、車両用故障検出装置１００のハードウェア構成図の一例を示す。車両用故障検出装置１００は、例えば、ドライバ監視装置３０と接続された、ＥＣＵ_Ａ及びＥＣＵ_Ｂ（以下、ＥＣＵ＿ＡとＥＣＵ＿Ｂを区別しない場合、ＥＣＵ２０という）により構成される。各ＥＣＵ（electronic control unit）２０がドライバ監視装置３０を備えていてもよいし、図示するように各ＥＣＵ２０に共通のドライバ監視装置３０を搭載してもよい。また、図２には、サービス工場においてＦＦＤをスキャンツールが読み出すためのＣＡＮＩ／Ｆ６０を示したが、車両用故障検出装置１００は携帯電話網や無線ＬＡＮ網を介してＦＦＤをサーバに送信することができる。

ＥＣＵ２０はコンピュータを実体とし、ＣＰＵ１４、ＥＥＰＲＯＭ１３、ＲＡＭ、ＣＡＮコントローラ１９、入力インターフェイス１２、出力インターフェイス１６、及び、ＡＳＩＣ（Application Specific Integrated Circuit）１７がバスを介して接続された構成を有する。車両には数多くのＥＣＵ２０が搭載されているが、車両用故障検出装置１００は、例えば、アクチュエータ１８を制御するパワートレーン系、エンジン系、電気モータ系、トランスミッション系、ブレーキ系等のＥＣＵ、また、ボディＥＣＵ、マルチメディアＥＣＵに好適に適用できる。

例えば、パワートレーン系のＥＣＵ＿Ａの入力インターフェイス１２に接続されるセンサＡ〜Ｃ（区別しない場合、センサ１１という）は、クランク角センサ、エアフローセンサ、Ｏ２センサ、ＥＧＲ（Exhaust Gas Recirculation）センサ等である。また、出力インターフェイス１６はＭＯＳＦＥＴやＩＧＢＴ（Insulated Gate Bipolar Transistor）等を実体とし、出力インターフェイス１６やＡＳＩＣ１７に接続されたに接続されるアクチュエータＡ〜Ｃ（区別しない場合、アクチュエータ１８という）は、例えば、イグニッションプラグ、インジェクタ、ＶＶＴソレノイド、各種のソレノイド、スロットルモータ等である。なお、ＡＳＩＣ１７は、特定の演算や制御に対応して実装されている。

ＣＡＮコントローラ１９は、他のＥＣＵ＿Ｂ、ドライバ監視装置３０、及び、ＣＡＮＩ／Ｆ６０とＣＡＮ（Controller Area Network）通信するためのコントローラである。ＣＡＮコントローラ１９は、ドライバ監視装置３０から仮異常検出の通知を受信したり、ＥＣＵ２０間でセンサ１１の測定したデータを送受信する。なお、ＣＡＮの他、ＦｌｅｘｒａｙやＬＩＮ等、通信態様は問わない。

ＣＰＵ１４は、ＥＥＰＲＯＭ１３に記憶されたプログラムやパラメータデータを読み出し、ＲＡＭ１５を作業メモリにしてセンサ１１が検出した信号に各種の演算を施し、演算結果に基づきアクチュエータ１８を制御する。また、ＣＰＵ１４は、ＥＥＰＲＯＭ１３に記憶されたプログラムをＲＡＭを作業メモリにして実行して、車両用故障検出装置１００の各機能を提供する。なお、制御用のＣＰＵ１４とは別に、故障検出のために別のＣＰＵ１４を搭載したり、マルチコア型の１つのＣＰＵ１４を搭載してもよい。また、マルチスレッド型のＣＰＵ１４を搭載し、スレッドの切り替えにより実装される仮想ＣＰＵを故障検出の処理を実行させてもよい。

図３は、車両用故障検出装置１００の機能ブロック図の一例を示す。ドライバ監視装置３０は、ドライバ状態監視部３２と比較情報記憶ＤＢ（Ｄａｔａ Ｂａｓｅ）３１を有する。ＥＣＵ２０（ＥＣＵ＿Ａ）は、ＣＰＵ１４がプログラムを実行することで実現された、部品推定部３６、ＦＦＤ記録部３４、故障検出部３５及び閾値変更部３８を有する。また、ＥＣＵ２０は、部品登録ＤＢ３７及びＦＦＤテーブル３３を不揮発メモリ（フラッシュメモリ、ＨＤＤ等）に記憶している。部品登録ＤＢ３７は、各ＥＣＵ２０に搭載されている必要はなく、別のＥＣＵ２０と共通に搭載されていてもよいし、車両用故障検出装置１００が通信により車外から取得してもよい。

〔ドライバ監視装置３０〕
まず、ドライバ監視装置３０について説明する。ドライバ監視装置３０は、乗車中のドライバの状態を各種の方法で監視する。監視したい状態は、ドライバが車両の不具合を感じ取った場合に変化する心理状態が影響しやすい状態である。例えば、次のような状態が挙げられる。なお、生体情報を除き、ドライバだけでなく助手席の乗員の状態も検出することができる。
・顔の表情
・音声
・生体情報（脳波、脈拍、血圧、心電図等）
ドライバが、異音や振動から不具合を感じ取った場合、驚く・困惑する・不機嫌そうな顔をする、視線を音のする方向に向ける、感嘆の声を出す、舌打ちをする、「変な音がする」と発言する、脈拍や血圧等が上昇する等、ドライバ状態が変化することがある。したがって、ドライバ状態を検知することで、車両に故障が生じた可能性があること（すなわち仮異常）を検出できる。

図４（ａ）〜（ｃ）は、ドライバ監視装置３０の一例を示す図である。

・顔の表情
図４（ａ）は顔の表情をドライバ状態として検出する場合の、ドライバ監視装置３０の一例を示す図である。図４（ａ）のドライバ監視装置３０は、カメラ１４，赤外線ライト４２、及び、画像処理装置４３を有する。図４（ａ）のドライバ監視装置３０は、運転者の表情、及び、視線方向を監視する。カメラ４１は、例えばステアリングコラムのアッパーカバーの上側又はメータパネルに、運転者の顔をほぼ正面から撮影するように配置されている。

画像処理装置４３は、カメラ４１が撮影した顔画像から顔の表情と顔向きを検出する。画像処理装置４３は、顔画像の背景部が静止しているのに対し、運転者の顔は顔画像毎に位置がずれることを利用して、顔画像から顔のおよその位置（顔の輪郭）を検出する。背景部と顔部の境界は画素値の変動が大きいので、画像処理装置４３はこの画素値を、顔画像が切り替わる毎に同じ画素位置同士で加算していく。顔画像の左右方向及び上下方向に加算した画素値を投影すると、背景部と顔部の境界でピークを示すのでそこが顔の輪郭位置となる。

そして、画像処理装置４３は、顔画像から輪郭内の画像データを取り出し、輪郭内のエッジ情報から顔の特徴点を検出する。顔の特徴点（眉、上下の瞼、鼻孔、口角、上下の唇の境など）は、肌に比べ輝度の変化が大きいのでエッジ情報として検出される。顔の特徴点の位置の変化は、表情の変化を意味する。例えば、笑顔であれば、口が開く、口角が上がる、目尻が下がる、等の表情の変化がある。また、困惑した表情であれば、眉間にしわが寄る、目を見開く、眉の角度が変化する、等の表情の変化がある。したがって、ドライバが不具合を感じた場合に示す表情を想定して、顔の特徴点がどのように変化するかを調査しておくことで、顔画像からドライバが車両の不具合を感じた可能性があることを検知できる。比較情報記憶ＤＢ３１には、予め調査しておいた、平静時の表情を基準にドライバが不具合を感じた場合に示す表情の特徴点の変化量、及び、変化の前後の顔の特徴点の位置情報が登録されている。

画像処理装置４３は、顔画像から取り出した顔の特徴点の変化量と位置情報が、比較情報記憶ＤＢ３１に比較情報として登録された変化量及び位置情報と一致すると見なせるか否かを判定する。画像処理装置４３は、一致すると見なせると判定した場合に仮異常を検出し、仮異常通知をＥＣＵ２０に通知する。このように、比較情報記憶ＤＢ３１に変化量を登録しておくことで、ドライバが変わっても不具合を感じた際の表情に変化したことを検知できる。

なお、比較情報記憶ＤＢ３１に、各ドライバ毎の変化量や不具合を感じたときの特徴点の位置情報を登録しておいてもよい。こうすることで、ドライバが、車両の不具合を感じたか否かの判定精度を向上できる。この場合、車両用故障検出装置１００は、例えばスマートキー（登録商標）のキーＩＤによりドライバを識別する。

また、各ドライバ毎に比較情報を記憶しておくことで、ドライバが意識的に表情を変えることで仮異常を発生させることができる。例えば、普段はドライバが作らないような表情の比較情報を予め比較情報記憶ＤＢ３１に登録しておけば、ドライバが不具合を感じて意識的に表情を作った場合にだけ、仮異常を発生させることができる。仮異常の誤検知を少なくすることができる。

また、比較情報ＤＢに登録された比較情報を、画像処理装置４３が学習により修正してもよい。仮異常が検出されるとＦＦＤが記録されるが、画像処理装置４３は、仮異常が検出された際の顔の特徴点の変化量や位置情報をＦＦＤと関連付けて（例えば、時刻情報、位置情報等と共に）記憶しておく。これにより、故障検出部３５が本異常を検出した場合に、閾値を低下させ本異常の検出をもたらしたＦＦＤに関連付けられた顔の特徴点の変化量や位置情報を特定できる。画像処理装置４３は、比較情報ＤＢに登録された比較情報を、仮異常が検出された際の顔の特徴点の変化量や位置情報に近づけるように修正できる。学習により、徐々に仮異常の検出精度を向上できる。

次に、視線方向について説明する。まず、人の顔の特徴点は左右対称に配置されているので、顔画像から得られたエッジ情報の数が左右でほぼ均等になる垂直線が顔の中央線である。ドライバが左右いずれかに顔を向けると中央線の位置も移動するので、画像処理装置４３はこの中央線の位置と左右の輪郭位置の関係から顔向き方向（顔向き度）を算出する。顔向き度は例えば正面方向を基準にした角度である。

また、視線方向は、さらに注視点を検出することで求められる。注視点の検出方法はいくつか知られているが、ここでは赤外線ライト４２が作るプルキニエ像（角膜表面における反射像）を利用する。プルキニエ像を得るため赤外線ライト４２は光束が発散しにくい点光源である。画像処理装置４３は、顔画像からまず瞳孔領域を決定する。近赤外画像では、瞳孔は周囲に比べ最も小さい輝度値（画素値）を示す。このため、画素値やその面積や形状に基づきフィルタリングすることで瞳孔を検出することができる。この瞳孔の中心と仮想的に求める眼球中心Ｏを結ぶ線が視線方向である。

次いでプルキニエ像を検出する。プルキニエ像は，点光源の映り込みであるため輝度値が大きい。プルキニエ像が検出されれば、カメラ４１の焦点距離、カメラ４１の位置，光軸の方向から、プルキニエ像の位置が得られる。プルキニエ像が所定の曲率半径Ｃの角膜上に存在すると仮定すると、プルキニエ像の位置を距離Ｃだけ延長した方向が、眼球中心Ｏとなる。したがって、眼球中心Ｏと瞳孔の中心とを結ぶことで視線方向が得られる。実際には、視線方向には個人差があるので、ドライバ毎にキャリブレーションパラメータを取得しておく。画像処理装置は、顔画像から仮異常を検出した場合、仮異常通知と視線方向をＥＣＵ２０に通知する。

・音声
図４（ｂ）は音声をドライバ状態として検出する場合の、ドライバ監視装置３０の一例を示す図である。図４（ｂ）のドライバ監視装置３０は、運転者の発する音声を監視する。このため、ドライバ監視装置３０は、主に、マイク４５と音声処理装置４４を有する。マイク４５は、例えばＡピラーに配置されている。

音声処理装置４４は、音声認識を行いドライバの発話内容からドライバが車両の不具合を感じたか否か、又は、不具合を感じた際に発する感嘆音を発したか否かを判定する。音声処理装置４４は、マイク４５が集音した音声が変換された電気信号の波形と、不図示の辞書データを照らし合わせ音声認識することで、発話内容をテキストデータに変換する。そして、音声処理装置４４は、発話内容が、比較情報記憶ＤＢ３１に記憶されているか否かに基づき、ドライバが不具合を感じたか否かを判定する。比較情報記憶ＤＢ３１には「変な音がする」「あれ？」「おかしいな」等、比較情報としてのテキストデータが登録されている。なお、音声処理装置４４は、比較情報の一部の単語と、発話内容を比較してドライバが不具合を感じたか否かを判定する。

また、音声処理装置４４は、マイク４５が集音した音声をスペクトル解析して、ドライバの心理状態を推定する。比較情報記憶ＤＢ３１には、「あー」や舌打ち等の感嘆音のスペクトルデータが登録されている。音声処理装置４４は、スペクトルデータ（波長毎の強度情報）とマイク４５が集音した音声のスペクトルを比較して、ドライバが車両の不具合を感じたか否かを判定する。音声処理装置４４は、音声から仮異常を検出した場合、仮異常通知をＥＣＵ２０に通知する。

音声から不具合を検出する場合も、各ドライバ毎に比較情報を記憶しておくことで、ドライバが意識的に不具合を感じた際に発する特定の言葉を発声することで仮異常を発生させることができる。また、音声処理装置４４は、同様に、比較情報記憶ＤＢ３１に記憶されている比較情報（発話内容）を学習により修正する。

・生体情報（脈拍、血圧、心電図、脳波等）
図４（ｃ）は生体情報をドライバ状態として検出する場合の、ドライバ監視装置３０の一例を示す図である。図４（ｃ）のドライバ監視装置３０は、運転者の生体情報を監視する。このため、ドライバ監視装置３０は、主に、電極４６、脈波計４７及び生体情報処理装置４８を有する。電極４６は例えば、ステアリングホイールのドライバの左右の把持位置に２箇所備えられている。脈波計４７は、例えば、ステアリングホイールの計器類側に指先を挿入する筒状に形成されるか、又は、アクセルペダルの指先側に配置されている。

生体情報処理装置４８は、左右の電極４６をドライバが把持することで生じる電位差を検出し、この電位差を増幅、成形して心電図を取得する。生体情報処理装置４８は、心電図から例えばＲ波、ＲＲ間隔、心拍数等を検出する。また、脈波計４７は、ドライバの指先を流れる血流（ヘモグロビン）を透過光の変化から計測する。血流の変化は透過光の変化として現れる。生体情報処理装置４８は、例えば加速度脈波を利用して血圧値を推定する。加速度脈波は、最大の振幅を示す最初の極大点を有する陽性波（ａ波）、ａ波に続く陰性波（ｂ波）、以下、ｃ波、ｄ波、ｅ波というように波形の極値を境に名称がある。例えば、このａ波とｅ波の時間間隔を所定の計算式に代入することで血圧値が得られる。なお、血圧をカフ方で測定してもよいし、心電図のＰＷＴＴ（脈波伝播時間：血液の脈波が心臓を発してから指先に到達するまでの時間）から算出してもよい。また、生体情報処理装置４８が脳波を測定してもよい。

生体情報処理装置４８は、生体情報からドライバが車両の不具合を感じたか否かを判定する。この場合、比較情報記憶ＤＢ３１には、ドライバが車両の不具合を感じた場合の典型的な生体情報のパターンが登録されている。例えば、ドライバが車両の不具合を感じた場合の脈拍や血圧の絶対値、脈拍や血圧の変化率が登録されている。生体情報処理装置４８は、計測した生体情報の絶対値と変化率を、比較情報記憶ＤＢ３１に記憶された比較情報と比較して、ドライバが不具合を感じているか否かを判定する。生体情報理装置は、生体情報から仮異常を検出した場合、仮異常通知をＥＣＵ２０に通知する。

なお、生体情報処理装置４８は、同様に、比較情報記憶ＤＢ３１に記憶されている比較情報（生体情報のパターン）を学習により修正する。

〔ＥＣＵ２０の各機能〕
ＥＣＵ２０が提供する各機能について説明する。まず、ドライバ監視装置３０から仮異常通知を取得したＦＦＤ記録部３４はＦＦＤをＦＦＤテーブル３３に記録する。ＦＦＤとして記録される情報は、車両の状況をできるだけ詳細に特定できるものが好ましい。例えば、ＦＦＤは、エンジン回転数、吸入空気量、車速、水温、吸気温、酸素濃度、加速度、減速度、ステアチング操舵角等である。また、ハイブリッド車の場合、バッテリ残量、モータ回転速度、モータ温度、モータ電流等をＦＦＤに含めることが好ましい。

ＦＦＤ記録部３４は、部品推定部３６に記録したＦＦＤを通知する。部品推定部３６は、通知されたＦＦＤとその他の必要な車両情報を利用して、異常が生じた部品を推定する。異常が生じた部品を推定するため、部品登録ＤＢ３７には、車両状況と異常が生じた可能性のある部品が対応づけて登録されている。

図５（ａ）は、部品登録ＤＢ３７に登録された部品推定情報の一例を示す図である。各種の車両状況に対応づけて、不具合が生じたと推定される部品が登録されている。例えば、加速中であれば、エンジン本体の各部品（インジェクタ、吸排気バルブ、各種センサ）や、これらとエンジンＥＣＵとの接続、エンジンＥＣＵの処理エラー等により、車両に不具合が生じていると考えられる。この推定が正しければ、ドライバはエンジンの異音・振動、加速の悪さ、急加速等に不具合を感じていることになる。

また、減速中であればブレーキ部品（ブレーキシュー、油圧配管、蓄圧器等）やこれらとブレーキＥＣＵの接続、ブレーキＥＣＵの処理エラー等により、車両に不具合が生じていると考えられる。この推定が正しければ、ドライバはブレーキ鳴き、ブレーキの効きの悪さ等に不具合を感じていることになる。

また、図５（ａ）にはハイブリッド車に特有の部品推定情報が登録されている。ハイブリッド車はエンジンのみを動力源とする走行と、モータのみを動力源とする走行と、両方を動力源とする走行、が可能である。したがって、モータ走行時にはモータやモータＥＣＵが、不具合が生じる可能性のある部品であり、エンジン走行時にはエンジン本体やエンジンＥＣＵが、不具合が生じる可能性のある部品である。

部品推定部３６は、ＦＦＤとその他の必要な車両情報から車両状況を特定する。部品推定部３６は、例えば、加速度が所定値以上であったりアクセル開度が所定値以上であれば加速中であること、減速度が所定値以上であったりストップランプスイッチがオンであれば減速中であること、シフトポジションの監視によりシフトチェンジした直後であること、操舵角が所定値以上であれば操舵中であること、ハイブリッドＥＣＵに問い合わせて得られる走行モードからモータ走行時であること又はエンジン走行時であること等、種々の車両状況を特定する。

また、ＦＦＤ記録部３４が、ドライバ監視装置３０から仮異常通知だけでなく視線方向を通知された場合、ＦＦＤ記録部３４は視線方向を部品推定部３６に通知する。したがって、部品推定部３６は、視線方向を用いて、不具合が生じたと推定される部品を絞り込むことができる。

図５（ｂ）は、部品登録ＤＢ３７に登録された視線方向部品情報の一例を示す図である。例えば、正面視の視線方向を、水平方向・上下方向に共に０度とし、正面に向かって左側を正、正面に向かって上方向を正とした。視線方向部品情報には、視線方向に対応づけて、部品が登録されている。例えば、水平＋４５度、上下−１０度は視線方向が左下方向であることを意味し、ドライバは左前輪のブレーキ部品に不具合を感じている可能性がある。また、水平＋１０度、上下−１０度は視線方向が中央下方向であることを意味し、ドライバはエンジン本体に不具合を感じている可能性がある。

部品推定部３６は、このようにして不具合が生じたと推定される部品の推定結果を閾値変更部３８に通知する。閾値変更部３８は、推定結果に含まれる部品の、異常を検出するための閾値を異常を検出しやすい側に変更する。

各ＥＣＵ２０のそれぞれの部品推定部３６が、不具合が生じた部品を推定するので、閾値を変更する閾値変更部３８は、この部品に接続された又は部品を制御するＥＣＵ２０の閾値変更部３８だけである。例えば、ＥＣＵ＿ＡがエンジンＥＣＵでＥＣＵ＿ＢがブレーキＥＣＵの場合であり、ドライバがエンジンＥＣＵの不具合を感じたと部品推定部３６が推定した場合、エンジンＥＣＵの閾値変更部３８が閾値を変更する。

なお、部品推定部３６は、部品の推定結果をＦＦＤ記録部３４にも通知することが好ましい。この部品は異常を生じている可能性があるので、この部品を制御するＥＣＵ２０のＦＦＤ記録部３４は、他のＥＣＵ２０よりも短いサンプリング周期でＦＦＤを記録する。こうすることで、故障検出部３５が本異常を検出できなくても、サービスマンはＦＦＤから故障した部品を特定しやすくなる。

図６は、閾値の変更を説明するための図である。異常又は本異常を検出する際、故障検出部３５は、電圧値や電流値を閾値と比較し、閾値を超えた時間又は閾値以下となった時間が判定時間以上になると故障を検出する。以下、電圧値や電流値が閾値を超えること又は閾値以下となることを、「信号値が異常判定値を充足する」という。信号値が異常判定値を充足した時間が判定時間以上必要とされるのは、瞬間的な異常判定値の充足から故障したと確定してしまうと、故障の誤検出となることが少なくないためである。

図６では、変更前の閾値をＴｈ０、判定時間をＴ０とする。また、図６では、信号値が閾値以下となると、信号値が異常判定値を充足するものとする。図６（ａ）では、信号値が閾値Ｔｈ０以下となっているが、信号値が異常判定値を充足する時間Ｔｘが判定時間Ｔ０未満なので、故障検出部３５が故障を検出することはない。

閾値変更部３８は、部品の推定結果を取得すると、次の２つの態様のいずれか又は両方で閾値を異常を検出しやすい側に変更する。
（ａ）閾値変更部３８は、閾値Ｔｈ０をＴｈ１に変更する（Ｔｈ０＜Ｔｈ１）
（ｂ）閾値変更部３８は、判定時間Ｔ０をＴ１に変更する（Ｔ０＞Ｔ１）
図６（ｂ）は、閾値Ｔｈ０をＴｈ１に変更した場合の信号値と閾値Ｔｈ１を模式的に示す図の一例である。閾値Ｔｈ０がＴｈ１に変更された結果、信号値が異常判定値を充足する時間Ｔｘが長くなる。このため、時間Ｔｘは判定時間Ｔ０を超えることができるようになる。

図６（ｃ）は、判定時間Ｔ０をＴ１に変更した場合の信号値と判定時間Ｔ０を模式的に示す図の一例である。判定時間Ｔ０が判定時間Ｔ１に変更された結果、時間Ｔｘが判定時間Ｔ１を超えることができるようになる。

特に、故障検出部３５が検出できない瞬間的な不具合の場合、センサ１１やアクチュエータ１８とＥＣＵ２０の接続が不安定になっていることがあるので、閾値Ｔｈ０や判定時間Ｔ０を異常を検出しやすい側に変更することで、故障検出部３５が瞬間的な接触不良等から故障を検出しやすくなる。

なお、閾値変更部３８は、閾値を変更したことを状態フラグ３９に登録する。状態フラグ３９は、例えば「０：閾値変更なし １：閾値変更あり」の２つの値を取り、故障検出部３５がどちらの閾値で異常を検出しているかを示す。

また、閾値変更部３８は、部品の推定結果を受け取る毎に、異常を検出するための閾値Ｔｈ０や判定時間Ｔ０を徐々に異常を検出しやすい側に変更してもよい。ドライバ監視装置３０が検出した仮異常が誤検出であった場合や、部品推定部３６が推定した部品が誤っている場合に、一度に閾値Ｔｈ０や判定時間Ｔ０を大きく変更すると、故障検出部３５が故障を誤検出するおそれがある。しかし、異常を検出するための閾値Ｔｈ０や判定時間Ｔ０を徐々に異常を検出しやすい側に変更することで、ドライバ監視装置３０が仮異常を何度か検出すること、及び、部品推定部３６が同じ部品を推定することで閾値が徐々に変更されるので、故障検出部３５が故障を誤検出するおそれを少なくすることができる。

また、閾値変更部３８は、部品によっては故障検出部３５による異常の検出条件を緩和する。例えば、エンジン始動の際、スタータモータが大きな電力を必要とするので、信号値が異常判定値を充足しやすい状態になることが知られている。このため、エンジン始動の時に不安定になるバッテリ電圧が安定するまでは、各ＥＣＵ２０の故障検出部３５は故障を検出しない。しかしながら、本来、信号値が異常判定値を充足しやすい状態でこそ、故障検出部３５が故障を検出しやすくなる。そこで、閾値変更部３８は、部品の推定結果を受け取ると、このような異常の検出条件を緩和する。緩和とは、異常を検出するための条件（異常があるか否かを判定するための条件：上記の閾値等）を減らすこと、異常を検出するための前提条件（異常があるか否かを判定するか否か、を定めた条件）を減らすこと、及び、異常を検出するための前提条件を全てなくすこと、が含まれる。このような、検出条件の緩和内容は、閾値変更部３８が部品に対応づけて保持している。

続いて、閾値変更部３８が閾値を変更した後、閾値を元に戻すタイミングについて説明する。閾値を元に戻すタイミングには以下のようなものがある。
（ｉ）閾値を元に戻さない
（ii）イグニッションオン（ガソリン車の場合）又はシステム（ハイブリッド車若しくは電気自動車の場合）スタート時に、閾値変更部３８が元の閾値に戻す
（iii）所定時間以上、仮異常が検出されないと、閾値変更部３８が閾値を元に戻す
（ｉ）閾値を元に戻さない場合、例えばサービスマンが修理箇所を修理した後、閾値を変更する。(ii)エンジン等のスタート時に、閾値変更部３８が元の閾値に戻す場合、仮異常の検出が誤っている場合、閾値が異常を検出しやすい側に維持される期間を制限できるので、本異常の誤検知を防止できる。

(iii)所定時間以上、仮異常が検出されないと、閾値変更部３８が閾値を元に戻す場合、(ii)よりもさらに閾値が異常を検出しやすい側に維持される期間を制限できるので、本異常の誤検知を防止できる。なお、閾値変更部３８が閾値を徐々に変更した場合は、徐々に閾値を元に戻す。こうすることで、仮異常が検出されやすいほど、閾値を異常を検出しやすい側に維持でき、仮異常が検出されにくいほど、閾値を異常を検出しにくい側に維持できる。したがって、実際には部品に故障が生じていない場合は本異常の誤検知を抑制でき、実際に部品に故障が生じている場合は本異常の検出を容易にできる。

また、閾値を徐々に変更する場合も最も異常を検出しやすい閾値（以下、最終値という）が定められている。閾値を徐々に変更する場合、閾値が最終値まで変更された場合、閾値変更部３８は閾値を一切、元に戻さない。こうすることで、運転者が不具合に慣れてしまい、仮異常が検出されなくなることを防止できる。

故障検出部３５は、閾値の変更の前から異常を検出している。故障検出部３５は、例えば、閾値変更部３８から通知を受け（変更通知）又は状態フラグ３９を参照して、閾値が変更されたことを検出する。そして、閾値の変更後、故障検出部３５が検出した異常は本異常となる。故障検出部３５が本異常を検出すると（異常を検出した場合も）、ダイアグコードを記録する。また、故障検出部３５はＦＦＤ記録部３４に記録要求を通知し、ＦＦＤＥ記録部３４はＦＦＤを記録する。ダイアグコードとＦＦＤは、後にサービスマンが解析できるように対応づけられている。

故障検出部３５は異常又は仮異常を検出すると、メータパネルなどのアラームランプを点灯する。ドライバこれを見て、車両をサービス工場に持ち込んだ際、サービスマンはダイアグコードからＦＦＤを特定できるようになっている。なお、サービスマンは、状態フラグ３９を確認して、状態フラグ３９が「１」であれば「０」に戻す。

また、サービスマンは、ダイアグコードがなくＦＦＤだけでも（仮異常だけが検出された場合）も故障した部品を特定する手がかりにすることができる。

〔車両用故障検出装置１００の動作手順〕
＜閾値を元に戻さない場合＞
図７は、車両用故障検出装置１００が動作する手順を示すフローチャート図の一例である。図７のフローチャート図は、イグニッション（ガソリン車の場合）又はシステム（ハイブリッド車若しくは電気自動車の場合）がオンになるとスタートする。

ドライバ状態監視部３２は、継続的にドライバの状態を監視している（Ｓ１０）。ドライバ状態監視部３２は、顔の表情、音声及び生体情報の少なくとも１つ以上と比較情報を比較して、ドライバが不具合を感じたか否かを判定する（Ｓ２０）。ドライバが不具合を感じない場合（Ｓ２０のＮｏ）、ドライバ状態監視部３２はドライバの状態を監視を継続する。

ドライバが不具合を感じた場合（Ｓ２０のＹｅｓ）、ドライバ状態監視部３２は仮異常通知をＦＦＤ記録部３４に送信する（Ｓ３０）。なお、ドライバ状態監視部３２は、視線方向を検出している場合、仮異常通知と共に視線方向をＦＦＤ記録部３４に通知する。

仮異常通知を受信したＦＦＤ記録部３４は、ＦＦＤを記録する（Ｓ４０）。また、閾値変更部３８は、異常を検出しやすい側に閾値を変更する（Ｓ５０）。これにより、エンジン等スタート時から異常を検出している故障検出部３５は、変更後の閾値と信号値を比較して本異常が検出されたか否かを判定する（Ｓ６０）。本異常が検出されない場合（Ｓ６０のＮｏ）、故障検出部３５は、変更後の閾値により本異常が検出されたか否かの判定を繰り返す。

また、本異常が検出された場合（Ｓ６０のＹｅｓ）、故障検出部３５は、ダイアグコードを記録し、ＦＦＤ記録部３４はＦＦＤを記録する（Ｓ７０）。サービスマンはこのダイアグコードとＦＦＤから、異常のある部品を特定し修理することができる。

本実施例の車両用故障検出装置１００は、ドライバの状態を監視することで、接触不良などの瞬間的に生じる不具合から故障を検出することができる。したがって、車両の出荷時には閾値を異常を検出しやすい側に設定する必要がなく、故障の兆候をトリガーに閾値を変更するので検出が困難な瞬間的な信号値の異常から故障を検出できる。また、ドライバが仮異常の段階でサービス工場に車両を持ち込んでも、ＦＦＤが記録されているので、サービスマンが異常をある部品を特定しやすい。

＜閾値を元に戻す場合＞
図８は、車両用故障検出装置１００が動作する手順を示すフローチャート図の一例である。図８において図７と同一部には同一の符号を付した。

図８では、仮異常通知を受信したＦＦＤ記録部３４がＦＦＤを記録する（Ｓ４０）までは図7と同様であるが、閾値変更部３８は、異常を検出しやすい側に１段階、閾値を変更する（Ｓ５１）。こうすることで、徐々に閾値を異常を検出しやすい側に変更できる。

そして、故障検出部３５は、変更後の閾値と信号値を比較して本異常が検出されたか否かを判定する（Ｓ６０）。また、本異常が検出されない場合（Ｓ６０のＮｏ）、閾値変更部３８は、最後に仮異常が検出されてから所定時間が経過したか否かを判定する（Ｓ８０）。所定時間が経過した場合（Ｓ８０のＹｅｓ）、閾値変更部３８は閾値を1段階、元に戻す（Ｓ９０）。こうすることで、徐々に閾値を元に戻すことができる。

所定時間が経過しない場合（Ｓ８０のＮｏ）、処理がステップＳ１０に戻り、ドライバ監視装置３０がドライバ状態を監視する。そして、ドライバが不具合を感じれば（Ｓ２０のＹｅｓ）、ドライバ状態監視部３２は仮異常通知をＦＦＤ記録部３４に送信する（Ｓ３０）。仮異常通知を受信したＦＦＤ記録部３４は、ＦＦＤを記録する（Ｓ４０）。閾値変更部３８は、異常を検出しやすい側に１段階、閾値を変更する（Ｓ５１）。したがって、閾値が徐々に閾値を異常を検出しやすい側に変更される。

ドライバが不具合を感じなければ（Ｓ２０のＮｏ）、閾値変更部３８は、最後に仮異常が検出されてから所定時間が経過したか否かを判定し（Ｓ８０）、所定時間が経過した場合（Ｓ８０のＹｅｓ）、閾値変更部３８は閾値を1段階、元に戻す（Ｓ９０）。

図８の手順によれば、図７の効果に加え、実際には部品に故障が生じていない場合は本異常の誤検知を抑制でき、実際に部品に故障が生じている場合は本異常の検出を容易にできる。

１１ センサ
１３ ＥＥＰＲＯＭ
１４ ＣＰＵ
１８ アクチュエータ
２０ ＥＣＵ
３０ ドライバ監視装置
３１ 比較情報記憶ＤＢ
３２ ドライバ状態監視部
３３ ＦＦＤテーブル
３４ ＦＦＤ記録部
３５ 故障検出部
３６ 部品推定部
３７ 部品登録ＤＢ
３８ 閾値変更部
３９ 状態フラグ
１００ 車両用故障検出装置

Claims (12)

1. 乗員の状態を監視する乗員状態監視手段と、
   車両に搭載される制御装置の故障の兆候を、乗員の状態から検出する故障兆候検出手段と、
   予め定められている閾値と制御装置に入力される信号値を比較して故障を検出する故障検出手段と、
   前記故障兆候検出手段が前記兆候を検出した場合、異常を検出しやすい側に前記閾値を変更する閾値変更手段と、
   を有することを特徴とする車両用故障検出装置。
2. 前記故障兆候検出手段が前記兆候を検出した場合、車両状況を表す車両状況情報を記憶する記憶手段、
   を有することを特徴とする請求項１記載の車両用故障検出装置。
3. 前記乗員状態監視手段は、乗員の顔画像を撮影する撮影手段と、顔画像に画像処理を施して乗員の表情を検出する画像処理装置とを有し、
   前記故障兆候検出手段は、乗員の表情から制御装置の前記兆候を検出する、
   ことを特徴とする請求項１又は２記載の車両用故障検出装置。
4. 前記閾値変更手段は、前記故障兆候検出手段が前記兆候を検出する毎に、異常を検出しやすい側に前記閾値を徐々に変更し、
   前記閾値変更手段は、前記故障兆候検出手段が前記兆候を最後に検出してから所定時間経過する毎に、異常を検出しにくい側に前記閾値を徐々に戻す、
   ことを特徴とする請求項１〜３いずれか１項記載の車両用故障検出装置。
5. 前記閾値変更手段は、前記閾値が最も異常を検出しやすい値に到達した場合、
   前記故障兆候検出手段が前記兆候を最後に検出してから所定時間が経過しても、異常を検出しにくい側に前記閾値を戻さない、
   ことを特徴とする請求項４記載の車両用故障検出装置。
6. 車両状況と故障の可能性のある制御装置を対応づけた故障部品推定情報記憶手段と、
   前記故障兆候検出手段が前記兆候を検出した場合、車両状況に基づき前記故障部品推定情報記憶手段を参照して故障の可能性のある制御装置を推定する部品推定手段と、を有し、
   前記閾値変更手段は、前記部品推定手段が推定した制御装置の故障を検出する前記閾値を異常を検出しやすい側に変更する、
   ことを特徴とする請求項１〜５いずれか１項記載の車両用故障検出装置。
7. 前記故障部品推定情報記憶手段には、モータ走行の車両状況に対し故障の可能性のある制御装置としてモータＥＣＵが対応づけて登録され、エンジン走行の車両状況に対し故障の可能性のある制御装置としてエンジンＥＣＵが対応づけて登録されており、
   前記故障兆候検出手段が前記兆候を検出した場合、前記部品推定手段は、車両状況に基づき前記故障部品推定情報記憶手段を参照してモータ走行かエンジン走行かを特定し、
   モータＥＣＵ又はエンジンＥＣＵを故障の可能性のある制御装置と推定する、
   ことを特徴とする請求項６記載の車両用故障検出装置。
8. 前記故障兆候検出手段が前記兆候を検出した場合、
   前記閾値変更手段は、異常を検出するための条件を減らす、異常を検出するための前提条件を減らす、又は、異常を検出するための前提条件を全てなくす、
   ことを特徴とする請求項１〜７いずれか１項記載の車両用故障検出装置。
9. 前記乗員状態監視手段は、乗員の発声した音声を集音するマイクと、音声をテキストデータに変換する音声処理装置とを有し、
   前記故障兆候検出手段は、前記テキストデータから前記兆候を検出する、
   ことを特徴とする請求項１記載の車両用故障検出装置。
10. 前記乗員状態監視手段は、乗員の状態を検出するセンサと、センサ信号から生体情報を検出する生体情報処理装置とを有し、
    前記故障兆候検出手段は、前記生体情報から前記兆候を検出する、
    ことを特徴とする請求項１記載の車両用故障検出装置。
11. 乗員の状態を監視する乗員状態監視手段と、
    車両に搭載される制御装置の故障の兆候を、乗員の状態から検出する故障兆候検出手段と、接続された電子制御ユニットであって、
    予め定められている閾値と制御装置に入力される信号値を比較して故障を検出する故障検出手段と、
    前記故障兆候検出手段が前記兆候を検出して異常検知情報を受信した場合、異常を検出しやすい側に前記閾値を変更する閾値変更手段と、
    を有することを特徴とする電子制御ユニット。
12. 乗員状態監視手段が、乗員の状態を監視するステップと、
    故障兆候検出手段が、車両に搭載される制御装置の故障の兆候を、乗員の状態から検出するステップと、
    故障検出手段が、予め定められている閾値と制御装置に入力される信号値を比較して故障を検出するステップと、
    閾値変更手段が、前記故障兆候検出手段が前記兆候を検出した場合、異常を検出しやすい側に前記閾値を変更するステップと、
    を有することを特徴とする車両用故障検出方法。

Images