JP2011107042A

JP2011107042A - 車両診断装置

Info

Publication number: JP2011107042A
Application number: JP2009264218A
Authority: JP
Inventors: Kazumori Sakai; 一守酒井; Migaku Makita; 琢牧田; Hiroki Hashimoto; 裕樹橋本; Yuichiro Ikeda; 雄一郎池田; Yosuke Morita; 陽介森田
Original assignee: Honda Motor Co Ltd
Current assignee: Honda Motor Co Ltd
Priority date: 2009-11-19
Filing date: 2009-11-19
Publication date: 2011-06-02
Anticipated expiration: 2029-11-19
Also published as: US8798843B2; JP5341725B2; US20110118933A1; CN102072822B; CN102072822A

Abstract

【課題】複数の診断プログラムが電子制御装置に対してデータを要求する場合でも、車両診断装置及び電子制御装置が要する通信負荷を低減可能な車両診断装置を提供する。
【解決手段】車両診断装置１２では、第１診断部２６から第１データの要求があった後、第２診断部２６から第２データの要求があったとき、第１データの種類と第２データの種類が同一であれば、当該種類のデータを電子制御装置に対して要求し、電子制御装置から受信した当該種類のデータを第１診断部及び第２診断部に送信し、又は、第１データの種類と第２データの種類が異なれば、第１データ及び第２データを電子制御装置に対して要求し、電子制御装置から第１データ及び第２データをまとめて受信し、受信した第１データを第１診断部に、受信した第２データを第２診断部に送信する。
【選択図】図１

Description

この発明は、車両に搭載された電子制御装置に対して車両外部から通信し、前記電子制御装置から入手した各種データに基づいて複数の診断項目の良否を判定する車両診断装置に関する。

電子制御装置（ＥＣＵ）を搭載した車両を生産する場合、車両組立後の最終検査工程において、ＥＣＵ及び当該ＥＣＵに電気的に接続された各機器が正常に機能しているかどうかを診断する。このような診断は、ＥＣＵに車両外部から接続された車両診断装置（テスタ）との間で通信をすることにより行われる（例えば、特許文献１、２）。

特許文献１では、検査時間を短縮するため、ＥＣＵ（１０）が検出したデータを一旦ＲＡＭ（２３）に格納し、その後、一括して当該検出データを検査テスタ（１００）に出力する（特許文献１の要約）。より具体的には、特許文献１では、検査テスタからＥＣＵへの通信要求により検査モードとなる（同段落［００１７］）。そして、ＥＣＵでは、各種データがＲＡＭに格納される（同段落［００２８］、［００３０］〜［００３２］）。ＲＡＭに格納されたデータは、検査テスタからの要求に応じてＥＣＵから検査テスタに送信される（同段落［００３９］、［００４３］）。

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

上記のように、特許文献１では、検査テスタからの通信要求に応じてＥＣＵは検査用のデータを検査テスタに送信する。しかしながら、検査テスタからの通信要求は、検査モードへの移行を指示するものでしかなく（特許文献１の段落［００１７］）、ＥＣＵに特定の検出データを要求可能なものとはなっていない。

このため、テスタにおいて、複数の診断プログラムを並行して実行し、各診断プログラムがＥＣＵから検出データを取得したい場合には特許文献１の構成は適用できない。

また、特許文献１では、ＲＡＭに格納した検出データをＥＣＵから検査テスタに送信すること、すなわち、ＥＣＵから検査テスタへのデータ送信に伴う通信負荷の低減は検討されているものの、検査テスタからＥＣＵへのデータ送信に伴う通信負荷の低減は考慮されていない。

この発明はこのような課題を考慮してなされたものであり、複数の診断プログラムが電子制御装置に対してデータを要求する場合でも、車両診断装置及び電子制御装置が要する通信負荷を低減することが可能な車両診断装置を提供することを目的とする。

この発明に係る車両診断装置は、車両に搭載された電子制御装置に対して車両外部から通信し、前記電子制御装置から入手した各種データに基づいて複数の診断項目の良否を判定するものであって、第１の診断プログラムを実行する第１診断部と、前記第１の診断プログラムとは異なる第２の診断プログラムを実行する第２診断部と、前記電子制御装置との間で通信を行う通信部とを備え、前記通信部は、前記第１診断部から前記電子制御装置に対する第１データの要求を受けた後、前記第２診断部から前記電子制御装置に対する第２データの要求を受けたとき、前記第１データの種類と前記第２データの種類が同一である場合、当該種類のデータを前記電子制御装置に対して要求し、前記電子制御装置から受信した当該種類のデータを前記第１診断部及び前記第２診断部に送信し、又は、前記第１データの種類と前記第２データの種類が異なる場合、前記第１データ及び前記第２データを前記電子制御装置に対して要求し、前記電子制御装置から前記第１データ及び前記第２データをまとめて受信し、受信した前記第１データを前記第１診断部に、受信した前記第２データを前記第２診断部に送信することを特徴とする。

この発明によれば、車両診断装置が実行する複数の診断プログラムが電子制御装置に対してデータを要求するとき、電子制御装置に対するデータ要求及び電子制御装置からのデータ受信をそれぞれ一度に行うことができる。これにより、複数の診断プログラムが別々に電子制御装置に対してデータを要求する場合と比べて、車両診断装置及び電子制御装置が要する通信負荷を低減し、効率的に処理を実行することが可能となる。

前記通信部は、前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データを要求し、当該第１データの受信後に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、前記電子制御装置に対して前記第２データを要求してもよい。これにより、第１データの受信までに第２データの要求がなかったとき、第１データとは別に第２データを要求することにより、データの要求の間隔が過度に長くなることを避け、第１データ及び第２データの鮮度を保つことができる。

前記第１データの種類と前記第２のデータの種類が同一である場合、前記通信部は、前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データを要求し、前記電子制御装置に対する前記第１データの要求後、当該第１データの受信前に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、受信した前記第１データを前記第１診断部及び前記第２診断部に送信してもよい。これにより、第２診断部に対するデータ送信を迅速に行うとともに、電子制御装置と車両診断装置の間の通信負荷を減らすことができる。

前記第１データの種類と前記第２データの種類が異なる場合、前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データ及び前記第２データの両方を要求し、前記電子制御装置に対する前記第１データ及び前記第２データの要求後、当該第１データ及び第２データの受信前に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、受信した前記第１データを前記第１診断部に送信し、受信した前記第２データを前記第２診断部に送信してもよい。これにより、第２診断部に対するデータ送信を迅速に行うとともに、電子制御装置と車両診断装置の間の通信負荷を減らすことができる。

この発明の一実施形態に係る車両診断装置としてのテスタを有する車両診断システムの概略構成図である。前記テスタのＣＰＵが実行するドライバソフトウェアの処理を示すフローチャートである。比較例のドライバソフトウェアを用いた場合の処理の一例を示す説明図である。前記実施形態のドライバソフトウェアを用いた場合の処理の第１例を示す説明図である。前記実施形態のドライバソフトウェアを用いた場合の処理の第２例を示す説明図である。図４の第１変形例を示す説明図である。図４の第２変形例を示す説明図である。図２の処理の第１変形例を示すフローチャートである。図２の処理の第２変形例を示すフローチャートである。図９の処理を行うドライバソフトウェアを用いた場合の処理の一例を示す説明図である。

［本実施形態の構成］
図１は、この発明の一実施形態に係る車両診断装置としてのテスタ１２を有する車両診断システム１０の概略構成図である。車両診断システム１０は、テスタ１２に加え、テスタ１２により各種の診断が行われる車両１４と、ホストコンピュータ１６とを有する。図１では明示していないが、車両診断システム１０には、テスタ１２と車両１４の組合せが複数含まれる。テスタ１２と車両１４とは通信ケーブル１８により接続され、両者の間で通信可能である。また、テスタ１２とホストコンピュータ１６とは無線通信が可能である。

テスタ１２は、入力部２０と、表示部２２と、スピーカ２４と、中央演算装置２６（ＣＰＵ２６）と、リードオンリメモリ２８（ＲＯＭ２８）と、ランダムアクセスメモリ３０（ＲＡＭ３０）と、通信インタフェース３２と、コネクタ３４とを有する。

車両１４は、電子制御装置４０（ＥＣＵ４０）と、イグニッションスイッチ４２（ＩＧＳＷ４２）と、エンジン４４と、エンジン回転数センサ４６（ＮＥセンサ４６）とを有する。また、ＥＣＵ４０は、中央演算装置５０（ＣＰＵ５０）と、リードオンリメモリ５２（ＲＯＭ５２）と、ランダムアクセスメモリ５４（ＲＡＭ５４）と、通信インタフェース５６と、コネクタ５８とを有する。

テスタ１２のＲＯＭ２８には、各種の検査に用いる複数の検査プログラムと、各検査プログラムからＥＣＵ４０に対するデータ要求を管理するドライバソフトウェアとが記憶されている。各検査プログラムとドライバソフトウェアはいずれもテスタ１２のＣＰＵ２６が実行する。また、ドライバソフトウェアとしては、例えば、ＣＡＮ（Controller Area Network）やＫＷＰ２０００用のものを用いることができる。

ホストコンピュータ１６は、各テスタ１２から各車両１４の診断データを吸い上げ、データベースとして記憶する。

車両診断システム１０の基本的な構成は、例えば、特許文献２に記載のものを用いることができる。

［ドライバソフトウェアによる処理］
図２は、本実施形態に係るテスタ１２のＣＰＵ２６が実行するドライバソフトウェアの処理を示すフローチャートである。図２におけるステップＳ１〜Ｓ４は、テスタ１２のＣＰＵ２６から車両１４のＥＣＵ４０にデータを要求する処理（データ要求処理）であり、ステップＳ５〜Ｓ６は、ＥＣＵ４０からＣＰＵ２６がデータを受信する処理（データ受信処理）である。また、本実施形態において、ステップＳ１〜Ｓ６の処理は、例えば、数十ナノ秒〜数十マイクロ秒の間に行い、ステップＳ１〜Ｓ６を何度も繰り返す。

ステップＳ１において、ＣＰＵ２６（ドライバソフトウェア）は、各検査プログラムから車両１４のＥＣＵ４０に対するデータ要求を受け付ける。受け付けたデータ要求は、当該データ要求を行った検査プログラムの識別子と共にドライバソフトウェアによりＲＡＭ３０に一時的に記憶される。

ステップＳ２において、ＣＰＵ２６（ドライバソフトウェア）は、タイマ値ＴＭＲ［μｓｅｃ］が、閾値ＴＨ＿ＴＭＲ［μｓｅｃ］以上となったかどうかを判定する。タイマ値ＴＭＲは、図示しないタイマがカウントするものであり、図２の処理の開始直後から時間の経過に応じて増加する。また、閾値ＴＨ＿ＴＭＲは、ＣＰＵ２６からＥＣＵ４０に対してデータ要求を行う周期（データ要求周期）を規定するものであり、本実施形態では固定値とされる。

タイマ値ＴＭＲが閾値ＴＨ＿ＴＭＲ以上でない場合（Ｓ２：ＮＯ）、ステップＳ５に進む。タイマ値ＴＭＲが閾値ＴＨ＿ＴＭＲ以上である場合（Ｓ２：ＹＥＳ）、ステップＳ３において、ＣＰＵ２６（ドライバソフトウェア）は、今回のデータ要求周期において各検査プログラムから受け付けたデータ要求を車両１４のＥＣＵ４０に対して送信する。この際、ＲＡＭ３０に一時的に記憶しているデータ要求と、当該データ要求を行った検査プログラムの識別子は記憶したままとする。続くステップＳ４において、ＣＰＵ２６（ドライバソフトウェア）は、タイマ値ＴＭＲをリセットする。

ステップＳ５において、ＣＰＵ２６（ドライバソフトウェア）は、ＥＣＵ４０からデータを受信したかどうかを確認する。このデータは、前回以前のデータ要求周期におけるデータ要求に対応するものである。ＥＣＵ４０からデータを受信した場合（Ｓ５：ＹＥＳ）、ステップＳ６において、ＣＰＵ２６（ドライバソフトウェア）は、当該データを要求した検査プログラム（対象検査プログラム）に対して当該データを送信する。当該データを受信した検査プログラムは、当該データを用いて検査を行う。一方、ＥＣＵ４０からデータを受信しなかった場合（Ｓ５：ＮＯ）、ＣＰＵ２６（ドライバソフトウェア）は、今回の図２の処理を終了する。図２の処理は、各検査プログラムによる検査が終了するまで繰り返される。

［本実施形態と比較例との比較］
図３は、比較例のドライバソフトウェアを用いた場合の処理の一例を示す。当該比較例のドライバソフトウェアは、いずれかの検査プログラムからデータ要求があると直ぐにＥＣＵ４０に対してデータ要求を行う（データ送信指令を送信する）と共に、当該データ要求に対応するデータを受信するまで次のデータ要求を保留する。図４は、本実施形態のドライバソフトウェアを用いた場合の処理の第１例を示す。図５は、本実施形態のドライバソフトウェアを用いた場合の処理の第２例を示す。前記第１例は、あるデータ要求周期に２つのデータ要求Ｒｎｅ１、Ｒｎｅ２があった場合の処理であり、前記第２例は、異なるデータ要求周期にそれぞれ１つのデータ要求Ｒｎｅ１、Ｒｎｅ２があった場合の処理である。

図３に示すように、比較例では、ドライバソフトウェア（図３では単に「ドライバ」と記載する。図４〜図７及び図１０においても同じ）は、検査プログラム１（図３では単に「検査１」と記載する。図４〜図７及び図１０においても同じ）からエンジン回転数ＮＥ［ｒｐｍ］のデータ要求Ｒｎｅ１を受けると、直ぐにＥＣＵ４０に対してこのデータ要求Ｒｎｅ１に対応するデータ送信指令Ｃｎｅ１を送信する。その後、比較例のドライバソフトウェアは、検査プログラム２（図３では単に「検査２」と記載する。図４〜図７及び図１０においても同じ）からエンジン回転数ＮＥのデータ要求Ｒｎｅ２を受けても、データ送信指令Ｃｎｅ１に対応するエンジン回転数ＮＥのデータＤｎｅ１を受信及び処理するまでデータ要求Ｒｎｅ２に対応するデータ送信指令Ｃｎｅ２をＥＣＵ４０に対して送信しない。

データ送信指令Ｃｎｅ１に対応するエンジン回転数ＮＥのデータＤｎｅ１を受信すると、ドライバソフトウェアは、当該データＤｎｅ１を検査プログラム１に送信する。その後、比較例のドライバソフトウェアは、保留していたデータ要求Ｒｎｅ２に対応するデータ送信指令Ｃｎｅ２をＥＣＵ４０に対して送信する。そして、データ送信指令Ｃｎｅ２に対応するエンジン回転数ＮＥのデータＤｎｅ２を受信すると、ドライバソフトウェアは、当該データＤｎｅ２を検査プログラム２に送信する。

以上のように、図３の比較例では、検査プログラム２からのデータ要求Ｒｎｅ２を受信しても、データＤｎｅ１の受信及び処理が終わるまでデータ送信指令Ｃｎｅ２の送信を保留する。このため、データ要求Ｒｎｅ２の処理が遅れる。また、テスタ１２からＥＣＵ４０に対して２度のデータ送信指令が行われ、ＥＣＵ４０からテスタ１２に対して２度のデータ送信が行われる。

一方、図４に示すように、本実施形態のドライバソフトウェアは、検査プログラム１からデータ要求Ｒｎｅ１を受けても、同一のデータ要求周期内に更なるデータ要求を受け付ける。これにより、図４では、検査プログラム２からのデータ要求Ｒｎｅ２もデータ要求Ｒｎｅ１と同じデータ要求周期で受け付ける。そして、データ要求Ｒｎｅ１、Ｒｎｅ２の両方に対応するデータ送信指令Ｃｎｅをテスタ１２からＥＣＵ４０に送信する。

データ送信指令Ｃｎｅに対応するエンジン回転数ＮＥのデータＤｎｅを受信すると、本実施形態のドライバソフトウェアは、当該データＤｎｅを検査プログラム１及び検査プログラム２の両方に送信する。

また、図５に示すように、本実施形態のドライバソフトウェアは、検査プログラム１からデータ要求Ｒｎｅ１を受けた後、同一のデータ要求周期内に別のデータ要求がなければ、データ要求Ｒｎｅ１のみに対応するデータ送信指令Ｃｎｅ１をＥＣＵ４０に送信する。そして、データ送信指令Ｃｎｅ１に伴うデータＤｎｅ１をＥＣＵ４０から受信すると、検査プログラム１に対して当該データＤｎｅ１を送信する。

次いで、別のデータ要求周期に別のデータ要求Ｒｎｅ２を受けた場合、データ送信指令Ｃｎｅ１とは別のデータ送信指令Ｃｎｅ２をＥＣＵ４０に送信する。そして、データ送信指令Ｃｎｅ２に伴うデータＤｎｅ２をＥＣＵ４０から受信すると、検査プログラム２に対して当該データＤｎｅ２を送信する。

以上のように、本実施形態の図４の例では、２つのデータ要求Ｒｎｅ１、Ｒｎｅ２をまとめてデータ送信指令Ｃｎｅとしてテスタ１２からＥＣＵ４０に送信する。そして、ＥＣＵ４０は、このデータ送信指令Ｃｎｅに対応するデータＤｎｅをテスタ１２に送信する。このため、データ要求Ｒｎｅ２の処理を早めることができる。また、テスタ１２からＥＣＵ４０に対して１度のデータ送信指令が行われ、ＥＣＵ４０からテスタ１２に対して１度のデータ送信が行われる。従って、テスタ１２及びＥＣＵ４０が要する通信負荷を低減し、効率的に処理を実行することができる。

また、本実施形態の図５の例では、データ要求Ｒｎｅ１があったデータ要求周期内にデータ要求Ｒｎｅ２がなかったとき、データ要求Ｒｎｅ１に対応するデータ送信指令Ｃｎｅ１とは別に、データ要求Ｒｎｅ２に対応するデータ送信指令Ｃｎｅ２を送信することにより、データ送信指令の間隔が過度に長くなることを避け、各データＤｎｅ１、Ｄｎｅ２の鮮度を保つことができる。

［本実施形態の効果］
以上説明したように、本実施形態（図４）によれば、テスタ１２が実行する検査プログラム１、２の両方がＥＣＵ４０に対してエンジン回転数ＮＥのデータを要求するとき、ＥＣＵ４０に対するデータ送信指令Ｃｎｅ及びＥＣＵ４０からのデータ受信をそれぞれ一度に行うことができる。これにより、検査プログラム１、２が別々にＥＣＵ４０に対してエンジン回転数ＮＥのデータを要求する場合と比べて、テスタ１２及びＥＣＵ４０が要する通信負荷を低減し、効率的に処理を実行することが可能となる。また、テスタ１２とＥＣＵ４０との通信方式には、ＣＡＮやＫＷＰ２０００等、様々な規格が存在するが、ドライバソフトウェア側の処理で対応するため、通信方式や通信速度に捉われずに適用することができる。

上記実施形態（図５）では、テスタ１２のＣＰＵ２６（ドライバソフトウェア）は、検査プログラム１からデータ要求Ｒｎｅ１を受けた後、検査プログラム２からデータ要求Ｒｎｅ２をデータ要求周期内に受けなかったとき、データ要求Ｒｎｅ１に対応するデータ送信指令Ｃｎｅ１をＥＣＵ４０に送信し、その後、データ要求Ｒｎｅ２に対応するデータ送信指令Ｃｎｅ２をＥＣＵ４０に送信する。これにより、データ要求Ｒｎｅ１があったデータ要求周期内にデータ要求Ｒｎｅ２がなかったとき、データ要求Ｒｎｅ１に対応するデータ送信指令Ｃｎｅ１とは別に、データ要求Ｒｎｅ２に対応するデータ送信指令Ｃｎｅ２を送信することにより、データ要求の間隔が過度に長くなることを避け、データＤｎｅ１、Ｄｎｅ２の鮮度を保つことができる。

［変形例］
なお、この発明は、上記実施形態に限らず、この明細書の記載内容に基づき、種々の構成を採り得ることはもちろんである。例えば、以下の構成を採用することができる。

上記実施形態（図４、図５）では、２つの検査プログラム１、２からのデータ要求Ｒｎｅ１、Ｒｎｅ２の例を説明したが、これに限らず、図６に示すように、３つ以上の検査プログラム１、２、…ｎからのデータ要求Ｒｎｅ１、Ｒｎｅ２、…、Ｒｎｅｎを処理することもできる。

上記実施形態では、データ要求Ｒｎｅ１、Ｒｎｅ２はいずれもエンジン回転数ＮＥを要求するものであったが、これに限らず、図７に示すように、ＣＰＵ２６（ドライバソフトウェア）は、エンジン回転数ＮＥを要求するデータ要求Ｒｎｅと、水温Ｔｗ［℃］を要求するデータ要求Ｒｔｗとを受け付け、両方のデータ要求Ｒｎｅ、Ｒｔｗに対応するデータ送信指令Ｃｄをテスタ１２からＥＣＵ４０に送信してもよい。

上記実施形態では、図２の処理を用いたが、これに限らない。例えば、図８に示す第１変形例の処理を用いることもできる。当該第１変形例は、一定間隔でデータ要求周期を設けるのではなく、最初のデータ要求があってから所定時間（閾値ＴＨ＿ＴＨＲ２）、更なるデータ要求を受け付けるものである。なお、第１変形例において、ステップＳ１１〜Ｓ１９の処理は、例えば、数十ナノ秒〜数十マイクロ秒の間に行い、ステップＳ１１〜Ｓ１９を何度も繰り返す。

ステップＳ１１において、テスタ１２のＣＰＵ２６（ドライバソフトウェア）は、いずれかの検査プログラムからデータ要求があったかどうかを判定する。データ要求があった場合（Ｓ１１：ＹＥＳ）、ステップＳ１２に進み、データ要求がなかった場合（Ｓ１１：ＮＯ）、ステップＳ１７に進む。

ステップＳ１２において、ＣＰＵ２６（ドライバソフトウェア）は、図示しないタイマ値ＴＭＲ２［μｓｅｃ］のカウントを開始する。タイマ値ＴＭＲ２は、図示しないタイマがカウントするものであり、ステップＳ１２から時間の経過に応じて増加し、ステップＳ１６においてタイマ値ＴＭＲ２がリセットされると増加を中止する。

ステップＳ１３において、ＣＰＵ２６（ドライバソフトウェア）は、各検査プログラムからデータ要求を受け付ける。すなわち、ステップＳ１１においてデータ要求を行った検査プログラムを含め、各検査プログラムからの更なるデータ要求を受け付ける。なお、ステップＳ１１においてデータ要求を行った検査プログラムを含めるのは、当該検査プログラムから別の種類のデータ要求がある場合を考慮したものである。

ステップＳ１４において、ＣＰＵ２６（ドライバソフトウェア）は、タイマ値ＴＭＲ２が閾値ＴＨ＿ＴＭＲ２以上になったかどうかを判定する。閾値ＴＨ＿ＴＭＲ２は、前記実施形態のデータ要求周期に対応するものであるが、最初のデータ要求又はＥＣＵ４０へのデータ送信指令送信後、最初のデータ要求があったとき（以下ではいずれの場合も「最初のデータ要求があったとき」と記載する。）からの期間を規定する点でデータ要求周期と異なる。タイマ値ＴＭＲ２が閾値ＴＨ＿ＴＭＲ２以上である場合（Ｓ１４：ＹＥＳ）、ステップＳ１５に進み、タイマ値ＴＭＲ２が閾値ＴＨ＿ＴＭＲ２以上でない場合（Ｓ１４：ＮＯ）、ステップＳ１７に進む。

ステップＳ１５において、ＣＰＵ２６（ドライバソフトウェア）は、ステップＳ１１、Ｓ１３で受け付けた全てのデータ要求に対応するデータ送信指令をＥＣＵ４０に送信する。ステップＳ１６において、ＣＰＵ２６（ドライバソフトウェア）は、タイマ値ＴＭＲ２をリセットし、その値をゼロにホールドする。当該ゼロへのホールドは、次のステップＳ１２を経るまで維持される。これにより、ＥＣＵ４０に対してデータ送信指令を送信した後、最初のデータ要求を受けるまでタイマ値ＴＭＲ２をゼロのまま維持することができる。

ステップＳ１７、Ｓ１８は、図２のステップＳ５、Ｓ６と同様である。

ステップＳ１９において、ＣＰＵ２６（ドライバソフトウェア）は、タイマ値ＴＭＲ２がゼロであるかどうかを判定する。タイマ値ＴＭＲ２がゼロでない場合（Ｓ１９：ＮＯ）、ステップＳ１２でタイマ値ＴＭＲ２のカウントを開始した後、ステップＳ１６でタイマ値ＴＭＲ２をリセットする前であるといえる。従って、ステップＳ１４がＹＥＳとはなっておらず、ＣＰＵ２６（ドライバソフトウェア）は、ステップＳ１３→Ｓ１４：ＮＯを繰り返しながら、更なるデータ要求を受け付けている状態である。そこで、更なるデータ要求を受け付けるためにステップＳ１３に戻る。タイマ値ＴＭＲ２がゼロである場合（Ｓ１９：ＹＥＳ）、ＣＰＵ２６（ドライバソフトウェア）は、最初のデータ要求を受付中である。そこで、今回の図８の処理を終了する。図８の処理は、各検査プログラムによる検査が終了するまで繰り返される。

第１変形例の処理によれば、更なるデータ要求の受付期間を最初のデータ要求があったときから起算するので、最初のデータ要求と更なるデータ要求のタイミングが接近しているとき、確実に両方のデータ要求に対応するデータ送信指令をＥＣＵ４０に送信することが可能となる。

図８の第１変形例の代わりに、図９に示す第２変形例の処理を用いることもできる。当該第２変形例は、基本的に図２の実施形態と同様であるが、あるデータ要求（第１データ要求）に伴うデータ送信要求をテスタ１２からＥＣＵ４０に行った直後に、第１データ要求の対象データと同じ種類のデータを要求するデータ要求（第２データ要求）があったとき、第１データ要求に対応するデータ（第１データ）を、第２データ要求に対して流用する点で上記実施形態と異なる。なお、第２変形例において、ステップＳ２１〜Ｓ２８の処理は、例えば、数十ナノ秒〜数十マイクロ秒の間に行い、ステップＳ２１〜Ｓ２８を何度も繰り返す。

図１０は、第２変形例の処理（図９）を行うドライバソフトウェアを用いた場合の処理の一例を示す図である。

図９のステップＳ２１〜Ｓ２５は、図２のステップＳ１〜Ｓ５と同様である。ステップＳ２５において、ＥＣＵ４０からデータを受信していない場合（Ｓ２５：ＮＯ）、今回の処理を終え、ステップＳ２１に戻る。一方、ＥＣＵ４０からデータを受信した場合（Ｓ２５：ＹＥＳ）、ステップＳ２６に進む。

ステップＳ２６において、ＣＰＵ２６（ドライバソフトウェア）は、ＥＣＵ４０から受信したデータを流用可能であるかどうかを判定する。ここでの「流用」とは、あるデータ要求（図１０の第１データ要求Ｒｎｅ１）に伴うデータ送信要求Ｃｎｅ１をテスタ１２からＥＣＵ４０に行った直後に、第１データ要求Ｒｎｅ１と同じくエンジン回転数ＮＥに関する第２データ要求Ｒｎｅ２を受け付けたとき、第１データ要求Ｒｎｅに対応するデータ（第１データＤｎｅ１）を、第２データ要求Ｒｎｅ２に対して流用することをいう。

ＥＣＵ４０から受信したデータ（図１０の第１データＤｎｅ１）を流用可能である場合（Ｓ２６：ＹＥＳ）、ステップＳ２７において、ＣＰＵ２６（ドライバソフトウェア）は、当該データを流用して、対象検査プログラムにデータを送信する。例えば、図１０の例であれば、第２データ要求Ｒｎｅ２に対応するデータ送信指令をＥＣＵ４０に送信せずに、第１データＤｎｅ１を検査プログラム１と検査プログラム２の両方に送信する。

一方、ＥＣＵ４０から受信したデータを流用可能でない場合（Ｓ２６：ＮＯ）、ステップＳ２８において、ＣＰＵ２６（ドライバソフトウェア）は、当該データを流用せずに対象検査プログラムにデータを送信する。すなわち、データ送信指令の元となったデータ要求を行った検査プログラム（図１０の例では、第１データ要求Ｒｎｅ１を行った検査プログラム１）に対してのみ、ＥＣＵ４０から受信したデータを送信する。

上記第２変形例では、検査プログラム１のデータ要求Ｒｎｅ１及び検査プログラム２のデータ要求Ｒｎｅ２はいずれもエンジン回転数ＮＥに関するものである。そして、テスタ１２のＣＰＵ２６は、検査プログラム１からＥＣＵ４０に対するデータ要求Ｒｎｅ１を受けた後、検査プログラム２からＥＣＵ４０に対するデータ要求Ｒｎｅ２を同一のデータ要求周期内に受けなかったとき、データ要求Ｒｎｅ１に対応するデータ送信指令Ｃｎｅ１をＥＣＵ４０に対して送信し、ＥＣＵ４０に対するデータ送信指令Ｃｎｅ１の送信後、これに対応するデータＤｎｅ１の受信前に、検査プログラム２からＥＣＵ４０に対するデータ要求Ｒｎｅ２を受けたとき、受信したデータＤｎｅ１を検査プログラム１及び検査プログラム２に送信する。これにより、検査プログラム２に対するデータ送信を迅速に行うとともに、テスタ１２とＥＣＵ４０の間の通信負荷を減らすことができる。

図９の第２変形例は、図７のように、異なる種類のデータを求めるデータ要求に対しても応用可能である。例えば、エンジン回転数ＮＥ又は水温Ｔｗのいずれか一方のデータ要求があったとき、ＣＰＵ２６（ドライバソフトウェア）は、エンジン回転数ＮＥ及び水温Ｔｗの両方を求めるデータ送信指令をＥＣＵ４０に送信する。そして、ＣＰＵ２６（ドライバソフトウェア）が、エンジン回転数ＮＥ及び水温ＴｗをＥＣＵ４０から受信した際にいずれか一方のデータを流用することができる。

１０…車両診断システム１２…テスタ（車両診断装置）
１４…車両１６…ホストコンピュータ
４０…ＥＣＵ（電子制御装置）

Claims

車両に搭載された電子制御装置に対して車両外部から通信し、前記電子制御装置から入手した各種データに基づいて複数の診断項目の良否を判定する車両診断装置であって、
第１の診断プログラムを実行する第１診断部と、
前記第１の診断プログラムとは異なる第２の診断プログラムを実行する第２診断部と、
前記電子制御装置との間で通信を行う通信部と
を備え、
前記通信部は、
前記第１診断部から前記電子制御装置に対する第１データの要求を受けた後、前記第２診断部から前記電子制御装置に対する第２データの要求を受けたとき、
前記第１データの種類と前記第２データの種類が同一である場合、当該種類のデータを前記電子制御装置に対して要求し、前記電子制御装置から受信した当該種類のデータを前記第１診断部及び前記第２診断部に送信し、又は、
前記第１データの種類と前記第２データの種類が異なる場合、前記第１データ及び前記第２データを前記電子制御装置に対して要求し、前記電子制御装置から前記第１データ及び前記第２データをまとめて受信し、受信した前記第１データを前記第１診断部に、受信した前記第２データを前記第２診断部に送信する
ことを特徴とする車両診断装置。
請求項１記載の車両診断装置において、
前記通信部は、
前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データを要求し、
当該第１データの受信後に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、前記電子制御装置に対して前記第２データを要求する
ことを特徴とする車両診断装置。
請求項１又は２記載の車両診断装置において、
前記第１データの種類と前記第２のデータの種類は同一であり、
前記通信部は、
前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データを要求し、
前記電子制御装置に対する前記第１データの要求後、当該第１データの受信前に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、受信した前記第１データを前記第１診断部及び前記第２診断部に送信する
ことを特徴とする車両診断装置。
請求項１〜３のいずれか１項に記載の車両診断装置において、
前記第１データの種類と前記第２データの種類は異なり、
前記第１診断部から前記車両診断装置に対する前記第１データの要求を受けた後、前記第２診断部から前記車両診断装置に対する前記第２データの要求を所定期間内に受けなかったとき、前記電子制御装置に対して前記第１データ及び前記第２データの両方を要求し、
前記電子制御装置に対する前記第１データ及び前記第２データの要求後、当該第１データ及び第２データの受信前に、前記第２診断部から前記車両診断装置に対する前記第２データの要求を受けたとき、受信した前記第１データを前記第１診断部に送信し、受信した前記第２データを前記第２診断部に送信する
ことを特徴とする車両診断装置。