JP2004161255A - 車両用電子制御装置，電子制御ユニット，プログラム及び記録媒体 - Google Patents

Abstract

【課題】 外部スキャンツールからの要求に応じ、複数搭載された電子制御ユニットの１つから車両識別情報を効率よく送信する車両用電子制御装置を提供する。
【解決手段】 本発明の車両用電子制御装置１０では、テスタ５０に対してＶＩＮコードを送信するＥＣＵの優先順位が予め定められており、優先順位の高い（つまり応答開始時間の早い）ＥＣＵが、故障や断線によりＶＩＮコードを正常に送信できないような場合には、次に優先順位の高いＥＣＵが順次代わってＶＩＮコードを送信する。また、各ＥＣＵは、テスタ５０からのＶＩＮコード要求を受信すると、通信ラインＬをモニタし、他のＥＣＵによりＶＩＮコードの応答が完了すると、以降のＶＩＮコード応答のための処理を中止し、自身はＶＩＮコードの応答を行わない。このため、ＯＢＤIIの改正における「１車両で１つのＶＩＮコードのみを応答すること」を遵守することができる。
【選択図】 図２

Description

本発明は、通信ラインに接続された外部スキャンツールからの要求に応じて車両識別情報を送信可能に構成された電子制御ユニット、及びその電子制御ユニットを複数備えた車両用電子制御装置に関する。

従来、車両の構成要素の増大に伴うシステムの大規模化に対処するため、これら複数の構成要素の個々に設けられた電子制御ユニット（以下「ＥＣＵ」ともいう）の間で互いにデータのやりとりができるように構成することにより、車両全体としての安定した制御を実現する車両用電子制御装置が採用されている。

そして近年、これらの電子制御ユニットが搭載された車両の診断システムにおいても所謂ＯＢＤIIへの対応づけが義務づけられている。このＯＢＤIIシステムを搭載した車両は、修理工場において外部スキャンツール（テスタ）を通信ライン経由で各ＥＣＵに接続することにより、所定の通信フォーマット（ＫＷＰダイアグ通信フォーマット）で車両固有の車両識別情報（以下「ＶＩＮコード」という）を読み出すことができる。このため、修理工場の作業員は、その外部スキャンツールに表示されたＶＩＮコードを介して車両の各種情報を取得し、当該車両を特定して最適な処置を施すことができるのである。

尚、以上の説明は当業者間で公知・公用の技術にかかるものであるため、出願人は特に先行技術文献を開示しない。

しかしながら、このような外部スキャンツールからのＶＩＮコードの送信要求に対して複数のＥＣＵの全てが応答すると、通信ライン上でデータの衝突が頻繁に発生して通信効率を悪化させると共に、各ＥＣＵに余分な負荷を与えてしまう。このような問題は、今後通信ラインに接続されるＥＣＵが増加するにつれ、益々顕在化されることになる。

また、最近のＯＢＤIIの改正により「１車両で１つのＶＩＮコードのみを応答すること」が義務付けられることになったため、外部スキャンツールにＶＩＮコードを応答する方法として、予め特定した１つのＥＣＵのみＶＩＮコードを出力する技術が考えられる。

しかし、このような技術においては、ＶＩＮコードをサポートしているＥＣＵが１車両に１つしかないため、そのＥＣＵが故障したり、若しくはそのＥＣＵの部分の通信ラインが断線したような場合には、外部スキャンツールに対してＶＩＮコードを応答できないといった問題があった。かかる問題は、上記のように全てのＥＣＵによってＶＩＮコードをサポートすることで解決できるが、その場合には、車両に搭載された全てのＥＣＵがＶＩＮコードを応答してしまうことになるため、結局、上記ＯＢＤIIの「１車両で１つのＶＩＮコードのみを応答すること」の要件を満足できなくなるといった問題が生じることになる。

本発明は、こうした問題に鑑みてなされたものであり、外部スキャンツールからの要求に応じ、複数搭載された電子制御ユニットの１つから車両識別情報を効率よく送信できる車両用電子制御装置を提供することを目的とする。

上記課題に鑑み、請求項１記載の車両用電子制御装置は、車両に搭載され、通信ラインを介して相互にデータ通信が可能な複数の電子制御ユニットを備え、通信ラインに接続された外部スキャンツールからの要求に応じて、車両固有の車両識別情報を送信可能に構成されている。ここで、外部スキャンツールと通信ラインとの接続は、例えば車両側の通信ラインに設けられたコネクタに、外部スキャンツール側のコネクタを接続する等して行われる。

そして、各電子制御ユニットにおいて、記憶手段が上記車両識別情報（つまりＶＩＮコード）を記憶しており、検出手段が、通信ラインをモニタし、他のいずれかの電子制御ユニットが外部スキャンツールに対して車両識別情報を応答した場合にこれを検出する。一方、計時手段が、外部スキャンツールから車両識別情報の送信要求を受信した時点からの経過時間を計時し、この計時手段により、複数の電子制御ユニットについて予め定めた優先順位に従って設定された自己の応答開始時間が計時されると、通信手段が、検出手段がそれ以前に他の電子制御ユニットによる車両識別情報の応答を検出していないことを条件に、記憶手段に記憶されている車両識別情報を読み出して外部スキャンツールに送信する。

すなわち、かかる構成では、外部スキャンツールに対して車両識別情報を送信する電子制御ユニットの優先順位が予め定められており、その優先順位が車両識別情報の応答開始時間という形で設定されている。従って、優先順位の高い（つまり応答開始時間の早い）電子制御ユニットが、故障や断線により車両識別情報を送信できないような場合には、次に優先順位の高い電子制御ユニットが順次代わって車両識別情報を送信するのである。その場合、車両識別情報の送信は、検出手段がそれ以前に他の電子制御ユニットによる車両識別情報の応答を検出していないことが条件とされているため、複数の電子制御ユニットから車両識別情報が送信されることはない。

かかる構成によれば、各電子制御ユニットが出力した複数のデータ（車両識別情報）が通信ライン上で衝突をすることもなく、通信効率の悪化を効果的に抑制又は防止することができる。また、１つの電子制御ユニットが車両識別情報を送信している間は、他の電子制御ユニットの送信手段が動作しないため、その負荷の増大をも効果的に抑制又は防止することができる。その効果は、今後通信ラインに接続される電子制御ユニットが増加するにつれて益々顕著なものとなる。

さらに、１つの電子制御ユニットが車両識別情報を応答した場合には、他の電子制御ユニットはその応答を行わないため、上述したＯＢＤIIの改正における「１車両で１つのＶＩＮコードのみを応答すること」を遵守することができる。

その際、請求項２に記載のように、上記検出手段は、外部スキャンツールから車両識別情報の送信要求を受信した時点から、通信ラインのモニタによる検出処理を開始するようにするとよい。

すなわち、車両識別情報の送信処理は、外部スキャンツールから車両識別情報の送信要求に対して行われるものであるため、それ以前の車両識別情報の検出処理は不要であり、また、このように検出手段による不要な動作をしないようにすることで、電子制御ユニットの処理負荷の増大を抑制することができる。

また、好ましくは請求項３に記載のように、検出手段が、通信ラインを流れるデータについて、まずその送信先アドレスを検出し、その送信先アドレスが外部スキャンツールのアドレスである場合にのみ、引き続きデータの内容が車両識別情報であるか否かをチェックするようにするとよい。

すなわち、送信先アドレスが外部スキャンツールのアドレスでなければ、他の電子制御ユニットによる車両識別情報の送信ではないことが分かるため、送信先アドレスをチェックして車両識別情報でないことが分かれば、そのデータについての検出処理を中止するのである。かかる構成により、検出手段の余分な動作を排除して、電子制御ユニットにかかる処理負荷の増大を効果的に抑制又は防止することができる。

さらに好ましくは、請求項４に記載のように、各電子制御ユニットが、検出手段を介して、他のいずれかの電子制御ユニットが外部スキャンツールに対して車両識別情報を応答したことを検出すると、検出手段及び計時手段の動作を中止するようにするとよい。

すなわち、いずれかの電子制御ユニットが外部スキャンツールに車両識別情報を送信すると、他の電子制御ユニットはもはや車両識別情報を送信する必要がないため、以降、検出手段及び計時手段の動作を中止することで、他の電子制御ユニットの処理負荷の増大を防止するのである。これにより、他の電子制御ユニットは、本来の車両制御処理を効率的に実施することができる。

また請求項５に記載のように、各電子制御ユニットの応答開始時間は、車両識別情報の応答に要する予め定める時間以上の時間間隔で順次設定するのがよい。
すなわち、車両識別情報を表す一連のデータが完全に送信されてから次の電子制御ユニットによる応答を開始するように、各電子制御ユニットの応答開始時間を設定するのである。例えば後述する実施例にて述べるように、車両識別情報を表すデータの最後尾のチェックサム（ＣＳ）が送信されるまで、後続する電子制御ユニットの応答を開始させないのである。

かかる構成により、例えばノイズ等の影響により、先行する電子制御ユニットによっては正常なデータが送信できず、外部スキャンツールによりその受信が拒否されたような場合に、後続する電子制御ユニットにより正常な車両識別情報を送信することができる。

一方、請求項６に記載のように、各電子制御ユニットの計時手段が、他の電子制御ユニットによる車両識別情報の応答が開始された時点で計時を終了し、その応答により車両識別情報が正常に送信されなかった場合には、その応答が終了された時点からの経過時間を計時するようにしてもよい。

すなわち、ある電子制御ユニットにより車両識別情報の応答が開始された場合には、他の電子制御ユニットの計時手段が計時を終了することで車両識別情報の応答を重複して行わないようにするのである。ここで、車両識別情報の応答が開始されたものの、例えばノイズ等の影響により、車両識別情報が正常に送信されない場合もあり得るため、この場合には、他の電子制御ユニットの計時手段は、その応答が終了された時点からの経過時間を計時するのである。

かかる構成によれば、上記請求項５の装置と同様に、先行する電子制御ユニットによっては正常なデータが送信できず、外部スキャンツールによりその受信が拒否されたような場合に、後続する電子制御ユニットにより正常な車両識別情報を送信することができる。そして特に、本請求項６の装置によれば、各電子制御ユニットの応答開始時間を設定する際に、上記請求項５のように車両識別情報の応答に要する時間を加味して長く設定する必要がないため、応答開始時間を設定する際の自由度を高くすることができる。さらに、本装置によれば、先行する電子制御ユニットが故障や断線により車両識別情報の応答を開始できない状態（つまりデータ送信不能状態）となっている場合には、後続する電子制御ユニットの計時手段による計時が終了されないため、不要な待ち時間を減らすことができる。

また、請求項７に記載のように、各電子制御ユニットの通信手段が、時間短縮手段を有し、この時間短縮手段が、自己の応答開始時間（つまり、当該電子制御ユニットについて設定された応答開始時間）よりも短い応答開始時間に設定された他の電子制御ユニットがデータ送信不能状態であるか否かを判定し、データ送信不能状態であると判定した場合には、自己の応答開始時間を短縮するようにするとよい。

すなわち、各電子制御ユニットの応答開始時間は、優先順位が低いほど長く設定する必要があるため、優先順位が低いほど待ち時間が長くなるが、優先順位の高い電子制御ユニットにデータ送信不能状態のものが存在する場合には、後続の電子制御ユニットの応答開始時間をその分短縮することができるのである。かかる構成により、外部スキャンツールの応答待ち時間を短縮することができる。また、不要な待ち時間を減らすことにより通信ラインの利用効率を向上させることができる。

そして、好ましくは請求項８に記載のように、各電子制御ユニットの時間短縮手段が、通信ラインをモニタし、自己の応答開始時間よりも短い応答開始時間に設定された他の電子制御ユニットが一定時間以上データを送信していない場合に、その電子制御ユニットがデータ送信不能状態であると判定するとよい。

すなわち、他の電子制御ユニットがデータ送信不能状態であるか否かを、その電子制御ユニットが通信ラインを介して送信するデータに基づき判定するのである。かかる構成により、他の電子制御ユニットがデータ送信不能状態であるか否かを容易に判定することができる。

さらに好ましくは、請求項９に記載のように、各電子制御ユニットの時間短縮手段が、データ送信不能状態であると判定した電子制御ユニットの数が多いほど自己の応答開始時間が短くなるようにその応答開始時間を短縮するとよい。

すなわち、各電子制御ユニットの応答開始時間は、優先順位が低いほど長く設定する必要があるため、逆に、優先順位の高い電子制御ユニットにデータ送信不能状態のものが多く存在するほど応答開始時間を短縮することができるのである。かかる構成により、外部スキャンツールの応答待ち時間を効率よく短縮することができる。また、通信ラインの利用効率を一層向上させることができる。

次に、請求項１０記載の電子制御ユニットは、車両に搭載され、通信ラインを介して他の電子制御ユニットとの間で相互にデータ通信が可能であり、通信ラインに接続された外部スキャンツールからの要求に応じて、車両固有の車両識別情報を送信可能に構成されている。

そして、記憶手段が、上記車両識別情報（ＶＩＮコード）を記憶しており、検出手段が、通信ラインをモニタし、他のいずれかの電子制御ユニットが外部スキャンツールに対して車両識別情報を応答したことを検出する。一方、計時手段が、外部スキャンツールから車両識別情報の送信要求を受信した時点からの経過時間を計時し、この計時手段により、複数の電子制御ユニットについて予め定めた優先順位に従って設定された自己の応答開始時間が計時されると、通信手段が、検出手段がそれ以前に車両識別情報を検出していないことを条件に、記憶手段に記憶されている車両識別情報を読み出して外部スキャンツールに送信する。

かかる構成によれば、他の電子制御ユニットが外部スキャンツールに対して車両識別情報を応答した場合には、自己の送信手段が動作しないため、その処理負荷の増大を効果的に抑制又は防止することができる。また、上記請求項１記載の車両用電子制御装置の１つの電子制御ユニットとして構成することができ、その場合には、請求項１記載の車両用電子制御装置と同様の作用効果を実現することができる。

また、請求項１１〜１８の夫々に記載の電子制御ユニットについても、夫々上記請求項２〜９の車両用電子制御装置の１つの電子制御ユニットとして構成することができ、その場合には、請求項２〜９の夫々に記載の車両用電子制御装置と同様の作用効果を実現することができる。

尚、このような電子制御ユニットにおける検出手段、計時手段及び通信手段をコンピュータシステムにて実現する機能は、例えば、コンピュータシステム側で起動するプログラムとして備えられる（請求項１９）。

次に、請求項２０記載の車両用電子制御装置は、上記請求項１の装置と同様、車両に搭載され、通信ラインを介して相互にデータ通信が可能な複数の電子制御ユニットを備え、通信ラインに接続された外部スキャンツールからの要求に応じて、車両固有の車両識別情報を送信可能に構成されている。

そして、各電子制御ユニットにおいて、記憶手段が上記車両識別情報（ＶＩＮコード）を記憶しており、検出手段が、通信ラインをモニタし、他のいずれかの電子制御ユニットが外部スキャンツールに対して車両識別情報を応答した場合にこれを検出する。

一方、各電子制御ユニットには、送信すべきデータを、通信ラインが使用中でなければ直ちに送信し、通信ラインが使用中であれば通信ラインが空き状態になってから送信するように構成されていると共に、他の電子制御ユニットと同時にデータを送信した場合には、複数の電子制御ユニットに対して予め定められた優先度に従い調停を行うように構成された通信手段が設けられている。

そして、各電子制御ユニットにおいて、送信要求手段が、外部スキャンツールから車両識別情報の送信要求を受信した場合に、検出手段がそれ以前に他の電子制御ユニットによる車両識別情報の応答を検出していないことを条件に、記憶手段に記憶されている車両識別情報の外部スキャンツールへの送信を通信手段に要求する。尚、このように送信を要求された車両識別情報が、上記送信すべきデータとなる。

また、この要求後に、検出手段により他の電子制御ユニットによる車両識別情報の応答が検出された場合には、送信要求手段が、車両識別情報の送信の中止を通信手段に要求する。

すなわち、かかる構成では、ある電子制御ユニットが外部スキャンツールに対して車両識別情報の応答を開始すると、他の電子制御ユニットは、通信ラインの使用中は応答を行わず、通信ラインが空き状態になってから応答を開始する。従って、先に車両識別情報の応答を開始した電子制御ユニットが、ノイズ等の影響により正常なデータを送信できなかった場合には、次の電子制御ユニットが順次代わって車両識別情報を送信するのである。ここで、複数の電子制御ユニットが同時にデータを送信した場合には、複数の電子制御ユニットに対して予め定められた優先度に従い調停が行われる。また、各電子制御ユニットの送信要求手段が車両識別情報の送信を通信手段に要求するのは、検出手段がそれ以前に他の電子制御ユニットによる車両識別情報の応答を検出していないことが条件とされており、加えて、送信要求手段が車両識別情報の送信を通信手段に要求した後であっても、検出手段が他の電子制御ユニットによる車両識別情報の応答を検出した場合には、送信要求手段が車両識別情報の送信の中止を通信手段に要求するようにしているため、複数の電子制御ユニットから車両識別情報が送信されることはない。

かかる構成によれば、上記請求項１の装置のように複数の電子制御ユニットについて予め応答開始時間を設定しなくても、上記請求項１の装置と同様、１つの電子制御ユニットが車両識別情報を応答した場合には、他の電子制御ユニットはその応答を行わないようにすることができる。この結果、上述したＯＢＤIIの改正における「１車両で１つのＶＩＮコードのみを応答すること」を遵守することができる。

その際、請求項２１に記載のように、通信手段が、送信すべきデータに優先度を表す識別コードを付加して送信し、送信した識別コードと通信ラインから検出される識別コードとが異なる場合に、調停負けしたものと判断してデータ送信を中止するようにするとよい。

すなわち、複数の電子制御ユニットが同時にデータを送信した場合には、そのデータに付加した識別コードに基づいて調停を行うのである。これによれば、調停を容易に行うことができる。

次に、請求項２２記載の電子制御ユニットは、上記請求項１０の電子制御ユニットと同様、車両に搭載され、通信ラインを介して他の電子制御ユニットとの間で相互にデータ通信が可能であり、通信ラインに接続された外部スキャンツールからの要求に応じて、車両固有の車両識別情報を送信可能に構成されている。

そして、記憶手段が、上記車両識別情報（ＶＩＮコード）を記憶しており、検出手段が、通信ラインをモニタし、他のいずれかの電子制御ユニットが外部スキャンツールに対して車両識別情報を応答したことを検出する。

一方、本電子制御ユニットには、送信すべきデータを、通信ラインが使用中でなければ直ちに送信し、通信ラインが使用中であれば通信ラインが空き状態になってから送信するように構成されていると共に、他の電子制御ユニットと同時にデータを送信した場合には、複数の電子制御ユニットに対して予め定められた優先度に従い調停を行うように構成された通信手段が設けられている。

そして、送信要求手段が、外部スキャンツールから車両識別情報の送信要求を受信した場合に、検出手段がそれ以前に他の電子制御ユニットによる車両識別情報の応答を検出していないことを条件に、記憶手段に記憶されている車両識別情報の外部スキャンツールへの送信を通信手段に要求する。尚、このように送信を要求された車両識別情報が、上記送信すべきデータとなる。

また、この要求後に、検出手段により他の電子制御ユニットによる車両識別情報の応答が検出された場合には、送信要求手段が、車両識別情報の送信の中止を通信手段に要求する。

かかる構成によれば、上記請求項２０記載の車両用電子制御装置の１つの電子制御ユニットとして構成することができ、その場合には、請求項２０記載の車両用電子制御装置と同様の作用効果を実現することができる。

また、請求項２３記載の電子制御ユニットについても、上記請求項２１の車両用電子制御装置の１つの電子制御ユニットとして構成することができ、その場合には、請求項２１記載の車両用電子制御装置と同様の作用効果を実現することができる。

尚、このような電子制御ユニットにおける検出手段及び送信要求手段をコンピュータシステムにて実現する機能は、例えば、コンピュータシステム側で起動するプログラムとして備えられる（請求項２４）。

そして、上記請求項１９又は請求項２４のようなプログラムの場合、例えば、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ハードディスク等の記録媒体に記録し、必要に応じてコンピュータシステムにロードして起動することにより用いることができる（請求項２５）。その他、ＲＯＭやバックアップＲＡＭを記録媒体として前記プログラムを記録しておき、このＲＯＭあるいはバックアップＲＡＭをコンピュータシステムに組み込んで使用してもよい。

以下、本発明の実施の形態を明確にするため、本発明の好適な実施例を図面と共に説明する。図１は第１実施例の車両用電子制御装置の概略構成を表すブロック図である。
同図に示すように、本第１実施例の車両用電子制御装置１０は、車両１００に搭載されており、複数の電子制御ユニット（以下「ＥＣＵ」という）として、エンジンを制御するエンジンＥＣＵ１，自動変速機を制御するトランスミッションＥＣＵ２，ブレーキ装置等を制御する走行制御ＥＣＵ３，パワーウィンドウの開閉やドアの施開錠等を制御するボデーＥＣＵ４等を備えている。各ＥＣＵは、所定の記憶・演算処理を実行するマイクロコンピュータ（以下、単に「マイコン」という）を中心に構成された独立の電子制御ユニットであり、その各々が通信部を内蔵し、データ通信用の通信ラインＬを介して互いに接続されている。各ＥＣＵのマイコンには、図示しないが、各種機器を制御するＣＰＵ，予め各種の数値やプログラムが書き込まれたＲＯＭ，演算過程の数値やフラグが所定の領域に書き込まれるＲＡＭ，アナログ入力信号をディジタル信号に変換するＡ／Ｄコンバータ，各種ディジタル信号が入力され、各種ディジタル信号が出力される入出力インターフェース（Ｉ／Ｏ），計時手段としてのタイマ，及びこれら各機器がそれぞれ接続されるバスラインから構成されている。また、各ＥＣＵには、ＶＩＮコード（車両識別情報）やダイアグ情報を記憶するための不揮発性メモリ（ＥＥＰＲＯＭ，バックアップＲＡＭ，フラッシュメモリ等）が設けられている。後述するフローチャートに示す処理は、上記ＲＯＭに予め書き込まれた制御プログラムに基づいて実行される。

具体的には、エンジンＥＣＵ１は、マイコン１ａを備え、通信部１ｂを介して所定の通信処理を実行できるように構成されている。このエンジンＥＣＵ１には、図示しないが、運転者によるアクセルペダルの踏込量を検出するアクセルペダル開度センサ、吸入空気の流量（吸気量）を検出するエアフローメータ、吸入空気の温度を検出する吸気温センサ、スロットルバルブの開度を検出するスロットル開度センサ、排気中の酸素濃度を酸素濃度センサ、冷却水温を検出する水温センサ、クランク軸の回転角度やその回転速度を検出するためのクランク角センサ、イグニションスイッチ、といったセンサ・スイッチ類が接続されると共に、エンジンの気筒毎に設けられたインジェクタ、点火用高電圧を発生するイグナイタ、燃料タンクから燃料を汲み上げインジェクタに供給する燃料ポンプ、エンジンの吸気管に設けられたスロットルバルブを開閉するためのスロットル駆動モータ、といったエンジン制御のための各種アクチュエータが接続されている。

トランスミッションＥＣＵ２は、マイコン２ａを備え、通信部２ｂを介して所定の通信処理を実行できるように構成されている。このトランスミッションＥＣＵ２には、トルクコンバータから変速機への入力軸の回転数を検出する回転数センサ、自動変速機の出力軸に連結された車両駆動軸の回転から車速を検出する車速センサ、自動変速機内の作動油の温度を検出する油温センサ、運転者が操作するシフトレバーの操作位置（シフト位置）を検出するシフトポジションスイッチ、といったセンサ・スイッチ類が接続されると共に、変速段を切り替えるためのシフトソレノイド、変速クラッチの係合力を操作するためのライン圧ソレノイド、トルクコンバータの入・出力軸を締結するロックアップクラッチの締結力を操作するためのロックアップ圧ソレノイド、といった変速制御のための各種アクチュエータ（ソレノイド）が接続されている。

走行制御ＥＣＵ３は、マイコン３ａを備え、通信部３ｂを介して所定の通信処理を実行できるように構成されている。この走行制御ＥＣＵ３は、急ブレーキの際の駆動輪のロックを防止するアンチロックブレーキユニット（ＡＢＳ）を含むブレーキ装置の制御を行うと共に、エンジンＥＣＵ１と協働して、レーザレーダにより先行車両との車間を測定することにより、当該先行車両との車間距離を一定にした走行を可能にする車間制御装置（ＡＣＣ）、カーブ走行時における車両の走行安定性を保持する車両安定化装置（ＶＳＣ）、及び駆動輪の加速スリップを防止するためのトラクションコントロール装置（ＴＲＣ）に対する制御をも行う。当該走行制御ＥＣＵ３には、ブレーキ装置のマスタシリンダの油圧を検出するマスタシリンダ圧センサ、車両の操舵角を検出するステアリングセンサ、車両のヨーレートを検出するヨーレートセンサ、といったセンサ・スイッチ類が接続されると共に、マスタシリンダの油圧を発生してブレーキ制御を行うためのブレーキアクチュエータ等が接続されている。

ボデーＥＣＵ４は、マイコン４ａを備え、通信部４ｂを介して所定の通信処理を実行できるように構成されている。このボデーＥＣＵ４は、パワーウィンドウの開閉やドアの施開錠を制御するものとして構成され、駆動モータの回転数センサ、パワーウィンドウスイッチ、ドアロックスイッチ等のセンサ・スイッチ類が接続されると共に、パワーウインドウモータ、ドアロックモータ等を動作させるための各種アクチュエータが接続されている。

尚、以下の説明においては、エンジンＥＣＵ１，トランスミッションＥＣＵ２，走行制御ＥＣＵ３，ボデーＥＣＵ４・・・の夫々を、単にＥＣＵ１，ＥＣＵ２，ＥＣＵ３，ＥＣＵ４・・・と表現する。

通信ラインＬは、車両１００側のコネクタ１１を介してテスタ５０と接続可能に構成されている。テスタ５０は、ＯＢＤII対応の外部診断装置であり、図示しない通信部，マイコン，ＩＣカード等の記憶装置，ＬＣＤ等の表示装置，キーボード等の入力装置，及びコネクタ１１に対して着脱自在に接続するためのコネクタ５１を備える。そして、各ＥＣＵとの間で例えばＫＷＰ２０００の通信プロトコルにしたがった通信を行う。例えば車両が修理工場等に持ち込まれたときにコネクタ５１が通信ラインＬのコネクタ１１に装着され、作業者による入力装置から入力により、各ＥＣＵに対してＶＩＮコードやダイアグ情報を要求し、各ＥＣＵからの応答を受信すると、取得した情報を表示装置に表示する。

次に、本実施例における外部スキャンツールと車両用電子制御装置との間の車両識別情報の通信方法について、図２〜図４に基づいて説明する。図２は当該通信方法の概要を表す説明図であり、図３は当該通信に用いられる通信プロトコルの説明図であり、図４は当該通信処理の一例を表すタイミングチャートである。

まず、本実施例のテスタ５０と車両用電子制御装置１０（つまり各ＥＣＵ１，２，３，４・・・）との通信は、図３に示すＫＷＰ（Keyword Protocol）２０００にしたがって行われる。ここで用いられる通信フォーマット（ＫＷＰメッセージフォーマット）は、同図（ａ）に示すように、ヘッダーにＦｍｔ（フォーマット），Ｔｇｔ（送信先アドレス），Ｓｒｃ（送信元アドレス）が記述され、続いてＤａｔａ（ＶＩＮコード）が記述され、最後にｃｓ（チェックサム）が記述されている。そして、各ＥＣＵは、通常処理においてはＴｇｔが自分宛か否かを確認して、自分宛であればデータを受信することになるが、後述するモニタ処理についてはＴｇｔにかかわらず行う。

そして、同図（ｂ）に示すように、例えばテスタ５０の個別アドレスとしてＦ１が設定され、ＥＣＵ１のアドレスとして個別アドレス１１と共有アドレス３３が、ＥＣＵ２のアドレスとして個別アドレス２１と共有アドレス３３が、夫々設定されている。ここで、共有アドレス３３は、全てのＥＣＵにアクセスする場合のＥＣＵ群のアドレスを表している。このため、同図（ｃ）に示すように、テスタ５０からＥＣＵ１に対してデータが送信されるときは、Ｔｇｔ＝１１，Ｓｒｃ＝Ｆ１と設定されることになり(例１)、ＥＣＵ２からテスタ５０に対してデータが送信されるときは、Ｔｇｔ＝Ｆ１，Ｓｒｃ＝２１と設定され（例２）、テスタ５０からＥＣＵ１及びＥＣＵ２に対してデータが送信されるときは、Ｔｇｔ＝３３，Ｓｒｃ＝Ｆ１と設定されることになる(例３)。尚、ＥＣＵ３，ＥＣＵ４・・・についても同様に個別アドレス及び共有アドレスが設定されるが、その説明については省略する。

図２を参照して、テスタ５０のコネクタ５１がコネクタ１１に装着され、作業者による入力装置から入力により、全ＥＣＵに対してＶＩＮコードの送信要求がなされ、各ＥＣＵにてこれを受信すると、各ＥＣＵ１，２，３，４・・・は、夫々自己のタイマを起動して各々の応答開始時間の計時を開始する。本実施例では、テスタ５０に対して一つのＥＣＵがＶＩＮコードを応答するようにするため、各ＥＣＵについてＶＩＮコードを応答するための優先順位が、ＥＣＵ１，ＥＣＵ２，ＥＣＵ３，ＥＣＵ４，・・・の順に定められ、その優先順位がＶＩＮコードの応答開始時間という形で設定されている。このため、ＥＣＵ１（応答開始時間：Ｔ１），ＥＣＵ２（応答開始時間：Ｔ２），ＥＣＵ３（応答開始時間：Ｔ３），ＥＣＵ４（応答開始時間：Ｔ４），・・・の順に応答開始時間が早くなっており、つまり、Ｔ１＜Ｔ２＜Ｔ３＜Ｔ４・・・のようになっている。そして、優先順位の高い（つまり応答開始時間の早い）ＥＣＵが、故障や断線によりＶＩＮコードを送信できないような場合には、次に優先順位の高いＥＣＵが順次代わってＶＩＮコードを送信するように構成されている。

より具体的には、図４に示すように、例えばＥＣＵ１及びＥＣＵＮ（Ｎ＝２，３，４・・・）がテスタ５０からのＶＩＮコード送信要求を受信すると、各ＥＣＵは、ＶＩＮコード要求フラグＶＩＮＲｅｑをＯＮにし、自己のタイマを起動してカウントアップを開始する。このカウントアップは、マイコンの内部クロックに基づいて後述する１ｍｓ処理のスロットで（つまり１ｍｓ毎に）行われる。

そして、例えばＥＣＵ１は、自己のタイマのカウント値Ｔｒｅｓが応答開始時間Ｔ１になった時点でＶＩＮコードの応答を開始すると共に、タイマのカウント値をクリアする。このとき、他のＥＣＵＮは、自己のタイマのアップカウントを継続すると共に、通信ラインＬを介してＥＣＵ１による応答をモニタする。そして、ＥＣＵ１の応答が完了した時点で、タイマのアップカウントを中止してそのカウント値をクリアすると共に、通信ラインＬのモニタを中止する。

尚、この場合、各ＥＣＵの応答開始時間Ｔｎは、ＶＩＮコードの応答に要する時間、つまり、先行してＶＩＮコードを送信するＥＣＵが、図３（ａ）に示す送信データのｃｓまでを送信し終えるまでの時間以上の時間間隔で順次設定されている。これにより、例えばノイズの影響によりテスタ５０に対して正常なデータが送信できなかったような場合でも、後続するＥＣＵが、それを確認した上で正常なＶＩＮコードを送信することができる。

また、本車両用電子制御装置１０のＥＣＵのうち、最も優先順位の低い（つまり最も応答開始時間の遅い）ＥＣＵの応答開始時間が、法規（ＯＢＤII）を遵守できる所定時間以下に設定されている。したがって、仮に、このＥＣＵ以外の他のすべてのＥＣＵがデータ送信不能状態となっても、この最も優先順位の低いＥＣＵによってＶＩＮコード応答がなされることにより、法規を遵守することができる。

図２に戻り、本実施例に示す同図の例では、ＥＣＵ１がテスタ５０に対してＶＩＮコードを応答したため、他のＥＣＵ２，３，４・・・は、ＶＩＮコードの応答を行わない様子が示されている。

尚、ここではＥＣＵ１がＶＩＮコードを正常に応答した例を示したが、例えばＥＣＵ１がＶＩＮコードを正常に応答できない場合には、次に優先順位の高いＥＣＵ２が自己の応答開始時間Ｔ２になった時点でＶＩＮコードの応答を開始し、さらにＥＣＵ２もＶＩＮコードを正常に応答できない場合には、後続する優先順位の高いＥＣＵＮが自己の応答開始時間Ｔｎになった時点でＶＩＮコードの応答を開始する・・・といったような処理が行われる。このとき、その他のＥＣＵは上述と同様の処理を行う。

次に、本実施例において各ＥＣＵのマイコンが実行する通信処理について、図５〜図８のフローチャートに基づいて説明する。
まず図５に示すように、テスタ５０からのＶＩＮコード送信要求を受信すると（Ｓ１１０）、当該要求があったことを示すＶＩＮコード要求フラグＶＩＮＲｅｑをＯＮにし、応答開始時間の計時を開始するためにタイマのカウント値Ｔｒｅｓを一旦ゼロにクリアする（Ｓ１２０）。

そして、図６に示す１ｍｓ毎の処理（１ｍｓ処理）を実行する。すなわち、ＶＩＮコード要求フラグＶＩＮＲｅｑがＯＮであると判断すると（Ｓ２１０：ＹＥＳ）、カウント値Ｔｒｅｓを１インクリメントする（Ｓ２２０）。

そして、カウント値Ｔｒｅｓが自己の応答開始時間Ｔｎ以上になったか否かを判断し（Ｓ２３０）、自己の応答開始時間Ｔｎ以上になったと判断されると（Ｓ２３０：ＹＥＳ）、自己の不揮発性メモリからＶＩＮコードを読み出して応答し（Ｓ２４０）、後述する終了処理に移行する（Ｓ２５０）。一方、Ｓ２１０又はＳ２３０にて否定判断された場合には、一旦１ｍｓ処理を抜ける。

また、上記１ｍｓ処理に並行して図７に示すモニタ処理を実行する。すなわち、各ＥＣＵは、テスタ５０からのＶＩＮコード送信要求を受信してから通信ラインＬをモニタしており、まず他のＥＣＵが応答したデータの送信先アドレスＴｇｔを検出する。そして、その送信先アドレスＴｇｔがテスタ５０のアドレスＦ１である場合には（Ｓ３１０：ＹＥＳ）、続いてデータの内容Ｄａｔａを検出し、それがＶＩＮコードであるか否かを判定する。このとき、データの内容ＤａｔａがＶＩＮコードである場合には（Ｓ３２０：ＹＥＳ）、テスタ５０に対するＶＩＮコードの送信が他のＥＣＵによってなされたと判断し、後述する終了処理に移行する（Ｓ３３０）。一方、Ｓ３１０又はＳ３２０にて否定判断された場合には、一旦本処理を抜ける。

そして、図８に示すように、各ＥＣＵは、終了処理においてＶＩＮコード要求フラグＶＩＮＲｅｑをＯＦＦにすると共に、タイマのカウント値Ｔｒｅｓをゼロにしてクリアし、一連の処理を終了する。

以上のように、本実施例の車両用電子制御装置１０によれば、テスタ５０に対してＶＩＮコードを送信するＥＣＵの優先順位が予め定められており、優先順位の高い（つまり応答開始時間の早い）ＥＣＵが、故障や断線によりＶＩＮコードを正常に送信できないような場合には、次に優先順位の高いＥＣＵが順次代わってＶＩＮコードを送信する。このため、テスタ５０からのＶＩＮコード要求に対して確実に応答することができる。

また、各ＥＣＵは、テスタ５０からのＶＩＮコード要求を受信すると、通信ラインＬをモニタし、他のＥＣＵによりＶＩＮコードの応答が完了すると、以降のＶＩＮコード応答のための処理を中止し、自身はＶＩＮコードの応答を行わない。このため、複数のＥＣＵからＶＩＮコードが送信されて通信ラインＬ上で衝突するといった問題もなく、通信効率の悪化を効果的に抑制又は防止することができる。また、上述したＯＢＤIIの改正における「１車両で１つのＶＩＮコードのみを応答すること」を遵守することができる。

さらに、各ＥＣＵは、他のＥＣＵによりＶＩＮコードの応答が完了すると、以降のＶＩＮコード応答のための処理を中止するため、その処理負荷の増大をも効果的に抑制又は防止することができる。その効果は、通信ラインＬに接続されるＥＣＵが増加するほど大きくなる。

尚、本実施例において、各ＥＣＵにおける不揮発性メモリが記憶手段に該当し、マイコンが検出手段、計時手段及び請求項１及び請求項１０の通信手段に該当する。
ところで、上記第１実施例では、各ＥＣＵの応答開始時間Ｔｎを固定値としているが、これに限ったものではなく、状況に応じて各ＥＣＵの応答開始時間Ｔｎを変更するようにしてもよい。

すなわち、例えば、各ＥＣＵが、テスタ５０からＶＩＮコードの送信要求がなされる前の通常動作中（車両１００の走行中等）において、自分より優先順位の高い（つまり応答開始時間の早い）ＥＣＵの中に、データ送信が不能な状態になっているものが存在するか否かを判断する。そして、各ＥＣＵが、自分より優先順位の高いＥＣＵの中に、データ送信不能状態になっているものが存在すると判断した場合には、テスタ５０からＶＩＮコードの送信要求がなされた場合の自己の応答開始時間を短縮するようにする。

ここで、上記第１実施例のように、ＥＣＵ１，ＥＣＵ２，ＥＣＵ３，・・・の各応答開始時間がＴ１＜Ｔ２＜Ｔ３・・・の関係にある場合の具体例について、図９のタイムチャートを用いて説明する。

図９（ａ）に示すように、ＥＣＵ１，ＥＣＵ２，ＥＣＵ３，・・・がそれぞれデータ送信可能な状態（つまり正常状態）では、テスタ５０からＶＩＮコードの送信要求がなされた場合のＥＣＵ２，ＥＣＵ３，・・・の各応答開始時間Ｔ２，Ｔ３，・・・は、上記第１実施例と同様、自分より優先順位の高いＥＣＵがＶＩＮコードの応答に要する時間以上の長さに設定される。

一方、図９（ｂ）は、ＥＣＵ１がデータ送信不能状態の場合を示している。この場合、ＥＣＵ１より優先順位の低いＥＣＵ２，ＥＣＵ３，・・・は、通信ラインＬをモニタし、ＥＣＵ１によるデータ送信がされていないことに基づきＥＣＵ１がデータ送信不能状態であると判定すると、テスタ５０からＶＩＮコードの送信要求がなされた場合の自己の応答開始時間Ｔ２，Ｔ３，・・・を短縮する。つまり、ＥＣＵ１がデータ送信不能状態である場合には、これより優先順位の低い他のＥＣＵＮは、ＥＣＵ１がＶＩＮコードの応答に要する時間を加味する必要がなくなるため、自己の応答開始時間Ｔｎをその分短縮するのである。

ここで、図９に示す処理内容を実現するために各ＥＣＵのマイコンが実行する通信処理について、図１０及び図１１のフローチャートに基づいて説明する。具体的には、上記第１実施例の通信処理（図５〜図８）のうち、図６の処理に代えて図１０の処理を行い、さらに、図５の処理に代えて図１１の処理を行う。

まず、図１０の処理内容について説明する。尚、図１０におけるＳ５９０〜Ｓ６３０の処理は、図６におけるＳ２１０〜Ｓ２５０の処理と同一内容であるため、詳細な説明は省略する。

図１０に示す１ｍｓ毎の処理（１ｍｓ処理）では、まず変数ｊの値を初期値である１に設定する（Ｓ５１０）。
続いて、変数ｊの値が自己の優先順位を表す値ｎ以上であるか否かを判断する（Ｓ５２０）。ここで、自己の優先順位とは、最も優先順位の高い（つまり応答開始時間の短い）ＥＣＵから順に付された番号であり、各ＥＣＵには、自己の優先順位と他のＥＣＵの優先順位とが予め記憶されている。上述したように、ＥＣＵ１，ＥＣＵ２，ＥＣＵ３，ＥＣＵ４，・・・は、各応答開始時間がＴ１＜Ｔ２＜Ｔ３＜Ｔ４・・・の関係にあるため、各優先順位ｎは、１，２，３，４，・・・である。

そして、変数ｊの値が自己の優先順位を表す値ｎ以上でない（つまり、変数ｊの表す優先順位が、自己の優先順位ｎよりも高い）と判断した場合には（Ｓ５２０：ＮＯ）、優先順位ｊのＥＣＵからデータが送信されているか否かを判断する（Ｓ５３０）。具体的には、送信元アドレスＳｒｃ（図３（ａ））が優先順位ｊのＥＣＵのアドレスであるデータを通信ラインＬで検出した場合に、優先順位ｊのＥＣＵからデータが送信されていると判断する。

そして、優先順位ｊのＥＣＵからデータが送信されていると判断した場合には（Ｓ５３０：ＹＥＳ）、この優先順位ｊのＥＣＵがデータを送信していない時間を計時するためのカウント値Ｅｊをゼロにクリアする（Ｓ５４０）。

一方、優先順位ｊのＥＣＵからデータが送信されていないと判断した場合には（Ｓ５３０：ＮＯ）、カウント値Ｅｊを１インクリメントする（Ｓ５５０）。そして、このカウント値Ｅｊが、優先順位ｊのＥＣＵについて予め決められている異常判定時間以上になったか否かを判断し（Ｓ５６０）、異常判定時間以上になったと判断した場合には（Ｓ５６０：ＹＥＳ）、優先順位ｊのＥＣＵがデータ送信不能状態であると判定する（Ｓ５７０）。すなわち、優先順位ｊのＥＣＵによって定期的に送信されるはずのデータが検出されなくなった場合に、そのＥＣＵはデータ送信不能状態であると判定するのである。このため、各ＥＣＵについての異常判定時間は、そのＥＣＵが正常状態においてデータを送信する頻度等に応じた長さに設定するのが好ましい。仮に、ＥＣＵ１が８ｍｓ毎にデータ（エンジン回転数の情報等）を送信する構成であれば、異常判定時間を例えば８０ｍｓに設定する。尚、あるＥＣＵについて一旦データ送信不能状態であると判定した場合にも、その後にそのＥＣＵからデータの送信がされた場合には、データ送信不能状態でない（つまり、正常な状態に復帰した）と判定するようにしてもよい。

そして、Ｓ５４０若しくはＳ５７０の処理の終了後、又はＳ５６０でカウント値Ｅｊが異常判定時間以上になっていないと判断した後は（Ｓ５６０：ＮＯ）、変数ｊを１インクリメントし（Ｓ５８０）、Ｓ５２０へ戻る。

一方、Ｓ５２０で、変数ｊの値が自己の優先順位を表す値ｎ以上である（つまり、変数ｊの表す優先順位が、自己の優先順位ｎ以下である）と判断した場合には（Ｓ５２０：ＹＥＳ）、Ｓ５９０〜Ｓ６３０の処理（つまり、上記第１実施例のＳ２１０〜Ｓ２５０の処理）を行った後、本１ｍｓ処理を終了する。

以上のように、本１ｍｓ処理では、自己の優先順位ｎよりも高い優先順位のＥＣＵの中に、データ送信不能状態となっているＥＣＵが存在するか否かを判断するようになっている。

次に、図１１の処理内容について説明する。尚、図１１におけるＳ７１０，Ｓ７２０の処理は、図５におけるＳ１１０，Ｓ１２０の処理と同一内容であるため、詳細な説明は省略する。

図１１に示すように、テスタ５０からのＶＩＮコード送信要求を受信すると、Ｓ７１０及びＳ７２０の処理（つまり、上記第１実施例のＳ１１０，Ｓ１２０の処理）を行った後、自己の応答開始時間を表す変数Ｔｎに、各ＥＣＵに対して予め設定されている応答開始時間の初期値Ｔｎ０（ｎ＝１，２，３，・・・）を代入する（Ｓ７３０）。尚、この初期値Ｔｎ０は、例えば上記第１実施例の応答開始時間Ｔｎと同じ値に設定される。

続いて、変数ｋの値を初期値である１に設定する（Ｓ７４０）。
続いて、変数ｋの値が自己の優先順位を表す値ｎ以上であるか否かを判断する（Ｓ７５０）。

そして、変数ｋの値が自己の優先順位を表す値ｎ以上でない（つまり、変数ｋの表す優先順位が、自己の優先順位ｎよりも高い）と判断した場合には（Ｓ７５０：ＮＯ）、上述したＳ５７０の処理において、優先順位ｋのＥＣＵがデータ送信不能状態と判定されているか否かを判断する（Ｓ７６０）。そして、データ送信不能状態と判定されていると判断した場合には（Ｓ７６０：ＹＥＳ）、自己の応答開始時間Ｔｎから固定値αを差し引く（Ｓ７７０）。つまり、自己の応答開始時間Ｔｎを固定値αだけ短縮するようになっている。尚、固定値αは、例えば、ＥＣＵがＶＩＮコードの応答に要する時間に設定される。

一方、Ｓ７６０で、優先順位ｋのＥＣＵがデータ送信不能状態と判定されていないと判断した場合（Ｓ７６０：ＮＯ）、又はＳ７７０の処理の終了後は、変数ｋを１インクリメントし（Ｓ７８０）、Ｓ７５０へ戻る。

一方また、Ｓ７５０で、変数ｋの値が自己の優先順位を表す値ｎ以上である（つまり、変数ｋの表す優先順位が、自己の優先順位ｎ以下である）と判断した場合には（Ｓ７５０：ＹＥＳ）、図１１の処理を終了する。

以上のように、図１１の処理では、自己の優先順位ｎよりも高い優先順位のＥＣＵのうち、データ送信不能状態となっているＥＣＵの数に応じて自己の応答開始時間Ｔｎを短縮するようになっている。そして、この図１１の処理で決定した自己の応答開始時間Ｔｎが、前述した図１０の１ｍｓ処理におけるＳ６１０で用いられることとなる。

このように、各ＥＣＵが、自分より優先順位の高いＥＣＵの中にデータ送信不能状態のものが存在すると判定した場合には、自己の応答開始時間を短縮するようにすることで、テスタ５０によりＶＩＮコードの送信要求がなされてからＶＩＮコードの応答がされるまでの時間（応答待ち時間）を短くすることができる。また、不要な待ち時間を減らすことにより通信ラインＬの利用効率を向上させることができる。さらに、ＥＣＵがデータ送信不能状態であるか否かを、そのＥＣＵがデータを送信していない時間が予め決められている異常判定時間以上になったか否かにより判断するようにしているため、データ送信不能状態であるか否かの判断を容易に行うことができる。加えて、データ送信不能状態のＥＣＵの数が多いほど応答開始時間を短くするようにしているため、応答待ち時間を効率よく短くすることができると共に、通信ラインＬの利用効率を効果的に向上させることができる。

尚、図１０におけるＳ５１０〜Ｓ５８０の処理と、図１１におけるＳ７３０〜Ｓ７８０の処理とが、時間短縮手段に該当する。
また、図１１の処理では、各ＥＣＵが、自己の応答開始時間Ｔｎから固定値αを差し引くようにしているが、これに限ったものではない。例えば、各ＥＣＵが、予め複数種類の応答開始時間を記憶しており、データ送信不能状態となったＥＣＵの数や種類に応じて、上記複数種類の応答開始時間の中から最適な応答開始時間を選択するようにしてもよい。

ところで、上記第１実施例では、各ＥＣＵが、他のＥＣＵによりＶＩＮコードの応答が開始された後も自己のタイマのカウントアップを継続するようになっていることから、各ＥＣＵの応答開始時間Ｔｎを、ＥＣＵがＶＩＮコードの応答に要する時間以上の時間間隔で順次設定しているが、これに限ったものではない。

すなわち、図１２に示す例では、上記第１実施例（図４）と同様、ＥＣＵ１及びＥＣＵＮ（Ｎ＝２，３，４・・・）がテスタ５０からのＶＩＮコード送信要求を受信すると、各ＥＣＵは、ＶＩＮコード要求フラグＶＩＮＲｅｑをＯＮにし、自己のタイマを起動してカウントアップを開始する。そして、例えばＥＣＵ１は、自己のタイマのカウント値Ｔｒｅｓが応答開始時間Ｔ１になった時点でＶＩＮコードの応答を開始すると共に、タイマのカウント値をクリアする。

ただし、図１２に示す例では、他のＥＣＵＮは、通信ラインＬを介して他のＥＣＵによる応答をモニタしており、ＥＣＵ１により応答が開始されたことを検出した時点で自己のタイマのカウント値Ｔｒｅｓを初期化（クリア）する。そして、ＥＣＵ１が、ノイズ等の影響によりテスタ５０に対して正常なデータを送信できなかった場合には、他のＥＣＵＮは、ＥＣＵ１による応答が終了されたことを検出した時点から自己のタイマを起動してカウントアップを開始する。

尚、各ＥＣＵは、他のＥＣＵによりＶＩＮコードが正常に送信されたか否かを、送信データにおけるＶＩＮコードの内容やｃｓの値に基づき判断することができる。また、図１２では、ＥＣＵ１がＶＩＮコードの応答を開始したものの正常なデータを送信できなかった例を示したが、例えばＥＣＵ１がデータ送信不能状態であれば、応答開始時間Ｔ１になってもＥＣＵ１によるＶＩＮコードの応答が開始されないため、他のＥＣＵＮは、自己のタイマのカウント値Ｔｒｅｓを初期化することなく、カウントアップを継続することとなる。

ここで、図１２に示す処理内容を実現するために各ＥＣＵのマイコンが実行する通信処理について、図１３のフローチャートに基づいて説明する。具体的には、上記第１実施例の通信処理（図５〜図８）のうち、図６の処理に代えて図１３の処理を行う。尚、図１３におけるＳ８１０，Ｓ８４０〜Ｓ８７０は、図６におけるＳ２１０〜Ｓ２５０の処理と同一内容であるため、詳細な説明は省略する。

図１３に示す１ｍｓ毎の処理（１ｍｓ処理）では、ＶＩＮコード要求フラグＶＩＮＲｅｑがＯＮであると判断すると（Ｓ８１０：ＹＥＳ）、他のＥＣＵが応答中であるか否かを判断する（Ｓ８２０）。尚、各ＥＣＵは、テスタ５０からのＶＩＮコード送信要求を受信すると、これに対する応答を行うように構成されている。このため、各ＥＣＵは、通信ラインＬから何らかの送信データを検出することで、他のＥＣＵによりＶＩＮコード応答が開始されたことを判断することができる。

そして、他のＥＣＵが応答中でないと判断した場合には（Ｓ８２０：ＮＯ）、Ｓ８４０〜Ｓ８７０の処理（つまり、上記第１実施例のＳ２２０〜Ｓ２５０の処理）を行った後、本１ｍｓ処理を終了する。

一方、他のＥＣＵが応答中であると判断した場合には（Ｓ８２０：ＹＥＳ）、自己のタイマのカウント値Ｔｒｅｓをゼロにクリアした後（Ｓ８３０）、本１ｍｓ処理を終了する。

以上のように、各ＥＣＵが、他のＥＣＵによりＶＩＮコードの応答が開始されたことを検出した場合には自己のタイマのカウント値Ｔｒｅｓを初期化することで、各ＥＣＵの応答開始時間Ｔｎを設定する際の制約（すなわち、ＶＩＮコードの応答に要する時間以上の時間間隔で設定するという制約）をなくすことができる。この結果、各ＥＣＵの応答開始時間Ｔｎを設定する際の自由度を高くすることができる。また、各ＥＣＵによるＶＩＮコード応答は、テスタ５０からのＶＩＮコード送信要求や、他のＥＣＵによるＶＩＮコード応答の終了後、少なくともＴ１以上の間隔をおいて行われることとなる。このため、通信ラインＬにおいて、あるデータの通信終了後、次のデータの通信開始までに一定時間を設けなければならないといった通信規定がある場合にも対応することができる。加えて、各ＥＣＵが、自分より優先順位の高い（つまり応答開始時間の短い）ＥＣＵがデータ送信不能状態の場合には、このＥＣＵの応答開始時間になっても自己のタイマのカウント値Ｔｒｅｓを初期化することなくカウントアップを継続することとなるため、テスタ５０によりＶＩＮコードの送信要求がなされてからＶＩＮコードの応答がされるまでの時間（応答待ち時間）を短くすることができる。また、不要な待ち時間を減らすことにより通信ラインＬの利用効率を向上させることができる。

次に、第２実施例の車両用電子制御装置について説明する。図１４は本第２実施例の車両用電子制御装置の概略構成を表すブロック図である。
同図に示すように、本第２実施例の車両用電子制御装置２０は、基本的な構成は上記第１実施例の車両用電子制御装置１０（図１）と同一であるが、各ＥＣＵが、車載ネットワークで一般的に利用されているプロトコルであるＣＡＮ（Controller Area Network）に則ってデータ通信を行うようになっており、通信部２１ｂ，２２ｂ，２３ｂ，２４ｂ，・・・としてＣＡＮドライバ／レシーバを使用している点が異なる。また、これに伴い、各ＥＣＵのマイコンが実行する通信処理の内容が異なる。尚、第１実施例において図１に示した構成と同じ構成要素については、同一の符号を付しているため、詳細な説明は省略する。

本第２実施例の車両用電子制御装置２０は、上記第１実施例の車両用電子制御装置１０と同様、車両１００に搭載されており、エンジンを制御するエンジンＥＣＵ２１，自動変速機を制御するトランスミッションＥＣＵ２２，ブレーキ装置等を制御する走行制御ＥＣＵ２３，パワーウィンドウの開閉やドアの施開錠等を制御するボデーＥＣＵ２４等を備えている。尚、各ＥＣＵの構成は、通信部２１ｂ，２２ｂ，２３ｂ，２４ｂ，・・・を除き、上記第１実施例で説明した各ＥＣＵの構成と同様であるため、詳細な説明は省略する。また、以下の説明においては、エンジンＥＣＵ２１，トランスミッションＥＣＵ２２，走行制御ＥＣＵ２３，ボデーＥＣＵ２４・・・の夫々を、単にＥＣＵ２１，ＥＣＵ２２，ＥＣＵ２３，ＥＣＵ２４・・・と表現する。

各ＥＣＵの通信部２１ｂ，２２ｂ，２３ｂ，２４ｂ，・・・は、ＣＡＮプロトコルに則って通信を行う。すなわち、各ＥＣＵの通信部２１ｂ，２２ｂ，２３ｂ，２４ｂ，・・・は、送信すべきフレームのヘッダー部分に、そのＥＣＵに固有の識別コード（ＣＡＮＩＤ）を付与する。そして、送信すべきフレームを有する通信部２１ｂ，２２ｂ，２３ｂ，２４ｂ，・・・は、通信ラインＬが使用中でなければ、直ちにフレームの送信を開始し、通信ラインＬが使用中であれば、通信ラインＬが空き状態になってからフレームの送信を開始する。このため、フレームの送信を希望するＥＣＵが複数ある場合には、通信ラインＬが空き状態になった時点でそれらが同時にフレームの送信を開始することとなり、通信ラインＬ上でフレームの衝突が発生する。

このようなフレームの衝突が発生した場合、ＣＡＮプロトコルでは、上記ＣＡＮＩＤを用いて、どのフレームを優先的に処理するかを決定する調停制御を、ビット単位非破壊アービトレーションと呼ばれる手法により実行するようになっている。

すなわち、通信ラインＬ上の信号レベルには、ドミナント（優性）とリセッシブ（劣性）とがあり、複数のＥＣＵから、ドミナントとリセッシブとが同時に送信された場合に、通信ラインＬの信号レベルはドミナントとなる。一般に、ドミナントの論理値を０、リセッシブの論理値を１として考える。

例えば、ＣＡＮＩＤが４ビット（実際のＣＡＮプロトコルでは１１ビット）で構成され、３つのＥＣＵが、同時にフレームの送信を開始し、第１のＥＣＵからのフレームに付与されたＣＡＮＩＤが０００１Ｂ、第２のＥＣＵからのフレームに付与されたＣＡＮＩＤが００１０Ｂ、第３のＥＣＵからのフレームに付与されたＣＡＮＩＤが０１００Ｂである場合を考える。この場合、ＣＡＮＩＤの上位から２ビット目を送信したときに、第３のＥＣＵの出力がリセッシブ（１）であるにもかかわらず通信ラインＬの信号レベルがドミナント（０）となるため、この時点で第３のＥＣＵは調停負けしたものとして、フレームの送信を中止し受信状態に遷移する。続くＣＡＮＩＤの上位から３ビット目を送信したときにも、同様に、第２のＥＣＵの出力がリセッシブであるにもかかわらず通信ラインＬの信号レベルがドミナントとなるため、この時点で第２のＥＣＵは調停負けしたものとして、フレームの送信を中止し受信状態に遷移する。その結果、第１のＥＣＵが、調停に勝ち残り、最後までフレームを送信することとなる。

つまり、ＣＡＮプロトコルを用いた通信システムでは、同時に複数のフレームが通信ラインＬ上に送信された場合、ＣＡＮＩＤの論理値が最も小さいフレームを送信したＥＣＵが送信権を得るのである。本第２実施例では、ＥＣＵ２１，ＥＣＵ２２，ＥＣＵ２３，ＥＣＵ２４，・・・の順にＣＡＮＩＤの論理値が大きくなるように設定されている。つまり、調停の際の優先度が、ＥＣＵ２１，ＥＣＵ２２，ＥＣＵ２３，ＥＣＵ２４，・・・の順に定められている。

次に、本第２実施例における外部スキャンツールと車両用電子制御装置との間の車両識別情報の通信処理について説明する。図１５は当該通信処理の一例を表すタイムチャートである。

テスタ５０のコネクタ５１がコネクタ１１に装着され、作業者による入力装置からの入力により、全ＥＣＵに対してＶＩＮコードの送信要求がなされると、各ＥＣＵ２１，ＥＣＵ２２，ＥＣＵ２３，ＥＣＵ２４・・・は、このＶＩＮコード送信要求のフレームを通信ラインＬを介して受信するための受信処理を行う。続いて、各ＥＣＵは、それぞれの処理タイミングでＶＩＮ応答準備処理を行う。ここで、ＶＩＮ応答準備処理とは、自己の不揮発性メモリからＶＩＮコードを読み出し、このＶＩＮコードを送信するためのフレームを生成する処理である。尚、図１５において、ＶＩＮ応答準備処理に要する時間が各ＥＣＵで異なっているのは、各ＥＣＵの性能（例えば駆動クロック）の違いや、各ＥＣＵで使用されるプログラムの違い等によるものである。

各ＥＣＵは、ＶＩＮ応答準備処理を終了すると、ＶＩＮコード応答の開始を自己の通信部に要求する。これにより、通信部は、通信ラインＬが空き状態になった時点でＶＩＮコード応答を開始する。図１５の例では、ＥＣＵ２２とＥＣＵ２３とが同時にＶＩＮコード応答を開始し、上述したＣＡＮＩＤに基づく調停が行われてＥＣＵ２３の送信が中断された様子（つまり、アービトレーション負けにより送信が中断された様子）が示されている。この場合、ＥＣＵ２３の通信部は、通信ラインＬが空き状態になった時点で再びＶＩＮコード応答を開始する。

そして、図１５の例では、ＥＣＵ２２がテスタ５０に対してＶＩＮコードを応答した様子が示されている。この場合、他のＥＣＵ２１，ＥＣＵ２３，ＥＣＵ２４，・・・は、このＶＩＮコード応答のフレームを通信ラインＬを介して受信するための受信処理を行い、ＶＩＮコードが正常に送信されたことを確認した時点で、ＶＩＮコードの送信中止を自己の通信部に要求する。一方、ＥＣＵ２２は、ＶＩＮコード応答の終了後、送信完了処理を行う。

尚、ここではＥＣＵ２２によりＶＩＮコードが正常に送信された例を示したが、例えばＥＣＵ２２によりＶＩＮコードが正常に送信されなかった場合には、別のＥＣＵがＶＩＮコードの応答を開始する。図１５に示す例では、ＣＡＮＩＤに基づく調停によりＥＣＵ２１がＶＩＮコードの応答を開始することとなる。そして、ＥＣＵ２１によってもＶＩＮコードが正常に送信されなかった場合には、さらに別のＥＣＵがＶＩＮコードの応答を開始する・・・といったような処理が行われる。このとき、その他のＥＣＵは上述と同様の処理を行う。

次に、本第２実施例において各ＥＣＵのマイコンが実行する通信処理について、図１６〜図１８のフローチャートに基づいて説明する。
まず、図１６の受信処理について説明する。本受信処理は、通信ラインＬから何らかのデータ（フレーム）が検出されることにより開始される。

この受信処理が開始されると、まず、検出されたデータがテスタ５０からのＶＩＮコード送信要求であるか否かを判断する（Ｓ９１０）。
そして、ＶＩＮコード送信要求であると判断した場合には（Ｓ９１０：ＹＥＳ）、他のＥＣＵによりＶＩＮコード応答が正常になされたことを示すＶＩＮ応答チェックフラグを、初期化のためにクリア（ＯＦＦ）し（Ｓ９２０）、さらに、テスタ５０からＶＩＮコード送信要求を受信したことを示すＶＩＮ要求処理フラグをＯＮした後（Ｓ９３０）、本受信処理を終了する。

一方、Ｓ９１０で、検出されたデータがＶＩＮコード送信要求でないと判断した場合には（Ｓ９１０：ＮＯ）、他のＥＣＵによるＶＩＮコード応答であるか否かを判断する（Ｓ９４０）。具体的には、他のＥＣＵにより正常に送信が完了されたＶＩＮコード応答であるか否かを判断するようになっている。

そして、他のＥＣＵによるＶＩＮコード応答であると判断した場合には（Ｓ９４０：ＹＥＳ）、ＶＩＮ応答チェックフラグをＯＮし（Ｓ９５０）、ＶＩＮ要求処理フラグをクリアする（Ｓ９６０）。尚、Ｓ９６０でＶＩＮ要求処理フラグをクリアするのは、ＶＩＮコード応答を重複して行わないようにするためである。

続いて、ＶＩＮ応答開始フラグがＯＮ／ＯＦＦの何れであるかを判断する（Ｓ９７０）。ここで、ＶＩＮ応答開始フラグとは、後述するが、ＶＩＮコード応答の開始を自己の通信部に要求していることを示すフラグである。

そして、ＶＩＮ応答開始フラグがＯＦＦである（つまり、ＶＩＮコード応答の開始を通信部に要求していない）と判断した場合には（Ｓ９７０：ＯＦＦ）、そのまま本受信処理を終了する。

一方、ＶＩＮ応答開始フラグがＯＮである（つまり、ＶＩＮコード応答の開始を通信部に要求している）と判断した場合には（Ｓ９７０：ＯＮ）、ＶＩＮコード応答の中止を自己の通信部に要求するためのＶＩＮ応答中止処理を行い（Ｓ９８０）、ＶＩＮ応答開始フラグをクリアした後（Ｓ９９０）、本受信処理を終了する。

一方また、Ｓ９４０で、他のＥＣＵによるＶＩＮコード応答でないと判断した場合には（Ｓ９４０：ＮＯ）、検出されたデータ（例えば、エンジン回転数のデータ）の内容に応じた受信処理を行った後（Ｓ１０００）、本受信処理を終了する。

次に、図１７のベース処理について説明する。本ベース処理は、例えば１ｍｓ毎，４ｍｓ毎，８ｍｓ毎というように、各ＥＣＵがそれぞれ決められた周期で実行する。
このベース処理が開始されると、まずＶＩＮ要求処理フラグがＯＮ／ＯＦＦの何れであるかを判断し（Ｓ１０１０）、ＶＩＮ要求処理フラグがＯＦＦであれば（Ｓ１０１０：ＯＦＦ）、本ベース処理を終了する。

一方、ＶＩＮ要求処理フラグがＯＮであれば（Ｓ１０１０：ＯＮ）、ＶＩＮコードを送信するためのフレームを生成するＶＩＮ応答準備処理を行う（Ｓ１０２０）。そして、ＶＩＮ要求処理フラグをクリアする（Ｓ１０３０）。

続いて、ＶＩＮ応答チェックフラグがＯＮ／ＯＦＦの何れであるかを判断する（Ｓ１０４０）。
そして、ＶＩＮ応答チェックフラグがＯＦＦであれば（Ｓ１０４０：ＯＦＦ）、ＶＩＮ応答開始フラグをＯＮする（Ｓ１０５０）。続いて、上記Ｓ１０２０のＶＩＮ応答準備処理で生成したフレームのテスタ５０への送信を通信部に要求する（Ｓ１０６０）。つまり、ＶＩＮコード応答の開始を通信部に要求するのである。その後、本ベース処理を終了する。尚、上述したように、通信部は、通信ラインＬが使用中であれば、通信ラインＬが空き状態になってからフレームの送信を開始する。このため、フレームの送信を開始する前に、他のＥＣＵによるＶＩＮコード応答が検出された場合には（Ｓ９４０）、上述したようにＶＩＮコード応答の中止を通信部に要求することとなる（Ｓ９８０）。

一方、Ｓ１０４０で、ＶＩＮ応答チェックフラグがＯＮであれば（Ｓ１０４０：ＯＮ）、ＶＩＮコード応答を中止するためのＶＩＮ応答中止処理を行い（Ｓ１０７０）、ＶＩＮ応答チェックフラグをクリアした後（Ｓ１０８０）、本ベース処理を終了する。尚、Ｓ１０４０でＶＩＮ応答チェックフラグがＯＮとなるのは、本ベース処理のＳ１０１０の処理が行われた後で、上記受信処理Ｓ９５０の処理でＶＩＮ応答チェックフラグがＯＮされた場合である。つまり、ＶＩＮ応答準備処理（Ｓ１０２０）を行っている間に、他のＥＣＵによるＶＩＮコード応答が検出された場合に、Ｓ１０７０の処理へ移行することとなる。

次に、図１８の送信完了処理について説明する。本送信完了処理は、自身が何らかのデータ（フレーム）の送信を完了することにより開始される。
この送信完了処理が開始されると、まず送信の完了したデータがＶＩＮコード応答であるか否かを判断する（Ｓ１１１０）。

そして、ＶＩＮコード応答の完了でないと判断した場合には（Ｓ１１１０：ＮＯ）、本送信完了処理を終了する。
一方、ＶＩＮコード応答の完了であると判断した場合には（Ｓ１１１０：ＹＥＳ）、ＶＩＮ応答開始フラグをクリアした後（Ｓ１１２０）、本送信完了処理を終了する。

以上のように、本第２実施例の車両用電子制御装置２０では、テスタ５０に対してＶＩＮコードを送信するＥＣＵの優先順位が定められておらず、応答準備処理を最初に完了したＥＣＵによりＶＩＮコード応答がなされる。そして、このＥＣＵがＶＩＮコードを正常に送信できなかった場合には、別のＥＣＵにより順次代わってＶＩＮコード応答が行われる。このため、本車両用電子制御装置２０によれば、上記第１実施例の車両用電子制御装置２０と同様、テスタ５０からのＶＩＮコード要求に対して確実に応答することができる。

また、各ＥＣＵは、通信ラインＬをモニタし、他のＥＣＵによるＶＩＮコードの応答が完了すると、以降のＶＩＮコード応答のための処理を中止し、自身はＶＩＮコードの応答を行わない。このため、上述したＯＢＤIIの改正における「１車両で１つのＶＩＮコードのみを応答すること」を遵守することができる。

尚、本第２実施例において、各ＥＣＵにおける不揮発性メモリが記憶手段に該当し、通信部が請求項２０及び請求項２２の通信手段に該当し、マイコンが検出手段及び送信要求手段に該当する。

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

例えば、上記各実施例では、本発明の車両用電子制御装置を構成する電子制御ユニットとして、エンジンＥＣＵ，トランスミッションＥＣＵ，走行制御ＥＣＵ，ボデーＥＣＵを例示したが、車両の構成要素を制御するこれ以外の電子制御ユニットを含み得ることはもちろんである。

また、上記実施例では、複数のＥＣＵの優先順位の設定の一例を示したが、これに限られず、設計の都合等によりその優先順位を適宜設定可能であることはいうまでもない。

本発明の第１実施例にかかる車両用電子制御装置の概略構成を表すブロック図である。 第１実施例の車両識別情報の通信方法を表す説明図である。 第１実施例の通信プロトコルを表す説明図である。 第１実施例の車両識別情報の通信方法を表す説明図である。 第１実施例の車両識別情報の通信処理を表すフローチャートである。 第１実施例の車両識別情報の通信処理を表すフローチャートである。 第１実施例の車両識別情報の通信処理を表すフローチャートである。 第１実施例の車両識別情報の通信処理を表すフローチャートである。 変形例（１）の車両識別情報の通信方法を表す説明図である。 変形例（１）の車両識別情報の通信処理を表すフローチャートである。 変形例（１）の車両識別情報の通信処理を表すフローチャートである。 変形例（２）の車両識別情報の通信方法を表す説明図である。 変形例（２）の車両識別情報の通信処理を表すフローチャートである。 本発明の第２実施例にかかる車両用電子制御装置の概略構成を表すブロック図である。 第２実施例の車両識別情報の通信方法を表す説明図である。 第２実施例の車両識別情報の通信処理を表すフローチャートである。 第２実施例の車両識別情報の通信処理を表すフローチャートである。 第２実施例の車両識別情報の通信処理を表すフローチャートである。

符号の説明

１，２１・・・エンジンＥＣＵ、 ２，２２・・・トランスミッションＥＣＵ、
３，２３・・・走行制御ＥＣＵ、 ４，２４・・・ボデーＥＣＵ、
１ｂ，２ｂ，３ｂ，４ｂ，２１ｂ，２２ｂ，２３ｂ，２４ｂ・・・通信部、
１０，２０・・・車両用電子制御装置、 １１・・・コネクタ、
５０・・・テスタ、 ５１・・・コネクタ、 １００・・・車両、
Ｌ・・・通信ライン

Claims (25)

1. 車両に搭載され、通信ラインを介して相互にデータ通信が可能な複数の電子制御ユニットを備え、前記通信ラインに接続された外部スキャンツールからの要求に応じて、前記車両固有の車両識別情報を送信可能に構成された車両用電子制御装置であって、
   前記各電子制御ユニットは、
   前記車両識別情報を記憶しておくための記憶手段と、
   前記通信ラインをモニタし、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出する検出手段と、
   前記外部スキャンツールから前記車両識別情報の送信要求を受信した時点からの経過時間を計時する計時手段と、
   該計時手段により、前記複数の電子制御ユニットについて予め定めた優先順位に従って設定された自己の応答開始時間が計時されると、前記検出手段がそれ以前に他の電子制御ユニットによる前記車両識別情報の応答を検出していないことを条件に、前記記憶手段に記憶されている車両識別情報を読み出して前記外部スキャンツールに送信する通信手段と、
   を備えたことを特徴とする車両用電子制御装置。
2. 前記検出手段は、前記外部スキャンツールから前記車両識別情報の送信要求を受信した時点から、前記通信ラインのモニタによる前記検出処理を開始することを特徴とする請求項１記載の車両用電子制御装置。
3. 前記検出手段は、前記通信ラインを流れるデータについて、まず該データの送信先アドレスを検出し、該送信先アドレスが前記外部スキャンツールのアドレスである場合にのみ、引き続き該データの内容が前記車両識別情報であるか否かをチェックすることを特徴とする請求項１又は請求項２に記載の車両用電子制御装置。
4. 前記各電子制御ユニットは、
   前記検出手段を介して、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出すると、前記検出手段及び前記計時手段の以降の動作を中止することを特徴とする請求項１〜３のいずれかに記載の車両用電子制御装置。
5. 前記各電子制御ユニットの応答開始時間は、前記車両識別情報の応答に要する予め定める時間以上の時間間隔で順次設定されていることを特徴とする請求項１〜４のいずれかに記載の車両用電子制御装置。
6. 前記各電子制御ユニットの計時手段は、他の電子制御ユニットによる前記車両識別情報の応答が開始された時点で計時を終了し、該応答により前記車両識別情報が正常に送信されなかった場合には、該応答が終了された時点からの経過時間を計時することを特徴とする請求項１〜４のいずれかに記載の車両用電子制御装置。
7. 前記各電子制御ユニットの通信手段は、
   自己の応答開始時間よりも短い応答開始時間に設定された他の電子制御ユニットがデータ送信不能状態であるか否かを判定し、データ送信不能状態であると判定した場合には、自己の応答開始時間を短縮する時間短縮手段を有していることを特徴とする請求項１〜６のいずれかに記載の車両用電子制御装置。
8. 前記各電子制御ユニットの時間短縮手段は、前記通信ラインをモニタし、自己の応答開始時間よりも短い応答開始時間に設定された他の電子制御ユニットが一定時間以上データを送信していない場合に、その電子制御ユニットがデータ送信不能状態であると判定することを特徴とする請求項７に記載の車両用電子制御装置。
9. 前記各電子制御ユニットの時間短縮手段は、データ送信不能状態であると判定した電子制御ユニットの数が多いほど自己の応答開始時間が短くなるように該応答開始時間を短縮することを特徴とする請求項７又は請求項８に記載の車両用電子制御装置。
10. 車両に搭載され、通信ラインを介して他の電子制御ユニットとの間で相互にデータ通信が可能であり、前記通信ラインに接続された外部スキャンツールからの要求に応じて、前記車両固有の車両識別情報を送信可能に構成された電子制御ユニットであって、
    前記車両識別情報を記憶しておくための記憶手段と、
    前記通信ラインをモニタし、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出する検出手段と、
    前記外部スキャンツールから前記車両識別情報の送信要求を受信した時点からの経過時間を計時する計時手段と、
    該計時手段により、前記複数の電子制御ユニットについて予め定めた優先順位に従って設定された自己の応答開始時間が計時されると、前記検出手段がそれ以前に他の電子制御ユニットによる前記車両識別情報の応答を検出していないことを条件に、前記記憶手段に記憶されている車両識別情報を読み出して前記外部スキャンツールに送信する通信手段と、
    を備えたことを特徴とする電子制御ユニット。
11. 前記検出手段は、前記外部スキャンツールから前記車両識別情報の送信要求を受信した時点から、前記通信ラインのモニタによる前記検出処理を開始することを特徴とする請求項１０記載の電子制御ユニット。
12. 前記検出手段は、前記通信ラインを流れるデータについて、まず該データの送信先アドレスを検出し、該送信先アドレスが前記外部スキャンツールのアドレスである場合にのみ、引き続き該データの内容が前記車両識別情報であるか否かをチェックすることを特徴とする請求項１０又は請求項１１に記載の電子制御ユニット。
13. 前記検出手段が、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出すると、前記検出手段及び前記計時手段の以降の動作を中止することを特徴とする請求項１０〜１２のいずれかに記載の電子制御ユニット。
14. 前記応答開始時間は、他の電子制御ユニットの応答開始時間に対し、前記車両識別情報の応答に要する予め定める時間以上の時間間隔で設定されていることを特徴とする請求項１０〜１３のいずれかに記載の電子制御ユニット。
15. 前記計時手段は、他の電子制御ユニットによる前記車両識別情報の応答が開始された時点で計時を終了し、該応答により前記車両識別情報が正常に送信されなかった場合には、該応答が終了された時点からの経過時間を計時することを特徴とする請求項１０〜１３のいずれかに記載の電子制御ユニット。
16. 前記通信手段は、
    自己の応答開始時間よりも短い応答開始時間に設定された他の電子制御ユニットがデータ送信不能状態であるか否かを判定し、データ送信不能状態であると判定した場合には、自己の応答開始時間を短縮する時間短縮手段を有していることを特徴とする請求項１０〜１５のいずれかに記載の電子制御ユニット。
17. 前記時間短縮手段は、前記通信ラインをモニタし、自己の応答開始時間よりも短い応答開始時間に設定された他の電子制御ユニットが一定時間以上データを送信していない場合に、その電子制御ユニットがデータ送信不能状態であると判定することを特徴とする請求項１６に記載の電子制御ユニット。
18. 前記時間短縮手段は、データ送信不能状態であると判定した電子制御ユニットの数が多いほど自己の応答開始時間が短くなるように該応答開始時間を短縮することを特徴とする請求項１６又は請求項１７に記載の電子制御ユニット。
19. 請求項１０〜１８のいずれかに記載の電子制御ユニットにおける検出手段、計時手段及び通信手段としてコンピュータシステムを機能させるためのプログラム。
20. 車両に搭載され、通信ラインを介して相互にデータ通信が可能な複数の電子制御ユニットを備え、前記通信ラインに接続された外部スキャンツールからの要求に応じて、前記車両固有の車両識別情報を送信可能に構成された車両用電子制御装置であって、
    前記各電子制御ユニットは、
    前記車両識別情報を記憶しておくための記憶手段と、
    前記通信ラインをモニタし、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出する検出手段と、
    送信すべきデータを、前記通信ラインが使用中でなければ直ちに送信し、前記通信ラインが使用中であれば該通信ラインが空き状態になってから送信するように構成されていると共に、他の電子制御ユニットと同時にデータを送信した場合には、前記複数の電子制御ユニットに対して予め定められた優先度に従い調停を行うように構成された通信手段と、
    前記外部スキャンツールから前記車両識別情報の送信要求を受信した場合に、前記検出手段がそれ以前に他の電子制御ユニットによる前記車両識別情報の応答を検出していないことを条件に、前記記憶手段に記憶されている車両識別情報の前記外部スキャンツールへの送信を前記通信手段に要求し、該要求後に前記検出手段により他の電子制御ユニットによる前記車両識別情報の応答が検出された場合には、前記車両識別情報の送信の中止を前記通信手段に要求する送信要求手段と、
    を備えたことを特徴とする車両用電子制御装置。
21. 前記通信手段は、前記送信すべきデータに前記優先度を表す識別コードを付加して送信し、送信した識別コードと前記通信ラインから検出される識別コードとが異なる場合に、調停負けしたものと判断してデータ送信を中止することを特徴とする請求項２０に記載の車両用電子制御装置。
22. 車両に搭載され、通信ラインを介して他の電子制御ユニットとの間で相互にデータ通信が可能であり、前記通信ラインに接続された外部スキャンツールからの要求に応じて、前記車両固有の車両識別情報を送信可能に構成された電子制御ユニットであって、
    前記車両識別情報を記憶しておくための記憶手段と、
    前記通信ラインをモニタし、他のいずれかの電子制御ユニットが前記外部スキャンツールに対して車両識別情報を応答したことを検出する検出手段と、
    送信すべきデータを、前記通信ラインが使用中でなければ直ちに送信し、前記通信ラインが使用中であれば該通信ラインが空き状態になってから送信するように構成されていると共に、他の電子制御ユニットと同時にデータを送信した場合には、複数の電子制御ユニットに対して予め定められた優先度に従い調停を行うように構成された通信手段と、
    前記外部スキャンツールから前記車両識別情報の送信要求を受信した場合に、前記検出手段がそれ以前に他の電子制御ユニットによる前記車両識別情報の応答を検出していないことを条件に、前記記憶手段に記憶されている車両識別情報の前記外部スキャンツールへの送信を前記通信手段に要求し、該要求後に前記検出手段により他の電子制御ユニットによる前記車両識別情報の応答が検出された場合には、前記車両識別情報の送信の中止を前記通信手段に要求する送信要求手段と、
    を備えたことを特徴とする電子制御ユニット。
23. 前記通信手段は、前記送信すべきデータに前記優先度を表す識別コードを付加して送信し、送信した識別コードと前記通信ラインから検出される識別コードとが異なる場合に、調停負けしたものと判断してデータ送信を中止することを特徴とする請求項２２に記載の電子制御ユニット。
24. 請求項２２又は請求項２３に記載の電子制御ユニットにおける検出手段及び送信要求手段としてコンピュータシステムを機能させるためのプログラム。
25. 請求項１９又は請求項２４に記載のプログラムを記録したコンピュータ読取可能な記録媒体。

Images