(57)【要約】【課題】一意性のあるＩＤを効率的に付与する車載ネットワークを提供すること。【解決手段】複数のノード１００は、各ノードに共通の、複数の識別番号候補の記憶手段２０と、各ノードに固有の固有識別番号３４と、複数の識別番号候補から１つの識別番号候補を決定する番号決定手段３１と、固有識別番号と識別番号候補を管理ノード２００に送信する送信手段３５と、を有し、管理ノードは、複数の識別番号候補の記憶手段２０と、複数のノードから受信した複数の識別番号候補に重複があるか否を判定する重複判定手段２２と、重複すると判定された識別番号候補を送信した複数のノードの固有識別番号を比較した結果に応じて、重複した識別番号候補を識別番号として割り当てるノードを決定するノード決定手段２３と、識別番号候補が重複しないノード又は識別番号が割り当てられたノードに、識別番号の決定通知を送信する結果通知手段２４と、を有する。【選択図】図１
2012222527.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムにおいて、
各ノードは、各ノードに共通の、複数の識別番号候補の第１の記憶手段と、
各ノードに固有の固有識別番号の第２の記憶手段と、
前記複数の識別番号候補から１つの識別番号候補を決定する番号決定手段と、
前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有し、
前記管理ノードは、
前記複数の識別番号候補の記憶手段と、
各ノードからそれぞれ受信した前記識別番号候補に重複があるか否を判定する重複判定手段と、
重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てる１つのノードを決定するノード決定手段と、
前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、
を有する車載ネットワークシステム。
【請求項２】
各ノードは、前記管理ノードから前記識別番号の決定通知を受信するまで、
前記番号決定手段が前記複数の識別番号候補から、まだ選択していない１つの識別番号候補を決定する処理、
前記送信手段が前記固有識別番号と前記識別番号候補を前記管理ノードに送信する処理、を繰り返す、
ことを特徴とする請求項１記載の車載ネットワークシステム。
【請求項３】
前記管理ノードは、各ノードに割り当てた前記識別番号を記憶しており、
通信データをノードから受信した際、前記識別番号が前記複数の識別番号候補のいずれかに該当するか否かを判定し、該当しない場合、各ノードに付与していない識別番号を前記複数の識別番号候補から決定して、通信データを送信した前記ノードに割り当てる新規識別番号付与手段、を有する、
ことを特徴とする請求項１又は２記載の車載ネットワークシステム。
【請求項４】
前記管理ノードは、ノードに前記複数の識別番号候補の全てを配信する識別番号候補配信手段を有する、
ことを特徴とする請求項１〜３いずれか１項記載の車載ネットワークシステム。
【請求項５】
前記番号決定手段は、前記複数の識別番号候補から異なる２つの識別番号候補を決定し、
前記送信手段は、前記固有識別番号と２つの前記識別番号候補を前記管理ノードに送信し、
前記重複判定手段は、あるノードから受信した２つの前記識別番号候補のどちらが、他のノードから受信した２つの前記識別番号候補と一致しなければ重複していないと判定する、
ことを特徴とする請求項１〜４いずれか１項記載の車載ネットワークシステム。
【請求項６】
前記ノード決定手段は、複数のノードの重複する前記固有識別番号のうち、最も小さい前記固有識別番号を送信したノードに、前記識別番号候補を識別番号として割り当てる、
ことを特徴とする請求項１記載の車載ネットワークシステム。
【請求項７】
各ノードは、各ノードに共通の、複数の識別番号候補を記憶する第１の記憶手段と、
各ノードに固有の固有識別番号を記憶する第２の記憶手段と、
前記複数の識別番号候補から１つの識別番号候補を決定する番号決定手段と、
前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有する複数のノードとネットワークを介して接続された管理ノードにおいて、
前記複数の識別番号候補の記憶手段と、
前記複数のノードから受信した複数の前記識別番号候補に重複があるか否を判定する重複判定手段と、
重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てるノードを決定するノード決定手段と、
前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、
を有する管理ノード。
【請求項８】
ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムの番号付与方法において、
各ノードの番号決定手段が、各ノードに共通の、複数の識別番号候補を記憶する第１の記憶手段から１つの識別番号候補を決定するステップと、
送信手段が、各ノードに固有の固有識別番号と前記識別番号候補を前記管理ノードに送信するステップと、
前記管理ノードの重複判定手段が、前記複数のノードから受信した複数の前記識別番号候補に重複があるか否を判定するステップと、
ノード決定手段が、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てるノードを決定するステップと、
結果通知手段が、前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段とステップと、
を有する番号付与方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、識別番号によりノードを識別する車載ネットワークにおいて、特に、ノードに動的に識別番号を付与できる車載ネットワークに関する。
【背景技術】
【０００２】
ネットワークに接続された機器が互いに通信するためには機器を特定するためのＩＤが必要になる。一般的なオフィスのＬＡＮではＭＡＣアドレスにより機器が識別されるし、ルータを超えた通信ではＩＰアドレスとＭＡＣアドレスにより機器が識別される。ＩＰアドレスは世界的に一意になるようにICANN/IANAが各国に割り当てており、ＭＡＣアドレスは世界的に一意のものが通信カードの製造時に記憶される。
【０００３】
車両の場合、少なくともある車両又はゲートウェイ内ではＥＣＵ（Electronic  Controller  Unit）のＩＤが重複しないことが要請される。しかし、車両のＥＣＵは車両メーカが製造するとは限らないため、重複したＩＤを有するＥＣＵが同一車両に搭載される可能性がある。例えば、ナビゲーションシステムは、メーカ出荷後に搭載されることが多く、このＩＤは搭載されるまで不明である。このため、車両において動的にＩＤを付与する仕組みが要請されている。
【０００４】
例えば、後から車載されるＥＣＵの取り付け箇所は限定されているので、取り付けによりオンになるメカ的なスイッチを取り付け箇所毎に配設しておき、スイッチのオンでＥＣＵに重複しないＩＤを付与する方法が考えられる。しかし、コスト増となるため採用しにくい。
【０００５】
また、車両においてもＭＡＣアドレスのような仕組みにより一意性を保証することが考えられる。しかし、現状そのような仕組みはない。また、１つの車両に搭載されるＥＣＵの数は最大でも１００のオーダーなので、仮に一意性が保証されたＩＤテーブルを車載しておき、マスター的なＥＣＵがその中から各ＥＣＵにＩＤを付与するのでは無駄になるＩＤの方がはるかに多くなってしまう。
【０００６】
そこで、まず、限定されたある範囲で管理用の機器が重複しないＩＤを各機器に付与することが考えられる（例えば、特許文献１参照。）。特許文献１には、ネットワーク中継器が各端末（各ＭＡＣアドレス）にそれぞれ各１つのＶＬＡＮＩＤを割り当て、テーブルで管理する技術が開示されている。
【０００７】
また、機器に付与される何らかの固有番号を利用した技術が提案されている（例えば、特許文献２参照。）。特許文献２には、クライアント家電機器の製品番号をその家電機器のＩＤとして付与し、重複している製品番号に対しては乱数を発生させてそれをＩＤとして付与するホームサーバー家電機器が開示されている。
【０００８】
また、ＩＤが重複した場合に変更する技術も考案されている（例えば、特許文献３参照。）。特許文献３には、２つのネットワークのアドレス範囲に重複がある場合、一方のアドレス範囲を重複しないように変更する中継装置が開示されている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開平１０−１７８４４２号公報
【特許文献２】特開平０６−０７４５３９号公報
【特許文献３】特開２００５−０３３２５１号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、特許文献１や特許文献２に開示されているように固有のＭＡＣアドレスや固有の製品番号は一意性が保証される十分な長さを有するため、例えばＣＡＮプロトコルのＣＡＮＩＤに収まりきらないおそれがある。短縮するために一部を取り出すと一意性が保証されなくなる。
【００１１】
また、特許文献３のように、重複しないようにＩＤを付与するだけでは、すでに割り当てられているＩＤを特定し、それらと異なることを確認しながら新たなＩＤを生成する必要が生じる。このため、処理負荷やＩＤ付与までの時間が長くなるおそれがある。
【００１２】
本発明は、上記課題に鑑み、一意性のあるＩＤを効率的に付与する車載ネットワークを提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は、ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムにおいて、各ノードは、各ノードに共通の、複数の識別番号候補の記憶手段と、  各ノードに固有の固有識別番号と、前記複数の識別番号候補から１つの識別番号候補を決定する番号決定手段と、前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有し、前記管理ノードは、前記複数の識別番号候補の記憶手段と、各ノードからそれぞれ受信した前記識別番号候補に重複があるか否を判定する重複判定手段と、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てる１つのノードを決定するノード決定手段と、前記識別番号候補が重複しないノード及び前記識別番号が割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、を有する。
【発明の効果】
【００１４】
一意性のあるＩＤを効率的に付与する車載ネットワークを提供することができる。
【図面の簡単な説明】
【００１５】
【図１】ＩＤ付与方式の概略を説明する図の一例である。
【図２】車載ネットワークの概略構成図の一例である。
【図３】管理ＥＣＵ、ＥＣＵ_Ａ〜ＥＣＵ_Ｃのハードウェア構成図の一例である。
【図４】ＣＡＮプロトコル、ＦｌｅｘＲａｙプロトコルの通信データのフォーマットの一例を示す図である。
【図５】管理ＥＣＵ及び各ＥＣＵの機能ブロック図の一例である。
【図６】管理ＥＣＵによるナンバーの重複判定と付与を模式的に説明する図の一例である。
【図７】本実施例の車載ネットワークがＩＤを決定する手順を示すフローチャート図の一例である。
【図８】本実施例の車載ネットワークがＩＤを決定する手順を示すフローチャート図の一例である。
【図９】管理ＥＣＵの機能ブロック図の一例である（実施例２）。
【図１０】車載ネットワークがＩＤを決定する手順を示すフローチャート図の一例である（実施例２）。
【図１１】車載ネットワークがＩＤを決定する手順を示すフローチャート図の一例である（実施例３）。
【発明を実施するための形態】
【００１６】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図１は本実施形態のＩＤ付与方式の概略を説明する図の一例である。本実施例の車載ネットワークでは、ＥＣＵ_Ａ〜ＥＣＵ_Ｃが共通の共通ナンバーテーブルを有する。共通ナンバーテーブルには複数のナンバー（例えば、００、０１…０８）が登録されている。
【００１７】
また、ＥＣＵ_Ａ〜ＥＣＵ_Ｃは固有ＩＤを有する。固有ＩＤはどのようなものでもよいが、一意性が保証されたシリアルナンバーや製品番号等を用いることができる。
【００１８】
ＩＤが付与されていない状態のＥＣＵ_Ａ〜ＥＣＵ_Ｃは、共有ＩＤテーブルから無作為に決定したナンバーと固有ＩＤを管理ＥＣＵ２００に送信する。
【００１９】
管理ＥＣＵ２００は、ＥＣＵ_Ａ〜ＥＣＵ_Ｃからナンバーと固有ＩＤの組を受信して、まず、ナンバーが重複しているか否かを判定する。全く重複していなければ、管理ＥＣＵ２００はＥＣＵ_Ａ〜ＥＣＵ_Ｃから受信したナンバーをそのままＥＣＵ_Ａ〜ＥＣＵ_ＣのＩＤに決定する。管理ＥＣＵ２００は決定したナンバーをＥＣＵ_Ａ〜ＥＣＵ_Ｃに送信するので、各ＥＣＵは受信したナンバーを自機のＩＤとして記憶し、通信を開始する。なお、各ＥＣＵが記憶するＩＤとは、通信時に自機を相手先に識別させるための識別情報である。例えば、ＣＡＮＩＤとして設定される。
【００２０】
ナンバーが重複した場合、管理ＥＣＵ２００は、固有ＩＤの例えば小さいＥＣＵを優先して、重複したナンバーを送信したＥＣＵのＩＤに決定する。
【００２１】
管理ＥＣＵ２００は固有ＩＤが大きかったその他のＥＣＵに対し、再度、ナンバーと固有ＩＤの送信を要求する。これにより、固有ＩＤが大きかったその他のＥＣＵが別のナンバーと固有ＩＤを管理ＥＣＵ２００に再度、送信するので、管理ＥＣＵ２００は同様の手順（ナンバーが重複している場合には固有ＩＤの小さいＥＣＵを優先する）で、ＩＤの決まっていないＥＣＵのＩＤを決定する。
【００２２】
このような手順によれば、管理ＥＣＵ２００は、共通ナンバーテーブルに登録されているナンバーの範囲で重複しないナンバーを各ＥＣＵに付与することができる。共通ナンバーテーブルにはネットワークに接続されうるＥＣＵの上限の数（多くても最大１０〜２０個）より多い数のナンバーを用意しておけばよいので、共通ナンバーテーブルのサイズは実用的なサイズに抑制できる。また、ナンバーは十進数で２桁程度なので、固有ＩＤをＩＤとするよりもＩＤの有効な桁数を十分に小さくできる。
【実施例１】
【００２３】
図２は、車載ネットワーク３００の概略構成図を示す。車載ネットワーク３００は、ＥＣＵ２００（区別する場合、ＥＣＵ_Ａ、ＥＣＵ_Ｂ、ＥＣＵ_Ｃ、ＥＣＵ＿Ｄという）及び管理ＥＣＵ２００を電気的に接続し、所定のプロトコル（例えば、ＣＡＮ（Controller  Area  Network）プロトコルやＬＩＮ（Local  Interconnect  Network）プロトコル等）に基づき、通信データの送受信を実現している。
【００２４】
管理ＥＣＵ（Electronic  Control  Unit）１００は、各ＥＣＵにＩＤを付与するＥＣＵである。本実施形態では管理ＥＣＵ２００としてゲートウェイ装置を想定しているが、ＩＤを付与するＥＣＵを他のＥＣＵ（例えばＥＣＵ_Ａ）とすることもできる。近年では機能統合が進んでおり、特定の機能のＥＣＵにゲートウェイ機能を統合し、ゲートウェイ装置としてのＥＣＵを省略することもある。
【００２５】
管理ＥＣＵ２００は、車載ネットワーク３００を複数のネットワークに分割することによって、通信データの通信量がもたらす負荷を緩和したり、例えばボディ系、情報・ＡＶ系、制御系毎の系統別にネットワークを構築するために利用される。管理ＥＣＵ２００はフィルタリングルールに基づきＥＣＵ_Ａ〜ＥＣＵ_Ｃが送信した通信データをＥＣＵ＿Ｄに又はその逆に中継する。
【００２６】
本実施形態では、管理ＥＣＵ２００がネットワーク１のＥＣＵ_Ａ〜ＥＣＵ_ＣにＩＤを付与する付与方法について説明する。これは、ネットワーク２は、メーカ出荷時に接続されるＥＣＵが固定（図ではＥＣＵ＿Ｄ）されているのに対し、ネットワーク１はナビゲーションシステムなどのディーラオプションが接続可能なネットワークであるためである。ＥＣＵ_Ａは例えば、ナビゲーションシステム用のＥＣＵ、ＥＣＵ_Ｂはリモートスタート用のＥＣＵ、ＥＣＵ_Ｃはセキュリティアラーム用のＥＣＵであるが、どのようなＥＣＵが接続されてもＩＤを付与することは可能である。なお、リモートスタート用のＥＣＵは、所定距離内のリモコンからエンジンスタート信号を送ると、乗員がいなくてもエンジンをスタートさせるＥＣＵである。また、セキュリティアラーム用のＥＣＵは、センサーにより例えば、ドア開、トランク開、ボンネット開、侵入者、車両傾斜等を検知し、アラーム音を発生させるＥＣＵである。これらのＥＣＵはディーラやユーザが市販品を装着することができる場合がある。
【００２７】
図３は、管理ＥＣＵ２００、ＥＣＵ_Ａ〜ＥＣＵ_Ｃのハードウェア構成図の一例を示す。ＥＣＵ_Ａ〜ＥＣＵ_Ｃは、マイコン５０やトランシーバ１７、不図示の電源ＩＣ、ドライバ回路等を有するコンピュータ装置の一形態である。マイコン５０は、バスを介して接続されたＣＰＵ１１、メモリ１２、ＤＭＡＣ１３、ＩＮＴＣ１４、通信装置１５、及びＡＤＣ１６を有する。
【００２８】
ＣＰＵ１１はバスを介してメモリ１２からプログラムを読み込み、また、必要であればバスを介してメモリ１２にデータを読み書きしてプログラムを実行する。このプログラムには、ＥＣＵ_Ａ〜ＥＣＵ_Ｃに特有の機能の他、管理ＥＣＵ２００からＩＤを取得するための機能が含まれる。
【００２９】
ＩＮＴＣ（Interrupt  Controller)１４は各種の周辺機器から入力された割り込み要求を、周辺機器の優先順位に基づき調停してＣＰＵ１１に通知する。これによりＣＰＵ１１は、割り込みした周辺機器に応じて決まった処理を実行する。例えば、図では通信装置１５が通信データを受信するとＩＮＴＣ１４を経由してＣＰＵ１１に通知する。ＣＰＵ１１は通信データを読み出して処理をする。
【００３０】
また、ＡＤＣ（analog  to  digital  converter）１６は、センサが検出したアナログ信号をデジタル信号に変換する。ＡＤＣ１６にはΔΣ型、逐次比較型、二重積分型などがあるがどのような変換原理で変換してもよい。なお、ＡＤＣ１６もＩＮＴＣ１４を介して変換の終了をＣＰＵ１１に通知する。
【００３１】
ＤＭＡＣ（Direct  Memory  Access  Controller）１３は、ＣＰＵ１１からの指示によりメモリ１２から周辺機器にデータを送信し、また、周辺機器から割り込みされたＣＰＵ１１から指示を受けて、不図示のバッファに記憶されたデータを読み出しメモリ１２に書き込む。これにより、ＣＰＵ１１は通信装置１５やＡＤＣ１６が取得したデータを使用できるようになる。
【００３２】
通信装置１５は、ＣＡＮやＦｌｅｘＲａｙ等の通信プロトコルに従って、ネットワークに通信データを送信し又ネットワークから通信データを受信する。ＣＰＵ１１が通信データを送信する場合、通信装置１５の送信バッファに通信データを記憶させる。通信装置１５にトランシーバ１７が接続されており、通信データをシリアルの送信信号に変換してトランシーバ１７の端子Ｔｘに出力する。
【００３３】
トランシーバ１７の送信回路１７１は、データの送信時、通信装置１５が端子Ｔｘに入力した論理レベルの送信信号を、トランシーバ１７対応する差動電圧に変換して１対のバスに出力する。ＣＡＮ又はＦｒｅｘＲａｙの場合、ノイズに強い２本の信号線の差動電圧により通信データを送信する。
【００３４】
データの受信時、トランシーバ１７の受信回路１７２は、差動電圧が所定の電圧範囲に含まれるように整形して受信信号を生成し、通信装置１５に出力する。通信装置１５は所定の閾値電圧と受信回路１７２からの受信信号とを比較して論理レベルの通信データを再現する。
【００３５】
ネットワーク１には複数のＥＣＵ_Ａ〜ＥＣＵ_Ｃが接続されているので、１つのＥＣＵが送信した通信データはネットワーク１に接続された自機を除くＥＣＵ_Ａ〜ＥＣＵ_Ｃ及び管理ＥＣＵ２００に同報的に送信される。このため、ＣＡＮプロトコルによるデータの受信時、通信装置１５は、後述する通信データのデータＩＤを、予め定められている受信対象のデータＩＤと比較し、受信すべきデータをＣＰＵ１１に出力し、それ以外は破棄する。また、トランシーバ１７では、送信回路１７１の送信線が受信回路１７２に接続されている。すなわち、通信装置１５は自機が送信した通信データを監視しており、より優先順位の高いＥＣＵが通信データを送信しているか否かを監視している。より優先順位の高いＥＣＵが通信データを送信していることを検出すると、通信装置１５は通信データの送信を停止し、ランダムな時間待機した後、通信データを再送する（ＣＳＭＡ／ＣＤ（Carrier  Sense  Multiple  Access/Collision  Detection））。
【００３６】
管理ＥＣＵ２００のハードウェア構成図も図３とほぼ同様になるが、管理用ＥＣＵはネットワーク１と２用の２つの通信装置１５及びトランシーバ１７を有している。また、ＣＰＵ１１をマルチコア又はマルチＣＰＵなどの高負荷に対応したものにしてもよい。
【００３７】
〔ＣＡＮ  ＩＤ  ＦｒｅｘＲａｙ  ＩＤ〕
図４（ａ）はＣＡＮプロトコルの通信データのフォーマットを模式的に説明する図の一例を、図４（ｂ）はＦｌｅｘＲａｙプロトコルの通信データのフォーマットの一例をそれぞれ示す。
【００３８】
ＣＡＮプロトコルの場合、通信データはフレームという単位で送信され、１つのフレームは、ＳｏＦ、ＣＡＮＩＤ、ＲＴＲ、コントロールフィールド、データフィールド、ＣＲＣ、ＡＣＫ、ＥｏＦの各フィールドを有する。図の数値は各フィールドのビット数を示す。ＳＯＦは通信データの開始を表し他のＥＣＵと同期するために使用され、ＣＡＮＩＤには送信元のＥＣＵを識別するためのＩＤが格納される。ＣＡＮＩＤはネットワーク１上で一意性が保証されている必要がある。本実施形態で決定されるＩＤはＣＡＮＩＤに格納される値になる。また、ＣＳＭＡ／ＣＤによる調停ではドミナントがリセッシブにより優先されるので、同時に送信を開始した２つ以上のＥＣＵでは最もＣＡＮＩＤが小さいＥＣＵが送信権を取得する。
【００３９】
ＲＴＲはデータフィールドとリモートフレーム（データフレームを要求するフレーム）の別を示す。コントロールフィールドはデータフィールドのバイト数を示す。ＣＲＣには誤り訂正符号が格納される。ＡＣＫには受信側のＥＣＵがＣＲＣまでを正確に受信できたことを応答する値（ドミナント）が格納される。
【００４０】
ＦｌｅｘＲａｙプロトコルの場合（スタティックセグメント）、大きく３つのセグメントで１つの通信データを構成する。ヘッダセグメントは送信データに関する情報が、ペイロードセグメントには送信対象のデータが、トレイラセグメントにはＣＲＣがそれぞれ格納される。各ＥＣＵを識別するためのＩＤはヘッダセグメントの先頭の１〜５ビット（ステータスビット）に続く１１ビットの「Ｆｒａｍｅ  ＩＤ（フレームＩＤ）」に格納される。なお、ＦｒｅｘＲａｙプロトコルでは、各ＥＣＵ毎にスタティックスロットが確保されているので、送信タイミングが重なることはない。具体的には、各通信装置１５は１つのスタティックスロット周期が経過する毎に１つ増えるカウンタを有し、予め決められたカウント値のスタティックスロットで通信データを送信する。
【００４１】
〔機能ブロック〕
図５は、管理ＥＣＵ２００及び各ＥＣＵ１００の機能ブロック図の一例を示す。各ＥＣＵ＿Ａ〜ＥＣＵ_Ｃは、通信部３５、ナンバー決定部３１、決定可否判定部３２、及び、ＩＤ保持部３３を有する。これらの各機能は、各ＣＰＵ１１がプログラムを実行し、上記のハードウェア構成と協働することで実現される。また、共通ナンバーテーブル２０と固有ＩＤ３４は、ＥＣＵ_Ａ〜ＥＣＵ_Ｃの不揮発メモリに記憶されている。
【００４２】
共通ナンバーテーブル２０には、少なくともネットワーク１に接続される可能性のある数以上の整数のナンバーが登録されている。例えば、図では一例として「００、０１、０２、０３、０４、０５、０６、０７、０８」の９個のナンバーが表示されている。共通ナンバーテーブル２０のナンバーは各ＥＣＵ_Ａ〜ＥＣＵ_Ｃに共通である。ただし、要素としてのナンバーが同じなら各ナンバーの配置場所は異なっていてもよい。なお、共通ナンバーテーブル２０は、静的である必要はなく、例えば００〜０８の整数を生成する手段で代用することもできる。
【００４３】
固有ＩＤ３４は、ＥＣＵのシリアルナンバー（製造番号）、製品の型番、生産年月日、ロット番号、又は、これらの組合せである。同じ種類のＥＣＵ（ナビならナビ）が複数個、搭載されないという前提では、製品の型番が一致することはなく、同じ種類のＥＣＵ（ナビならナビ）が複数個搭載されるのであれば、シリアルナンバー（製造番号）が一致することはない。したがって、シリアルナンバー（製造番号）や製品の型番を固有ＩＤ３４とすることができる。なお、固有ＩＤ３４が数字だけで構成されているとは限らないが、アルファベットはアスキーコードで表現されているので実質的には数値と同様に扱うことができる。
【００４４】
ナンバー決定部３１は、共通ナンバーテーブル２０から１つのナンバーを決定する。不作為に決定してもよいし、小さい値から順に決定してもよいし、左上又は右上などの決まった場所から順にナンバーを決定してもよい。
【００４５】
決定可否判定部３２は、通信部３５を介して管理ＥＣＵ２００から受信した重複判定結果に基づき、送信したナンバーが自機のＩＤとして受け付けられたか否かを判定する。重複判定結果は以下のような内容を有する。
・重複しない場合…ＥＣＵ１００が送信したナンバー
・重複した場合…重複したという旨のメッセージや記号（例えば、ＦＦＦＦなど共通ナンバーテーブル２０に存在しない番号）
管理ＥＣＵ２００により送信したナンバーが自機のＩＤとして受け付けられない場合（重複したという重複判定結果を受信した場合）、決定可否判定部３２はナンバー決定部３１に再度のナンバーの決定を要求する。管理ＥＣＵ２００により送信したナンバーが自機のＩＤとして受け付けられた場合（重複しないという重複判定結果を受信した場合）、決定可否判定部３２はＩＤ保持部３３にナンバーを保持させる。
【００４６】
ＩＤ保持部３３は、一度特定されたナンバーを保持する記憶手段である。ＩＤ保持部３３は不揮発メモリでも揮発性メモリのどちらでもよい。揮発性メモリの場合、電源供給されない状態になると、再度、管理ＥＣＵ２００が全てのＥＣＵのＩＤを決定する必要がある。しかし、例えば、新しくＥＣＵがネットワーク１に加わる場合は、他のＥＣＵ１００も電源供給されない状態になるので、新しくＥＣＵがネットワーク１に加わったタイミングで、他のＥＣＵを含めＩＤを決定することができる。不揮発メモリの場合、ＩＤが一度決定されたＥＣＵは、電源供給されない状態になっても、再度、管理ＥＣＵ２００が決定する必要がない。
【００４７】
通信部３５は、ＣＡＮＩＤ又はフレームＩＤに設定する値を決定し、通信プロトコルに応じて通信データのフレームを生成する。受信時には、データフィールド又はペイロードセグメントの内容をアプリ等に送出する。
・ＩＤ決定前
通信部３５は、固有ＩＤ３４をＣＡＮＩＤ又はフレームＩＤに設定する。または、固有ＩＤ３４とナンバーを合体させてＣＡＮＩＤ又はフレームＩＤに設定してもよい。固有ＩＤ３４が１１ビット以上の場合、一意性が保証しやすいＬＳＢから１１ビットをＣＡＮＩＤ又はフレームＩＤに設定する。この場合、ＣＡＮプロトコルのデータフィールド又はＦｌｅｘＲａｙプロトコルのペイロードセグメントには、ナンバー決定部３１が決定したナンバーが設定される。
・ＩＤ決定後
通信部３５は、ＩＤ保持部３３が保持しているＩＤをＣＡＮＩＤ又はフレームＩＤに設定する。
【００４８】
なお、ＩＤが決定されＩＤ保持部３３がＩＤを保持していることは、決定可否判定部３２が、例えばＩＤ保持部３３にＩＤが決定されたことを示すフラグをセットすることで判定される。
【００４９】
管理ＥＣＵ２００は、通信部２６、自ＩＤ決定部２１、重複判定部２２、最小固有ＩＤ決定部２３，結果通信部２４、及び、新規ＩＤ付与部２５を有する。これらの各機能は、各ＣＰＵ１１がプログラムを実行し、上記のハードウェア構成と協働することで実現される。
【００５０】
自ＩＤ決定部２１は、管理ＥＣＵ２００のＩＤを決定する。管理ＥＣＵ２００もネットワーク１ではＥＣＵ_Ａ〜ＥＣＵ_Ｃと異なるＩＤを有している必要がある。また、ＣＡＮプロトコルにおいて、ゲートウェイ装置は、通信データを送信する際の優先度が最も高く設定される。したがって、自ＩＤ決定部２１は、共通ナンバーテーブル２０から最も小さいナンバーを自機のＩＤに決定する。
【００５１】
または、管理ＥＣＵ２００のＩＤは、車両の出荷時に予め固定されていてもよい。しかしながら、管理ＥＣＵ２００は上記のように最も優先度が高いことが好ましいので、管理ＥＣＵ２００のＩＤは共通ナンバーテーブル２０内で最も小さい値、又は、共通ナンバーテーブル２０に登録されているどのナンバーよりも小さい値であることが好ましい。
【００５２】
重複判定部２２は、管理ＥＣＵ２００のＩＤと各ＥＣＵが送信するナンバーが重複するか否か、及び、各ＥＣＵが送信するナンバー同士に重複するナンバーがあるか否か、を判定する。管理ＥＣＵ２００のＩＤが予め決まっている場合、前者の判定は不要になる。管理ＥＣＵ２００のＩＤとＥＣＵ_Ａ〜ＥＣＵ_Ｃが送信するナンバーが重複する場合、重複判定部２２は重複したこと及び重複したＥＣＵ１００を結果通知部２４に通知する。結果通知部２４は、重複する旨の重複判定結果を、ナンバーを送信したＥＣＵ１００に送信する。これにより、ＥＣＵ１００のナンバー決定部３１は再度、共通ナンバーテーブル２０からナンバーを決定する。
【００５３】
また、各ＥＣＵ１００が送信するナンバー同士に重複するナンバーがある場合、重複判定部２２は最小固有ＩＤ決定部２３に、ナンバーが重複した全てのＥＣＵ１００の固有ＩＤを通知する。最小固有ＩＤ決定部２３は、ナンバーが重複した複数のＥＣＵの固有ＩＤ３４のうち、最も小さい固有ＩＤ３４を決定し、結果通知部２４に通知する。結果通知部２４は、最も小さい固有ＩＤ３４のＥＣＵ１００にナンバーを含む重複判定結果を送信する。ナンバーを含む重複判定結果はそのナンバーがＥＣＵ１００のＩＤに決定されたことを意味する。
【００５４】
なお、最小固有ＩＤ決定部２３は、ナンバーが重複した複数のＥＣＵの固有ＩＤ３４のうち、最も“大きい”固有ＩＤ３４を決定してもよい。固有ＩＤ３４はＥＣＵ_Ａ〜ＥＣＵ_Ｃの元々の優位性とは関係がないためである。しかしながら、ＣＡＮプロトコルではＣＳＭＡ／ＣＤにより同時に送信を開始したＥＣＵのうち小さい固有ＩＤ３４のＥＣＵを優先する。このため、固有ＩＤ３４が小さいＥＣＵ１００を優先することは、管理用ＥＣＵに先に通信データを送信したＥＣＵが優先してＩＤが決定されるという作用をもたらす。
【００５５】
また、結果通知部２４は、固有ＩＤ３４が最も小さくはなかったＥＣＵ１００に重複する旨の重複判定結果を送信する。これにより、ＥＣＵ１００のナンバー決定部３１は再度、共通ナンバーテーブル２０からナンバーを決定する。
【００５６】
また、ＥＣＵ_Ａ〜ＥＣＵ_Ｃが送信するナンバー同士に重複するナンバーがない場合、重複判定部２２はその判定結果を結果通知部２４に通知する。結果通知部２４は、全てのＥＣＵ_Ａ〜ＥＣＵ_Ｃにナンバーを含む重複判定結果を送信する。
【００５７】
〔重複判定及びナンバー付与例〕
図６は、管理ＥＣＵ２００によるナンバーの重複判定と付与を模式的に説明する図の一例である。ＥＣＵ_Ａは固有ＩＤ＝１００１０、ＥＣＵ_Ｂは固有ＩＤ＝１００１５、ＥＣＵ_Ｃは固有ＩＤ＝１１００４、である。
（１）ＥＣＵ_Ａ〜ＥＣＵ_Ｃはそれぞれの固有ＩＤを仮のＩＤにして、ＥＣＵ_Ａはナンバー０１を、ＥＣＵ_Ｂはナンバー０３を、ＥＣＵ_Ｃはナンバー０３を、それぞれ管理ＥＣＵ２００に送信する。
（２）管理ＥＣＵ２００の重複判定部２２は、重複するナンバーがあるか否かを判定する。この例では、ＥＣＵ_ＢとＥＣＵ_Ｃのナンバーが０３なので、重複している。
（３）まず、結果通知部２４はナンバーが重複していないＥＣＵ_Ａにナンバー０１を含む重複判定結果を送信する。
（４）最小固有ＩＤ決定部２３は、ナンバー０３が共通したＥＣＵ_ＢとＥＣＵ_Ｃの固有ＩＤ３４のうち小さい方を特定する。「１００１５＜１１００４」なので、ＥＣＵ_Ｂを優先する。よって、結果通知部２４はＥＣＵ_Ｂにナンバー０３を含む重複判定結果を送信する。
（５）結果通知部２４はナンバーが重複し、固有ＩＤ３４も最小値でなかったＥＣＵ_Ｃに、重複する旨の重複判定結果を送信する。
（６）ＥＣＵ_Ｃは新たにナンバー０７を決定し管理ＥＣＵ２００に送信する。
（７）ナンバー０７は他のＥＣＵ_Ａ、ＥＣＵ_Ｂのナンバーと重複しないので、結果通知部２４はナンバー０７を含む重複判定結果を送信する。
【００５８】
〔動作手順〕
図７は、本実施例の車載ネットワーク３００がＩＤを決定する手順を示すフローチャート図の一例である。この例は、ＩＤ保持部３３のＩＤが電力供給のオフにより消失されてもよい場合に対応している。なお、ＥＣＵ_Ａ〜ＥＣＵ_Ｃの処理手順は同じなので１つのＥＣＵ１００のみを示した。
【００５９】
この手順は、バッテリが外されるなどして、管理ＥＣＵ２００を含む全てのＥＣＵへの電力供給がオフの状態から、バッテリが装着されオンになるとスタートする。電力供給がオンになると、管理ＥＣＵ２００及び各ＥＣＵ１００は再起動（またはリセット）するので、ネットワーク１を介した通信のためＩＤの決定手順を開始する。
【００６０】
まず、ＥＣＵ１００のナンバー決定部３１が共通ナンバーテーブル２０から１つのナンバーを決定する（Ｓ１０）。そして、通信部３５は、固有ＩＤ３４をＣＡＮＩＤ等に設定しナンバーをデータフィールド等に格納して管理ＥＣＵ２００に送信する（Ｓ２０）。
【００６１】
すると、ＥＣＵ１００は重複判定結果を受信するまで待機し（Ｓ３０）、重複判定結果を受信すると決定可否判定部３２がナンバーを含む重複判定結果を受信したか否かを判定する（Ｓ４０）。
【００６２】
ナンバーを含む重複判定結果を受信した場合、決定可否判定部３２はＩＤ保持部３３にナンバーを記憶する（Ｓ５０）。これによりナンバーが確定し当該ＥＣＵ１００の処理は終了する。
【００６３】
ナンバーを含む重複判定結果を受信しない場合、この場合、重複判定結果（ＦＦＦＦ）を受信したことになるので、ナンバー決定部３１がステップＳ１０からの処理を繰り返す。しかしながら、最高でもネットワーク１のＥＣＵ１００の数だけ繰り返すと全てのＥＣＵ１００はナンバーを決定できる。
【００６４】
次に、管理ＥＣＵ２００の処理に移る。管理ＥＣＵ２００の自ＩＤ決定部２１は、マイコン５０が再起動すると自機のＩＤを決定する（Ｓ１１０）。そして、通信部２６がＥＣＵ１００からナンバー及び固有ＩＤを受信する（Ｓ１２０）。重複判定部２２は、通信部２６が受信した固有ＩＤ３４とナンバーを対応づけてメモリ１２に記憶していく。
【００６５】
複数のＥＣＵ１００はプロトコルの制約上、同時にはナンバーと固有ＩＤを送信できないので、重複判定部２２は自機のＩＤを決定してから所定時間待機し、その間、ナンバーと固有ＩＤの受信を継続している（Ｓ１３０）。
【００６６】
所定時間が経過すると、重複判定部２２は、まず自ＩＤと重複するナンバーがあるか否かを判定する（Ｓ１４０）。自ＩＤと重複するナンバーがある場合、結果通知部２４が自ＩＤと重複するナンバーを送信したＥＣＵに重複する旨の重複判定結果を送信する（Ｓ１５０）。
【００６７】
次に、重複判定部２２は、ＥＣＵ_Ａ〜ＥＣＵ_Ｃが送信したナンバーに重複があるか否かを判定する（Ｓ１６０）。
【００６８】
重複がなければ、結果通知部２４はナンバーを含む重複判定結果をナンバーの送信元のＥＣＵに送信する（Ｓ１７０）。管理ＥＣＵ２００は、確定した各ＥＣＵのナンバーをメモリ１２に記憶しておく。
【００６９】
重複がある場合、最小固有ＩＤ決定部２３は重複するナンバーを送ったＥＣＵの固有ＩＤのうち最も小さい固有ＩＤ３４を決定する（Ｓ１８０）。
【００７０】
そして、結果通知部２４は、固有ＩＤ３４が最も小さいＥＣＵ１００にナンバーを含む重複判定結果を送信する（Ｓ１９０）。一方、結果通知部２４は、固有ＩＤ３４が最も小さいＥＣＵ以外のＥＣＵに重複判定結果（ＦＦＦＦ）を送信する（Ｓ２００）。
【００７１】
管理ＥＣＵ２００は、Ｓ１２０で受信したナンバーの数と、ＩＤを決定したＥＣＵ１００の数（ナンバーを含む重複判定結果の送信回数）を比較するなどして、全てのＥＣＵ１００のＩＤを決定したか否かを判定する（Ｓ２１０）。全てのＥＣＵ１００のＩＤを決定するまでは、Ｓ１２０以下の処理が繰り返され、全てのＥＣＵ１００のＩＤを決定すると図７の手順は終了する。
【００７２】
このように、管理ＥＣＵ２００は、バッテリが外されるなどしてネットワーク１のＥＣＵ_Ａ〜ＥＣＵ_ＣがＩＤを消失したタイミングで、共通ナンバーテーブル２０に登録されているナンバーの範囲で重複しないＩＤをＥＣＵ１００に付与することができる。
【００７３】
〔動作手順２〕
図８は、本実施例の車載ネットワーク３００がＩＤを決定する手順を示すフローチャート図の一例である。この例は、新たなＥＣＵ１００がネットワーク１に接続された場合に対応している。新たなＥＣＵをＥＣＵ_Ｃとする。
【００７４】
・管理ＥＣＵ２００及びＥＣＵ_Ａ、Ｂがリセットされた場合
ＥＣＵ＿Ｃの接続時には、バッテリが外されるなどして管理用ＥＣＵ２００及びＥＣＵ_Ａ、Ｂへの電力供給がオフになることが多い。この場合、管理用ＥＣＵ２００はＥＣＵ_Ａ〜ＥＣＵ_Ｃに対し、図７と同様の手順でＩＤを決定する。
【００７５】
・管理ＥＣＵ２００及びＥＣＵ_Ａ、Ｂがリセットされない場合
ユーザによってはＥＣＵ_Ｃの接続時に、バッテリを外さない場合がある。この場合、ＥＣＵ_ＣだけＩＤが付与されていない状況が生じるので、管理ＥＣＵ２００がＥＣＵ_ＣにのみＩＤを付与できれば便利である。
【００７６】
まず、ネットワーク１に接続されたＥＣＵ_Ｃは、マイコン５０が起動すると、存在を通知するため固有ＩＤ３４をＣＡＮＩＤ等に設定して通信データを送信する（Ｓ２５０）。このような動作は車載ネットワーク３００の通信仕様である。
【００７７】
管理ＥＣＵ２００の新規ＩＤ付与部２５は、ＥＣＵ_Ｃから通信データを受信すると（Ｓ３１０）、ＣＡＮＩＤ又はフレームＩＤを抽出して、これらの値が共通ナンバーテーブル２０に登録されているか否かを判定する（Ｓ３２０）。
【００７８】
登録されている場合は、新たに接続されたＥＣＵ_Ｃにはすでに共通ナンバーテーブル２０から重複しないナンバーがＩＤとして付与されているので、処理は終了する。このような状況は、ＥＣＵ_ＣのＩＤ保持部３３が不揮発メモリであり、以前にＥＣＵ_Ｃがネットワーク１に接続されていた場合に生じる。
【００７９】
登録されていない場合は、新たに接続されたＥＣＵ_Ｃに共通ナンバーテーブル２０からＩＤを付与する必要があるので、新規ＩＤ付与部２５は、すでに他のＥＣＵ_Ａ、Ｂに付与しているＩＤ及び自機のＩＤと重複しないナンバーを共通ナンバーテーブル２０から決定する（Ｓ３３０）。
【００８０】
新規ＩＤ付与部２５は決定したナンバーをＩＤとしてＥＣＵ_Ｃに送信する（Ｓ３４０）。
【００８１】
ＥＣＵ_Ｃの通信部３５がナンバーを受信するので（Ｓ２６０）、ＩＤ保持部３３がＩＤを記憶する（Ｓ２７０）。このように、管理ＥＣＵ２００はＥＣＵ_Ａ、ＥＣＵ_Ｂと重複しない、ＩＤを新たなＥＣＵ_Ｃに付与できる。
【００８２】
以上のように、本実施例の車載ネットワークは、桁数が短く統一された数値が登録されている共通ナンバーテーブルの範囲でＩＤを各ＥＣＵに付与することができる。共通ナンバーテーブルのサイズは実用的なサイズに抑制できる。
【実施例２】
【００８３】
実施例１の動作手順２では、新たに装着されたＥＣＵ_Ｃに対し、管理ＥＣＵ２００が単に重複しない共通ナンバーテーブル２０から重複しないＩＤを付与した。しかし、新たなＥＣＵ_Ｃを装着することで、ＥＣＵ_Ａ、ＢのＩＤ保持部３３がＩＤを消失し、管理ＥＣＵ２００もＥＣＵ_Ａ、ＢのＩＤを消失した場合、これらのＥＣＵ_Ａ、Ｂに再度、ＩＤを付与する。
【００８４】
この場合、ＥＣＵ_Ｃが共通ナンバーテーブル２０を有していれば、実施例１の動作手順１のように管理ＥＣＵ２００がＥＣＵ_Ａ〜ＥＣＵ_ＣのＩＤを決定すればよい。しかし、ＥＣＵ_Ｃが共通ナンバーテーブル２０を有していない場合、ＥＣＵ_Ｃが共通ナンバーテーブル２０を取得する仕組みがあることが好ましい。
【００８５】
そこで、本実施例では、ＥＣＵが共通ナンバーテーブル２０を後天的に取得可能な車載ネットワークについて説明する。
【００８６】
図９は、本実施例の管理ＥＣＵ２００の機能ブロック図の一例である。図９において図５と同一部の説明は省略する。図示するように、管理ＥＣＵ２００は共通ナンバー提供部２７を有する。共通ナンバー提供部２７は、バッテリがオフからオンになると、同報的に共通ナンバーテーブル２０をＥＣＵ_Ａ〜ＥＣＵ_Ｃに送信する。または、ＥＣＵ_Ａ〜ＥＣＵ_Ｃから受信した通信データのＣＡＮＩＤ又はフレームＩＤが、共通ナンバーテーブル２０に登録されていない値の場合、該ＥＣＵに共通ナンバーテーブル２０を送信する。
【００８７】
図１０は、本実施例の車載ネットワーク３００がＩＤを決定する手順を示すフローチャート図の一例である。なお、図１０において図７と同一ステップの説明は省略する。バッテリが外されるなどしてリセットされた管理ＥＣＵ２００は共通ナンバーテーブル２０をネットワーク１のＥＣＵ_Ａ〜ＥＣＵ_Ｃに配信する（Ｓ１０２）。
【００８８】
各ＥＣＵ１００は、共通ナンバーテーブル２０を受信する（Ｓ２）。すでに共通ナンバーテーブル２０を記憶しているＥＣＵ_Ａ、Ｂは受信した共通ナンバーテーブル２０を破棄してもよいし、上書きしてもよい。また、共通ナンバーテーブル２０を記憶していないＥＣＵ_Ｃは、共通ナンバーテーブル２０を好ましくは不揮発メモリに記憶する。これにより、ＥＣＵ_Ｃは共通ナンバーテーブル２０からナンバーを決定し（Ｓ１０）、管理ＥＣＵ２００に送信することができる（Ｓ２０）。以降の処理は実施例１と同様になる。
【００８９】
本実施例の車載ネットワーク３００は、新たに接続されたＥＣＵ_Ｃが共通ナンバーテーブル２０を有していなくても、ＥＣＵ_Ａ〜ＥＣＵ_Ｃに同じ仕組みでＩＤを付与することができる。
【実施例３】
【００９０】
本実施例では、ＥＣＵ_Ａ〜ＥＣＵ_Ｃが複数のナンバーを送信する車載ネットワーク３００について説明する。複数のナンバーを送信することで、管理ＥＣＵ２００は１回のナンバー及び固有ＩＤの受信で、重複しないナンバーをＩＤに決定しやすくなる。
【００９１】
図１１は、本実施例の車載ネットワーク３００がＩＤを決定する手順を示すフローチャート図の一例である。この例は、ＩＤ保持部３３のＩＤが電力供給のオフにより消失されてもよい場合に対応している。なお、図１１において図７と同一ステップの説明は省略する。
【００９２】
まず、ＥＣＵのナンバー決定部３１が共通ナンバーテーブル２０から２つのナンバーを決定する（Ｓ１２）。そして、通信部３５は、固有ＩＤ３４をＣＡＮＩＤ等に設定し２つのナンバーをデータフィールド等に格納して管理ＥＣＵ２００に送信する（Ｓ２２）。
【００９３】
次に、管理ＥＣＵ２００の処理に移る。管理ＥＣＵ２００の自ＩＤ決定部２１は、再起動により自機のＩＤを決定する（Ｓ１１０）。そして、通信部２６が各ＥＣＵ１００からそれぞれ２つのナンバーを受信する（Ｓ１２２）。
【００９４】
重複判定部２２は、通信部２６が受信した固有ＩＤ３４と２つのナンバーを対応づけてメモリ１２に記憶していく。図ではＥＣＵ_Ａが「０１  ０２」ＥＣＵ_Ｂが「０３  ０４」ＥＣＵ_Ｃが「０３  ０５」を送信した。
【００９５】
この後、管理ＥＣＵ２００は自ＩＤとの重複の有無を判定する。そして、Ｓ１６０以下の処理において、ＥＣＵ_Ａの「０１」と重複するナンバーはないので、重複判定部２２はＥＣＵ_ＡのＩＤを「０１」に決定する。ＥＣＵ_Ｂの「０３」はＥＣＵ_Ｃの「０３」と重複しているので、実施例１と同様に、重複判定部２２は、ＥＣＵ_ＢのＩＤを「０３」に決定する。ＥＣＵ_Ｃの「０３」はすでにＥＣＵ_ＢのＩＤになったので、重複判定部２２は「０５」をＥＣＵ_ＣのＩＤに決定する。すなわち、重複判定部２２は、ＥＣＵから受信した２つのナンバーのうちどちらが、他のＥＣＵの送信したナンバーと一致しなければ重複していないと判定できる。
【００９６】
このように１つのＥＣＵ１００について複数のナンバーの候補があれば、重複判定部２２は重複しないＥＣＵを１回のナンバーの受信で特定しやすい。このため、早期に各ＥＣＵのＩＤが決定されるし、ネットワーク１の通信量も低減できる。
【符号の説明】
【００９７】
２０    共通ナンバーテーブル
２１    自ＩＤ決定部
２２    重複判定部
２３    最小固有ＩＤ決定部
２４    結果通知部
２５    新規ＩＤ付与部
２６    通信部
２７    共通ナンバー提供部
３１    ナンバー決定部
３２    決定可否判定部
３３    ＩＤ保持部
３４    固有ＩＤ
５０    マイコン
１００  ＥＣＵ
２００  管理ＥＣＵ
【図１】
2012222527.tif 000003
【図２】
2012222527.tif 000004
【図３】
2012222527.tif 000005
【図４】
2012222527.tif 000006
【図５】
2012222527.tif 000007
【図６】
2012222527.tif 000008
【図７】
2012222527.tif 000009
【図８】
2012222527.tif 000010
【図９】
2012222527.tif 000011
【図１０】
2012222527.tif 000012
【図１１】
2012222527.tif 000013