JP4661438B2 - 車両通信システム - Google Patents

Description

本発明は、車両に搭載された複数の制御装置が車両内の通信用のネットワークによって接続されると共に、そのネットワークには車両外の故障診断装置が有線又は無線にて通信可能に接続される車両通信システムに関するものである。

従来より、この種の車両通信システムにおいては、送信するメッセージのヘッダ領域に、送信先の制御装置を示すアドレスを含ませることで、その制御装置との通信が実現されるようになっている。

そして、車両の故障診断を行う際には、作業者が、車両内のネットワークに故障診断装置（いわゆる故障診断ツール）を通信可能に接続すると共に、その故障診断装置に備えられた入力キー等を操作して、その故障診断装置に、故障診断をしたい目的の機能が実装された制御装置と、故障診断に関する処理内容（即ち、その制御装置に実施させたい故障診断処理の内容）とのそれぞれを示す情報を入力すると、故障診断装置から上記目的の機能が実装された制御装置へ、その制御装置を送信先とし且つ上記処理内容の実施を指令する要求メッセージが送信させるようになっていた。

尚、故障診断用の要求メッセージとしては、例えば、制御装置内に記憶されている制御データを返送させるためのデータ要求メッセージや、アクチュエータを強制的に駆動させるための駆動要求メッセージなどがある。

一方、車両通信システムではないが、異なるネットワークを相互に接続するルータ機器に関する技術として、特許文献１がある。
特開２０００−２４４５４９号公報

ところで、上記従来の技術では、故障診断装置を扱う作業者（換言すれば、車両の故障診断を行う作業者）は、どの機能がどの制御装置に実装されているかを事前に調査して把握していなければならず、故障診断の作業が非常に面倒なものになっていた。

つまり、近年の車両においては、車両内における通信システムのハードウェアの標準化が進み、機能を実現するアプリケーションソフトの可搬性が高くなっているため、たとえ同じ機能であっても、車種によって、その機能が搭載される制御装置が異なる、ということが起こっているからである。また、同じ車種であっても、グレードやオプション設定によって、機能の違いや有無が生じるため、やはり同様である。

本発明は、こうした問題に鑑みなされたものであり、車両の故障診断を行う作業者が、どの機能がどの制御装置に実装されているかを把握していなくても、目的の機能の故障診断を実施できるようにすることを目的としている。

本発明の車両通信システムでは、車両に搭載された複数の制御装置が車両内の通信用のネットワークによって接続されると共に、車両外の故障診断装置がそのネットワークに有線又は無線にて通信可能に接続され、その故障診断装置が各制御装置と故障診断用の通信を行う。

そして、故障診断装置は、複数の制御装置のうち、故障診断対象である目的の機能が実装された制御装置を特定する特定手段を備えており、その特定手段により特定された制御装置に対して、目的の機能の故障診断を行うための要求メッセージを送信するようになっている。

尚、故障診断対象である目的の機能と、実施する故障診断の内容は、作業者が故障診断装置の入力キーなどを操作して、その故障診断装置に入力するように構成することができる。この場合、故障診断装置は、作業者により入力された目的の機能が実装された制御装置を特定手段により特定し、その特定した制御装置へ、作業者により入力された故障診断の内容に応じた故障診断用処理の実施を指示する要求メッセージを送信することとなる。また、故障診断装置の構成としては、作業者により故障診断の内容が入力されると、その内容から目的の機能を自動的に判別し、その判別した機能の実装された制御装置が、特定手段により特定される、という構成でも良い。

そして、このような車両通信システムによれば、車両の故障診断を行う作業者が、故障診断をしたい目的の機能が実装された制御装置が何れであるかを知らなくても、その制御装置が特定手段により自動的に特定されて、その特定された制御装置へ故障診断装置から故障診断用の要求メッセージが送信されることとなる。よって、作業者は、どの機能がどの制御装置に実装されているかを把握していなくても、目的の機能の故障診断を実施することができるようになる。

ところで、参考構成例について述べると、例えば、故障診断装置は、複数の機能の各々が複数の制御装置の何れに実装されているかを示すデータテーブルを有し、特定手段は、そのデータテーブルに基づいて、目的の機能が実装された制御装置を特定するように構成することができる。

また、上記データテーブルが、故障診断装置に着脱可能な記憶手段に記憶され、故障診断装置は、その記憶手段からデータテーブルを読み込むように構成すれば、使い勝手が一層良好となる。

つまり、機能と制御装置との組み合わせが異なる車両毎について、データテーブルを記憶した記憶手段をそれぞれ用意しておけば、故障診断装置に取り付ける記憶手段を取り替えるだけで、異なる車両に素早く対応することができるからである。

更に、データテーブルの変更に対しても容易に対応でき、拡張性が向上する。尚、着脱可能な記憶手段としては、例えば、ディスクタイプの記憶媒体や、メモリカードや、ＵＳＢ接続式のリムーバブルメモリなどがある。

一方、請求項１の車両通信システムでは、上記のデータテーブルを故障診断装置に予め記憶させておくのではなく、故障診断装置は、複数の各制御装置へ、その制御装置に実装されている機能を問い合わせる機能確認要求メッセージを送信し、各制御装置は、故障診断装置からの機能確認要求メッセージを受信すると、自装置に実装されている機能を示す機能識別情報及び自装置を示す装置識別情報を含んだ機能確認応答メッセージを、故障診断装置に送信するようになっている。更に、故障診断装置は、各制御装置からの機能確認応答メッセージに基づいて、どの機能が複数の制御装置の何れに実装されているかを示すデータテーブルを作成し、特定手段は、その作成されたデータテーブルに基づいて、目的の機能が実装された制御装置を特定する。

このような請求項１の車両通信システムによれば、故障診断装置にデータテーブルを事前に記憶させておく必要がない上に、機能と制御装置との組み合わせが異なる車両毎にデータテーブルを用意しておく必要もなくなる。つまり、データテーブルを人為的に管理する必要がなく、高い利便性が得られる。

しかも、請求項１の車両通信システムにおいて、故障診断装置は、機能確認要求メッセージの送信を実施する前に、ネットワークに接続された全ての制御装置へ、通信可能であるか否かを確認するための通信確認要求メッセージを送信し、その通信確認要求メッセージに対して規定時間以内に応答があった制御装置へ、機能確認要求メッセージを送信するようになっている。

このため、ネットワークに接続されていない通信不能な制御装置あての機能確認要求メッセージが、故障診断装置から送信されることがなく、ネットワークを効率良く使用することができる。

一方、特定手段は、請求項２に記載のように構成することもできる。
即ち、請求項２に記載の車両通信システムでは、特定手段は、複数の各制御装置へ、目的の機能を示す機能識別情報を含んだ機能問い合わせ要求メッセージを送信し、各制御装置は、その機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報に該当する機能が自装置に実装されているか否かを判定して、その機能が実装されているならば、自装置を示す装置識別情報を含んだ機能問い合わせ応答メッセージを故障診断装置に送信するようになっている。そして、特定手段は、制御装置から送信されてきた機能問い合わせ応答メッセージ内の装置識別情報に該当する制御装置を、目的の機能が実装された制御装置であると特定する。

このような請求項２の車両通信システムによれば、故障診断装置は上述したようなデータテーブルを保持したり作成したりする必要がないため、故障診断装置の必要メモリ容量と処理負荷を低減することができる。

次に、請求項３の車両通信システムでは、請求項２の車両通信システムにおいて、ネットワークは、故障診断装置の接続される通信線が最上位通信線であると共に、上位の通信線と下位の通信線とがゲートウェイを介して接続される階層構造のネットワークとなっている。そして、複数の制御装置のうちの何れかが、ゲートウェイとして機能するゲートウェイ制御装置となっている。

そして更に、そのゲートウェイ制御装置は、自装置よりも下位側の制御装置から、その下位側の制御装置に実装されている機能の機能識別情報を通信により取得すると共に、その取得した機能識別情報を記録した機能リストを作成し、その後、故障診断装置からの（詳しくは、故障診断装置の特定手段により送信された）機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記作成した機能リストに記録されている場合にのみ、その機能問い合わせ要求メッセージの中継を実施する。

尚、ゲートウェイ制御装置であっても、ゲートウェイ制御装置ではない制御装置（以下、非ゲートウェイ制御装置という）と同様に、故障診断装置からの機能問い合わせ要求メ
ッセージに含まれている機能識別情報に該当する機能が自装置に実装されているならば、自装置を示す装置識別情報を含んだ機能問い合わせ応答メッセージを故障診断装置に送信する。

このような請求項３の車両通信システムによれば、ネットワークを構成する通信線のうち、故障診断対象である目的の機能が実装されている制御装置がその通信線にも下位の通信線にも接続されていない通信線へは、故障診断装置からの機能問い合わせ要求メッセージが中継されなくなる（換言すれば、目的の機能が実装されていない制御装置だけからなる下位の部分ネットワークへは、故障診断装置からの機能問い合わせ要求メッセージが中継されなくなる）ため、ネットワークの通信負荷と各制御装置の通信処理負荷を抑制することができる。また、ネットワークの通信負荷が低減されることから、目的の機能が実装されている制御装置から故障診断装置への機能問い合わせ応答メッセージの応答時間（延いては、故障診断装置にて目的の機能が実装された制御装置を特定できるまでの時間）も短縮することができる。

ところで、請求項３の車両通信システムにおいて、ゲートウェイ制御装置にて前記機能リストを作成するために各制御装置間で行われる通信は、請求項４に記載のように、各制御装置への電源供給が開始された直後に実施されるように構成するのが好ましい。

このように構成すれば、故障診断装置から機能問い合わせ要求メッセージが送信される前にゲートウェイ制御装置にて機能リストを作成しておくことを、確実に達成することができる。

更に、請求項４の車両通信システムにおいて、ネットワークの階層が３階層以上である（つまり、最上位通信線の下位に少なくとも２階層以上の通信線が存在する）ならば、請求項５のように構成することができる。

即ち、請求項５の車両通信システムでは、最上位通信線よりも下位の通信線に接続された非ゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイ制御装置へ、自装置に実装されている機能を示す機能識別情報を通知する。

また、最上位通信線に接続されたゲートウェイ制御装置以外のゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知される機能識別情報を受信して前記機能リストを作成すると共に、その作成した機能リストに記録された機能識別情報と自装置の機能を示す機能識別情報とを、自装置よりも１つ上位のゲートウェイ制御装置へ通知する。

そして、最上位通信線に接続されたゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知される機能識別情報を受信して前記機能リストを作成する。

このような請求項５の構成によれば、ネットワークの階層が３階層以上である場合に、各ゲートウェイ制御装置にて機能リストを効率良く確実に作成することができる。
尚、請求項４，５の車両通信システムにおいて、各制御装置へ電源供給が開始されるタイミングとしては、請求項６に記載のように、車両のイグニッションスイッチがオンされたときや、請求項７に記載のように、車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされたときが考えられる。

次に、請求項８の車両通信システムでは、請求項３〜７の車両通信システムにおいて、ゲートウェイ制御装置にて前記機能リストを作成するために、そのゲートウェイ制御装置へ他の制御装置から送信されるメッセージ（即ち、ゲートウェイ制御装置へ下位側の制御装置が機能識別情報を通知するためのメッセージ）のヘッダ領域には、そのメッセージが機能リスト作成用の通信メッセージであることを示す識別情報が含まれている。この車両通信システムによれば、ゲートウェイ制御装置は、機能リスト作成用の通信メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようになり有利である。

一方、請求項９の車両通信システムでは、請求項２の車両通信システムにおいて、ネットワークは、故障診断装置の接続される通信線が最上位通信線であると共に、上位の通信線と下位の通信線とがゲートウェイを介して接続される階層構造のネットワークとなっている。そして、複数の制御装置のうちの何れかが、ゲートウェイとして機能するゲートウェイ制御装置となっている。

そして更に、そのゲートウェイ制御装置は、自装置よりも下位側の制御装置から、その下位側の制御装置に実装されている機能の機能識別情報及びその下位側の制御装置の装置識別情報を通信により取得して、その取得した機能識別情報及び装置識別情報を用い、更に自装置に実装されている機能があれば該機能の機能識別情報及び自装置の装置識別情報も用いて、機能識別情報とその機能識別情報が示す機能が実装された制御装置の装置識別情報とを対応させて記録したデータテーブルを作成し、その後、故障診断装置からの（詳しくは、故障診断装置の特定手段により送信された）機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記データテーブルに記録されているか否かを判定して、その機能識別情報が記録されているならば、その機能識別情報に対応して前記データテーブルに記録されている装置識別情報を含んだ機能問い合わせ応答メッセージを、故障診断装置に送信する。

このような請求項９の車両通信システムによれば、故障診断装置からの機能問い合わせ要求メッセージに対して、目的の機能が搭載された制御装置の代わりに、その制御装置よりも上位側のゲートウェイ制御装置が応答する（即ち、機能問い合わせ応答メッセージを送信する）こととなる。

よって、ネットワークの通信負荷と各制御装置の通信処理負荷を抑制することができる。更に、故障診断装置が機能問い合わせ要求メッセージを送信してから、それに対する機能問い合わせ応答メッセージを受け取るまでの応答時間（延いては、故障診断装置にて目的の機能が実装された制御装置を特定できるまでの時間）を短縮することができる。

ところで、請求項９の車両通信システムにおいて、ゲートウェイ制御装置にて前記データテーブルを作成するために各制御装置間で行われる通信は、請求項１０に記載の如く、各制御装置への電源供給が開始された直後に実施されるように構成するのが好ましい。

このように構成すれば、故障診断装置から機能問い合わせ要求メッセージが送信される前にゲートウェイ制御装置にてデータテーブルを作成しておくことを、確実に達成することができる。

更に、請求項１０の車両通信システムにおいて、ネットワークの階層が３階層以上である（つまり、最上位通信線の下位に少なくとも２階層以上の通信線が存在する）ならば、請求項１１のように構成することができる。

即ち、請求項１１の車両通信システムでは、最上位通信線よりも下位の通信線に接続された非ゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイ制御装置へ、自装置に実装されている機能を示す機能識別情報及び自装置の装置識別情報を、データテーブル作成用情報として通知する。

また、最上位通信線に接続されたゲートウェイ制御装置以外のゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知されるデータテーブル作成用情報を用いて前記データテーブルを作成すると共に、その作成したデータテーブルを表す情報を、自装置よりも１つ上位のゲートウェイ制御装置へデータテーブル作成用情報として通知する。

そして、最上位通信線に接続されたゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知されるデータテーブル作成用情報を用いて前記データテーブルを作成し、故障診断装置からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記データテーブルに記録されているか否かを判定して、その機能識別情報が記録されているならば、その機能識別情報に対応して前記データテーブルに記録されている装置識別情報を含んだ機能問い合わせ応答メッセージを、故障診断装置に送信する。

このような請求項１１の構成によれば、ネットワークの階層が３階層以上である場合に、最上位通信線に接続されたゲートウェイ制御装置にてデータテーブルを効率良く確実に作成することができる。そして、最上位通信線よりも下位の通信線に接続された制御装置は、故障診断装置からの能問い合わせ要求メッセージに応答しなくても良く、ネットワークの階層が多くても、ネットワークの通信負荷と各制御装置の通信処理負荷を抑制することができると共に、故障診断装置が機能問い合わせ要求メッセージを送信してから、それに対する機能問い合わせ応答メッセージを受け取るまでの応答時間を短縮することができる。

尚、請求項１０，１１の車両通信システムにおいて、各制御装置へ電源供給が開始されるタイミングとしては、請求項１２に記載のように、車両のイグニッションスイッチがオンされたときや、請求項１３に記載のように、車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされたときが考えられる。

次に、請求項１４の車両通信システムでは、請求項９〜１３の車両通信システムにおいて、ゲートウェイ制御装置にて前記データテーブルを作成するために、そのゲートウェイ制御装置へ他の制御装置から送信されるメッセージのヘッダ領域には、そのメッセージがデータテーブル作成用の通信メッセージであることを示す識別情報が含まれている。この車両通信システムによれば、ゲートウェイ制御装置は、データテーブル作成用の通信メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようになり有利である。

次に、請求項１５の車両通信システムでは、請求項９〜１４の車両通信システムにおいて、故障診断装置の特定手段は、機能問い合わせ要求メッセージを各制御装置へ送信することに代えて、機能問い合わせ要求メッセージを最上位通信線に接続されている特定の制御装置へ送信する。そして、その特定の制御装置は、機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージを他の各制御装置へ送信すると共に、その機能問い合わせ要求メッセージに対して返送されてくる機能問い合わせ応答メッセージを受信して、その機能問い合わせ応答メッセージを故障診断装置へ送信する。

つまり、請求項１５の車両通信システムでは、車両内のネットワークに接続された特定の制御装置が、故障診断装置からの機能問い合わせ要求メッセージを他の制御装置に中継すると共に、他の制御装置から返送されてくる機能問い合わせ応答メッセージを故障診断装置に中継するようになっている。

そして、このような車両通信システムによれば、故障診断装置は、目的の機能が搭載された制御装置を特定するために、特定の制御装置とだけ通信すれば良いため、その故障診断装置の通信処理負荷を軽減することができる。また、上記特定の制御装置はデータテーブルを持つ必要がないため、その制御装置におけるデータ記憶用のリソースを増大させてしまうこともない。

一方、特定手段は、請求項１６に記載のように構成することもできる。
即ち、請求項１６に記載の車両通信システムでは、複数の制御装置のうちの特定の制御装置が、複数の機能の各々が複数の制御装置の何れに実装されているかを示すデータテーブルを有しており、特定手段は、その特定の制御装置へ、目的の機能を示す機能識別情報を含んだ機能問い合わせ要求メッセージを送信する。そして、特定の制御装置は、機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報に該当する機能が実装されている制御装置を前記データテーブルから検索して、その検索した制御装置の装置識別情報を含んだ機能問い合わせ応答メッセージを故障診断装置に送信する。そして更に、特定手段は、特定の制御装置から送信されてきた機能問い合わせ応答メッセージ内の装置識別情報に該当する制御装置を、目的の機能が実装された制御装置であると特定する。

このような請求項１６の車両通信システムによれば、請求項２の車両通信システムと同様に、故障診断装置にてデータテーブルを保持したり作成したりする必要がないため、故障診断装置の必要メモリ容量と処理負荷を低減することができる。また、故障診断装置は、目的の機能が搭載された制御装置を特定するために、特定の制御装置とだけ通信すれば良いため、その故障診断装置の通信処理負荷を軽減することができる。

しかも、請求項１６の車両通信システムにおいて、前記特定の制御装置以外の制御装置は、電源供給が開始されると、前記特定の制御装置へ、自装置に実装されている機能を示す機能識別情報及び自装置の装置識別情報を通知し、前記特定の制御装置は、電源供給が開始されると、他の制御装置から通知される機能識別情報及び装置識別情報に基づいて前記データテーブルを作成する。

このため、故障診断装置から機能問い合わせ要求メッセージが送信される前に、特定の制御装置にて、データテーブルを確実に作成しておくことができ、故障診断装置が機能問い合わせ要求メッセージを送信してから、それに対する機能問い合わせ応答メッセージを受け取るまでの応答時間（延いては、故障診断装置にて目的の機能が実装された制御装置を特定できるまでの時間）を短縮することができる。

尚、請求項１６の車両通信システムにおいて、各制御装置へ電源供給が開始されるタイミングとしては、請求項１７に記載のように、車両のイグニッションスイッチがオンされたときや、請求項１８に記載のように、車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされたときが考えられる。

次に、請求項１９の車両通信システムでは、請求項１６〜１８の車両通信システムにおいて、前記特定の制御装置にて前記データテーブルを作成するために、その特定の制御装置へ他の制御装置から送信されるメッセージのヘッダ領域には、そのメッセージがデータテーブル作成用の通信メッセージであることを示す識別情報が含まれている。この車両通信システムによれば、特定の制御装置は、データテーブル作成用の通信メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようになり有利である。

以下に、本発明が適用された実施形態の車両通信システムについて説明する。尚、以下の説明においては、車両に搭載された電子制御装置のことを、ＥＣＵといい、車両外の故障診断装置のことを、外部ツールという。
［第１実施形態］
まず図１に示すように、第１実施形態の車両通信システムでは、複数のＥＣＵ（この例では符号１〜７，１０を付した８個のＥＣＵ）が、車両内に配設された通信用のネットワーク５０によって通信可能に接続されている。また、ネットワーク５０には、外部ツール６３がコネクタ６１によって着脱可能に接続されるようになっており、その外部ツール６３は、ネットワーク５０を介して各ＥＣＵと故障診断用の通信を行う。

具体的には、本第１実施形態において、ネットワーク５０は、外部ツール６３がコネクタ６１により接続される最上位の通信線５１と、下位の通信線５２とからなると共に、その上位と下位の通信線５１，５２がゲートウェイ（Ｇ／Ｗ）を介して接続される２階層のネットワークとなっている。そして、下位の通信線５２には５つのＥＣＵ１〜５とＥＣＵ１０が接続され、上位の通信線５１には２つのＥＣＵ６，７とＥＣＵ１０が接続されており、更に、ＥＣＵ１０は、通信線５１と通信線５２との間で通信データを中継するゲートウェイとして機能するようになっている。尚、本第１実施形態において、ＥＣＵ１０は、ゲートウェイ専用のＥＣＵである。

また、本第１実施形態では、エンジン制御やエアコン制御など、車両に関する制御の各機能であって、ＥＣＵに実装される（換言すれば、ＥＣＵに備えられる）各機能には、車両開発時において、その機能毎にユニークなＩＤ（即ち、その機能を示す機能識別情報に相当し、以下、ＦＩＤという）が静的に設定されており、同様に、各ＥＣＵには、車両開発時において、そのＥＣＵ毎にユニークなＩＤ（即ち、そのＥＣＵを示す装置識別情報に相当し、以下、ＵＩＤという）が静的に設定されている。尚、このことは、後述する他の実施形態についても同様である。

この例では、図１に示すように、ＥＣＵ１〜７，１０の各々には、そのＥＣＵの符号と同じ値のＵＩＤが設定されている。そして、ＥＣＵ１には、ＦＩＤ＝１の機能（○×制御機能）が実装されており、ＥＣＵ２には、ＦＩＤ＝１の機能とＦＩＤ＝２の機能（○×診断機能）とが実装されており、ＥＣＵ３には、ＦＩＤ＝２の機能が実装されており、ＥＣＵ４には、ＦＩＤ＝３の機能（△△機能）が実装されており、ＥＣＵ５には、ＦＩＤ＝４の機能（××制御機能）が実装されており、ＥＣＵ６とＥＣＵ７には、ＦＩＤ＝５の機能（□×システムの機能）が実装されている。

更に、外部ツール６３には、メモリカード６５（故障診断装置に着脱可能な記憶手段に相当）が着脱可能となっている。
そして、メモリカード６５には、図３に示すように、ＦＩＤとそのＦＩＤが示す機能が実装されたＥＣＵのＵＩＤとを対応させて記録したデータテーブルであるＦＩＤ−ＵＩＤテーブルが記憶されている。つまり、このＦＩＤ−ＵＩＤテーブルは、複数の機能の各々が複数のＥＣＵの何れに実装されているか（更に簡単に言うと、どの機能がどのＥＣＵに実装されているか）を示すデータテーブルである。また、こうしたＦＩＤ−ＵＩＤテーブルは、機能とＥＣＵとの組み合わせが異なる車両毎に用意され、その車両毎のＦＩＤ−ＵＩＤテーブルは、それぞれ異なるメモリカード６５に記憶されている。

次に、図２は、外部ツール６３がネットワーク５０に接続されたＥＣＵ１〜７，１０へ
アクセスする際に実行するアクセス制御処理を表すフローチャートである。
尚、外部ツール６３はコンピュータを備えており、図２のアクセス制御処理は、実際にはそのコンピュータによって実行される。また、車両の故障診断を行う作業者は、故障診断を行う車両用のＦＩＤ−ＵＩＤテーブルが記憶されたメモリカード６５を外部ツール６３に取り付ける。そして、作業者が、外部ツール６３に備えられた入力キー（図示省略）を操作して、故障診断対象である目的の機能のＦＩＤと、実施する故障診断の内容とを外部ツール６３に入力すると、図２のアクセス制御処理が開始される。また、外部ツール６３の構成としては、作業者が目的の機能のＦＩＤを入力しなくても、故障診断の内容が入力されると、その内容から目的の機能のＦＩＤを自動的に判別する、という構成でも良い。

図２に示すように、外部ツール６３がアクセス制御処理を開始すると、まずＳ１１０にて、メモリカード６５からＦＩＤ−ＵＩＤテーブルを読み込み、そのＦＩＤ−ＵＩＤテーブルから、目的の機能のＦＩＤに対応するＵＩＤを検索して取得する処理を行う。

そして、次のＳ１２０にて、上記Ｓ１１０でＵＩＤを取得できたか否かを判定し、ＵＩＤを取得できなかった場合（即ち、目的の機能が実装されたＥＣＵが車両に存在しない場合）には、そのまま当該アクセス制御処理を終了する。

また、Ｓ１２０にて、上記Ｓ１１０でＵＩＤを取得できたと判定した場合には、Ｓ１３０に進み、上記Ｓ１１０で取得したＵＩＤのリストを作成する。
次に、続くＳ１４０にて、上記Ｓ１３０で作成したリスト中の１つのＵＩＤに該当するＥＣＵを送信先として、作業者により入力された故障診断の内容に応じた故障診断用処理の実施を指示する要求メッセージ（故障診断用の要求メッセージ）を送信する。そして更に、その後、上記Ｓ１３０で作成したリストから、今回、故障診断用の要求メッセージを送信したＥＣＵのＵＩＤを削除する。

尚、外部ツール６３とＥＣＵとの間、或いは、ＥＣＵ同士の間で通信されるメッセージは、少なくとも、データが配置されるデータ領域と、そのデータ領域の前に設けられるヘッダ領域とを有しており、そのヘッダ領域には、宛先（送信先）を示す宛先情報が配置されるが、ＥＣＵへのメッセージのヘッダ領域に配置される宛先情報は、そのＥＣＵのＵＩＤであっても良いし、また、ＵＩＤとは別の宛先情報用のデータであっても良い。そして、後者の場合には、送信先ＥＣＵのＵＩＤを宛先情報用のデータに変換して、メッセージのヘッダ領域に配置することとなる。一方、故障診断用の要求メッセージとしては、例えば、ＥＣＵ内に記憶されている制御データを指定して、その制御データを返送させるためのデータ取得要求メッセージや、アクチュエータを指定して、そのアクチュエータを強制的に駆動させるためのアクチュエータ駆動要求メッセージなどがある。

次に、Ｓ１５０にて、上記Ｓ１３０で作成したリストに他のＵＩＤが存在するか否かを判定し、他のＵＩＤが存在しなければ、そのまま当該アクセス制御処理を終了するが、他のＵＩＤが存在するならば（Ｓ１５０：ＹＥＳ）、Ｓ１４０へ戻る。

つまり、図２のアクセス制御処理では、メモリカード６５内のＦＩＤ−ＵＩＤテーブルから、目的の機能が実装されたＥＣＵのＵＩＤを検索し（Ｓ１１０）、その検索した全てのＵＩＤに該当する各ＥＣＵへ、故障診断用の要求メッセージを送信するようにしている（Ｓ１３０〜Ｓ１５０）。

以上のような第１実施形態の車両通信システムによれば、車両の故障診断を行う作業者
が、故障診断をしたい目的の機能が実装されたＥＣＵが何れであるかを知らなくても、そのＥＣＵが図２におけるＳ１１０の処理により自動的に特定されて、その特定されたＥＣＵへ外部ツール６３から故障診断用の要求メッセージが送信されることとなる。よって、作業者は、どの機能がどのＥＣＵに実装されているかを把握していなくても、目的の機能の故障診断を実施することができるようになる。

また、機能とＥＣＵとの組み合わせが異なる車両毎について、ＦＩＤ−ＵＩＤテーブルを記憶したメモリカード６５がそれぞれ用意されているため、外部ツール６３に取り付けるメモリカード６５を取り替えるだけで、異なる車両に素早く対応することができる。

尚、本第１実施形態では、図２におけるＳ１１０の処理が、特定手段に相当している。［第２実施形態］
次に、第２実施形態の車両通信システムは、第１実施形態の車両通信システムと比較すると、外部ツール６３が各ＥＣＵからの情報を元にＦＩＤ−ＵＩＤテーブルを自動的に作成する点が異なっている。このため、外部ツール６３は、メモリカード６５が着脱可能となっている必要はない。尚、他のハードウェア構成については、第１実施形態と同じであるが、各ＥＣＵには、そのＥＣＵのＵＩＤと、そのＥＣＵに実装されている機能のＦＩＤとが記憶されている。

そこで、第２実施形態の車両通信システムについて、図４を用いて説明する。尚、図４は、外部ツール６３と各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。
まず、外部ツール６３は、ネットワーク５０に接続された状態で、電源投入または起動スイッチのオンにより動作を開始すると、図４（１）に示すように、ネットワーク５０に接続された全てのＥＣＵへ、通信可能であるか否かを確認するための通信確認要求メッセージを送信する。この通信確認要求メッセージは、ヘッダ領域の宛先情報として、宛先が全てのＥＣＵである（換言すれば、不特定多数のＥＣＵである）ことを示す宛先情報が付加されたメッセージ（つまり、ブロードキャストされるメッセージ）である。

そして、図４（２）に示すように、ネットワーク５０に接続された各ＥＣＵは、外部ツール６３からの通信確認要求メッセージを受信すると、外部ツール６３へ、自装置のＵＩＤを含んだ通信確認応答メッセージを返送する。

そこで、図４（３）に示すように、外部ツール６３は、通信確認要求メッセージに対して規定時間以内に応答があったＥＣＵ（即ち、通信確認応答メッセージを返送してきたＥＣＵ）を、通信可能なＥＣＵとして記憶する。具体的な処理としては、返送されてきた通信確認応答メッセージの各々に含まれているＵＩＤを、通信可能なＥＣＵのＵＩＤとして記憶する。

そして、作業者が、故障診断対象である目的の機能のＦＩＤと、実施する故障診断の内容とを外部ツール６３に入力すると、図４（４）に示すように、外部ツール６３は、図４（３）で記憶した各ＥＣＵ（即ち、通信可能であると確認できているＥＣＵ）へ、そのＥＣＵに実装されている機能を問い合わせる機能確認要求メッセージを送信する。

また、図４（５）に示すように、各ＥＣＵは、外部ツール６３からの機能確認要求メッセージを受信すると、自装置に実装されている機能を示すＦＩＤと自装置のＵＩＤとを含んだ機能確認応答メッセージを、外部ツール６３に送信する。

そこで、外部ツール６３は、図４（６）に示すように、各ＥＣＵからの機能確認応答メッセージに基づいて、図３に示したようなＦＩＤ−ＵＩＤテーブルを作成し、そのＦＩＤ
−ＵＩＤテーブルを内部のメモリ（例えばＲＡＭ）に記憶する。

そして、図４（７）に示すように、外部ツール６３は、第１実施形態で説明した図２のＳ１１０と同様に、図４（６）で作成したＦＩＤ−ＵＩＤテーブルから、目的の機能のＦＩＤに対応するＵＩＤを検索して取得する。

そして更に、図４（８）に示すように、外部ツール６３は、第１実施形態で説明した図２のＳ１２０〜Ｓ１５０と同様の処理を実行して、図４（７）で取得した全てのＵＩＤに該当する各ＥＣＵへ、故障診断用の要求メッセージを送信する。

尚、図４（８）では、外部ツール６３からＥＣＵ４へ、故障診断用の要求メッセージとして、アクチュエータを強制的に駆動させるためのアクチュエータ駆動要求メッセージが送信される場合を例示している。よって、図４の例では、ＥＣＵ４が、外部ツール６３からのアクチュエータ駆動要求メッセージによって指示されるアクチュエータを駆動することとなり、作業者は、そのアクチュエータに関連する機器の動作状態によって、正常／異常の判断をすることとなる。

以上のような第２実施形態の車両通信システムによれば、外部ツール６３にＦＩＤ−ＵＩＤテーブルを事前に記憶させておく必要がない上に、機能とＥＣＵとの組み合わせが異なる車両毎にＦＩＤ−ＵＩＤテーブルを用意しておく必要もなくなる。つまり、ＦＩＤ−ＵＩＤテーブルを人為的に管理する必要がなく、高い利便性が得られる。

更に、第２実施形態の車両通信システムによれば、図４（１）〜（３）の動作により、外部ツール６３からは、通信不能なＥＣＵあての機能確認要求メッセージが送信されることがないため、ネットワーク５０を効率良く使用することができる。

尚、本第２実施形態では、外部ツール６３の動作のうち、図４（７）の動作が、特定手段に相当している。
一方、図４（１）〜（３）の動作は、例えば、作業者が外部ツール６３に対して通信確認実施の指令入力を行った際に実施されるように構成しても良く、また、作業者が外部ツール６３に目的の機能のＦＩＤと故障診断の内容とを入力すると、機能確認要求メッセージの送信に先立って実施されるように構成しても良い。
［第３実施形態］
次に、第３実施形態の車両通信システムは、第１，２実施形態の車両通信システムと比較すると、外部ツール６３が、全ての機能についてのＦＩＤ−ＵＩＤテーブルを用いずに、目的の機能が実装されているＥＣＵ（即ち、故障診断用の要求メッセージを送信すべきＥＣＵ）を特定する点が異なっている。尚、本第３実施形態においても、外部ツール６３は、メモリカード６５が着脱可能となっている必要はなく、それ以外のハードウェア構成については、第１実施形態と同じである。また、各ＥＣＵには、そのＥＣＵのＵＩＤと、そのＥＣＵに実装されている機能のＦＩＤとが記憶されている。

そこで、第３実施形態の車両通信システムについて、図５を用いて説明する。尚、図５は、外部ツール６３と各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。
まず、外部ツール６３は、作業者により、故障診断対象である目的の機能のＦＩＤと、実施する故障診断の内容とが入力されると、図５（１）に示すように、ネットワーク５０に接続された各ＥＣＵへ、目的の機能のＦＩＤを含んだ機能問い合わせ要求メッセージを送信する。

そして、各ＥＣＵは、図５（２）に示すように、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれているＦＩＤに該当する機能が自装置に実装されているか否かを判定し、その機能が実装されているならば、図５（３）に示すように、自装置のＵＩＤを含んだ機能問い合わせ応答メッセージを外部ツール６３に送信する。尚、図５の例では、外部ツール６３から、ＦＩＤとして「０１」を含んだ機能問い合わせ要求メッセージが送信されているため、ＦＩＤ＝０１の機能が実装されているＥＣＵ１とＥＣＵ２との各々が、外部ツール６３へ機能問い合わせ応答メッセージを送信しており、他のＥＣＵ（図５ではＥＣＵ４）は、機能問い合わせ応答メッセージを送信しない。

そこで、外部ツール６３は、図５（４）に示すように、ＥＣＵからの機能問い合わせ応答メッセージを全て受信して、その機能問い合わせ応答メッセージに含まれているＵＩＤのリストを作成する。つまり、ここで作成されるリストは、第１実施形態で説明した図２のＳ１３０で作成されるリストと同じ意味のものであり、目的の機能が実装されたＥＣＵのＵＩＤを列挙したものとなる。

そして、図５（５），（７）に示すように、外部ツール６３は、第１実施形態で説明した図２のＳ１４０，Ｓ１５０と同様の処理を実行して、図５（４）で作成したリスト中の各ＵＩＤに該当するＥＣＵへ、故障診断用の要求メッセージを送信する。

尚、図５の例では、外部ツール６３から、故障診断用の要求メッセージとして、データ取得要求メッセージが送信される場合を例示している。このため、図５（５）に示すように、外部ツール６３がＥＣＵ２へデータ取得要求メッセージを送信すると、図５（６）に示すように、ＥＣＵ２は、そのデータ取得要求メッセージによって指定される制御データ（即ち、外部ツール６３から要求されたデータ）をデータ領域に配置したデータ取得応答メッセージを、外部ツール６３へ送信することとなる。また、図５（７）に示すように、外部ツール６３がＥＣＵ１へデータ取得要求メッセージを送信すると、図５（８）に示すように、ＥＣＵ１は、そのデータ取得要求メッセージによって指定される制御データをデータ領域に配置したデータ取得応答メッセージを、外部ツール６３へ送信することとなる。そして、外部ツール６３は、各ＥＣＵ１，２から受信したデータ取得応答メッセージ内の制御データを、当該外部ツール６３に備えられた表示器に表示させることとなる。よって、作業者は、その表示された制御データの値や内容等により、正常／異常の判断をすることとなる。

つまり、本第３実施形態の車両通信システムにおいて、外部ツール６３は、各ＥＣＵへ、目的の機能のＦＩＤを含んだ機能問い合わせ要求メッセージを送信し、そのメッセージに対してＥＣＵから送信されてきた機能問い合わせ応答メッセージ内のＵＩＤに該当するＥＣＵを、目的の機能が実装されたＥＣＵであると特定するようになっている。

このような第３実施形態車両通信システムによれば、第２実施形態の車両通信システムと同様の効果が得られる上に、外部ツール６３は全ての機能についてのＦＩＤ−ＵＩＤテーブルを保持したり作成したりする必要がなく、その外部ツール６３の必要メモリ容量と処理負荷を低減することができる。

尚、本第３実施形態では、外部ツール６３の動作のうち、図５（１），（４）の動作が、特定手段に相当している。
［第４実施形態］
次に、第４実施形態の車両通信システムについて、図６を用いて説明する。

第４実施形態の車両通信システムでは、外部ツール６３と車両側の各ＥＣＵが第３実施
形態と同様に、図５（１）〜（８）で説明した動作を行うが、ネットワーク５０が図６のようになっていると共に、ＥＣＵの数が第３実施形態よりも増えており（この例では１２個）、更に、各ＥＣＵは後述する（Ａ）〜（Ｄ）の動作を追加して行う。

まず、図６に示すように、本第４実施形態の車両通信システムでは、ネットワーク５０が、３階層のネットワークとなっている。
即ち、ネットワーク５０は、外部ツール６３がコネクタ６１により接続される最上位の通信線５１と、それよりも１つ下位で別系統の２つの通信線５２，５３と、その各通信線５２，５３よりも１つ下位の２つの通信線５４，５５とからなっている。

そして、通信線５１には、ＥＣＵ１，２とＥＣＵ１０，２０が接続され、通信線５２には、ＥＣＵ３とＥＣＵ１０，３０が接続され、通信線５３には、ＥＣＵ６とＥＣＵ２０，４０が接続され、通信線５４には、ＥＣＵ４，５とＥＣＵ３０が接続され、通信線５５には、ＥＣＵ７，８とＥＣＵ４０が接続されている。

そして更に、ＥＣＵ１０が、通信線５１と通信線５２との間で通信データを中継するゲートウェイとして機能し、ＥＣＵ２０が、通信線５１と通信線５３との間で通信データを中継するゲートウェイとして機能し、ＥＣＵ３０が、通信線５２と通信線５４との間で通信データを中継するゲートウェイとして機能し、ＥＣＵ４０が、通信線５３と通信線５５との間で通信データを中継するゲートウェイとして機能するようになっている。

また、ＥＣＵ２０とＥＣＵ３０は、ゲートウェイ専用のＥＣＵであるが、ＥＣＵ１０とＥＣＵ４０は、ＥＣＵ１〜８と同様に、車両に関する制御も実施する。尚、以下の説明において、ゲートウェイとして機能するＥＣＵ１０〜４０と、ゲートウェイとして機能しないＥＣＵ１〜８とを特に区別する場合には、前者をゲートウェイＥＣＵといい、後者を非ゲートウェイＥＣＵという。

そして、本第４実施形態においても、図６に示すように、ＥＣＵ１〜８，１０〜４０の各々には、そのＥＣＵの符号と同じ値のＵＩＤが設定されている。
また、ＥＣＵ１にはＦＩＤ＝１の機能が、ＥＣＵ２にはＦＩＤ＝２の機能が、ＥＣＵ３にはＦＩＤ＝３の機能が、ＥＣＵ４にはＦＩＤ＝２の機能が、ＥＣＵ５にはＦＩＤ＝１の機能とＦＩＤ＝２の機能が、ＥＣＵ６にはＦＩＤ＝６の機能が、ＥＣＵ７にはＦＩＤ＝１の機能が、ＥＣＵ８にはＦＩＤ＝８の機能が、ＥＣＵ１０にはＦＩＤ＝１１の機能が、ＥＣＵ４０にはＦＩＤ＝１３の機能が、それぞれ実装されている。そして、各ＥＣＵには、そのＥＣＵに実装されている機能のＦＩＤと、そのＥＣＵのＵＩＤとが記憶されている。

更に、本第４実施形態において、各ＥＣＵは、図５（２），（３）で説明した動作に加えて、下記（Ａ）〜（Ｄ）の動作を行う。
（Ａ）まず、最上位の通信線５１よりも下位の通信線５２〜５５に接続された非ゲートウェイＥＣＵ３〜８は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイＥＣＵ（即ち、その両通信線を中継するゲートウェイＥＣＵ）へ、自装置に実装されている機能のＦＩＤを通知する。

尚、本第４実施形態及び後述する他の実施形態において、各ＥＣＵへは、車両のイグニッションスイッチがオンされると電源供給が開始されるが、例えば、車両のイグニッションキーシリンダにキーが挿入されて、そのイグニッションキーシリンダに設けられたキースイッチがオンされると、各ＥＣＵへの電源供給が開始される構成も考えられる。

（Ｂ）また、ゲートウェイＥＣＵ１０，２０以外のゲートウェイＥＣＵ３０，４０は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されているＥＣＵ（ゲートウェイＥＣＵも含む）から通知されるＦＩＤを受信して、その受信したＦＩＤを記録した機能リストＬ３０，Ｌ４０を作成すると共に、その作成した機能リストＬ３０，Ｌ４０に記録されたＦＩＤと自装置の機能を示すＦＩＤとを、自装置よりも１つ上位のゲートウェイＥＣＵへ通知する。

このため、ある非ゲートウェイＥＣＵから、あるゲートウェイＥＣＵへ通知されたＦＩＤは、そのゲートウェイＥＣＵにて機能リストを作成するために用いられ、また、あるゲートウェイＥＣＵから、それよりも１つ上位のゲートウェイＥＣＵへ通知されたＦＩＤは、その上位のゲートウェイＥＣＵにて、機能リストを作成するために用いられることとなる。

（Ｃ）そして、最上位の通信線５１に接続されたゲートウェイＥＣＵ１０，２０は、電源供給が開始されると、自装置の接続された通信線のうち、下位側の通信線に接続されているＥＣＵ（ゲートウェイＥＣＵも含む）から通知されるＦＩＤを受信して、その受信したＦＩＤを記録した機能リストＬ１０，Ｌ２０を作成する。

（Ｄ）そして更に、各ゲートウェイＥＣＵ１０〜４０は、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれているＦＩＤが、自装置で作成した機能リストＬ１０〜Ｌ４０に記録されている場合にのみ、その機能問い合わせ要求メッセージの中継を実施する。

尚、ゲートウェイＥＣＵ１０〜４０も、非ゲートウェイＥＣＵ１〜８と同様に、図５（２），（３）で説明した動作を行う。つまり、ゲートウェイＥＣＵ１０〜４０も、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれているＦＩＤに該当する機能が自装置に実装されているか否かを判定し、その機能が実装されているならば、自装置のＵＩＤを含んだ機能問い合わせ応答メッセージを外部ツール６３に送信する。

また、本第４実施形態において、各ＥＣＵへの電源供給開始時にゲートウェイＥＣＵへ下位側のＥＣＵがＦＩＤを通知するためのメッセージ（即ち、ゲートウェイＥＣＵにて機能リストを作成するために、そのゲートウェイＥＣＵへ他のＥＣＵから送信されるメッセージ）のヘッダ領域には、そのメッセージが機能リスト作成用の通信メッセージであることを示す識別情報が含まれている。これは、ゲートウェイＥＣＵが、機能リスト作成用の通信メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようにするためである。

次に、上記（Ａ）〜（Ｄ）の動作を、図６の例で具体的に説明する。
車両のイグニッションスイッチがオンされて各ＥＣＵへの電源供給が開始されると、上記（Ａ）の動作により、非ゲートウェイＥＣＵ４，５の各々はゲートウェイＥＣＵ３０へ自装置の機能のＦＩＤ（＝０１，０２）を通知し、非ゲートウェイＥＣＵ３はゲートウェイＥＣＵ１０へ自装置の機能のＦＩＤ（＝０３）を通知し、非ゲートウェイＥＣＵ７，８の各々はゲートウェイＥＣＵ４０へ自装置の機能のＦＩＤ（＝０１，０８）を通知し、非ゲートウェイＥＣＵ６はゲートウェイＥＣＵ２０へ自装置の機能のＦＩＤ（＝０６）を通知する。

そして、上記（Ｂ）の動作により、ゲートウェイＥＣＵ３０は、下位側の通信線５４に
接続されているＥＣＵ４，５から通知されるＦＩＤを受信して、機能リストＬ３０を作成するが、このゲートウェイＥＣＵ３０には車両の制御に関する機能がないため、作成した機能リストＬ３０に記録されたＦＩＤ（＝０１，０２）のみを、１つ上位のゲートウェイＥＣＵ１０へ通知する。

また、上記（Ｂ）の動作により、ゲートウェイＥＣＵ４０は、下位側の通信線５５に接続されているＥＣＵ７，８から通知されるＦＩＤを受信して、機能リストＬ４０を作成すると共に、その作成した機能リストＬ４０に記録されたＦＩＤ（＝０１，０８）と自装置の機能を示すＦＩＤ（＝１３）とを、１つ上位のゲートウェイＥＣＵ２０へ通知する。

そして、上記（Ｃ）の動作により、ゲートウェイＥＣＵ１０は、下位側の通信線５２に接続されているＥＣＵ３，３０から通知されるＦＩＤを受信して、ＦＩＤ＝０１，０２，０３からなる機能リストＬ１０を作成することとなる。

また、上記（Ｃ）の動作により、ゲートウェイＥＣＵ２０は、下位側の通信線５３に接続されているＥＣＵ６，４０から通知されるＦＩＤを受信して、ＦＩＤ＝０１，０６，０８，１３からなる機能リストＬ２０を作成することとなる。

その後、例えば、外部ツール６３が、図５（１）で説明した動作により、ネットワーク５０に接続された各ＥＣＵへ、ＦＩＤとして「０２」を含んだ機能問い合わせ要求メッセージを送信したとする。

すると、この場合、ゲートウェイＥＣＵ１０，３０の各々で作成された機能リストＬ１０，Ｌ３０には、ＦＩＤ＝０２が記録されているため、そのゲートウェイＥＣＵ１０，３０の各々は、上記（Ｄ）の動作により、図６における二点鎖線の矢印で示すように、外部ツール６３からの機能問い合わせ要求メッセージを下位側の通信線に中継することとなる。

また、ゲートウェイＥＣＵ２０，４０の各々で作成された機能リストＬ２０，Ｌ４０には、ＦＩＤ＝０２が記録されていない。このため、上位のゲートウェイＥＣＵ２０は、上記（Ｄ）の動作により、外部ツール６３からの機能問い合わせ要求メッセージを下位側の通信線に中継しないこととなる。このため、外部ツール６３がＦＩＤとして「０２」を含んだ機能問い合わせ要求メッセージを送信すると、その機能問い合わせ要求メッセージは、通信線５３，５５には中継されない。

そして、この場合、外部ツール６３からの機能問い合わせ要求メッセージに対しては、ＥＣＵ２，４，５の各々が自装置のＵＩＤを含んだ機能問い合わせ応答メッセージを送信することとなるが、図６における点線の矢印で示すように、ＥＣＵ２からの機能問い合わせ応答メッセージは、通信線５１のみを経由して外部ツール６３に受信され、ＥＣＵ４とＥＣＵ５からの機能問い合わせ応答メッセージは、通信線５４、ゲートウェイＥＣＵ３０、通信線５２、ゲートウェイＥＣＵ１０、及び通信線５１を経由して、外部ツール６３に受信されることとなる。

以上のような第４実施形態の車両通信システムによれば、目的の機能が実装されていないＥＣＵだけからなる下位の部分ネットワーク（図６の例では、通信線５３，５５からなるネットワーク）へは、外部ツール６３からの機能問い合わせ要求メッセージが中継されなくなり、ネットワーク５０の通信負荷と各ＥＣＵの通信処理負荷を抑制することができる。更に、ネットワーク５０の通信負荷が低減されることから、目的の機能が実装されているＥＣＵから外部ツール６３への機能問い合わせ応答メッセージの応答時間（延いては、外部ツール６３にて目的の機能が実装されたＥＣＵを特定できるまでの時間であり、具
体的には、図５（４）で説明した動作によりＵＩＤのリストを作成できるまでの時間）も短縮することができる。
［第５実施形態］
次に、第５実施形態の車両通信システムについて、図７を用いて説明する。

第５実施形態の車両通信システムは、第４実施形態の車両通信システムと比較すると、図７に示すように、ハードウェア構成は同じであるが、各ＥＣＵが、前述した（Ａ）〜（Ｄ）の動作に代えて、下記の（ａ）〜（ｄ）の動作を行う点が異なっている。

（ａ）まず、最上位の通信線５１よりも下位の通信線５２〜５５に接続された非ゲートウェイＥＣＵ３〜８は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイＥＣＵ（即ち、その両通信線を中継するゲートウェイＥＣＵ）へ、自装置に実装されている機能のＦＩＤ及び自装置のＵＩＤを、データテーブル作成用情報として通知する。

（ｂ）また、ゲートウェイＥＣＵ１０，２０以外のゲートウェイＥＣＵ３０，４０は、電源供給が開始されると、自装置の接続された通信線のうち、下位側の通信線に接続されているＥＣＵ（ゲートウェイＥＣＵも含む）から通知されるデータテーブル作成用情報を受信して、その受信したデータテーブル作成用情報を用い、更に自装置に実装されている機能があれば該機能のＦＩＤ及び自装置のＵＩＤも用いて、ＦＩＤ−ＵＩＤテーブル（即ち、ＦＩＤとそのＦＩＤが示す機能が実装されたＥＣＵのＵＩＤとを対応させて記録したデータテーブル）Ｔ３０，Ｔ４０を作成すると共に、その作成したＦＩＤ−ＵＩＤテーブルＴ３０，Ｔ４０を表す情報（詳しくは、そのＦＩＤ−ＵＩＤテーブルＴ３０，Ｔ４０を構成する各ＦＩＤとＵＩＤとの組み合わせの情報）を、自装置よりも１つ上位のゲートウェイＥＣＵへデータテーブル作成用情報として通知する。

（ｃ）そして、最上位の通信線５１に接続されたゲートウェイＥＣＵ１０，２０は、電源供給が開始されると、自装置の接続された通信線のうち、下位側の通信線に接続されているＥＣＵ（ゲートウェイＥＣＵも含む）から通知されるデータテーブル作成用情報を受信して、その受信したデータテーブル作成用情報を用い、更に自装置に実装されている機能があれば該機能のＦＩＤ及び自装置のＵＩＤも用いて、ＦＩＤ−ＵＩＤテーブルＴ１０，Ｔ２０を作成する。

（ｄ）そして更に、ゲートウェイＥＣＵ１０，２０は、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれているＦＩＤが、自装置で作成したＦＩＤ−ＵＩＤテーブル（以下、自装置のＦＩＤ−ＵＩＤテーブルという）に記録されているか否かを判定して、そのＦＩＤが記録されているならば、そのＦＩＤに対応して自装置のＦＩＤ−ＵＩＤテーブルに記録されているＵＩＤを検索し、その検索したＵＩＤ含んだ機能問い合わせ応答メッセージを、外部ツール６３に送信する。

尚、本第５実施形態において、各ＥＣＵへの電源供給開始時にゲートウェイＥＣＵへ下位側のＥＣＵがデータテーブル作成用情報を通知するためのメッセージ（即ち、ゲートウェイＥＣＵにてＦＩＤ−ＵＩＤテーブルを作成するために、そのゲートウェイＥＣＵへ他のＥＣＵから送信されるメッセージ）のヘッダ領域には、そのメッセージがＦＩＤ−ＵＩＤテーブル作成用の通信メッセージであることを示す識別情報が含まれている。これは、ゲートウェイＥＣＵが、ＦＩＤ−ＵＩＤテーブル作成用の通信メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようにするためである。

次に、上記（ａ）〜（ｄ）の動作を、図７の例で具体的に説明する。
車両のイグニッションスイッチがオンされて各ＥＣＵへの電源供給が開始されると、上記（ａ）の動作により、非ゲートウェイＥＣＵ４，５の各々はゲートウェイＥＣＵ３０へ自装置の機能のＦＩＤ及び自装置のＵＩＤを通知し、非ゲートウェイＥＣＵ３はゲートウェイＥＣＵ１０へ自装置の機能のＦＩＤ及び自装置のＵＩＤを通知し、非ゲートウェイＥＣＵ７，８の各々はゲートウェイＥＣＵ４０へ自装置の機能のＦＩＤ及び自装置のＵＩＤを通知し、非ゲートウェイＥＣＵ６はゲートウェイＥＣＵ２０へ自装置の機能のＦＩＤ及び自装置のＵＩＤを通知する。

そして、上記（ｂ）の動作により、ゲートウェイＥＣＵ３０は、車両の制御に関する機能がないため、下位側の通信線５４に接続されているＥＣＵ４，５から通知されるＦＩＤ及びＵＩＤのみを用いて、図７に示すようなＦＩＤ−ＵＩＤテーブルＴ３０を作成し、その作成したＦＩＤ−ＵＩＤテーブルＴ３０を表す情報を、１つ上位のゲートウェイＥＣＵ１０へ通知する。

また、上記（ｂ）の動作により、ゲートウェイＥＣＵ４０は、下位側の通信線５５に接続されているＥＣＵ７，８から通知されるＦＩＤ及びＵＩＤと、自装置のＦＩＤ及びＵＩＤとから、図７に示すようなＦＩＤ−ＵＩＤテーブルＴ４０を作成し、その作成したＦＩＤ−ＵＩＤテーブルＴ４０を表す情報を、１つ上位のゲートウェイＥＣＵ２０へ通知する。

そして、上記（ｃ）の動作により、ゲートウェイＥＣＵ１０は、下位側の通信線５２に接続されているＥＣＵ３，３０から通知されるＦＩＤ及びＵＩＤと、自装置のＦＩＤ及びＵＩＤとから、図７に示すようなＦＩＤ−ＵＩＤテーブルＴ１０を作成することとなる。

また、上記（ｃ）の動作により、ゲートウェイＥＣＵ２０は、車両の制御に関する機能がないため、下位側の通信線５３に接続されているＥＣＵ６，４０から通知されるＦＩＤ及びＵＩＤのみを用いて、図７に示すようなＦＩＤ−ＵＩＤテーブルＴ２０を作成することとなる。

その後、例えば、外部ツール６３が、図５（１）で説明した動作により、各ＥＣＵへ、ＦＩＤ＝０２を含んだ機能問い合わせ要求メッセージを送信したとする。
すると、この場合、ゲートウェイＥＣＵ１０で作成されたＦＩＤ−ＵＩＤテーブルＴ１０には、ＦＩＤ＝０２が記録されているため、ゲートウェイＥＣＵ１０は、そのＦＩＤ＝０２に対応してＦＩＤ−ＵＩＤテーブルＴ１０に記録されているＵＩＤを検索し、その検索したＵＩＤ（この例では、ＵＩＤ＝０４とＵＩＤ＝０５）含んだ機能問い合わせ応答メッセージを、外部ツール６３に送信する。

一方、ゲートウェイＥＣＵ２０で作成されたＦＩＤ−ＵＩＤテーブルＴ２０には、ＦＩＤ＝０２が記録されていないため、ゲートウェイＥＣＵ２０は、外部ツール６３に機能問い合わせ応答メッセージを送信しない。

尚、図７の例では、外部ツール６３からのＦＩＤ＝０２を含んだ機能問い合わせ要求メッセージに対して、最上位の通信線５１に接続されたＥＣＵ２も、図５（２），（３）で説明した動作により、自装置のＵＩＤ（＝０２）を含んだ機能問い合わせ応答メッセージを、外部ツール６３へ送信することとなる。

また、本第５実施形態において、外部ツール６３からの機能問い合わせ要求メッセージは、通信線５１よりも下位の通信線５２〜５５に中継する必要がないため、ゲートウェイ
ＥＣＵ１０，２０の各々は、外部ツール６３からの機能問い合わせ要求メッセージを通信線５２，５３に中継しない。

よって、図７の例では、二点差線の矢印で示すように、外部ツール６３からＦＩＤ＝０２を含んだ機能問い合わせ要求メッセージが送信されると、点線の矢印で示すように、ＥＣＵ２とゲートウェイＥＣＵ１０が、外部ツール６３へ機能問い合わせ応答メッセージを送信することとなる。そして、外部ツール６３は、図５（４）に示したように、ＥＣＵ２，１０からの機能問い合わせ応答メッセージを全て受信して、その機能問い合わせ応答メッセージに含まれているＵＩＤのリストを作成することとなる。尚、この例で作成されるリストは、ＦＩＤ＝０２の機能が実装されたＥＣＵ２，４，５のＵＩＤ（＝０２，０４，０５）を列挙したものとなる。

以上のような第５実施形態の車両通信システムによれば、故障診断対象である目的の機能が搭載されたＥＣＵのうち、下位の通信線５２〜５５に接続されたＥＣＵの代わりに、最上位の通信線５１に接続されたゲートウェイＥＣＵ１０，２０の両方又は一方が、外部ツール６３からの機能問い合わせ要求メッセージに対して応答することとなる。つまり、下位の通信線５２〜５５に接続されたＥＣＵは、外部ツール６３からの能問い合わせ要求メッセージに応答しなくても良い。

よって、ネットワーク５０の通信負荷と各ＥＣＵの通信処理負荷を一層抑制することができる。更に、外部ツール６３が機能問い合わせ要求メッセージを送信してから、それに対する機能問い合わせ応答メッセージを受け取るまでの応答時間（延いては、外部ツール６３にて目的の機能が実装されたＥＣＵを特定できるまでの時間）を一層短縮することができる。
［第６実施形態］
次に、第６実施形態の車両通信システムについて、図８を用いて説明する。

第６実施形態の車両通信システムは、第５実施形態の車両通信システムと比較すると、下記の２点が異なっている。
まず、第１の相違点として、図８に示すように、ＥＣＵ９が追加されており、そのＥＣＵ９は最上位の通信線５１に接続されている。そして、そのＥＣＵ９には、ＦＩＤ＝０９の機能が実装されていると共に、その機能のＦＩＤ（＝０９）と、そのＥＣＵ９のＵＩＤ（＝０９）とが記憶されている。尚、ＥＣＵ９は、請求項１５における特定の制御装置に相当するものであり、以下の説明では、マスタＥＣＵ９と言う。

次に、第２の相違点として、外部ツール６３は、図８における二点鎖線で示すように、目的の機能のＦＩＤを含んだ機能問い合わせ要求メッセージを、マスタＥＣＵ９だけに送信する。尚、本実施形態では、この外部ツール６３の動作が、請求項１５に記載の特定手段の動作に相当している。

そして、マスタＥＣＵ９は、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージを他の各ＥＣＵへ送信すると共に、その機能問い合わせ要求メッセージに対して他のＥＣＵから返送されてくる機能問い合わせ応答メッセージを受信して、その機能問い合わせ応答メッセージを、図８における点線で示すように、外部ツール６３へ送信する。

このため、例えば、外部ツール６３からマスタＥＣＵ９へ、ＦＩＤ＝０２を含んだ機能問い合わせ要求メッセージが送信された場合には、その機能問い合わせ要求メッセージが、マスタＥＣＵ９から通信線５１に接続された各ＥＣＵ１，２，１０，２０へ送信される
。すると、図７で説明した例と同様に、ＥＣＵ２，１０の各々がマスタＥＣＵ９へ機能問い合わせ応答メッセージを送信することとなる。そして、マスタＥＣＵ９は、ＥＣＵ２，１０からの機能問い合わせ応答メッセージを受信して、その機能問い合わせ応答メッセージを外部ツール６３へ送信することとなる。

つまり、本第６実施形態の車両通信システムでは、マスタＥＣＵ９が、外部ツール６３からの機能問い合わせ要求メッセージを他のＥＣＵに中継すると共に、他のＥＣＵから返送されてくる機能問い合わせ応答メッセージを外部ツール６３に中継するようになっている。

よって、この車両通信システムによれば、外部ツール６３は、目的の機能が搭載されたＥＣＵを特定するために、マスタＥＣＵ９とだけ通信すれば良いため、その外部ツール６３の通信処理負荷を軽減することができる。また、マスタＥＣＵ９はＦＩＤ−ＵＩＤテーブルを持つ必要がないため、そのマスタＥＣＵ９におけるデータ記憶用のリソースを増大させてしまうこともない。

尚、本第６実施形態において、マスタＥＣＵ９は、他のＥＣＵと同様に、図５（２），（３）で説明した動作も行う。つまり、もし、外部ツール６３からＦＩＤ＝０９を含んだ機能問い合わせ要求メッセージが送信されたならば、マスタＥＣＵ９は、その機能問い合わせ要求メッセージを、通信線５１に接続された各ＥＣＵ１，２，１０，２０へ送信するだけでなく、自装置のＵＩＤ（＝０９）を含んだ機能問い合わせ応答メッセージを、外部ツール６３に送信することとなる。
［第７実施形態］
次に、第７実施形態の車両通信システムは、第１実施形態の車両通信システムと比較すると、ハードウェア構成は同じであるが、外部ツール６３が、特定のＥＣＵと通信することで、目的の機能が実装されているＥＣＵ（即ち、故障診断用の要求メッセージを送信すべきＥＣＵ）を特定する点が異なっている。

尚、本第７実施形態においても、外部ツール６３は、メモリカード６５が着脱可能となっている必要はなく、それ以外のハードウェア構成については、第１実施形態（図１）と同じである。そして、各ＥＣＵには、そのＥＣＵのＵＩＤと、そのＥＣＵに実装されている機能のＦＩＤとが記憶されている。また、本第７実施形態では、ネットワーク５０で接続されたＥＣＵのうちの１つ（ここでは、例えばＥＣＵ７とする）が、上記特定のＥＣＵとしてのマスタＥＣＵとなっている。

そこで、第７実施形態の車両通信システムについて、図９を用いて説明する。尚、図９は、外部ツール６３と各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。
まず、ネットワーク５０で接続されたＥＣＵのうち、マスタＥＣＵ７及びゲートウェイＥＣＵ１０以外の各ＥＣＵ１〜６は、電源供給が開始されると、図９（１）に示すように、マスタＥＣＵ７へ、自装置に実装されている機能のＦＩＤ及び自装置のＵＩＤを通知する。具体的には、通知すべきＦＩＤとＵＩＤとを含んだ機能登録通知メッセージを、マスタＥＣＵ７に送信する。

また、図９（２）に示すように、マスタＥＣＵ７は、電源供給が開始されると、他のＥＣＵの各々から送信されてくる上記機能登録通知メッセージを受信し、その機能登録通知メッセージに含まれているＦＩＤ及びＵＩＤに基づいて、図３に示したようなＦＩＤ−ＵＩＤテーブルを作成する。

尚、この例において、ＥＣＵ１０は、ゲートウェイ専用のＥＣＵであるため、機能登録
通知メッセージを送信しないが、そのＥＣＵ１０にＦＩＤが記憶されているならば（つまり、そのＥＣＵ１０が車両の制御に関する機能を有しているならば）、そのＥＣＵ１０もマスタＥＣＵ７へ機能登録通知メッセージを送信することとなる。

また、本第７実施形態において、各ＥＣＵへの電源供給開始時にマスタＥＣＵ７へ他のＥＣＵが送信する機能登録通知メッセージ（即ち、マスタＥＣＵ７にてＦＩＤ−ＵＩＤテーブルを作成するために、そのマスタＥＣＵ７へ他のＥＣＵから送信されるメッセージ）のヘッダ領域には、そのメッセージが機能登録通知メッセージであることを示す識別情報が含まれている。これは、マスタＥＣＵ７が、機能登録通知メッセージと通常の通信メッセージとを、確実且つ簡単に区別することができるようにするためである。

そして、その後、外部ツール６３は、作業者により、故障診断対象である目的の機能のＦＩＤと、実施する故障診断の内容とが入力されると、図９（３）に示すように、マスタＥＣＵ７へ、目的の機能のＦＩＤ（図９の例ではＦＩＤ＝３）を含んだ機能問い合わせ要求メッセージを送信する。

また、マスタＥＣＵ７は、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、図９（４）に示すように、その機能問い合わせ要求メッセージに含まれているＦＩＤの機能が実装されているＥＣＵのＵＩＤを、図９（２）の動作で作成したＦＩＤ−ＵＩＤテーブルから検索して取得し、図９（５）に示すように、その取得したＵＩＤを含む機能問い合わせ応答メッセージを、外部ツール６３に送信する。

尚、図９の例では、外部ツール６３からマスタＥＣＵ７へ、ＦＩＤ＝０３を含んだ機能問い合わせ要求メッセージが送信されているため、マスタＥＣＵ７から外部ツール６３へは、ＦＩＤ＝０３の機能が実装されているＥＣＵ４のＵＩＤ（＝０４）を含んだ機能問い合わせ応答メッセージが送信されることとなる。

そして、外部ツール６３は、図９（６）に示すように、マスタＥＣＵ７からの機能問い合わせ応答メッセージを受信して、その機能問い合わせ応答メッセージに含まれているＵＩＤのリストを作成する。つまり、ここで作成されるリストは、第１実施形態で説明した図２のＳ１３０で作成されるリストと同じ意味のものであり、目的の機能が実装されたＥＣＵのＵＩＤを列挙したものとなる。

そして、図９（７）に示すように、外部ツール６３は、第１実施形態で説明した図２のＳ１４０，Ｓ１５０と同様の処理を実行して、図９（６）の動作で作成したリスト中の各ＵＩＤに該当するＥＣＵへ、故障診断用の要求メッセージを送信する。

尚、図９の例では、外部ツール６３からＥＣＵ４へ、故障診断用の要求メッセージとして、アクチュエータを強制的に駆動させるためのアクチュエータ駆動要求メッセージが送信される場合を例示している。よって、図９の例では、ＥＣＵ４が、外部ツール６３からのアクチュエータ駆動要求メッセージによって指示されるアクチュエータを駆動することとなり、作業者は、そのアクチュエータに関連する機器の動作状態によって、正常／異常の判断をすることとなる。

以上のような第７実施形態の車両通信システムによれば、第３実施形態の車両通信システムと同様に、外部ツール６３にてＦＩＤ−ＵＩＤテーブルを保持したり作成したりする必要がないため、外部ツール６３の必要メモリ容量と処理負荷を低減することができる。また、外部ツール６３は、目的の機能が搭載されたＥＣＵを特定するために、マスタＥＣＵ７とだけ通信すれば良いため、その外部ツール６３の通信処理負荷を軽減することができる。

尚、本第７実施形態では、外部ツール６３の動作のうち、図９（３），（６）の動作が、特定手段に相当している。
一方、マスタＥＣＵ７は、各ＥＣＵへの電源供給開始時ではなく、例えば、外部ツール６３からの機能問い合わせ要求メッセージを受信した際に、ＦＩＤ−ＵＩＤテーブルを作成するように構成することもできる。具体的に説明すると、マスタＥＣＵ７は、外部ツール６３からの機能問い合わせ要求メッセージを受信すると、他の各ＥＣＵへ、そのＥＣＵに実装されている機能を問い合わせる機能確認要求メッセージを送信し、そのメッセージに対して各ＥＣＵが返送するメッセージであって、そのＥＣＵに実装されている機能のＦＩＤとそのＥＣＵのＵＩＤとを含んだメッセージに基づいてＦＩＤ−ＵＩＤテーブルを作成する、というように構成することもできる。

但し、図９に示したように、各ＥＣＵへの電源供給開始時にマスタＥＣＵ７がＦＩＤ−ＵＩＤテーブルを作成するように構成した方が、外部ツール６３が機能問い合わせ要求メッセージに対する応答としての機能問い合わせ応答メッセージを受け取るまでの時間を短縮することができ、有利である。
［第８実施形態］
次に、第８実施形態の車両通信システムは、第１実施形態の車両通信システムと比較すると、ハードウェア構成は同じであるが、外部ツール６３とＥＣＵとの通信のやり方が異なっている。尚、本第８実施形態においても、外部ツール６３は、メモリカード６５が着脱可能となっている必要はない。

そこで、第８実施形態の車両通信システムについて、図１０を用いて説明する。尚、図１０は、外部ツール６３と各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。
まず、外部ツール６３は、作業者により、故障診断対象である目的の機能のＦＩＤと、実施する故障診断の内容とが入力されると、図１０（１），（４）の各々に示すように、その目的の機能のＦＩＤが含まれると共に、作業者により入力された故障診断の内容に応じた故障診断用処理の実施を指示する要求メッセージ（故障診断用の要求メッセージ）を、ネットワーク５０中の各ＥＣＵ１〜７，１０に送信する。尚、第１実施形態でも述べたが、外部ツール６３の構成としては、目的の機能のＦＩＤが入力されなくても、故障診断の内容が入力されると、その内容から目的の機能のＦＩＤを自動的に判別する構成でも良い。

そして、各ＥＣＵ１〜７，１０は、図１０（２），（５）の各々に示すように、外部ツール６３からの故障診断用の要求メッセージを受信すると、その要求メッセージに含まれているＦＩＤに該当する機能（即ち、外部ツール６３によって指定された機能）が自装置に実装されているか否かを判定し、その機能が実装されているならば、図１０（３），（６）の各々に示すように、外部ツール６３からの故障診断用の要求メッセージが示す処理を実施する。

尚、図１０（１）の例では、外部ツール６３から各ＥＣＵへ、故障診断用の要求メッセージとして、ＦＩＤ＝０１を含むデータ取得要求メッセージが送信されている。このため、図１０（３）では、ＦＩＤ＝０１の機能を有したＥＣＵ１とＥＣＵ２との各々が、外部ツール６３からのデータ取得要求メッセージにより指定される制御データ（即ち、要求されたデータ）を含んだデータ取得応答メッセージを、外部ツール６３へ送信することとなる。また、図１０（３）の例では、外部ツール６３から各ＥＣＵへ、故障診断用の要求メッセージとして、ＦＩＤ＝０２を含むアクチュエータ駆動要求メッセージが送信されている。このため、図１０（６）では、ＦＩＤ＝０２の機能を有したＥＣＵ２が、外部ツール
６３からのアクチュエータ駆動要求メッセージにより指示されるアクチュエータを駆動することとなる。

そして、このような第８実施形態の車両通信システムによっても、車両の故障診断を行う作業者は、どの機能がどのＥＣＵに実装されているかを把握していなくても、目的の機能の故障診断を実施することができるようになる。

以上、本発明の一実施形態について説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々なる態様で実施し得ることは勿論である。

例えば、図６〜図８に示した第４〜第６実施形態の車両通信システムにおいて、車両内のネットワーク５０は４階層以上のネットワークであっても良い。
また、上記各実施形態では、外部ツール６３と車両側のネットワーク５０との接続が、コネクタ６１による有線接続であったが、外部ツール６３とネットワーク５０との接続は、無線接続であっても良い。具体的には、車両側に、外部ツール６３と無線通信を行って、その外部ツール６３とネットワーク５０との間での通信データの中継を行う無線通信制御用の装置を設ければ良く、また、その装置の機能は、既存のゲートウェイＥＣＵ又は非ゲートウェイＥＣＵに実装するようにしても良い。

第１実施形態の車両通信システムを表す構成図である。 第１実施形態の外部ツールが実行するアクセス制御処理を表すフローチャートである。 ＦＩＤ−ＵＩＤテーブルの説明図である。 第２実施形態の外部ツールと各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。 第３実施形態の外部ツールと各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。 第４実施形態の車両通信システムを説明する説明図である。 第５実施形態の車両通信システムを説明する説明図である。 第６実施形態の車両通信システムを説明する説明図である。 第７実施形態の外部ツールと各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。 第８実施形態の外部ツールと各ＥＣＵとの通信及び動作の流れを表すシーケンス図である。

符号の説明

１〜９，１０〜４０…ＥＣＵ（電子制御装置）、５０…ネットワーク、５１〜５５…通信線、６１…コネクタ、６３…外部ツール（故障診断装置）、６５…メモリカード、Ｌ１０〜Ｌ４０…機能リスト、Ｔ１０〜Ｔ４０…ＦＩＤ−ＵＩＤテーブル

Claims (19)

1. 車両に搭載された複数の制御装置が前記車両内の通信用のネットワークによって接続されると共に、前記車両外の故障診断装置が前記ネットワークに有線又は無線にて通信可能に接続され、その故障診断装置が前記各制御装置と故障診断用の通信を行う車両通信システムであって、
   前記故障診断装置は、前記複数の制御装置のうち、故障診断対象である目的の機能が実装された制御装置を特定する特定手段を備えており、その特定手段により特定された制御装置に対して、前記目的の機能の故障診断を行うための要求メッセージを送信するようになっており、
   前記故障診断装置は、前記複数の各制御装置へ、その制御装置に実装されている機能を問い合わせる機能確認要求メッセージを送信し、
   前記各制御装置は、前記機能確認要求メッセージを受信すると、自装置に実装されている機能を示す機能識別情報及び自装置を示す装置識別情報を含んだ機能確認応答メッセージを、前記故障診断装置に送信し、
   前記故障診断装置は、前記各制御装置からの前記機能確認応答メッセージに基づいて、どの機能が前記複数の制御装置の何れに実装されているかを示すデータテーブルを作成し、
   前記特定手段は、前記データテーブルに基づいて、前記目的の機能が実装された制御装置を特定し、
   しかも、前記故障診断装置は、前記機能確認要求メッセージの送信を実施する前に、前記ネットワークに接続された全ての制御装置へ、通信可能であるか否かを確認するための通信確認要求メッセージを送信し、その通信確認要求メッセージに対して規定時間以内に応答があった制御装置へ、前記機能確認要求メッセージを送信すること、
   を特徴とする車両通信システム。
2. 車両に搭載された複数の制御装置が前記車両内の通信用のネットワークによって接続されると共に、前記車両外の故障診断装置が前記ネットワークに有線又は無線にて通信可能に接続され、その故障診断装置が前記各制御装置と故障診断用の通信を行う車両通信システムであって、
   前記故障診断装置は、前記複数の制御装置のうち、故障診断対象である目的の機能が実装された制御装置を特定する特定手段を備えており、その特定手段により特定された制御装置に対して、前記目的の機能の故障診断を行うための要求メッセージを送信するようになっており、
   前記特定手段は、前記複数の各制御装置へ、前記目的の機能を示す機能識別情報を含んだ機能問い合わせ要求メッセージを送信し、
   前記各制御装置は、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報に該当する機能が自装置に実装されているか否かを判定して、その機能が実装されているならば、自装置を示す装置識別情報を含んだ機能問い合わせ応答メッセージを前記故障診断装置に送信し、
   更に、前記特定手段は、前記制御装置から送信されてきた前記機能問い合わせ応答メッセージ内の装置識別情報に該当する制御装置を、前記目的の機能が実装された制御装置であると特定すること、
   を特徴とする車両通信システム。
3. 請求項２に記載の車両通信システムにおいて、
   前記ネットワークは、前記故障診断装置の接続される通信線が最上位通信線であると共に、上位の通信線と下位の通信線とがゲートウェイを介して接続される階層構造のネットワークであり、
   前記複数の制御装置のうちの何れかが、前記ゲートウェイとして機能するゲートウェイ制御装置であり、
   更に、前記ゲートウェイ制御装置は、自装置よりも下位側の制御装置から、その下位側の制御装置に実装されている機能の機能識別情報を通信により取得すると共に、その取得した機能識別情報を記録した機能リストを作成し、その後、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記作成した機能リストに記録されている場合にのみ、その機能問い合わせ要求メッセージの中継を実施すること、
   を特徴とする車両通信システム。
4. 請求項３に記載の車両通信システムにおいて、
   前記ゲートウェイ制御装置にて前記機能リストを作成するために各制御装置間で行われる通信は、前記各制御装置への電源供給が開始された直後に実施されること、
   を特徴とする車両通信システム。
5. 請求項４に記載の車両通信システムにおいて、
   前記ゲートウェイ制御装置ではない制御装置（以下、非ゲートウェイ制御装置という）のうち、前記最上位通信線よりも下位の通信線に接続された非ゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイ制御装置へ、自装置に実装されている機能を示す機能識別情報を通知し、
   前記最上位通信線に接続されたゲートウェイ制御装置以外のゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知される機能識別情報を受信して前記機能リストを作成すると共に、その作成した機能リストに記録された機能識別情報と自装置の機能を示す機能識別情報とを、自装置よりも１つ上位のゲートウェイ制御装置へ通知し、
   前記最上位通信線に接続されたゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知される機能識別情報を受信して前記機能リストを作成すること、
   を特徴とする車両通信システム。
6. 請求項４又は請求項５に記載の車両通信システムにおいて、
   前記各制御装置には、前記車両のイグニッションスイッチがオンされると、電源供給が開始されること、
   を特徴とする車両通信システム。
7. 請求項４又は請求項５に記載の車両通信システムにおいて、
   前記各制御装置には、前記車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされると、電源供給が開始されること、
   を特徴とする車両通信システム。
8. 請求項３ないし請求項７の何れか１項に記載の車両通信システムにおいて、
   前記ゲートウェイ制御装置にて前記機能リストを作成するために、そのゲートウェイ制御装置へ他の制御装置から送信されるメッセージのヘッダ領域には、そのメッセージが機能リスト作成用の通信メッセージであることを示す識別情報が含まれていること、
   を特徴とする車両通信システム。
9. 請求項２に記載の車両通信システムにおいて、
   前記ネットワークは、前記故障診断装置の接続される通信線が最上位通信線であると共に、上位の通信線と下位の通信線とがゲートウェイを介して接続される階層構造のネットワークであり、
   前記複数の制御装置のうちの何れかが、前記ゲートウェイとして機能するゲートウェイ制御装置であり、
   更に、前記ゲートウェイ制御装置は、自装置よりも下位側の制御装置から、その下位側の制御装置に実装されている機能の機能識別情報及びその下位側の制御装置の装置識別情報を通信により取得して、その取得した機能識別情報及び装置識別情報を用い、更に自装置に実装されている機能があれば該機能の機能識別情報及び自装置の装置識別情報も用いて、機能識別情報とその機能識別情報が示す機能が実装された制御装置の装置識別情報とを対応させて記録したデータテーブルを作成し、その後、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記データテーブルに記録されているか否かを判定して、その機能識別情報が記録されているならば、その機能識別情報に対応して前記データテーブルに記録されている装置識別情報を含んだ機能問い合わせ応答メッセージを、前記故障診断装置に送信すること、
   を特徴とする車両通信システム。
10. 請求項９に記載の車両通信システムにおいて、
    前記ゲートウェイ制御装置にて前記データテーブルを作成するために各制御装置間で行われる通信は、前記各制御装置への電源供給が開始された直後に実施されること、
    を特徴とする車両通信システム。
11. 請求項１０に記載の車両通信システムにおいて、
    前記ゲートウェイ制御装置ではない制御装置（以下、非ゲートウェイ制御装置という）のうち、前記最上位通信線よりも下位の通信線に接続された非ゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された通信線と該通信線より１つ上位の通信線との間に設けられたゲートウェイ制御装置へ、自装置に実装されている機能を示す機能識別情報及び自装置の装置識別情報を、データテーブル作成用情報として通知し、
    前記最上位通信線に接続されたゲートウェイ制御装置以外のゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知されるデータテーブル作成用情報を用いて前記データテーブルを作成すると共に、その作成したデータテーブルを表す情報を、自装置よりも１つ上位のゲートウェイ制御装置へデータテーブル作成用情報として通知し、
    前記最上位通信線に接続されたゲートウェイ制御装置は、電源供給が開始されると、自装置の接続された下位側の通信線に接続されている制御装置から通知されるデータテーブル作成用情報を用いて前記データテーブルを作成し、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報が前記データテーブルに記録されているか否かを判定して、その機能識別情報が記録されているならば、その機能識別情報に対応して前記データテーブルに記録されている装置識別情報を含んだ機能問い合わせ応答メッセージを、前記故障診断装置に送信すること、
    を特徴とする車両通信システム。
12. 請求項１０又は請求項１１に記載の車両通信システムにおいて、
    前記各制御装置には、前記車両のイグニッションスイッチがオンされると、電源供給が開始されること、
    を特徴とする車両通信システム。
13. 請求項１０又は請求項１１に記載の車両通信システムにおいて、
    前記各制御装置には、前記車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされると、電源供給が開始されること、
    を特徴とする車両通信システム。
14. 請求項９ないし請求項１３の何れか１項に記載の車両通信システムにおいて、
    前記ゲートウェイ制御装置にて前記データテーブルを作成するために、そのゲートウェイ制御装置へ他の制御装置から送信されるメッセージのヘッダ領域には、そのメッセージがデータテーブル作成用の通信メッセージであることを示す識別情報が含まれていること、
    を特徴とする車両通信システム。
15. 請求項９ないし請求項１４の何れか１項に記載の車両通信システムにおいて、
    前記特定手段は、前記機能問い合わせ要求メッセージを各制御装置へ送信することに代えて、前記機能問い合わせ要求メッセージを前記最上位通信線に接続されている特定の制御装置へ送信し、
    前記特定の制御装置が、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージを他の各制御装置へ送信すると共に、その機能問い合わせ要求メッセージに対して返送されてくる前記機能問い合わせ応答メッセージを受信して、その機能問い合わせ応答メッセージを前記故障診断装置へ送信すること、
    を特徴とする車両通信システム。
16. 車両に搭載された複数の制御装置が前記車両内の通信用のネットワークによって接続されると共に、前記車両外の故障診断装置が前記ネットワークに有線又は無線にて通信可能に接続され、その故障診断装置が前記各制御装置と故障診断用の通信を行う車両通信システムであって、
    前記故障診断装置は、前記複数の制御装置のうち、故障診断対象である目的の機能が実装された制御装置を特定する特定手段を備えており、その特定手段により特定された制御装置に対して、前記目的の機能の故障診断を行うための要求メッセージを送信するようになっており、
    前記複数の制御装置のうちの特定の制御装置が、複数の機能の各々が前記複数の制御装置の何れに実装されているかを示すデータテーブルを有しており、
    前記特定手段は、前記特定の制御装置へ、前記目的の機能を示す機能識別情報を含んだ機能問い合わせ要求メッセージを送信し、
    前記特定の制御装置は、前記機能問い合わせ要求メッセージを受信すると、その機能問い合わせ要求メッセージに含まれている機能識別情報に該当する機能が実装されている制御装置を前記データテーブルから検索して、その検索した制御装置の装置識別情報を含んだ機能問い合わせ応答メッセージを前記故障診断装置に送信し、
    更に、前記特定手段は、前記特定の制御装置から送信されてきた前記機能問い合わせ応答メッセージ内の装置識別情報に該当する制御装置を、前記目的の機能が実装された制御装置であると特定し、
    しかも、前記特定の制御装置以外の制御装置は、電源供給が開始されると、前記特定の制御装置へ、自装置に実装されている機能を示す機能識別情報及び自装置の装置識別情報を通知し、
    前記特定の制御装置は、電源供給が開始されると、他の制御装置から通知される前記機能識別情報及び前記装置識別情報に基づいて前記データテーブルを作成すること、
    を特徴とする車両通信システム。
17. 請求項１６に記載の車両通信システムにおいて、
    前記各制御装置には、前記車両のイグニッションスイッチがオンされると、電源供給が開始されること、
    を特徴とする車両通信システム。
18. 請求項１６に記載の車両通信システムにおいて、
    前記各制御装置には、前記車両のイグニッションキーシリンダにキーが挿入されて該イグニッションキーシリンダに設けられたキースイッチがオンされると、電源供給が開始されること、
    を特徴とする車両通信システム。
19. 請求項１６ないし請求項１８の何れか１項に記載の車両通信システムにおいて、
    前記特定の制御装置にて前記データテーブルを作成するために、その特定の制御装置へ他の制御装置から送信されるメッセージのヘッダ領域には、そのメッセージがデータテーブル作成用の通信メッセージであることを示す識別情報が含まれていること、
    を特徴とする車両通信システム。

Images