異常判定装置、異常判定プログラム及び異常判定方法
【課題】修理後に異常が再発した場合にもその異常の発生をセンタへ通知することができるようにする。
【解決手段】ナビゲーション装置は、車両において故障が発生したと判定した場合にその故障を情報収集センタのサーバへ通知する（Ｓ１０１）。具体的には、このナビゲーション装置は、ある故障が発生していないと判定している状態においてその故障の検出される状態が８秒間継続したことを条件としてその故障が発生したと判定する。そして、その後にその故障の検出されない状態が１０トリップ継続したことを条件としてその故障が解消したと判定するが、故障に対する修理が完了したことを検出した場合には（Ｓ１０６：ＹＥＳ）、１０トリップを１トリップに短縮する（Ｓ１０８）。
【解決手段】ナビゲーション装置は、車両において故障が発生したと判定した場合にその故障を情報収集センタのサーバへ通知する（Ｓ１０１）。具体的には、このナビゲーション装置は、ある故障が発生していないと判定している状態においてその故障の検出される状態が８秒間継続したことを条件としてその故障が発生したと判定する。そして、その後にその故障の検出されない状態が１０トリップ継続したことを条件としてその故障が解消したと判定するが、故障に対する修理が完了したことを検出した場合には（Ｓ１０６：ＹＥＳ）、１０トリップを１トリップに短縮する（Ｓ１０８）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両における異常の発生の有無を判定するための異常判定装置、異常判定プログラム及び異常判定方法に関するものである。
【背景技術】
【０００２】
従来、車両において異常が発生した場合に、その情報を車両から外部のセンタへ自動的に通知する技術が知られている。例えば、特許文献１に記載の情報提供システムでは、車両に搭載された通信ＥＣＵが、他のＥＣＵと定期的に通信を行ってその動作状態をモニタリングし、正常に動作していない場合にはそのデータを情報提供センタに送信する。このようにすることで、情報提供センタでは、異常の生じた機能を特定し、その機能を代行あるいは部分代行するといったことが可能となる。
【特許文献１】特開平１０−２９７４４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、車両において検出される異常は、異常の検出される状態と検出されない状態とが頻繁に変化する（チャタリングが生じる）ことがある。例えば、オイルやウォッシャー液などの液面レベルに基づき異常を検出するものでは、坂道等による車両の傾きの影響を受けて、異常の検出されない状態から一時的に異常の検出される状態となったり、逆に、異常の検出される状態から一時的に異常の検出されない状態となったりすることがある。したがって、異常の検出状態に応じて直ちに異常が発生した（あるいは解消した）と判定することは適切ではない。
【０００４】
そこで、異常の検出される状態が一定期間継続したことをもって異常が発生したと判定する手法が有効となる。また、異常が発生したと判定した後にその異常が解消したと判定する場合も同様であり、異常の検出されない状態が一定期間継続したことをもって異常が解消したと判定する。
【０００５】
ここで、上記一定期間は、チャタリングの影響を受けにくくするという面では長期間に設定することが好ましいが、異常の発生については早期に通知することも重要となる。そこで、異常が発生したと判定するための期間は比較的短期間（例えば８秒間）に設定され、異常が発生したと判定した後にその異常が解消したと判定するための期間は比較的長期間（例えば１０トリップ）に設定されることが好ましい。なお、ここでいうトリップとは、イグニッションスイッチがオンされてから次にオンされるまでの期間を意味する。
【０００６】
例えば、図４に示すように、車両において故障の有無を判定する装置は、同一の故障通知を一定期間（例えば８秒間）継続して受信した時点で、故障が発生したという判定結果を確定する。その後、その故障通知が受信されない状態が一定期間（例えば１０トリップ）継続した時点で、故障が解消したという判定結果を確定する。
【０００７】
このような仕組みを導入することにより、車両の修理を行うディーラでは、車両の故障情報をセンタから事前に取得して準備を行うことができ、これにより車両の修理を効率よく行うことができる。
【０００８】
しかしながら、車両がディーラで修理されてユーザへ返却された後に故障が再発した場合には、その故障の発生がセンタへ通知されないといった問題が生じ得る。具体的には、１０トリップが継続する前に、つまり故障が解消したと判定する前に故障が再発した場合であり、故障状態が継続しているのと同様の扱いになってしまう。
【０００９】
本発明は、こうした問題にかんがみてなされたものであり、修理後に異常が再発した場合にもその異常の発生をセンタへ通知することのできる異常判定装置、異常判定プログラム及び異常判定方法を提供することを目的としている。
【課題を解決するための手段】
【００１０】
上記目的を達成するためになされた本発明の請求項１に記載の異常判定装置では、通知手段が、車両において異常が発生したと判定した場合にその異常を外部へ通知する。具体的には、この異常判定装置は、ある異常が発生していないと判定している状態においてその異常の検出される状態が所定の異常発生判定期間継続したことを条件としてその異常が発生したと判定する。そして、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定する。
【００１１】
また、この異常判定装置では、完了検出手段が、異常に対する修理が完了したことを検出し、完了検出手段により修理の完了が検出された場合に、短縮手段が、異常解消判定期間を短縮する。
【００１２】
このような異常判定装置によれば、異常に対する修理が完了した後でその異常が再発した場合に、その異常が外部へ通知されないといったことを防ぐことができる。すなわち、前述したように、異常に対する修理が完了しても、異常解消判定期間内（異常が解消したと判定する前）にその異常が再発すると、異常状態が継続しているのと同様の扱いになってしまい、異常の通知が行われない。このため、実際には異常が新たに発生したにもかかわらず、その異常が外部へ通知されないことになってしまう。
【００１３】
これに対し、本発明の異常判定装置では、修理の完了を検出した場合に異常解消判定期間を短縮するようにしているため、異常解消判定期間内に異常が再発するといったことが生じにくくなる。
【００１４】
ここで、異常に対する修理が完了したことの検出は、例えば請求項２に記載のように、完了検出手段が、修理の際に接続されるサービスツールからの情報に基づき検出するとよい。このようにすれば、異常に対する修理が完了したことを容易にかつ正確に検出することができる。
【００１５】
また、修理中には、動作チェックなどを行うことにより、新たに異常が発生したと判定してその異常を外部へ通知してしまうことが考えられるが、このように修理中に検出される異常は外部へ通知しないことが好ましい。
【００１６】
そこで、請求項３に記載の異常判定装置では、開始検出手段が、異常に対する修理が開始されたことを検出し、通知手段は、開始検出手段により修理の開始が検出されてから完了検出手段により修理の完了が検出されるまでの期間は異常の通知を行わない。このような異常判定装置によれば、修理中に異常を通知してしまうことを防ぐことができる。
【００１７】
次に、請求項４に記載の異常判定プログラムは、車両において異常が発生したと判定した場合にその異常を外部へ通知する通知手段を備え、その異常が発生していないと判定している状態においてその異常の検出される状態が所定の異常発生判定期間継続したことを条件としてその異常が発生したと判定するとともに、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定する異常判定装置としてコンピュータを機能させるためのものである。そして、この異常判定プログラムは、その異常に対する修理が完了したことを検出する完了検出手段と、完了検出手段により修理の完了が検出された場合に、異常解消判定期間を短縮する短縮手段としてコンピュータを機能させる。
【００１８】
このような異常判定プログラムによれば、請求項１に記載の異常判定装置としてコンピュータを機能させることができ、これにより前述した効果を得ることができる。
また、請求項５に記載の異常判定方法は、車両において異常の検出される状態が、その異常が発生していないと判定している状態において所定の異常発生判定期間継続したことを条件として、その異常が発生したと判定するとともに、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定するものである。そして、この異常判定方法では、異常に対する修理が完了したことを検出した場合に、異常解消判定期間を短縮する。
【００１９】
このような異常判定方法によれば、請求項１に記載の異常判定装置と同様の効果を得ることができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明が適用された実施形態について、図面を用いて説明する。
［１．全体構成］
図１は、実施形態の情報提供システムの概略構成を表すブロック図である。
【００２１】
同図に示すように、この情報提供システムは、複数の車両から無線送信される情報を車両外部の情報収集センタが管理する仕組みを実現するものである。
この情報提供システムを利用する車両には、ナビゲーション装置１０と、通信機２０とが搭載されている。
【００２２】
ナビゲーション装置１０は、メインマイコン１１と、車載ＬＡＮドライバ１２とを備える。車載ＬＡＮドライバ１２は、車載ＬＡＮ３０を介して接続されたＥＣＵ４０，４０，…との間で通信を行うためのインタフェースとして機能する。また、メインマイコン１１は、通信機２０を介して、遠隔地に存在する情報収集センタと無線通信を行う。
【００２３】
一方、情報収集センタには、サーバ５１と、データベース（ＤＢ）５２とが設けられている。データベース５２は、車両から収集された情報を管理するためのものである。
［２．処理の概要］
次に、この情報提供システムで実現される処理の概要について説明する。
【００２４】
図２に示すように、車両において故障が発生すると、ＥＣＵ４０によってその故障が検出され、その故障に関する故障通知（ウォーニング通知）がそのＥＣＵ４０からナビゲーション装置１０へ送信される。具体的には、例えば、ナビゲーション装置１０がウォーニングランプ等の情報を定期的に監視し、異常を検出した場合にすべてのＥＣＵ４０に問い合わせを行い、その異常に対応するＥＣＵ４０が故障通知をナビゲーション装置１０へ送信する、といった仕組みで実現される。
【００２５】
ナビゲーション装置１０では、故障通知を８秒間継続して受信した時点で、故障が発生したという判定結果を確定し、その情報を情報収集センタのサーバ５１へ通知（アップロード）する。これにより、車両の修理を行うディーラは、情報収集センタへの問い合わせや情報収集センタからの通知などにより、車両の故障情報を事前に取得して修理の準備を行うことができる。
【００２６】
その後、ナビゲーション装置１０は、その故障に関する故障通知がＥＣＵ４０から送信されない状態が１０トリップ継続した時点で、故障が解消したという判定結果を確定し、その情報を情報収集センタのサーバ５１へ通知（アップロード）する。ただし、故障が解消したという判定結果を確定する前に、ディーラで故障が修理されたと判定した場合には、１０トリップを１トリップに変更して同様の処理を行う。なお、ディーラで故障が修理されたという判定は、ディーラにおいて故障の修理の際に接続されるサービスツールからの情報に基づき行う。
【００２７】
［３．ナビゲーション装置が実行する処理］
次に、ナビゲーション装置１０のメインマイコン１１が、あらかじめ記憶しているプログラムに従い実行する故障確定処理について、図３のフローチャートを用いて説明する。なお、この故障確定処理は、故障が発生したという判定結果を確定した時点（故障通知を８秒間継続して受信した時点）で開始される。
【００２８】
メインマイコン１１は、この故障確定処理を開始すると、まずＳ１０１で、確定した故障情報を情報収集センタのサーバ５１へ通知（アップロード）する。
続いて、Ｓ１０２では、トリップ数を計数するための故障解消カウンタＮの値を１０に設定する。
【００２９】
続いて、Ｓ１０３では、確定した故障に関する故障通知がＥＣＵ４０から受信されたか否かを判定する。
そして、Ｓ１０３で、確定した故障に関する故障通知が受信されていないと判定した場合には、Ｓ１０４へ移行し、ディーラでの故障修理の開始を検出したか否かを判定する。具体的には、サービスツールが接続されたことを、修理の開始として検出する。
【００３０】
そして、Ｓ１０４で、ディーラでの故障修理の開始を検出したと判定した場合には、Ｓ１０５へ移行し、故障情報アップロードマスク機能をオンした後、Ｓ１０６へ移行する。ここで、故障情報アップロードマスク機能とは、当該ナビゲーション装置１０から情報収集センタのサーバ５１への故障情報の通知（アップロード）を禁止する機能のことであり、この機能がオンされている状態では、新たな故障通知が受信された場合にも、サーバ５１への情報の通知を行わない。このようにしているのは、修理中における動作チェック時に、故障通知が受信されてしまうことがあるからである。
【００３１】
一方、Ｓ１０４で、ディーラでの故障修理の開始を検出していないと判定した場合には、そのままＳ１０６へ移行する。
Ｓ１０６では、ディーラでの故障修理の完了を検出したか否かを判定する。具体的には、サービスツールから修理が完了したことを示す信号が受信されたことを、修理の完了として検出する。
【００３２】
そして、Ｓ１０６で、ディーラでの故障修理の完了を検出したと判定した場合には、Ｓ１０７へ移行し、Ｓ１０５でオンした故障情報アップロードマスク機能をオフする。続いて、Ｓ１０８で、故障解消カウンタＮの値を１に設定する。その後、Ｓ１０９へ移行する。
【００３３】
一方、Ｓ１０６で、ディーラでの故障修理の完了を検出していないと判定した場合には、そのままＳ１０９へ移行する。
Ｓ１０９では、イグニッションスイッチがオフからオンにされたか否かを判定する。
【００３４】
そして、Ｓ１０９で、イグニッションスイッチがオフからオンにされていないと判定した場合には、Ｓ１０３へ戻る。
一方、Ｓ１０９で、イグニッションスイッチがオフからオンにされたと判定した場合には、Ｓ１１０へ移行し、故障解消カウンタＮの値をデクリメント（１を減算）する。つまり、トリップ数を計数する。
【００３５】
続いて、Ｓ１１１では、故障解消カウンタＮの値が０以下になったか否かを判定する。
そして、Ｓ１１１で、故障解消カウンタＮの値が０以下になっていないと判定した場合には、Ｓ１０３へ戻る。
【００３６】
つまり、確定した故障に関する故障通知が受信されない間は（Ｓ１０３：ＮＯ）、Ｓ１０３〜Ｓ１０９の処理が繰り返し実行され、イグニッションスイッチがオフからオンにされるごとに、故障解消カウンタＮの値が１ずつ減算される。したがって、１０トリップの期間中（故障解消カウンタＮ＞０となっている間）は、Ｓ１０３〜Ｓ１０９の処理が繰り返されることになる。
【００３７】
ただし、前述したＳ１０３で、確定した故障に関する故障通知が受信されたと判定した場合には、Ｓ１０２へ戻り、故障解消カウンタＮの値が１０に設定（リセット）されることになる。つまり、確定した故障に関する故障通知が受信されない状態が継続する必要がある。
【００３８】
一方、Ｓ１１１で、故障解消カウンタＮの値が０以下になったと判定した場合には、本故障確定処理を終了する。これにより、故障が解消したという判定結果を確定する。
［４．効果］
以上説明したように、本実施形態の情報提供システムにおいて、ナビゲーション装置１０は、ある故障が発生していないと判定している状態においてその故障の検出される状態が８秒間継続したことを条件としてその故障が発生したと判定する。そして、その後にその故障の検出されない状態が１０トリップ継続したことを条件としてその故障が解消したと判定するが、故障に対する修理が完了したことを検出した場合には（Ｓ１０６：ＹＥＳ）、１０トリップを１トリップに短縮する（Ｓ１０８）。
【００３９】
このようなナビゲーション装置１０によれば、故障に対する修理が完了した後でその故障が再発した場合に、その故障が情報収集センタのサーバ５１へ通知されないといったことを防ぐことができる。
【００４０】
また、ナビゲーション装置１０は、修理の際に接続されるサービスツールからの情報に基づき修理が完了したことを検出するようにしているため、故障に対する修理が完了したことを容易にかつ正確に検出することができる。
【００４１】
さらに、ナビゲーション装置１０は、故障に対する修理中は故障情報アップロードマスク機能をオンにするため、修理中であるにもかかわらず情報収集センタのサーバ５１へ故障を通知してしまうことを防ぐことができる。
【００４２】
［５．特許請求の範囲との対応］
なお、本実施形態の情報提供システムでは、ナビゲーション装置１０が異常判定装置に相当する。そして、Ｓ１０１の処理を実行するメインマイコン１１が通知手段に相当し、Ｓ１０４の処理を実行するメインマイコン１１が開始検出手段に相当し、Ｓ１０６の処理を実行するメインマイコン１１が完了検出手段に相当し、Ｓ１０８の処理を実行するメインマイコン１１が短縮手段に相当する。
【００４３】
［６．他の形態］
以上、本発明の実施形態について説明したが、本発明は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。
【００４４】
例えば、上記実施形態では、本発明の異常発生判定期間を８秒間、異常解消判定期間を１０トリップに設定した構成を示したが、これらはあくまでも一例であり、適宜最適な期間に設定すればよい。
【００４５】
また、上記実施形態では、本発明の異常判定装置をナビゲーション装置に適用した構成を例示したが、これに限定されるものではなく、ナビゲーション装置以外の車載装置に適用することも可能である。また、上記実施形態では、異常として故障を判定する構成を例示したが、故障以外の異常（液量の不足等）についても同様である。
【図面の簡単な説明】
【００４６】
【図１】実施形態の情報提供システムの概略構成を表すブロック図である。
【図２】情報提供システムで実現される処理の概要を表すタイムチャートである。
【図３】故障確定処理のフローチャートである。
【図４】車両における故障の有無の判定方法を説明するための説明図である。
【符号の説明】
【００４７】
１０…ナビゲーション装置、１１…メインマイコン、１２…車載ＬＡＮドライバ、２０…通信機、３０…車載ＬＡＮ、４０…ＥＣＵ、５１…サーバ、５２…データベース
【技術分野】
【０００１】
本発明は、車両における異常の発生の有無を判定するための異常判定装置、異常判定プログラム及び異常判定方法に関するものである。
【背景技術】
【０００２】
従来、車両において異常が発生した場合に、その情報を車両から外部のセンタへ自動的に通知する技術が知られている。例えば、特許文献１に記載の情報提供システムでは、車両に搭載された通信ＥＣＵが、他のＥＣＵと定期的に通信を行ってその動作状態をモニタリングし、正常に動作していない場合にはそのデータを情報提供センタに送信する。このようにすることで、情報提供センタでは、異常の生じた機能を特定し、その機能を代行あるいは部分代行するといったことが可能となる。
【特許文献１】特開平１０−２９７４４６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、車両において検出される異常は、異常の検出される状態と検出されない状態とが頻繁に変化する（チャタリングが生じる）ことがある。例えば、オイルやウォッシャー液などの液面レベルに基づき異常を検出するものでは、坂道等による車両の傾きの影響を受けて、異常の検出されない状態から一時的に異常の検出される状態となったり、逆に、異常の検出される状態から一時的に異常の検出されない状態となったりすることがある。したがって、異常の検出状態に応じて直ちに異常が発生した（あるいは解消した）と判定することは適切ではない。
【０００４】
そこで、異常の検出される状態が一定期間継続したことをもって異常が発生したと判定する手法が有効となる。また、異常が発生したと判定した後にその異常が解消したと判定する場合も同様であり、異常の検出されない状態が一定期間継続したことをもって異常が解消したと判定する。
【０００５】
ここで、上記一定期間は、チャタリングの影響を受けにくくするという面では長期間に設定することが好ましいが、異常の発生については早期に通知することも重要となる。そこで、異常が発生したと判定するための期間は比較的短期間（例えば８秒間）に設定され、異常が発生したと判定した後にその異常が解消したと判定するための期間は比較的長期間（例えば１０トリップ）に設定されることが好ましい。なお、ここでいうトリップとは、イグニッションスイッチがオンされてから次にオンされるまでの期間を意味する。
【０００６】
例えば、図４に示すように、車両において故障の有無を判定する装置は、同一の故障通知を一定期間（例えば８秒間）継続して受信した時点で、故障が発生したという判定結果を確定する。その後、その故障通知が受信されない状態が一定期間（例えば１０トリップ）継続した時点で、故障が解消したという判定結果を確定する。
【０００７】
このような仕組みを導入することにより、車両の修理を行うディーラでは、車両の故障情報をセンタから事前に取得して準備を行うことができ、これにより車両の修理を効率よく行うことができる。
【０００８】
しかしながら、車両がディーラで修理されてユーザへ返却された後に故障が再発した場合には、その故障の発生がセンタへ通知されないといった問題が生じ得る。具体的には、１０トリップが継続する前に、つまり故障が解消したと判定する前に故障が再発した場合であり、故障状態が継続しているのと同様の扱いになってしまう。
【０００９】
本発明は、こうした問題にかんがみてなされたものであり、修理後に異常が再発した場合にもその異常の発生をセンタへ通知することのできる異常判定装置、異常判定プログラム及び異常判定方法を提供することを目的としている。
【課題を解決するための手段】
【００１０】
上記目的を達成するためになされた本発明の請求項１に記載の異常判定装置では、通知手段が、車両において異常が発生したと判定した場合にその異常を外部へ通知する。具体的には、この異常判定装置は、ある異常が発生していないと判定している状態においてその異常の検出される状態が所定の異常発生判定期間継続したことを条件としてその異常が発生したと判定する。そして、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定する。
【００１１】
また、この異常判定装置では、完了検出手段が、異常に対する修理が完了したことを検出し、完了検出手段により修理の完了が検出された場合に、短縮手段が、異常解消判定期間を短縮する。
【００１２】
このような異常判定装置によれば、異常に対する修理が完了した後でその異常が再発した場合に、その異常が外部へ通知されないといったことを防ぐことができる。すなわち、前述したように、異常に対する修理が完了しても、異常解消判定期間内（異常が解消したと判定する前）にその異常が再発すると、異常状態が継続しているのと同様の扱いになってしまい、異常の通知が行われない。このため、実際には異常が新たに発生したにもかかわらず、その異常が外部へ通知されないことになってしまう。
【００１３】
これに対し、本発明の異常判定装置では、修理の完了を検出した場合に異常解消判定期間を短縮するようにしているため、異常解消判定期間内に異常が再発するといったことが生じにくくなる。
【００１４】
ここで、異常に対する修理が完了したことの検出は、例えば請求項２に記載のように、完了検出手段が、修理の際に接続されるサービスツールからの情報に基づき検出するとよい。このようにすれば、異常に対する修理が完了したことを容易にかつ正確に検出することができる。
【００１５】
また、修理中には、動作チェックなどを行うことにより、新たに異常が発生したと判定してその異常を外部へ通知してしまうことが考えられるが、このように修理中に検出される異常は外部へ通知しないことが好ましい。
【００１６】
そこで、請求項３に記載の異常判定装置では、開始検出手段が、異常に対する修理が開始されたことを検出し、通知手段は、開始検出手段により修理の開始が検出されてから完了検出手段により修理の完了が検出されるまでの期間は異常の通知を行わない。このような異常判定装置によれば、修理中に異常を通知してしまうことを防ぐことができる。
【００１７】
次に、請求項４に記載の異常判定プログラムは、車両において異常が発生したと判定した場合にその異常を外部へ通知する通知手段を備え、その異常が発生していないと判定している状態においてその異常の検出される状態が所定の異常発生判定期間継続したことを条件としてその異常が発生したと判定するとともに、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定する異常判定装置としてコンピュータを機能させるためのものである。そして、この異常判定プログラムは、その異常に対する修理が完了したことを検出する完了検出手段と、完了検出手段により修理の完了が検出された場合に、異常解消判定期間を短縮する短縮手段としてコンピュータを機能させる。
【００１８】
このような異常判定プログラムによれば、請求項１に記載の異常判定装置としてコンピュータを機能させることができ、これにより前述した効果を得ることができる。
また、請求項５に記載の異常判定方法は、車両において異常の検出される状態が、その異常が発生していないと判定している状態において所定の異常発生判定期間継続したことを条件として、その異常が発生したと判定するとともに、その後にその異常の検出されない状態が所定の異常解消判定期間継続したことを条件としてその異常が解消したと判定するものである。そして、この異常判定方法では、異常に対する修理が完了したことを検出した場合に、異常解消判定期間を短縮する。
【００１９】
このような異常判定方法によれば、請求項１に記載の異常判定装置と同様の効果を得ることができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明が適用された実施形態について、図面を用いて説明する。
［１．全体構成］
図１は、実施形態の情報提供システムの概略構成を表すブロック図である。
【００２１】
同図に示すように、この情報提供システムは、複数の車両から無線送信される情報を車両外部の情報収集センタが管理する仕組みを実現するものである。
この情報提供システムを利用する車両には、ナビゲーション装置１０と、通信機２０とが搭載されている。
【００２２】
ナビゲーション装置１０は、メインマイコン１１と、車載ＬＡＮドライバ１２とを備える。車載ＬＡＮドライバ１２は、車載ＬＡＮ３０を介して接続されたＥＣＵ４０，４０，…との間で通信を行うためのインタフェースとして機能する。また、メインマイコン１１は、通信機２０を介して、遠隔地に存在する情報収集センタと無線通信を行う。
【００２３】
一方、情報収集センタには、サーバ５１と、データベース（ＤＢ）５２とが設けられている。データベース５２は、車両から収集された情報を管理するためのものである。
［２．処理の概要］
次に、この情報提供システムで実現される処理の概要について説明する。
【００２４】
図２に示すように、車両において故障が発生すると、ＥＣＵ４０によってその故障が検出され、その故障に関する故障通知（ウォーニング通知）がそのＥＣＵ４０からナビゲーション装置１０へ送信される。具体的には、例えば、ナビゲーション装置１０がウォーニングランプ等の情報を定期的に監視し、異常を検出した場合にすべてのＥＣＵ４０に問い合わせを行い、その異常に対応するＥＣＵ４０が故障通知をナビゲーション装置１０へ送信する、といった仕組みで実現される。
【００２５】
ナビゲーション装置１０では、故障通知を８秒間継続して受信した時点で、故障が発生したという判定結果を確定し、その情報を情報収集センタのサーバ５１へ通知（アップロード）する。これにより、車両の修理を行うディーラは、情報収集センタへの問い合わせや情報収集センタからの通知などにより、車両の故障情報を事前に取得して修理の準備を行うことができる。
【００２６】
その後、ナビゲーション装置１０は、その故障に関する故障通知がＥＣＵ４０から送信されない状態が１０トリップ継続した時点で、故障が解消したという判定結果を確定し、その情報を情報収集センタのサーバ５１へ通知（アップロード）する。ただし、故障が解消したという判定結果を確定する前に、ディーラで故障が修理されたと判定した場合には、１０トリップを１トリップに変更して同様の処理を行う。なお、ディーラで故障が修理されたという判定は、ディーラにおいて故障の修理の際に接続されるサービスツールからの情報に基づき行う。
【００２７】
［３．ナビゲーション装置が実行する処理］
次に、ナビゲーション装置１０のメインマイコン１１が、あらかじめ記憶しているプログラムに従い実行する故障確定処理について、図３のフローチャートを用いて説明する。なお、この故障確定処理は、故障が発生したという判定結果を確定した時点（故障通知を８秒間継続して受信した時点）で開始される。
【００２８】
メインマイコン１１は、この故障確定処理を開始すると、まずＳ１０１で、確定した故障情報を情報収集センタのサーバ５１へ通知（アップロード）する。
続いて、Ｓ１０２では、トリップ数を計数するための故障解消カウンタＮの値を１０に設定する。
【００２９】
続いて、Ｓ１０３では、確定した故障に関する故障通知がＥＣＵ４０から受信されたか否かを判定する。
そして、Ｓ１０３で、確定した故障に関する故障通知が受信されていないと判定した場合には、Ｓ１０４へ移行し、ディーラでの故障修理の開始を検出したか否かを判定する。具体的には、サービスツールが接続されたことを、修理の開始として検出する。
【００３０】
そして、Ｓ１０４で、ディーラでの故障修理の開始を検出したと判定した場合には、Ｓ１０５へ移行し、故障情報アップロードマスク機能をオンした後、Ｓ１０６へ移行する。ここで、故障情報アップロードマスク機能とは、当該ナビゲーション装置１０から情報収集センタのサーバ５１への故障情報の通知（アップロード）を禁止する機能のことであり、この機能がオンされている状態では、新たな故障通知が受信された場合にも、サーバ５１への情報の通知を行わない。このようにしているのは、修理中における動作チェック時に、故障通知が受信されてしまうことがあるからである。
【００３１】
一方、Ｓ１０４で、ディーラでの故障修理の開始を検出していないと判定した場合には、そのままＳ１０６へ移行する。
Ｓ１０６では、ディーラでの故障修理の完了を検出したか否かを判定する。具体的には、サービスツールから修理が完了したことを示す信号が受信されたことを、修理の完了として検出する。
【００３２】
そして、Ｓ１０６で、ディーラでの故障修理の完了を検出したと判定した場合には、Ｓ１０７へ移行し、Ｓ１０５でオンした故障情報アップロードマスク機能をオフする。続いて、Ｓ１０８で、故障解消カウンタＮの値を１に設定する。その後、Ｓ１０９へ移行する。
【００３３】
一方、Ｓ１０６で、ディーラでの故障修理の完了を検出していないと判定した場合には、そのままＳ１０９へ移行する。
Ｓ１０９では、イグニッションスイッチがオフからオンにされたか否かを判定する。
【００３４】
そして、Ｓ１０９で、イグニッションスイッチがオフからオンにされていないと判定した場合には、Ｓ１０３へ戻る。
一方、Ｓ１０９で、イグニッションスイッチがオフからオンにされたと判定した場合には、Ｓ１１０へ移行し、故障解消カウンタＮの値をデクリメント（１を減算）する。つまり、トリップ数を計数する。
【００３５】
続いて、Ｓ１１１では、故障解消カウンタＮの値が０以下になったか否かを判定する。
そして、Ｓ１１１で、故障解消カウンタＮの値が０以下になっていないと判定した場合には、Ｓ１０３へ戻る。
【００３６】
つまり、確定した故障に関する故障通知が受信されない間は（Ｓ１０３：ＮＯ）、Ｓ１０３〜Ｓ１０９の処理が繰り返し実行され、イグニッションスイッチがオフからオンにされるごとに、故障解消カウンタＮの値が１ずつ減算される。したがって、１０トリップの期間中（故障解消カウンタＮ＞０となっている間）は、Ｓ１０３〜Ｓ１０９の処理が繰り返されることになる。
【００３７】
ただし、前述したＳ１０３で、確定した故障に関する故障通知が受信されたと判定した場合には、Ｓ１０２へ戻り、故障解消カウンタＮの値が１０に設定（リセット）されることになる。つまり、確定した故障に関する故障通知が受信されない状態が継続する必要がある。
【００３８】
一方、Ｓ１１１で、故障解消カウンタＮの値が０以下になったと判定した場合には、本故障確定処理を終了する。これにより、故障が解消したという判定結果を確定する。
［４．効果］
以上説明したように、本実施形態の情報提供システムにおいて、ナビゲーション装置１０は、ある故障が発生していないと判定している状態においてその故障の検出される状態が８秒間継続したことを条件としてその故障が発生したと判定する。そして、その後にその故障の検出されない状態が１０トリップ継続したことを条件としてその故障が解消したと判定するが、故障に対する修理が完了したことを検出した場合には（Ｓ１０６：ＹＥＳ）、１０トリップを１トリップに短縮する（Ｓ１０８）。
【００３９】
このようなナビゲーション装置１０によれば、故障に対する修理が完了した後でその故障が再発した場合に、その故障が情報収集センタのサーバ５１へ通知されないといったことを防ぐことができる。
【００４０】
また、ナビゲーション装置１０は、修理の際に接続されるサービスツールからの情報に基づき修理が完了したことを検出するようにしているため、故障に対する修理が完了したことを容易にかつ正確に検出することができる。
【００４１】
さらに、ナビゲーション装置１０は、故障に対する修理中は故障情報アップロードマスク機能をオンにするため、修理中であるにもかかわらず情報収集センタのサーバ５１へ故障を通知してしまうことを防ぐことができる。
【００４２】
［５．特許請求の範囲との対応］
なお、本実施形態の情報提供システムでは、ナビゲーション装置１０が異常判定装置に相当する。そして、Ｓ１０１の処理を実行するメインマイコン１１が通知手段に相当し、Ｓ１０４の処理を実行するメインマイコン１１が開始検出手段に相当し、Ｓ１０６の処理を実行するメインマイコン１１が完了検出手段に相当し、Ｓ１０８の処理を実行するメインマイコン１１が短縮手段に相当する。
【００４３】
［６．他の形態］
以上、本発明の実施形態について説明したが、本発明は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。
【００４４】
例えば、上記実施形態では、本発明の異常発生判定期間を８秒間、異常解消判定期間を１０トリップに設定した構成を示したが、これらはあくまでも一例であり、適宜最適な期間に設定すればよい。
【００４５】
また、上記実施形態では、本発明の異常判定装置をナビゲーション装置に適用した構成を例示したが、これに限定されるものではなく、ナビゲーション装置以外の車載装置に適用することも可能である。また、上記実施形態では、異常として故障を判定する構成を例示したが、故障以外の異常（液量の不足等）についても同様である。
【図面の簡単な説明】
【００４６】
【図１】実施形態の情報提供システムの概略構成を表すブロック図である。
【図２】情報提供システムで実現される処理の概要を表すタイムチャートである。
【図３】故障確定処理のフローチャートである。
【図４】車両における故障の有無の判定方法を説明するための説明図である。
【符号の説明】
【００４７】
１０…ナビゲーション装置、１１…メインマイコン、１２…車載ＬＡＮドライバ、２０…通信機、３０…車載ＬＡＮ、４０…ＥＣＵ、５１…サーバ、５２…データベース
【特許請求の範囲】
【請求項１】
車両において異常が発生したと判定した場合に前記異常を外部へ通知する通知手段を備え、
前記異常が発生していないと判定している状態において前記異常の検出される状態が所定の異常発生判定期間継続したことを条件として前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定装置であって、
前記異常に対する修理が完了したことを検出する完了検出手段と、
前記完了検出手段により修理の完了が検出された場合に、前記異常解消判定期間を短縮する短縮手段と、
を備えることを特徴とする異常判定装置。
【請求項２】
前記完了検出手段は、修理の際に接続されるサービスツールからの情報に基づき、修理が完了したことを検出すること
を特徴とする請求項１に記載の異常判定装置。
【請求項３】
前記異常に対する修理が開始されたことを検出する開始検出手段を備え、
前記通知手段は、前記開始検出手段により修理の開始が検出されてから前記完了検出手段により修理の完了が検出されるまでの期間は異常の通知を行わないこと
を特徴とする請求項１又は請求項２に記載の異常判定装置。
【請求項４】
車両において異常が発生したと判定した場合に前記異常を外部へ通知する通知手段を備え、前記異常が発生していないと判定している状態において前記異常の検出される状態が所定の異常発生判定期間継続したことを条件として前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定装置としてコンピュータを機能させるための異常判定プログラムであって、
前記異常に対する修理が完了したことを検出する完了検出手段と、
前記完了検出手段により修理の完了が検出された場合に、前記異常解消判定期間を短縮する短縮手段
としてコンピュータを機能させることを特徴とする異常判定プログラム。
【請求項５】
車両において異常の検出される状態が、その異常が発生していないと判定している状態において所定の異常発生判定期間継続したことを条件として、前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定方法であって、
前記異常に対する修理が完了したことを検出した場合に、前記異常解消判定期間を短縮すること
を特徴とする異常判定方法。
【請求項１】
車両において異常が発生したと判定した場合に前記異常を外部へ通知する通知手段を備え、
前記異常が発生していないと判定している状態において前記異常の検出される状態が所定の異常発生判定期間継続したことを条件として前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定装置であって、
前記異常に対する修理が完了したことを検出する完了検出手段と、
前記完了検出手段により修理の完了が検出された場合に、前記異常解消判定期間を短縮する短縮手段と、
を備えることを特徴とする異常判定装置。
【請求項２】
前記完了検出手段は、修理の際に接続されるサービスツールからの情報に基づき、修理が完了したことを検出すること
を特徴とする請求項１に記載の異常判定装置。
【請求項３】
前記異常に対する修理が開始されたことを検出する開始検出手段を備え、
前記通知手段は、前記開始検出手段により修理の開始が検出されてから前記完了検出手段により修理の完了が検出されるまでの期間は異常の通知を行わないこと
を特徴とする請求項１又は請求項２に記載の異常判定装置。
【請求項４】
車両において異常が発生したと判定した場合に前記異常を外部へ通知する通知手段を備え、前記異常が発生していないと判定している状態において前記異常の検出される状態が所定の異常発生判定期間継続したことを条件として前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定装置としてコンピュータを機能させるための異常判定プログラムであって、
前記異常に対する修理が完了したことを検出する完了検出手段と、
前記完了検出手段により修理の完了が検出された場合に、前記異常解消判定期間を短縮する短縮手段
としてコンピュータを機能させることを特徴とする異常判定プログラム。
【請求項５】
車両において異常の検出される状態が、その異常が発生していないと判定している状態において所定の異常発生判定期間継続したことを条件として、前記異常が発生したと判定するとともに、その後に前記異常の検出されない状態が所定の異常解消判定期間継続したことを条件として前記異常が解消したと判定する異常判定方法であって、
前記異常に対する修理が完了したことを検出した場合に、前記異常解消判定期間を短縮すること
を特徴とする異常判定方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１０−７９６４９（Ｐ２０１０−７９６４９Ａ）
【公開日】平成２２年４月８日（２０１０．４．８）
【国際特許分類】
【出願番号】特願２００８−２４８０１８（Ｐ２００８−２４８０１８）
【出願日】平成２０年９月２６日（２００８．９．２６）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
【公開日】平成２２年４月８日（２０１０．４．８）
【国際特許分類】
【出願日】平成２０年９月２６日（２００８．９．２６）
【出願人】（０００００４２６０）株式会社デンソー (27,639)
【Ｆターム（参考）】
[ Back to top ]