JP2010032431A - リモート車両診断方法、リモート車両診断システム、及び車載診断装置 - Google Patents

Abstract

【課題】 センタからの診断要求に従って車両側で診断処理を実行するにあたり、診断の実施に伴ってユーザ側に懸念を生じさせないようにする。
【解決手段】 センタからの診断要求に対して車両が診断を実行してもよいか否かを車両自身が判断するため、診断許可条件テーブル（ａ）が、センタ内に保有されており、センタは、リモート診断を実行すべきタイミングが到来すると、車両へ診断要求と共にこの診断許可条件テーブル及び診断シナリオ（ｂ）を送信する。車両は、センタからの診断要求を受信すると、診断実行に先立って、まず、この診断要求と共に受信した診断許可条件テーブルに従い、診断を実行してよい状態にあるか否かを判断する。そして、テーブル中の各レコード１〜Ｎのうちいずれかのレコードについて各条件Ａ〜Ｃが全て満たされた場合に、診断許可条件が成立したものとして、診断シナリオに沿った診断を実行する。
【選択図】図３

Description

本発明は、センタから車両へ送信されてくる診断要求に従って車両が各種診断処理を実行するリモート車両診断システムに関する。

従来より、この種のリモート車両診断システムとして、車両とセンタとの間での情報授受により車両の故障診断を行うリモート故障診断システムが知られている（例えば、特許文献１参照。）。

特許文献１に開示されたリモート故障診断システムでは、車両において異常や故障など（以下「故障等」という）が検知されたときに、その検知時点で車両からセンタへその故障等が発生した旨を通知する。この通知に対し、センタは、故障等の原因を特定するために必要な診断手順を設定し、これを一括して車両側へ送る。車両は、このセンタから送信されてきた診断手順に従って複数の診断を行い、その診断結果を一括してセンタへ送る。

車両で故障等が発生した場合に限らず、センタから定期的に車両へ診断要求して車両側で診断を実行させ、車両がその診断結果をセンタへ送ることにより、センタが定期的に車両の状態をチェックするようなリモート車両診断システムも知られている。このような定期診断を行うことで、ユーザが販売店等に車両を持ち込むことなく、故障等の有無を定期的に監視することができる。そして、故障等の発生が検知された場合には速やかにユーザへ修理等の必要性を知らしめることができる。
特開２００６−６４６５１号公報

しかしながら、特許文献１に開示された診断システムを含む従来のリモート車両診断システムは、診断の実施場所に対する考慮がなされていないという問題があった。
例えば、出かけ先のスーパーの駐車場に車両を駐車している間にも診断サービスを受けることは可能ではあるが、その場合の診断メニューとして例えばドアのロック、アンロック動作を行うような診断メニューが組まれている場合、ユーザとしては盗難の心配を考えて離車することができない。

また、診断の実施場所に限らず、例えば車両が走行中かどうかといった車両の状態、或いは時間帯などによっても、センタからの診断要求に従って無条件に診断が実施されると各種の懸念が生じるおそれがある。

本発明は上記課題に鑑みなされたものであり、センタからの診断要求に従って車両側で診断処理を実行するにあたり、診断の実施に伴ってユーザ側に懸念を生じさせないようにすることを目的とする。

上記課題を解決するためになされた請求項１記載の発明は、センタが送信した診断要求に従って車両が診断処理を実行するリモート車両診断方法であって、車両が診断処理を実行可能な許可条件が予め設定されており、車両は、センタから診断要求を受信したときに、該受信時の当該車両の状態が許可条件を満たしているか否か判断し、該許可条件を満たしている場合に、診断処理を実行する。

このように構成された請求項１記載のリモート車両診断方法によれば、車両は、センタから診断要求があった場合に無条件に診断処理を実行するのではなく、予め設定されている許可条件を満たしている場合に、診断処理を実行する。そのため、許可条件を適宜設定することで、診断処理の実施に伴ってユーザ側（例えば車両の運転者等）に懸念を生じさせないようにすることができる。

許可条件は種々考えられ、例えば請求項２記載のように、許可条件として少なくとも、診断処理を実行可能な車両の位置を設定するようにしてもよい。
このようにすれば、センタから診断要求があったときに、車両が許可条件として設定されている位置に存在している場合に診断処理が実行され、許可条件として設定されている位置とは異なる位置に存在している場合には診断処理が実行されないため、診断処理実行場所に起因するユーザの懸念を払拭することが可能となる。具体的には、例えば車両がユーザの自宅にあるときのみ診断実行を許可することで、ユーザの監視下で診断処理を実行させることが可能となる。

また例えば、請求項３記載のように、車両が、当該車両が備えているバッテリを当該車両の外部から供給される充電用電力によって充電可能に構成されている場合は、許可条件として少なくとも、充電用電力によるバッテリへの充電が行われていることを設定するようにしてもよい。

このようにすれば、センタからの診断要求があったときに、車両のバッテリへの充電が行われている場合に診断処理が実行されることになるため、仮に電力消費の大きな診断処理が実行されたとしてもバッテリ上がりのおそれはない。そのため、診断処理実行時のバッテリ電力消費に起因するユーザの懸念（バッテリ上がりの懸念）を払拭することが可能となる。

次に、請求項４記載の発明は、センタが送信した診断要求に従って車両が診断処理を実行するリモート車両診断システムであって、当該システムは、車両が診断処理を実行可能な許可条件が予め設定された許可条件設定手段を備えている。そして、車両は、センタから診断要求を受信したときに、許可条件設定手段に設定されている許可条件に基づき、該受信時の当該車両の状態が該許可条件を満たしているか否か判断する許可条件判断手段と、この許可条件判断手段により許可条件を満たしていると判断された場合に診断処理を実行する診断実行手段と、を備えている。

このように構成された請求項４記載のリモート車両診断システムによれば、車両の診断実行手段は、予め設定されている許可条件が満たされている場合に診断処理を実行するため、請求項１記載のリモート車両診断方法を実現でき、請求項１と同様の効果が得られる。

そして、請求項５記載の発明は、請求項４記載のリモート車両診断システムであって、許可条件設定手段には、許可条件として、少なくとも、診断処理を実行可能な車両の位置である診断実行可能位置が設定されている。また、車両は、当該車両の位置を取得する位置取得手段を備えている。そして、許可条件判断手段は、センタから診断要求を受信したとき、許可条件を満たしているか否かの判断として少なくとも、位置取得手段によって取得された該受信時の車両の位置が許可条件設定手段に設定されている診断実行可能位置と一致するか否かの判断を行う。

このように構成された請求項５記載のリモート車両診断システムによれば、車両の診断実行手段は、車両が診断実行可能位置に存在している場合に診断処理を実行するため、請求項２記載のリモート車両診断方法を実現でき、請求項２と同様の効果が得られる。

そして、このように許可条件として診断実行可能位置が設定されているリモート車両診断システムは、特に請求項６に記載のように、車両が実行する診断処理には当該車両が備えるドアをアンロックさせる動作が含まれており、診断実行手段が、許可条件判断手段によって車両の位置が許可条件設定手段に設定されている診断実行可能位置と一致すると判断された場合に該ドアをアンロックさせる動作を含む診断処理を実行するよう構成されている場合に、より効果的である。

ドアをアンロックさせる動作を含む診断処理が車両の位置に関係なく無条件に行われると、車両の位置によっては、盗難等の懸念をユーザに生じさせるおそれがある。そこで、ドアをアンロックさせる動作を含む診断処理を実行するための許可条件として診断実行可能位置が設定されていれば、車両がその設定されている位置に存在している場合にそのドアのアンロックを含む診断処理が実行されることになるため、ドアのアンロック動作に伴うユーザの懸念を払拭することができる。

また、請求項７記載の発明は、請求項４〜６いずれかに記載のリモート車両診断システムであって、車両は、当該車両が備えているバッテリの充電用電力を当該車両の外部から入力するための充電用電力入力手段と、この充電用電力入力手段に入力された充電用電力の、バッテリへの充電を制御する充電制御手段と、充電用電力に基づくバッテリの充電が行われている状態であるか否かを直接又は間接的に検出する充電状態検出手段と、を備えている。また、許可条件設定手段には、許可条件として、少なくとも、充電用電力に基づくバッテリの充電が行われている状態であること、が設定されている。そして、許可条件判断手段は、センタから診断要求を受信したとき、判断として少なくとも、充電用電力に基づくバッテリの充電が行われている状態であるか否かの判断を、充電状態検出手段による検出結果に基づいて行う。

このように構成された請求項７記載のリモート車両診断システムによれば、車両の診断実行手段は、車両のバッテリが外部の充電用電力によって充電されている場合に診断処理を実行するため、請求項３記載のリモート車両診断方法を実現でき、請求項３と同様の効果が得られる。

そして、このように許可条件として充電用電力に基づくバッテリの充電が行われている状態であることが設定されているリモート車両診断システムは、特に請求項８記載のように、車両が実行する診断処理には該車両のエンジンが停止した状態でバッテリの電力を消費させる動作が含まれており、診断実行手段が、許可条件判断手段により充電用電力に基づくバッテリへの充電が行われていると判断された場合に、エンジンが停止した状態でバッテリの電力を消費させる動作を含む診断処理を実行するよう構成されている場合に、より効果的である。

エンジンが停止した状態でバッテリの電力を消費させる動作を含む診断処理が行われると、その消費電力量によっては、バッテリ上がりの懸念をユーザに生じさせるおそれがある。そこで、エンジン停止中にバッテリの電力を消費させる動作を含む診断処理を実行するための許可条件として、充電用電力に基づくバッテリへの充電が行われている状態であることが設定されていれば、診断処理はバッテリへの充電が行われている際に実行されることになるため、バッテリ上がりの懸念を払拭することができる。

請求項９記載の発明は、請求項４〜８いずれかに記載のリモート車両診断システムであって、許可条件設定手段はセンタに備えられていると共に、センタは更に、許可条件設定手段に設定されている許可条件を更新要求に従って更新する更新手段を備えている。

このように更新手段を備えた請求項９記載のリモート車両診断システムによれば、許可条件が一律に固定されず、ユーザの要望や車両の状態等に応じて許可条件を適宜設定変更することができるため、使い勝手の良い、よりユーザ本意のシステムが実現される。

この場合、ユーザが許可条件を更新する具体的方法は種々考えられるが、例えば請求項１０記載のように、センタと通信回線を介して通信可能な通信端末を備え、この通信端末を用いてユーザが更新を行えるようにしてもよい。具体的には、通信端末は、センタの許可条件設定手段に設定されている許可条件を取得する許可条件取得手段と、該許可条件取得手段により取得された許可条件を更新するための所定の更新操作を受け付ける更新操作受付手段と、該更新操作受付手段が受け付けた更新操作に対応した更新要求をセンタへ送信する更新要求送信手段と、を備える。そして、センタが備える更新手段は、通信端末からの更新要求を受信したとき、該更新要求に基づいて、許可条件設定手段に設定されている前記許可条件を更新する。

このように構成された請求項１０記載のリモート診断システムによれば、ユーザが端末装置を用いてセンタ内に設定されている許可条件を更新することができるため、ユーザにとってより使い勝手の良いシステムが実現される。

また、請求項１１記載の発明は、請求項４〜１０いずれかに記載のリモート車両診断システムであって、許可条件設定手段には、複数種類の許可条件が設定され、且つ、該複数種類の許可条件の論理的な組み合わせを示す論理式が設定されている。そして、許可条件判断手段は、複数種類の許可条件の各々について判断を行う個別判断手段と、該個別判断手段による各設定条件毎の判断結果に基づく論理式の演算結果に基づいて車両の状態が診断処理を実行可能な状態にあるか否かを最終的に判断する最終判断手段と、を備え、診断実行手段は、最終判断手段によって診断処理を実行可能な状態にあると判断された場合に、該診断処理を実行する。

このように構成された請求項１１記載のリモート車両診断システムによれば、論理式を適宜設定することで、例えば許可条件として２種類（条件Ａと条件Ｂ）が設定されている場合に、例えば条件Ａと条件Ｂの論理積を設定すれば、条件Ａと条件Ｂの双方を満たしている場合にのみ診断処理を実行するようにすることができる。また例えば、条件Ａと条件Ｂの論理和を設定すれば、条件Ａと条件Ｂのうち少なくとも一方さえ満たされていれば診断処理を実行するようにすることもできる。そのため、複数の許可条件の間で相対的な重み付けを設定することができ、ユーザの意向により即した許可条件の設定が可能となる。

そして、請求項１２記載の発明は、車両に搭載され、センタから送信されてくる診断要求に従って診断処理を実行する車載診断装置であって、センタから診断要求を受信したときに、予め設定された許可条件に基づいて、該診断要求に応じた診断処理を実行可能な状態であるか否かを判断する許可条件判断手段と、該許可条件判断手段により許可条件を満たしていると判断された場合に診断処理を実行する診断実行手段と、を備えたことを特徴とするものである。

このように構成された請求項１２記載の車載診断装置によれば、請求項４〜１１いずれかに記載のリモート車両診断システムを構成することができる。

以下に、本発明の好適な実施形態を図面に基づいて説明する。
［第１実施形態］
図１に、本発明が適用された実施形態のリモート車両診断システムの概略構成を示す。

本実施形態のリモート車両診断システム１は、リモート診断センタ（以下「センタ」と略す）２からの診断要求に従って車両３が当該車両３内の診断を実行すると共にその診断結果をセンタ２へ通知するよう構成されたシステムであり、図１に示すように、センタ２側にはセンタ内システム１０が構築されており、車両３内には車両内システム９が構築されている。

センタ２に構築されたセンタ内システム１０は、車両３を含む複数の車両にそれぞれ診断サービスを提供するサーバ１１と、診断サービスを提供する顧客毎に車両番号、診断シナリオ（図３（ｂ）参照）、診断許可条件テーブル（図３（ａ）参照）などが一元管理された診断サービス情報管理データベース（ＤＢ）１２と、診断対象の車両から通知される診断結果と照合することによって当該車両の正常／異状の判断や処置方法等を導出する為の、規範となる事例情報が蓄積された事例データベース１３と、を備え、これらがネットワーク１４を介して相互にデータ送受信可能に接続されている。

センタ２が提供する診断サービスの実行時期（実行周期）、実行する診断メニュー毎に診断の手順が明記された診断シナリオ、実行を許可する条件である診断許可条件（後述する診断許可条件テーブル）は、ユーザ毎に（車両毎に）、ユーザと診断サービス提供側との間で締結される診断サービスの契約時点で予め取り決められ、その内容はセンタ内システム１０の診断サービス情報管理データベース１２に保管されている。

サーバ１１は、その契約内容に従い、ユーザ毎に、リモート診断を実行する。即ち、リモート診断実行の際は、インターネット網５や携帯電話網４等の通信ネットワークを介して診断要求を車両３側へ送信する。この際、診断要求と共に、診断シナリオ及び診断許可条件テーブルも送信される。

車両３に構築された車両内システム９は、リモート診断マスタＥＣＵ（以下「マスタＥＣＵ」と略す）２０と、車両３内の各部を制御する複数のＥＣＵ（第１ＥＣＵ４０、第２ＥＣＵ５０、第３ＥＣＵ６０・・・、ナビＥＣＵ７０）と、を備え、これら各ＥＣＵが多重通信線３０を介して相互にデータ送受信可能に接続されている。

マスタＥＣＵ２０は、センタ２側からの診断要求に従って各種診断を実行するという、本実施形態のリモート車両診断システム１の車両３側における統括的役割を果たすものである。センタ２側からインターネット網５にて伝送され、さらに携帯電話網４を通じて無線送信された診断要求等のデータは、車両内システム９においてマスタＥＣＵ２０が備えるアンテナ２１にて受信される。

また、ユーザは、自宅６にパソコン（ＰＣ）７を備えており、パソコン７は例えば光ファイバやＡＤＳＬ等の通信回線８によってインターネット網５に接続されている。そのため、ユーザは、自宅６のパソコン７からインターネット網５を介してセンタ２のセンタ内システム１０へアクセスすることが可能であり、これにより、後述するように、診断サービス情報管理データベース１２内の診断許可条件テーブルの内容をユーザ自身がパソコン７を用いて変更することができる。

車両内システム９のより具体的な構成を、図２に基づいて説明する。図２に示すように、マスタＥＣＵ２０は、プログラムに基づく各種処理を実行するＭＣＵ３１と、このＭＣＵ３１により実行される各種プログラムが格納されたＲＯＭ３２と、ＭＣＵ３１による各種処理実行時のワークメモリとなるＲＡＭ３３と、他の各ＥＣＵ４０，５０，６０，７０・・・との間で多重通信を行うための通信コントローラ３６及びトランシーバ２４と、センタ２のセンタ内システム１０との間で無線通信を行うための、アンテナ２１を備えた通信機３４と、図示しないＧＰＳ衛星からの信号に基づいて車両３の自車位置（座標）を検出するための、アンテナ２２を備えたＧＰＳ３５と、マスタＥＣＵ２０内の各部に動作用電源を供給する電源回路２３と、を備えている。なお、ＧＰＳ３５は、自車位置情報と共に現在時刻を示す現在時刻情報も受信する。

マスタＥＣＵ２０は、多重通信線３０によって、各ＥＣＵ４０，５０，６０，７０・・・と接続されている。マスタＥＣＵ２０は、センタ２側からの診断要求に応じてリモート診断を実行する際は、診断を実行できる条件が成立しているか否かを判定するために必要な情報を各ＥＣＵから取得する。また、診断実行中は、診断に必要な各種情報を各ＥＣＵから取得する。

ナビＥＣＵ７０を除く他の各ＥＣＵ４０，５０，６０・・・には、それぞれ、当該各ＥＣＵにより制御される一又は複数のアクチュエータからなるアクチュエータ群４１，５１，６１・・・が接続されている。また、各ＥＣＵ４０，５０，６０・・・には、それぞれ、一又は複数のセンサ・スイッチ等（例えば車速センサ、Ｏ₂センサ、温度センサなど）からなるセンサ群４２，５２，６２・・・が接続されている。

本実施形態では、第１ＥＣＵ４０に接続されたセンサ群４２に、車速センサ４３が含まれており、この車速センサ４３にて検出された車速信号は第１ＥＣＵ４０に入力される。そのため、マスタＥＣＵ２０は、リモート診断を行う際、必要に応じて、この第１ＥＣＵ４０から車速信号を取得することにより、車速を知ることができる。

なお、第１ＥＣＵ４０は、車両３のエンジンを制御するものである。そのため、マスタＥＣＵ２０は、この第１ＥＣＵ４０からエンジンの状態に関する情報を取得することにより、エンジンの動作状態を知ることができる。

また、第２ＥＣＵ５０に接続されたアクチュエータ群５１には、図示しない車両３の各ドアのロック機構の動作（ロック／アンロック）を制御するドアロック機構５３が含まれている。また、第２ＥＣＵ５０に接続されたセンサ群５２には、各ドアのロック／アンロック状態を検知してその検知結果であるロックポジション信号を出力するロックポジションスイッチ５４が含まれている。そのため、マスタＥＣＵ２０は、リモート診断を行う際、必要に応じて、この第２ＥＣＵ５０からロックポジション信号を取得することにより、各ドアのロック／アンロック状態を知ることができる。

ナビＥＣＵ７０は、車両３におけるナビゲーションシステムを実現するための周知のＥＣＵであり、内蔵されているＧＰＳを介して自車位置データ（座標データ）を取得して現在位置を検出し、その検出した現在位置を地図データ上に重ね合わせてディスプレイ７１に表示させる。

ディスプレイ７１は、単に情報を表示させる機能を備えているだけではなく、ユーザが指等で表示面に接触することにより各種入力を行うことが可能ないわゆるタッチパネルをも備えている。本実施形態では、後述するように、センタ２側の診断サービス情報管理データベース１２内に格納されている診断許可条件テーブルの内容をユーザ自身が変更できるようにされており、ユーザによるその変更は、ユーザがディスプレイ７１のタッチパネルを操作することで行うことができる。

なお、本実施形態ではマスタＥＣＵ２０内にＧＰＳ３５が内蔵されているため、ナビＥＣＵ７０には必ずしもＧＰＳが内蔵されている必要性はなく、ナビＥＣＵ７０はマスタＥＣＵ２０内のＧＰＳ３５から自車位置情報を取得するようにしてもよい。逆に、マスタＥＣＵ２０にＧＰＳ３５を備えず、マスタＥＣＵ２０は自車位置情報や現在時刻情報をナビＥＣＵ７０から取得するようにしてもよい。

ここで、リモート診断の実行時にセンタ２側のセンタ内システム１０が診断対象の車両３へ送信する情報のうち、診断要求と共に送信される診断許可条件テーブル及び診断シナリオの具体例について、図３を用いて説明する。図３（ａ）は診断許可条件テーブルであり、同図（ｂ）は診断シナリオである。これら診断許可条件テーブル及び診断シナリオはいずれも、既述の通り、診断サービス情報管理データベース１２内に格納されているものである。

図３（ａ）に示すように、診断許可条件テーブルは、複数（Ｎ個）のレコードを備えており、各レコードは、複数の条件（本例では条件Ａ，Ｂ，Ｃの３つ）から成っている。各レコードは、１〜Ｎのレコード番号で管理される。

条件Ａは車速であり、リモート診断を行うことができる車速の条件がレコード毎に設定されている。
条件Ｂは自車位置であり、リモート診断を行うことができる自車位置の条件がレコード毎に設定されている。本例では、一例として「自宅」、「事務所」、「実家」といった名称が設定されているが、診断サービス情報管理データベース１２に格納されている実際のデータは、これら各場所を示す座標値である。この座標値は、リモート診断サービスの契約時点において、ユーザが場所を指定することによりその指定した場所に応じた値が設定・格納される。そして、契約時に設定されたこの条件Ｂの内容は、既述の通りユーザ自身が後から変更することができる。

条件Ｃは時間帯であり、リモート診断を行うことができる時間帯の条件がレコード毎に設定されている。
そして、本実施形態では、リモート診断を実行するにあたり、マスタＥＣＵ２０は、レコード毎に、各条件が全て満たされているか否かを判断する。そして、いずれかのレコードに設定されている各条件が全て満たされている場合は、許可条件成立、即ち、診断を実行できる条件が成立しているものとして、リモート診断の実行を許可し、リモート診断を実行する。一方、１〜Ｎの全てのレコードについて、各条件Ａ，Ｂ，Ｃを全て満たさなかった場合は、許可条件不成立として、少なくともその時点ではリモート診断を行わない。

マスタＥＣＵ２０による各条件の判断は、次のように行われる。条件Ａ（車速）の判断は、第１ＥＣＵ４０に接続された車速センサ４３からの車速信号をこの第１ＥＣＵ４０から取得することにより行われる。条件Ｂ（自車位置）の判断は、マスタＥＣＵ２０内のＧＰＳ３５により取得される自車位置情報（座標値）に基づいて行われる。条件Ｃ（時間帯）の判断は、ＧＰＳ３５によって自車位置情報と共に取得される現在時刻情報に基づいて行われる。

なお、診断許可条件テーブル中、「Ｎｏ−ｃａｒｅ」とある場合は、その条件は不問とされる。例えばレコードＮの場合は、条件ＣがＮｏ−ｃａｒｅである。そのため、センタ２側から診断要求が送信されてきたときに、例えば現在の車速が０であって且つ現在の車両３の位置が実家にある場合は、時間帯には関係なく、レコードＮの許可条件が全て成立したものと判断されて、リモート診断が実行されることとなる。

診断要求の送信時に上記診断許可条件テーブルと共にセンタ２から送信される診断シナリオは、図３（ｂ）に示すように、実行すべき診断メニュー毎にその診断実行時の手順が具体的に示されたものである。図３（ｂ）の例では、複数の診断メニューα、β、・・・が設定されている。

このうち診断メニューαは、ドアのロック、アンロック操作を伴うものであり、図示の如く、手順１にてエンジンがＯＦＦ（停止）されていることの確認及び各ドアがロックされていることの確認が行われる。エンジンＯＦＦの確認は、マスタＥＣＵ２０が第１ＥＣＵ４０からエンジン状態を示す情報を取得することにより行われる。ドアがロックされていることの確認は、マスタＥＣＵ２０が第２ＥＣＵ５０からのロックポジション信号を取得することにより行われる。

手順２では、各ドアのアンロック操作が行われ、その操作時における各ドアのアンロック動作が確認される。各ドアのアンロック操作は、マスタＥＣＵ２０が第２ＥＣＵ５０に対してアンロック指令を送り、これに応じて第２ＥＣＵ５０がドアロック機構５３を制御することにより行われる。アンロック動作の確認は、第２ＥＣＵ５０により上記ドアロック機構５３の制御が行われたときの、ドアポジションスイッチ５４からのロックポジション信号を含む各種センサ信号等に基づいて行われる。手順３では、再び各ドアをロックする操作及びその際のロック動作の確認が行われる。

なお、図３（ａ）に示した診断許可条件テーブルは、診断メニュー毎に個々に用意するようにしてもよいし、診断メニューにかかわらず１つのテーブルを共通で用いるようにしてもよく、診断許可条件テーブルの数や各診断メニューとの関係は適宜決めることができる。

次に、本実施形態のリモート車両診断システム１において行われるリモート診断について、図４〜図６に基づいてより具体的に説明する。
まず、センタ２のセンタ内システム１０におけるサーバ１１にて実行される、センタ側診断処理について、図４に基づいて説明する。サーバ１１は、ユーザ毎に、図４に示すセンタ側診断処理を実行する。

このセンタ側診断処理において、サーバ１１は、まず、診断実行タイミングが到来したか否かを判断する（Ｓ１１０）。既述の通り、リモート診断をいつ実行するかについては、ユーザによって契約時点で予め設定されている。具体的には、例えば「毎月○日に診断実行する」、「３ヶ月毎に診断実行する」といった具合である。そのため、サーバ１１は、その予め設定されている実行時期情報に基づき、リモート診断の実行タイミングを逐次監視するのである。

そして、診断実行タイミングが到来したと判断した場合は（Ｓ１１０：ＹＥＳ）、診断対象の車両（ここでは車両３）に対し、インターネット網５や携帯電話網４等を通じて車両３内のマスタＥＣＵ２０へ診断要求を送信する（Ｓ１２０）。この際、既述の通り、診断要求と共に、診断サービス情報管理データベース１２に格納されている診断シナリオ及び診断許可条件テーブルも送信する。診断要求等の送信後は、その送信した診断要求に対する、車両３からの応答を待つ（Ｓ１３０）。

診断要求を受けた車両３のマスタＥＣＵ２０は、後述する図５の車両側診断処理を実行することにより、要求された診断を診断シナリオに沿って実行する。但し本実施形態のマスタＥＣＵ２０は、センタ２側から診断要求があったときに常に無条件でその要求された診断を実行するのではなく、後述するように、診断許可条件テーブルに設定された各許可条件をレコード毎にサーチし、全ての許可条件が満たされているレコードかあるか否か、即ち診断を実行してよい状態にあるか否かを判断する。そして、何れか一つのレコードでも、当該レコードにおける各許可条件が全て満たされた場合に、許可条件成立として診断を行うようにしている。車両３側で診断が許可・実行された場合は、車両３による診断の終了後にその診断結果がセンタ２側へ送信されてくる。一方、各許可条件が全て満たされるレコードが存在しなかった場合は、許可条件不成立として、後述するように条件成立待ちを示す信号が送信されてくる。

サーバ１１は、診断要求の送信後、何らかのデータを受信した場合は（Ｓ１３０：ＹＥＳ）、その受信したデータが車両３からの診断結果であるか否かを判断し（Ｓ１４０）、診断結果ならば（Ｓ１４０：ＹＥＳ）、その診断結果に基づく判定を行う（Ｓ１５０）。具体的には、その診断結果を事例データベース１３で照合することにより、車両３が正常か或いは異常かの判断や、修理等のために販売店等に入庫させる必要があるか否かの判断などを行う。

そして、その判断の結果をあらためて通知する（Ｓ１６０）。このＳ１６０の結果通知は、例えば、ユーザの携帯電話や、ユーザの自宅６のパソコン７宛にメールなどを送って通知するようにしてもよいし、あらためて車両３に対して通知するようにしてもよい。その場合、車両３側ではマスタＥＣＵ２０がその結果通知を受け、多重通信線３０に接続された表示装置、例えば図示しないメータや、ナビＥＣＵ７０に接続されたディスプレイ７１等を通じて、ユーザに結果を知らしめることができる。

一方、受信したデータが診断結果ではなかった場合は（Ｓ１４０：ＮＯ）、リモート診断を中断させるべきか否かの診断中断判定を行う（Ｓ１７０）。具体的には、Ｓ１２０における診断要求を送信した時点からの経過時間などを基準として、例えばその送信した時点からまだそれほど時間が経過していない場合など、もう暫く様子をみるべき（リモート診断処理を続行させるべき）と判断した場合は、Ｓ１９０に進む。

Ｓ１９０では、受信したデータが条件成立待ちを示す信号であるか否かを判断する。そして、条件成立待ちを示す信号である場合は（Ｓ１９０：ＹＥＳ）、それは即ち、少なくとも現時点では車両３がリモート診断を実行できる状態になく、車両３が自律でリモート診断の実行機会をうかがっている待ち処理に入っている状態であるということである。そのため、Ｓ１３０に戻り、新たなデータ受信を待つ。逆に、条件成立待ちを示す信号ではなかった場合は（Ｓ１９０：ＮＯ）、その受信したデータに応じた所定のデータ処理を行った上で（Ｓ２００）、再びＳ１３０以下の処理を行う。

一方、Ｓ１７０の診断中断処理において、例えば、Ｓ１２０で診断要求を送信した時点から長時間経過していたり、条件成立待ちを示す信号を継続的に受信している場合など、車両３がリモート診断を実行できない状態がまだ暫く続くことが予想される場合は、リモート診断処理を一旦中断させるべきと判断し、車両３へ中断指示を送信する（Ｓ１８０）。この中断指示により、車両３側では診断待ち状態が解除されることになる。

次に、車両３の車両内システム９におけるマスタＥＣＵ２０にて実行される、車両側診断処理について、図５に基づいて説明する。マスタＥＣＵ２０のＲＯＭ３２には、車両側診断処理プログラムが格納されており、センタ２側からの診断要求（図４のＳ１２０）が受信されたときに、ＭＣＵ３１は、このＲＯＭ３２内の車両側診断処理プログラムに従って処理を実行する。

センタ２側から診断要求を受信したことによってこの車両側診断処理が開始されると、マスタＥＣＵ２０は、まず、診断要求と共に送信されてきた診断シナリオ及び診断許可条件テーブルの受信とＲＡＭ３３への保存を行う（Ｓ３１０）。そして、その保存した設定許可条件テーブルを読み出し（Ｓ３２０）、診断許可条件テーブルのレコード読み出し位置を決めるポインタを初期化して、診断許可条件テーブルを先頭レコード（レコード番号＝１）から読み出す準備を整える（Ｓ３３０）。

その後、診断許可条件の成立可否を判定する、許可条件成立判定処理を行う（Ｓ３４０）。この許可条件成立判定処理の詳細を、図６に示す。
Ｓ３４０の許可条件成立判定処理は、ポインタで指定されたレコードに設定された各条件（条件Ａ〜Ｃ）について現時点での車両３の状態と比較、照合することにより各条件が満たされているか否かを判断し、延いてはリモート診断を実行可能な許可条件が成立しているか否かを判断するものであり、図６に示すように、まず、条件Ａとして設定されている車速について、車両３の車速の現在値を確認する（Ｓ３４１）。この車速の確認は、第１ＥＣＵ４０からの車速信号に基づいて行われる。

そして、確認した車速の現在値と、ポインタで指定されたレコード中の条件Ａに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ３４２）。例えばポインタの値が１であってレコード番号１が判断対象とされている場合は、車速の現在値が０以下であるか否かが判断されることとなる。なお、診断許可条件テーブル中の設定内容が「Ｎｏ−ｃａｒｅ」の場合は「一致」と同じ扱いとする。

このＳ３４２の判断において、車速の現在値が条件Ａの設定内容と一致しなかった場合は、許可条件不成立、即ち、各レコードのうち少なくとも現在ポインタで指定されているレコードについては許可条件を満たさないものがあるとして、当該レコードにおける他の条件Ｂ，Ｃに関する判断を行うことなく、この許可条件成立判定処理を一旦終了して図５のＳ３８０に進む。

Ｓ３４２の判断において、車速の現在値が条件Ａの設定内容と一致した場合は（Ｎｏ−ｃａｒｅも含む）、続くＳ３４３にて、条件Ｂとして設定されている自車位置について、車両３の自車位置の現在値を確認する。この自車位置の確認は、マスタＥＣＵ２０に内臓されているＧＰＳ３５から現在の位置情報を取得することにより行う。

そして、確認した自車位置の現在値と、レコード中の条件Ｂに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ３４４）。例えばポインタの値が１であってレコード番号１が判断対象とされている場合は、車両３が自宅に位置しているか否かが判断されることとなる。

このＳ３４４の判断において、自車位置の現在値が条件Ｂの設定内容と一致しなかった場合は、許可条件不成立として、当該レコードにおける他の条件Ｃに関する判断を行うことなく、この許可条件成立判定処理を一旦終了して図５のＳ３８０に進む。

Ｓ３４４の判断において、自車位置の現在値が条件Ｂの設定内容と一致した場合は（Ｎｏ−ｃａｒｅも含む）、続くＳ３４５にて、条件Ｃとして設定されている時間帯について、現在の時刻を確認する。この現在時刻の確認は、マスタＥＣＵ２０に内臓されているＧＰＳ３５から現在時刻情報を取得することにより行う。

そして、確認した現在時刻と、レコード中の条件Ｃに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ３４６）。例えばポインタの値が１であってレコード番号１が判断対象とされている場合は、現在時刻が３：００〜５：００の間にあるか否かが判断されることとなる。

このＳ３４６の判断において、現在時刻が条件Ｃの設定内容と一致しなかった場合は、許可条件不成立として、この許可条件成立判定処理を一旦終了して図５のＳ３８０に進む。

Ｓ３４６の判断において、現在時刻が条件Ｃの設定内容と一致した場合は（Ｎｏ−ｃａｒｅも含む）、当該レコードにおける全ての条件Ａ〜Ｃが満たされていることから、許可条件成立として、図５のＳ３５０に進む。

図５に戻り、Ｓ３４０の許可条件成立判定処理において許可条件成立と判定された場合は、Ｓ３１０で保存した、センタ２から送信された診断シナリオ（図３（ｂ）参照）に沿って、車両３内の診断を実行する（Ｓ３５０）。

なお、図３（ｂ）に示す診断シナリオは、診断メニューを複数含んでいる。即ち、ドアのロック・アンロック操作を含む一連の診断を行うメニューαと、その他、メニューβを含む一又は複数の診断メニューを含んでいる。そして、診断メニュー毎に、診断シナリオが設定されている。このように診断すべきメニューが複数存在する場合、Ｓ３５０の診断処理では、１つの診断メニューのみ（例えばまずメニューαのみ）実行される。

そして、その１つの診断メニューにつき診断処理が完了すると、診断メニュー全てについて診断が終了したか否かを判断する（Ｓ３６０）。このとき、全ての診断メニューについて診断が終了した場合は（Ｓ３６０：ＹＥＳ）、各診断メニューの診断結果を一括してセンタ２へ送信して（Ｓ３７０）、この車両側診断処理を終了する。

まだ実施されていない診断メニューが残っている場合は（Ｓ３６０：ＮＯ）、Ｓ３４０に戻り、残っている診断メニューのうち１つにつき、Ｓ３４０による許可条件成立判定処理を経てその診断メニューについて診断シナリオに沿った診断処理を実行する（Ｓ３５０）。

一方、Ｓ３４０の許可条件成立判定処理において許可条件不成立と判定された場合は、現在のポインタの値が、診断条件許可テーブルにおいて設定されているレコード番号の末尾の番号より小さいか否か、即ち、まだＳ３４０による許可条件成立判定を行っていないレコードが残っているか否かを判断する（Ｓ３８０）。このとき、ポインタの値がレコード番号の末尾より小さい場合は（Ｓ３８０：ＹＥＳ）、ポインタの値を更新（インクリメント）する（Ｓ３９０）。そして、センタ２側から中断指示が受信されたか否かを判断し（Ｓ４００）、受信されていなければ（Ｓ４００：ＮＯ）、再びＳ３４０に戻って許可条件成立判定処理を行う。このとき行われる許可条件成立判定処理は、前回行ったときのレコード番号の次のレコードの設定内容に基づいて行われることとなる。

このようにして、いずれかのレコードについて許可条件成立と判断されるまでは、センタ２側から中断指示を受けない限り、各レコードにつき順次Ｓ３４０の許可条件成立判定を実行する。そして、全てのレコード（図３（ａ）ではレコード１〜レコードＮまでの全て）についていずれも許可条件不成立と判定された場合は、Ｓ３８０で否定判定されてＳ４１０に進み、条件成立待ちを示す信号をセンタ２へ送信（通知）する。その上で、Ｓ３３０に戻り、再びレコード１から許可条件成立判定を行う。

そして、センタ２側から中断指示を受信しない間は、レコード毎に許可条件の成立可否の判定（Ｓ３４０）が継続されるが、条件不成立のままセンタ２側から中断指示を受信した場合は（Ｓ４００：ＹＥＳ）、そのままこの車両側診断処理を終了する。

なお、Ｓ４１０による条件成立待ちを示す信号の通知後にそのままこの車両側診断処理を終了するようにしてもよいが、本実施形態では、センタ２から中断指示があるまでは許可条件成立を監視するようにしている。

ところで、本実施形態では、ユーザが診断サービスの契約締結時に設定した診断許可条件テーブルの内容を、その後にユーザの意志により更新することが可能である。更新の方法は、例えば、ユーザが自宅６のパソコン７からセンタ内システム１０のサーバ１１へアクセスし、パソコン７にて所定のテーブル更新処理を実行して行う方法、或いは、車両３におけるナビゲーションシステムのディスプレイ７１（タッチパネル）を介してユーザが所定の操作をすることにより、その操作内容に応じてマスタＥＣＵ２０が所定のテーブル更新処理を実行して行う方法などがある。

このように、パソコン７或いは車両３のナビゲーションシステムを用いることで、診断サービス情報管理データベース１２上の診断許可条件テーブルの各条件Ａ〜Ｂの設定内容を書き換えたり、レコードの新規追加、削除等を行うことができる。診断許可条件テーブルの更新の際にユーザ側（パソコン７或いは車両３のマスタＥＣＵ２０）及びセンタ２側（サーバ１１）でそれぞれ実行されるテーブル更新処理について、図７に基づいて説明する。

図７において、左側の処理はユーザ側（パソコン７或いはマスタＥＣＵ２０）にて実行されるテーブル更新処理であり、右側の処理はセンタ２側（サーバ１１）にて実行されるテーブル更新処理である。

図７に示すように、ユーザが所定の操作を行うことによりセンタ２側へ更新要求が送信されると（Ｓ５１０）、センタ２のサーバ１１は、そのユーザ側からの更新要求を受信して（Ｓ６１０）、送信元のユーザへ、診断サービス情報データベース１２内に格納されている現在の診断許可条件テーブルのデータを送信する（Ｓ６２０）。

ユーザ側では、その送信されてきた診断許可条件テーブルのデータを受信すると共に、その受信したデータに基づいて現在の診断許可条件テーブルの内容を表示デバイス（パソコン７であればそのディスプレイ、ナビゲーションシステムであればディスプレイ７１）に表示させる（Ｓ５２０）。そして、ユーザによるテーブル設定内容の変更操作を受け付け（Ｓ５３０）、ユーザによる変更操作が完了したならば（Ｓ５４０：ＹＥＳ）、その変更後の情報を更新情報としてセンタ２側へ送信する（Ｓ５５０）。

例えば条件Ｂの自車位置を変更したい場合は、ユーザは、車両３内のナビゲーションシステム（ナビＥＣＵ７０）のメモリ地点登録機能で特定の場所を登録し、その登録した場所の名称をその場所の座標値と関連付けてセンタ２側へ送信することにより行うことができる。

センタ２のサーバ１１は、ユーザ側から送信された更新情報を受信すると（Ｓ６３０）、その更新情報に基づき、診断サービス情報データベース１２内に格納されている現在の診断許可条件テーブルの内容を更新する（Ｓ６４０）。

このように、本実施形態では、契約時にユーザが設定した診断許可条件テーブルがそのまま固定されてしまうのではなく、ユーザ自身が適宜その内容を変更することができるのである。

以上説明した本実施形態のリモート車両診断システム１では、センタ２からの診断要求に対して車両３が診断を実行してもよいか否かを車両３自身が判断するための条件を、許可条件テーブルとしてセンタ２内に保有しておく。そして、センタ２は、リモート診断を実行すべきタイミングが到来すると、車両３へ診断要求と共に診断許可条件テーブル及び診断シナリオを送信する。車両３は、センタ２からの診断要求を受信したとき、その診断要求を受信したことのみをもって無条件にリモート診断を実行開始するのではなく、診断要求と共に受信した診断許可条件テーブルに従って、診断を実行してよい状態にあるか否かを判断する。そして、許可条件が成立しない限り診断は実行せず、許可条件が成立した場合に、診断シナリオに沿って診断を実行する。

従って、本実施形態のリモート車両診断システム１によれば、センタ２からの診断要求送信時に、診断許可条件テーブルに設定されている条件Ａ〜Ｃが全て満たされている場合にのみ、診断シナリオに沿った診断処理が実行されるため、診断処理の実施に伴ってユーザに懸念を生じさせないようにすることができる。

特に、条件Ｂとして自車位置が設定されており、車両３がこの条件Ｂに設定されている位置に存在している場合に診断処理が実行され、条件Ｂに設定されている位置とは異なる位置に存在している場合には診断処理が実行されないため、診断処理実行場所に起因するユーザの懸念（盗難の心配等）を払拭することが可能となる。

特に、本実施形態では、診断シナリオの中にドアのアンロック動作が含まれており、このようなドアのアンロック動作が車両の位置にかかわらず無条件に行われてしまうと、盗難等のおそれが高くなり、ユーザの懸念も高くなる。これに対し、本実施形態では条件Ｂとして自車位置が設定されているため、ドアのアンロック動作を伴う診断が実行されても、ユーザに懸念を生じさせることがない。

また、本実施形態のリモート車両診断システム１では、ユーザが自宅のパソコン７や車両３のナビゲーションシステム等を用いてセンタ２のサーバ１１へアクセスすることにより、診断サービス情報管理データベース１１内の診断許可条件テーブルの設定内容を自在に更新（変更、追加、削除等）できるよう構成されている。そのため、ユーザにとってより使い勝手の良い、ユーザ本意のシステムが実現される。

ここで、本実施形態の構成要素と本発明の構成要素の対応関係を明らかにする。本実施形態において、診断許可条件テーブルに設定されている条件Ａ，Ｂ，Ｃはいずれも本発明の許可条件に相当し、このうち条件Ｂとして設定されている自車位置は本発明の診断実行可能位置に相当し、診断サービス情報管理データベースは本発明の許可条件設定手段に相当し、サーバ１１は本発明の更新手段に相当し、マスタＥＣＵ２０は本発明の許可条件判断手段及び診断実行手段に相当し、ＧＰＳ３５は本発明の位置取得手段に相当し、パソコン７及びナビゲーションシステム（ナビＥＣＵ７０及びディスプレイ７１からなるシステム）は本発明の通信端末に相当する。

また、図７のテーブル更新処理において、Ｓ５２０の処理は本発明の許可条件取得手段が実行する処理に相当し、Ｓ５３０の処理は本発明の更新操作受付手段が実行する処理に相当し、Ｓ５５０の処理は本発明の更新要求送信手段が実行する処理に相当し、Ｓ６４０の処理は本発明の更新手段が実行する処理に相当する。

［第２実施形態］
図８に、本実施形態のリモート車両診断システムを構成する車両内システムの概略構成を示す。本実施形態のリモート車両診断システムは、システム全体の基本構成としては、図１に示した第１実施形態のリモート車両診断システム１と基本的に同じである。

そして、本実施形態のリモート車両診断システムが第１実施形態のリモート車両診断システム１と異なるのは、主として、車両３が、スマートイグニション機能を備えたプラグインハイブリッド車両であること、診断許可条件テーブルの設定条件として、条件Ａ〜Ｃに加えて更に条件Ｄが設定されていること、及び、診断メニューαが第１実施形態とは異なることである。そのため、以下の説明では、第１実施形態と異なる構成について詳しく説明し、第１実施形態と同じ構成については第１実施形態と同じ符号を付し、その詳細説明を省略する。

プラグインハイブリッド車両とは、内燃機関と電気モータを組み合わせた周知のハイブリッド車両に対して、更に、電気モータ駆動用のバッテリを外部の商用交流電源にて充電することが可能に構成された車両である。

そのため、本実施形態の車両内システム８０は、図８に示すように、充電用の商用交流電源（本例ではＡＣ１００Ｖ）を取り込むための電源ソケット９１と、この電源ソケット９１を介して入力されたＡＣ１００Ｖ電源の、モータ駆動用バッテリ９２及び補機用バッテリ９３への充電をそれぞれ制御する充電制御ＥＣＵ９０とを備えている。この充電制御ＥＣＵ９０も、多重通信線３０に接続され、マスタＥＣＵ８１との間で相互にデータ送受信可能に構成されている。

ユーザの自宅６内の商用交流電源１０１からは、ＡＣ１００Ｖ電源が、一端に充電用電源プラグ１００が接続された充電用ケーブル１０２を介して車両側に供給される。即ち、充電用電源プラグ１００が車両の電源ソケット９１に接続されることで、商用交流電源１０１からのＡＣ１００Ｖ電源が充電制御ＥＣＵ９０内に供給される。

充電制御ＥＣＵ９０は、供給されたＡＣ１００Ｖ電源を各バッテリ９２，９３に充電する制御を実行する他、車両側の電源ソケット９１に対する充電用電源プラグ１００の接続状態を検知すると共に、その接続状態を示すプラグ接続状態信号をマスタＥＣＵ８１へ送信する。即ち、電源ソケット９１に充電用電源プラグ１００が接続されている場合は接続されている旨のプラグ接続状態信号を送信し、電源ソケット９１に充電用電源プラグ１００が接続されていない場合は接続されていない旨のプラグ接続状態信号を送信する。

この接続状態の検知は、換言すれば、外部から供給されたＡＣ１００Ｖ電源による各バッテリ９２，９３への充電が行われている状態であるか否かの検知とも言える。
充電制御ＥＣＵ９０による接続状態の検知方法は適宜考えられ、例えば、電源ソケット９１を介してＡＣ１００Ｖの電源が供給されているか否かを判断することにより行うことができる。また例えば、電源ソケット９１に充電用電源プラグ１００が接続されたときに機械的にスイッチがオンされるような機構を設けて、そのスイッチの状態に基づいて接続状態を検知するようにしてもよい。

また、本実施形態の車両が備えるスマートイグニション機能とは、ユーザ（運転者）が正規の携帯機（スマートキー）、即ち車両側のＩＤコードと一致するＩＤコードを有する携帯機を車室内に持ち込むだけで、エンジンの始動を許可する機能である。

ユーザは、この正規の携帯機を所持して運転席に座り、ハンドル近傍に設けられたプッシュスイッチ９８を押すことで、エンジンを始動させることができる。また、このプッシュスイッチ９８の押し操作により、キーをキーシリンダに挿入して回転操作する一般的なキーシステムと同様、アクセサリスイッチのみオンさせたり、アクセサリスイッチと共にイグニションスイッチもオンさせたりすることができる。

また、本実施形態の車両内システム８０は、多重通信線３０に接続されるＥＣＵとして、電源制御ＥＣＵ９６を有している。この電源制御ＥＣＵ９６は、車両内の各部への電源供給を制御する種々の機能を備えており、その１つとして、ユーザが正規の携帯機を所持した状態でプッシュスイッチ９８が押されたときに、その操作内容に応じてリレー制御ボックス９７を動作させて、アクセサリスイッチのみオン、或いはイグニションスイッチもオン、更にはエンジンを始動させるといった、スイッチ制御機能を有する。

本実施形態でも、第１施形態と同様、センタ２から診断要求をマスタＥＣＵ８１が受信したときに、マスタＥＣＵ８１は、その診断要要求と共に受信した診断シナリオ及び診断許可条件テーブルに基づいて、リモート診断を行う。

このリモート診断の際にセンタ２のサーバ１１で実行されるセンタ側診断処理は、基本的には第１実施形態の図４と同じである。但し、このセンタ側診断処理におけるＳ１２０において車両側へ送信される診断シナリオ及び診断許可条件テーブルが、第１実施形態（図３）とは異なる。

また、リモート診断の際に車両側で実行される車両側診断処理は、基本的には第１実施形態の図５と同じである。但し、図５の車両側診断処理におけるＳ３４０の許可条件成立判定処理が、第１実施形態（図６）とは異なる。これは、センタ２側から送信されてくる診断許可条件テーブルの構成が第１実施形態と異なっていることによるものである。そこで、以下の説明では、本実施形態の診断シナリオと診断許可条件テーブル、及び許可条件成立判定処理について説明する。

図９に、本実施形態の診断許可条件テーブル及び診断シナリオの一例を示す。図９（ａ）に示すように、本実施形態の診断許可条件テーブルも、複数（Ｎ個）のレコードを備えている。但し、各レコードは、本実施形態では、条件Ａ，Ｂ，Ｃに加えてさらに条件Ｄを含む、４つの条件から成っており、この点で第１実施形態の診断許可条件テーブル（図３（ａ））とは異なる。

条件Ｄは、充電用電源プラグ１００の接続状態である。即ち、車両側の電源ソケット９１に対する充電用電源プラグ１００の接続状態が、リモート診断の実行条件としてレコード毎に設定されている。

本例では、レコード２において、条件Ｄとして「プラグ接続」が設定されている。また、このレコード２では他の各条件Ａ，Ｂ，ＣはいずれもＮｏ−ｃａｒｅである。そのため、センタ２側から診断要求が送信されてきたとき、電源ソケット９１に充電用電源プラグ１００が接続されている場合は、他の車速、自車位置、及び時間帯に関係なく、レコード２について許可条件成立として、診断が実行されることとなる。なお、マスタＥＣＵ２０による条件Ｄの判断は、具体的には、充電制御ＥＣＵ９０からのプラグ接続状態信号に基づいて行われる。

また、本実施形態の診断シナリオは、図９（ｂ）に示すように、複数の診断メニューα、β、・・・毎に、その診断実行時の手順が具体的に示されている。
このうち診断メニューαは、エンジンがＯＦＦ（停止）された状態でアクセサリスイッチがオンされる（つまりエンジン停止時にバッテリ電力が消費される）動作を伴うものであり、図示の如く、手順１にてエンジンがＯＦＦ（停止）されていることの確認が行われる。このエンジンＯＦＦの確認は、図３（ｂ）の診断メニューαにおける手順１と同じである。

手順２では、アクセサリスイッチをオンさせる操作が行われる。このアクセサリスイッチのオン操作は、マスタＥＣＵ８１が電源制御ＥＣＵ９６へアクセサリスイッチをオンすべき旨のスイッチ操作指令を送信することにより行われる。電源制御ＥＣＵ９６は、マスタＥＣＵ８１からこのスイッチ操作指令を受信すると、リレー制御ボックス９７を制御することによりアクセサリスイッチをオンさせる。そして、手順３では、ナビゲーションシステム（ナビＥＣＵ７０等）の動作チェックが行われる。

本実施形態の診断許可条件テーブルにおいて、充電用電源プラグ１００の接続状態を条件Ｄとして設定している背景として、リモート診断を実行する上での懸念事項の１つである診断実行中のバッテリ上がりがある。本実施形態の診断メニューαのように、エンジンをＯＦＦ（停止）した状態でアクセサリスイッチをオンさせる動作を伴う診断を実行する際には、エンジンＯＦＦ中はバッテリが充電されないことから、エンジンＯＦＦのままアクセサリスイッチのオン状態が継続されると、バッテリが上がるおそれがある。

これに対し、本実施形態では、車両がプラグインハイブリッド車両であることから、エンジンがＯＦＦ中であっても、電源ソケット９１を介して充電用電源（ＡＣ１００Ｖ）が供給されて各バッテリ９２，９３への充電が行われている間は、バッテリ上がりの心配はない。そこで、リモート診断を実行可能な許可条件として、「プラグ接続」、即ち「充電用電源プラグ１００が電源ソケット９１に接続されている場合」を設定している。そして、レコード２において、他の各条件Ａ〜Ｃに対応した車両状態に関係なく、条件Ｄが成立したならば（つまり充電実行中ならば）診断を許可するようにしている。

次に、本実施形態のマスタＥＣＵ８１が実行する許可条件成立判定処理（図５の車両側診断処理におけるＳ３４０の処理）について、図１０を用いて説明する。
図１０に示した本実施形態の許可条件成立判定処理のうち、Ｓ７１０〜Ｓ７６０の各処理は、それぞれ、図６に示した第１実施形態の許可条件成立判定処理のＳ３４１〜Ｓ３４６の各処理と全く同じである。そのため、Ｓ７１０〜Ｓ７６０の説明はここでは省略する。

Ｓ７６０の判断において、現在時刻が条件Ｃの設定内容と一致した場合は（Ｎｏ−ｃａｒｅも含む）、続くＳ７７０にて、条件Ｄとして設定されている充電用電源プラグ１００の接続状態について、現在の接続状態を確認する。この接続状態の確認は、充電制御ＥＣＵ９０がマスタＥＣＵ８１へ送信するプラグ接続状態信号に基づいて行う。

そして、確認した接続状態と、レコード中の条件Ｄに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ７８０）。例えばポインタの値が２であってレコード番号２が判断対象とされている場合は、電源ソケット９１に充電用電源プラグ１００が接続されているか否かが判断されることとなる。

このＳ７８０の判断において、接続状態が条件Ｄの設定内容と一致しなかった場合（レコード２においては電源ソケット９１に充電用電源プラグ１００が接続されていなかった場合）は、許可条件不成立として、この許可条件成立判定処理を一旦終了し、図５のＳ３８０に進むこととなる。

一方、Ｓ７８０の判断において、接続状態が条件Ｄの設定内容と一致した場合（レコード２においては電源ソケット９１に充電用電源プラグ１００が接続されている場合）は、当該レコードにおける４つの条件Ａ〜Ｄ全てが満たされていることから、許可条件成立として、図５のＳ３５０に進むこととなる。

以上説明した本実施形態のリモート車両診断システムによれば、センタ２からの診断要求があったときに、車両３の各バッテリ９２，９３への充電が行われている場合に診断処理が実行されることになるため、仮に電力消費の大きな診断が実行されたとしてもバッテリ上がりのおそれはない。そのため、診断処理実行時のバッテリ電力消費に起因するユーザの懸念（バッテリ上がりの懸念）を払拭することが可能となる。

特に、本実施形態では、診断メニューとしてエンジンをＯＦＦさせた状態でアクセサリスイッチをオンさせる（バッテリ電力を消費させる）処理が含まれており、エンジンＯＦＦ中にバッテリ電力の消費が続くとバッテリ上がりの懸念があるが、バッテリ充電中にのみ診断処理が実行されるため、バッテリ上がりの懸念を払拭することができる。

なお、本実施形態において、充電用電源プラグ１００から電源ソケット９１を介して入力されるＡＣ１００Ｖ電源が本発明の充電用電力に相当し、電源ソケット９１は本発明の充電用電力入力手段に相当し、充電制御ＥＣＵ９０は本発明の充電制御手段及び充電状態検出手段に相当する。

［第３実施形態］
図１１に、本実施形態のリモート車両診断システムにおいて用いられる診断許可条件テーブルを示し、図１２に、本実施形態のリモート車両診断システムにおいて車両側のマスタＥＣＵが実行する許可条件成立判定処理（（図５の車両側診断処理におけるＳ３４０の処理）を示す。本実施形態のリモート車両診断システムは、第１実施形態のリモート車両診断システム１と比較して、上記の診断許可条件テーブル（図１１）及び許可条件成立判定処理（図１２）がそれぞれ異なるだけであり、その他の構成、機能等については基本的に第１実施形態と同じである。

本実施形態の診断許可条件テーブルは、図１１に示すように、レコード毎に条件Ａ〜Ｂの３種類の許可条件が設定されており、この点では第１実施形態のテーブル（図３（ａ））と同じである。そして、本実施形態では、単に条件Ａ〜Ｃが設定されているだけではなく、これら３つの条件の論理的な組合せが、「条件式」として、レコード毎に設定されている。「条件式」とは、レコード毎に複数ある許可条件の、論理的な組合せを論理式で記述した情報である。本例では、条件Ａ〜Ｃに対して「条件式」が設定されることで、レコード毎に、各条件の重み付けが設定されている。

例えばレコード１の場合、条件式が「条件Ａ×条件Ｂ×条件Ｃ」に設定されていることから、三つの条件Ａ〜Ｃが全て満たされたときにこのレコード１の許可条件が成立し、いずれか１つでも満たされない場合は許可条件不成立となる。つまり、レコード１については各条件Ａ，Ｂ，Ｃの重み付けは同レベルである。そのため、レコード１に関しては第１実施形態や第２実施形態と同じ扱いとなる。

これに対し、例えばレコード２の場合、条件式が「（条件Ａ＋条件Ｂ）×条件Ｃ」に設定されている。そのため、このレコード２の許可条件が成立するためには、少なくとも条件Ｃは満たす必要がある。しかし、条件Ａと条件Ｂについては、必ずしも両者が同時に満たされている必要はなく、条件Ａ又は条件Ｂの少なくとも一方が満たされていればよい。つまり、このレコード２については、条件Ａ及び条件Ｂの重みに対し、条件Ｃの重みが高く設定されている。

そのため、例えば車両がユーザの友人宅に停車中であって条件Ｂを満たしていない場合であっても、他の２つの条件Ａ，Ｃを何れも満たしていれば、結果としてレコード２の許可条件が成立することとなる。逆に、例えば車両が事務所に停車中であって条件Ａ，Ｂをいずれも満たしていたとしても、時間帯が条件Ｃから外れていた場合は、結果としてレコード２の許可条件は不成立となる。

なお、レコードＮでは、条件ＣがＮｏ−ｃａｒｅに設定されているため、条件式は「条件Ａ×条件Ｂ」に設定され、時間帯に関係なく条件Ａ及び条件Ｂが共に満たされればレコードＮの許可条件が成立する。

次に、診断許可条件テーブルが図１１のように設定されている本実施形態のリモート車両診断システムにおいて、マスタＥＣＵが実行する許可条件判定処理（図５のＳ３４０処理）を、図１２に基づいて説明する。

マスタＥＣＵは、本処理を開始すると、まず最初に、ポインタが示すレコードに設定されている「条件式」を読み取る（Ｓ８１０）。
そして、図６のＳ３４１〜Ｓ３４２と同様、条件Ａとして設定されている車速について、車両３の車速の現在値を確認し（Ｓ８２０）、その確認した車速の現在値と、ポインタで指定されたレコード中の条件Ａに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ８３０）。

このＳ８３０の判断処理において、車速の現在値が条件Ａの設定内容と一致しなかった場合は（Ｓ８３０：ＮＯ）、条件式における該当項（ここでは条件Ａの項）に「０」をセットして、Ｓ８６０に進む。一方、車速の現在値が条件Ａの設定内容と一致（Ｎｏ−ｃａｒｅも含む）した場合は、条件式における該当項（条件Ａの項）に「１」をセットして（Ｓ８４０）、Ｓ８６０に進む。

続くＳ８６０〜Ｓ８７０では、図６のＳ３４３〜Ｓ３４４と同様、条件Ｂとして設定されている自車位置について、車両３の自車位置の現在値を確認し（Ｓ８６０）、その確認した自車位置の現在値と、ポインタで指定されたレコード中の条件Ｂに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ８７０）。

このＳ８７０の判断処理において、自車位置の現在値が条件Ｂの設定内容と一致しなかった場合は（Ｓ８７０：ＮＯ）、条件式における該当項（ここでは条件Ｂの項）に「０」をセットして、Ｓ９００に進む。一方、自車位置の現在値が条件Ｂの設定内容と一致（Ｎｏ−ｃａｒｅも含む）した場合は、条件式における該当項（条件Ａの項）に「１」をセットして（Ｓ８８０）、Ｓ９００に進む。

続くＳ９００〜Ｓ９１０では、図６のＳ３４５〜Ｓ３４６と同様、条件Ｃとして設定されている時間帯について、現在の時刻（現在値）を確認し（Ｓ９００）、その確認した現在の時刻と、ポインタで指定されたレコード中の条件Ｃに設定されている内容とを比較して、両者が一致するか否かを判断する（Ｓ９１０）。

このＳ９１０の判断処理において、現在時刻が条件Ｃの設定内容と一致しなかった場合は（Ｓ９１０：ＮＯ）、条件式における該当項（ここでは条件Ｃの項）に「０」をセットして、Ｓ９４０に進む。一方、現在時刻が条件Ｃの設定内容と一致（Ｎｏ−ｃａｒｅも含む）した場合は、条件式における該当項（条件Ｃの項）に「１」をセットして（Ｓ９２０）、Ｓ９４に進む。

そして、Ｓ９４０では、Ｓ８１０にて読み取った条件式における各条件項（条件Ａ，Ｂ，Ｃ）に、上記セットした「１」又は「０」の値を適用して、条件式全体の演算結果を得る。そして、その演算結果が「１」であるか否かを判断する。

この判断において演算結果が「１」であれば、当該レコードの許可条件が成立したものとして、図５のＳ３５０に進み、診断シナリオに沿った診断が実行されることとなる。一方、演算結果が「０」ならば、当該レコードについては許可条件が成立しなかったものとして、図５のＳ３８０に進む。

なお、本実施形態においても、ユーザがパソコン７や車両のナビゲーションシステムを介して診断許可条件テーブルの設定内容を更新することが可能であり、その際、各条件Ａ，Ｂ，Ｃの内容を更新できるのはもちろん、条件式を更新することもできる。

以上説明した本実施形態のリモート車両診断システムによれば、診断許可条件テーブルにおいて、各条件Ａ〜Ｃに加えてこれらの論理的な組み合わせを示す条件式が設定されており、最終的にはこの論理式の演算結果をもって診断を実行してもよいか否かが判断させるため、論理式を適宜設定することで、複数の許可条件の間で相対的な重み付けを設定することができ、ユーザの意向により即した状態でのリモート診断の実施が可能となる。

なお、図１２の許可条件成立判定処理において、Ｓ８２０〜Ｓ９３０の処理は本発明の個別判断手段が実行する処理に相当し、Ｓ９４０の処理は本発明の最終判断手段が実行する処理に相当する。

［変形例］
以上、本発明の実施の形態について説明したが、本発明の実施の形態は、上記実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採り得ることはいうまでもない。

例えば、上記実施形態では、診断許可条件テーブルにおいて複数のレコードを設定しておき、いずれか１つのレコードの許可条件が成立した場合にはリモート診断を実行できるものとしたが、レコードは１つのみであってもよい。また、設定される条件の数についても、第１実施形態では条件Ａ〜Ｃの三つ、第２実施形態では条件Ａ〜Ｄの四つとしたが、これもあくまでも一例である。更に、条件の内容として、上記実施形態では、車速、自車位置、時間帯、充電用電源プラグの接続状態が設定されていたが、これもあくまでも一例であり、条件の数やその内容は、リモート診断の実施の際にユーザに各種の懸念を生じさせることがないよう、適宜決めることができる。

また、上記実施形態では、図３（ｂ）、図９（ｂ）に示したように、診断シナリオについても、複数のメニューα、β、・・・が設定されていたが、これもあくまでも一例であり、メニューの数は１つであってもよいし、診断シナリオにおける各手順の内容についても一例に過ぎない。

また、上記第１実施形態では、ユーザが自宅６のパソコン７や車両３内のナビゲーションシステムを用いてセンタ２側と通信を行うことにより、センタ２の診断サービス情報管理データベース１２に格納されている診断許可条件テーブルの内容を変更（更新）できるものとして説明したが、ユーザによる診断許可条件テーブルの更新方法はこれに限らず、例えば、診断サービスの契約を行った販売店等に連絡して販売店等を経由して更新を申し出るようにしてもよいし、携帯電話からセンタ２のサーバ１１にアクセスしてユーザ自身が更新できるようにしてもよく、更新の具体的方法は種々考えられる。

また、上記実施形態では、診断許可条件テーブルは、診断要求と共にセンタ２から車両３へ通知されるものとして説明したが、これに限らず、例えば、車両３側において予めマスタＥＣＵ２０がプロラム情報として保有しておくようにすることもできる。

但し、上記実施形態のようにリモート診断実行の度にセンタ２側から逐一送信するようにすることで、診断要求の都度、最新の診断許可条件テーブルを送信することが可能となる。

また、上記実施形態では、リモート診断の実施、即ちセンタ２から車両３へのリモート診断の診断要求を、診断サービスの契約時点で予め設定した実行時期情報（例えば「毎月○日」、「３ヶ月毎」など）に基づいて定期的に行うものとして説明したが、これはあくまでも一例であり、センタ２がどのようなタイミングで車両３側へ診断要求を送信するかについては種々考えられる。

また、センタ２から診断要求があった場合にのみ車両３が診断を実行するのに限らず、車両３内で何らかの故障等が検知された場合にその旨を車両３からセンタ２へ送信し、それに基づいてセンタ２が故障等の原因を特定するために必要な診断シナリオを設定して診断許可条件テーブルと共に車両３側へ送り、車両３がその送られてきた診断許可条件テーブルに基づいて診断実行可能であるか否かを判断して、診断実行可能と判断した場合に診断シナリオに従って診断を実行する、というようなリモート車両診断システムを構成することもできる。

また、上記第２実施形態では、車両がプラグインハイブリッド車である場合について説明したが、プラグインハイブリッド車に限らず、例えば電気モータのみを備えた電気自動車であってバッテリを外部から充電可能に構成されているものなど、車両内のバッテリを外部から充電可能に構成された車両であれば、第２実施形態のリモート車両診断システムを構成することができる。

また、上記実施形態では、インターネット網５及び携帯電話網４を介してセンタ２と車両３との間の通信が行われるものとして説明したが、センタ２と車両３との間の通信網は特に限定されるものではない。

第１実施形態のリモート車両診断システムの概略構成を表す説明図である。 第１実施形態のリモート車両診断システムを構成する車両内システムの概略構成を表すブロック図である。 第１実施形態の、リモート診断実行時にリモート診断センタが車両へ送信する情報を表す図であり、（ａ）は診断許可条件テーブル、（ｂ）は診断シナリオである。 リモート診断センタ内のサーバで実行されるセンタ側診断処理を表すフローチャートである。 第１実施形態の、車両内のマスタＥＣＵが実行する車両側診断処理を表すフローチャートである。 第１実施形態の車両側診断処理におけるＳ３４０の許可条件成立判定処理の詳細を表すフローチャートである。 診断許可条件テーブルの更新の際にユーザ側及びセンタ側でそれぞれ実行されるテーブル更新処理を表すフローチャートである。 第２実施形態のリモート車両診断システムを構成する車両内システムの概略構成を表すブロック図である。 第２実施形態の、リモート診断実行時にリモート診断センタが車両へ送信する情報を表す図であり、（ａ）は診断許可条件テーブル、（ｂ）は診断シナリオである。 第２実施形態の許可条件成立判定処理の詳細を表すフローチャートである。 第３実施形態の診断許可条件テーブルを表す図である。 第３実施形態の許可条件成立判定処理の詳細を表すフローチャートである。

符号の説明

１…リモート車両診断システム、２…センタ、３…車両、４…携帯電話網、５…インターネット網、６…自宅、７…パソコン、８…通信回線、９，８０…車両内システム、１０…センタ内システム、１１…サーバ、１２…診断サービス情報管理データベース、１３…事例データベース、１４…ネットワーク、２０，８１…リモート診断マスタＥＣＵ、２１，２２…アンテナ、２３…電源回路、２４…トランシーバ、３０…多重通信線、３１…ＭＣＵ、３２…ＲＯＭ、３３…ＲＡＭ、３４…通信機、３５…ＧＰＳ、３６…通信コントローラ、４０…第１ＥＣＵ、４１，５１，６１…アクチュエータ群、４２，５２，６２…センサ群、４３…車速センサ、５０…第２ＥＣＵ、５３…ドアロック機構、５４…ロックポジションスイッチ、６０…第３ＥＣＵ、７０…ナビＥＣＵ、７１…ディスプレイ、９０…充電制御ＥＣＵ、９１…電源ソケット、９２…モータ駆動用バッテリ、９３…補機用バッテリ、９６…電源制御ＥＣＵ、９７…リレー制御ボックス、９８…プッシュスイッチ、１００…充電用電源プラグ、１０１…商用交流電源、１０２…充電用ケーブル

Claims (12)

1. センタが送信した診断要求に従って車両が診断処理を実行するリモート車両診断方法であって、
   前記車両が前記診断処理を実行可能な許可条件が予め設定されており、
   前記車両は、前記センタから前記診断要求を受信したときに、該受信時の当該車両の状態が前記許可条件を満たしているか否か判断し、該許可条件を満たしている場合に、前記診断処理を実行する
   ことを特徴とするリモート車両診断方法。
2. 請求項１記載リモート車両診断方法であって、
   前記許可条件として、少なくとも、前記診断処理を実行可能な前記車両の位置が設定されている
   ことを特徴とするリモート車両診断方法。
3. 請求項１又は２記載のリモート車両診断方法であって、
   前記車両は、当該車両が備えているバッテリを当該車両の外部から供給される充電用電力によって充電可能に構成されており、
   前記許可条件として、少なくとも、前記充電用電力による前記バッテリへの充電が行われていること、が設定されている
   ことを特徴とするリモート車両診断方法。
4. センタが送信した診断要求に従って車両が診断処理を実行するリモート車両診断システムであって、
   前記車両が前記診断処理を実行可能な許可条件が予め設定された許可条件設定手段を備え、
   前記車両は、
   前記センタから前記診断要求を受信したときに、前記許可条件設定手段に設定されている前記許可条件に基づき、該受信時の当該車両の状態が該許可条件を満たしているか否か判断する許可条件判断手段と、
   該許可条件判断手段により前記許可条件を満たしていると判断された場合に、前記診断処理を実行する診断実行手段と、
   を備えたことを特徴とするリモート車両診断システム。
5. 請求項４記載のリモート車両診断システムであって、
   前記許可条件設定手段には、前記許可条件として、少なくとも、前記診断処理を実行可能な前記車両の位置である診断実行可能位置が設定されており、
   前記車両は、当該車両の位置を取得する位置取得手段を備え、
   前記許可条件判断手段は、前記センタから前記診断要求を受信したとき、前記判断として少なくとも、前記位置取得手段によって取得された該受信時の前記車両の位置が前記許可条件設定手段に設定されている前記診断実行可能位置と一致するか否かの判断を行う
   ことを特徴とするリモート車両診断システム。
6. 請求項５記載のリモート車両診断システムであって、
   前記車両が実行する前記診断処理には、当該車両が備えるドアをアンロックさせる動作が含まれており、
   前記診断実行手段は、前記許可条件判断手段により前記車両の位置が前記許可条件設定手段に設定されている前記診断実行可能位置と一致すると判断された場合に、該ドアをアンロックさせる動作を含む前記診断処理を実行する
   ことを特徴とするリモート車両診断システム。
7. 請求項４〜６いずれかに記載のリモート車両診断システムであって、
   前記車両は、
   当該車両が備えているバッテリの充電用電力を当該車両の外部から入力するための充電用電力入力手段と、
   該充電用電力入力手段に入力された前記充電用電力の、前記バッテリへの充電を制御する充電制御手段と、
   前記充電用電力に基づく前記バッテリの充電が行われている状態であるか否かを直接又は間接的に検出する充電状態検出手段と、
   を備え、
   前記許可条件設定手段には、前記許可条件として、少なくとも、前記充電用電力に基づく前記バッテリの充電が行われている状態であること、が設定されており、
   前記許可条件判断手段は、前記センタから前記診断要求を受信したとき、前記判断として少なくとも、前記充電用電力に基づく前記バッテリの充電が行われている状態であるか否かの判断を、前記充電状態検出手段による検出結果に基づいて行う
   ことを特徴とするリモート車両診断システム。
8. 請求項７記載のリモート車両診断システムであって、
   前記車両が実行する前記診断処理には、該車両のエンジンが停止した状態で前記バッテリの電力を消費させる動作が含まれており、
   前記診断実行手段は、前記許可条件判断手段により前記充電用電力に基づく前記バッテリへの充電が行われていると判断された場合に、該エンジンが停止した状態で前記バッテリの電力を消費させる動作を含む前記診断処理を実行する
   ことを特徴とするリモート車両診断システム。
9. 請求項４〜８いずれかに記載のリモート車両診断システムであって、
   前記センタは、
   前記許可条件設定手段と、
   該許可条件設定手段に設定されている前記許可条件を更新要求に従って更新する更新手段と、
   を備えていることを特徴とするリモート車両診断システム。
10. 請求項９記載のリモート車両診断システムであって、
    前記センタと通信回線を介して通信可能な通信端末を備え、
    前記通信端末は、
    前記センタの前記許可条件設定手段に設定されている前記許可条件を取得する許可条件取得手段と、
    該許可条件取得手段により取得された許可条件を更新するための所定の更新操作を受け付ける更新操作受付手段と、
    該更新操作受付手段が受け付けた更新操作に対応した前記更新要求を前記センタへ送信する更新要求送信手段と、
    を備え、
    前記センタが備える前記更新手段は、前記通信端末からの前記更新要求を受信したとき、該更新要求に基づいて、前記許可条件設定手段に設定されている前記許可条件を更新する
    ことを特徴とするリモート車両診断システム。
11. 請求項４〜１０いずれかに記載のリモート車両診断システムであって、
    前記許可条件設定手段には、複数種類の前記許可条件が設定され、且つ、該複数種類の許可条件の論理的な組み合わせを示す論理式が設定されており、
    前記許可条件判断手段は、
    前記複数種類の許可条件の各々について前記判断を行う個別判断手段と、
    該個別判断手段による前記各設定条件毎の判断結果に基づく前記論理式の演算結果に基づいて前記車両の状態が前記診断処理を実行可能な状態にあるか否かを最終的に判断する最終判断手段と、
    を備え、
    前記診断実行手段は、前記最終判断手段によって前記診断処理を実行可能な状態にあると判断された場合に、該診断処理を実行する
    ことを特徴とするリモート車両診断システム。
12. 車両に搭載され、センタから送信されてくる診断要求に従って診断処理を実行する車載診断装置であって、
    前記センタから前記診断要求を受信したときに、予め設定された許可条件に基づいて、該診断要求に応じた前記診断処理を実行可能な状態であるか否かを判断する許可条件判断手段と、
    該許可条件判断手段により前記許可条件を満たしていると判断された場合に、前記診断処理を実行する診断実行手段と、
    を備えたことを特徴とする車載診断装置。