"ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムにおいて、各ノードは、各ノードに共通の、複数の識別番号候補の第1の記憶手段と、各ノードに固有の固有識別番号の第2の記憶手段と、前記複数の識別番号候補から1つの識別番号候補を決定する番号決定手段と、前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有し、前記管理ノードは、前記複数の識別番号候補の記憶手段と、各ノードからそれぞれ受信した前記識別番号候補に重複があるか否を判定する重複判定手段と、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てる1つのノードを決定するノード決定手段と、前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、を有する車載ネットワークシステム。各ノードは、前記管理ノードから前記識別番号の決定通知を受信するまで、前記番号決定手段が前記複数の識別番号候補から、まだ選択していない1つの識別番号候補を決定する処理、前記送信手段が前記固有識別番号と前記識別番号候補を前記管理ノードに送信する処理、を繰り返す、ことを特徴とする請求項1記載の車載ネットワークシステム。前記管理ノードは、各ノードに割り当てた前記識別番号を記憶しており、通信データをノードから受信した際、前記識別番号が前記複数の識別番号候補のいずれかに該当するか否かを判定し、該当しない場合、各ノードに付与していない識別番号を前記複数の識別番号候補から決定して、通信データを送信した前記ノードに割り当てる新規識別番号付与手段、を有する、ことを特徴とする請求項1又は2記載の車載ネットワークシステム。前記管理ノードは、ノードに前記複数の識別番号候補の全てを配信する識別番号候補配信手段を有する、ことを特徴とする請求項1~3いずれか1項記載の車載ネットワークシステム。前記番号決定手段は、前記複数の識別番号候補から異なる2つの識別番号候補を決定し、前記送信手段は、前記固有識別番号と2つの前記識別番号候補を前記管理ノードに送信し、前記重複判定手段は、あるノードから受信した2つの前記識別番号候補のどちらが、他のノードから受信した2つの前記識別番号候補と一致しなければ重複していないと判定する、ことを特徴とする請求項1~4いずれか1項記載の車載ネットワークシステム。前記ノード決定手段は、複数のノードの重複する前記固有識別番号のうち、最も小さい前記固有識別番号を送信したノードに、前記識別番号候補を識別番号として割り当てる、ことを特徴とする請求項1記載の車載ネットワークシステム。各ノードは、各ノードに共通の、複数の識別番号候補を記憶する第1の記憶手段と、各ノードに固有の固有識別番号を記憶する第2の記憶手段と、前記複数の識別番号候補から1つの識別番号候補を決定する番号決定手段と、前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有する複数のノードとネットワークを介して接続された管理ノードにおいて、前記複数の識別番号候補の記憶手段と、前記複数のノードから受信した複数の前記識別番号候補に重複があるか否を判定する重複判定手段と、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てるノードを決定するノード決定手段と、前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、を有する管理ノード。ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムの番号付与方法において、各ノードの番号決定手段が、各ノードに共通の、複数の識別番号候補を記憶する第1の記憶手段から1つの識別番号候補を決定するステップと、送信手段が、各ノードに固有の固有識別番号と前記識別番号候補を前記管理ノードに送信するステップと、前記管理ノードの重複判定手段が、前記複数のノードから受信した複数の前記識別番号候補に重複があるか否を判定するステップと、ノード決定手段が、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てるノードを決定するステップと、結果通知手段が、前記識別番号候補が重複しないノード及び重複したが前記識別番号候補が前記識別番号として割り当てられたノードに、識別番号の決定通知を送信する結果通知手段とステップと、を有する番号付与方法。しかしながら、特許文献1や特許文献2に開示されているように固有のMACアドレスや固有の製品番号は一意性が保証される十分な長さを有するため、例えばCANプロトコルのCANIDに収まりきらないおそれがある。短縮するために一部を取り出すと一意性が保証されなくなる。また、特許文献3のように、重複しないようにIDを付与するだけでは、すでに割り当てられているIDを特定し、それらと異なることを確認しながら新たなIDを生成する必要が生じる。このため、処理負荷やID付与までの時間が長くなるおそれがある。本発明は、上記課題に鑑み、一意性のあるIDを効率的に付与する車載ネットワークを提供することを目的とする。本発明は、ネットワークに管理ノード及び複数のノードが接続された車載ネットワークシステムにおいて、各ノードは、各ノードに共通の、複数の識別番号候補の記憶手段と、各ノードに固有の固有識別番号と、前記複数の識別番号候補から1つの識別番号候補を決定する番号決定手段と、前記固有識別番号と前記識別番号候補を前記管理ノードに送信する送信手段と、を有し、前記管理ノードは、前記複数の識別番号候補の記憶手段と、各ノードからそれぞれ受信した前記識別番号候補に重複があるか否を判定する重複判定手段と、重複すると判定された前記識別番号候補を送信した複数のノードの前記固有識別番号を比較した結果に応じて、重複した前記識別番号候補を識別番号として割り当てる1つのノードを決定するノード決定手段と、前記識別番号候補が重複しないノード及び前記識別番号が割り当てられたノードに、識別番号の決定通知を送信する結果通知手段と、を有する。一意性のあるIDを効率的に付与する車載ネットワークを提供することができる。以下、本発明を実施するための形態について図面を参照しながら説明する。図1は本実施形態のID付与方式の概略を説明する図の一例である。本実施例の車載ネットワークでは、ECUA~ECUCが共通の共通ナンバーテーブルを有する。共通ナンバーテーブルには複数のナンバー例えば、00、01...08が登録されている。また、ECUA~ECUCは固有IDを有する。固有IDはどのようなものでもよいが、一意性が保証されたシリアルナンバーや製品番号等を用いることができる。IDが付与されていない状態のECUA~ECUCは、共有IDテーブルから無作為に決定したナンバーと固有IDを管理ECU200に送信する。管理ECU200は、ECUA~ECUCからナンバーと固有IDの組を受信して、まず、ナンバーが重複しているか否かを判定する。全く重複していなければ、管理ECU200はECUA~ECUCから受信したナンバーをそのままECUA~ECUCのIDに決定する。管理ECU200は決定したナンバーをECUA~ECUCに送信するので、各ECUは受信したナンバーを自機のIDとして記憶し、通信を開始する。なお、各ECUが記憶するIDとは、通信時に自機を相手先に識別させるための識別情報である。例えば、CANIDとして設定される。ナンバーが重複した場合、管理ECU200は、固有IDの例えば小さいECUを優先して、重複したナンバーを送信したECUのIDに決定する。管理ECU200は固有IDが大きかったその他のECUに対し、再度、ナンバーと固有IDの送信を要求する。これにより、固有IDが大きかったその他のECUが別のナンバーと固有IDを管理ECU200に再度、送信するので、管理ECU200は同様の手順ナンバーが重複している場合には固有IDの小さいECUを優先するで、IDの決まっていないECUのIDを決定する。このような手順によれば、管理ECU200は、共通ナンバーテーブルに登録されているナンバーの範囲で重複しないナンバーを各ECUに付与することができる。共通ナンバーテーブルにはネットワークに接続されうるECUの上限の数多くても最大10~20個より多い数のナンバーを用意しておけばよいので、共通ナンバーテーブルのサイズは実用的なサイズに抑制できる。また、ナンバーは十進数で2桁程度なので、固有IDをIDとするよりもIDの有効な桁数を十分に小さくできる。図2は、車載ネットワーク300の概略構成図を示す。車載ネットワーク300は、ECU200区別する場合、ECUA、ECUB、ECUC、ECU_Dという及び管理ECU200を電気的に接続し、所定のプロトコル例えば、CANControllerAreaNetworkプロトコルやLINLocalInterconnectNetworkプロトコル等に基づき、通信データの送受信を実現している。管理ECUElectronicControlUnit100は、各ECUにIDを付与するECUである。本実施形態では管理ECU200としてゲートウェイ装置を想定しているが、IDを付与するECUを他のECU例えばECUAとすることもできる。近年では機能統合が進んでおり、特定の機能のECUにゲートウェイ機能を統合し、ゲートウェイ装置としてのECUを省略することもある。管理ECU200は、車載ネットワーク300を複数のネットワークに分割することによって、通信データの通信量がもたらす負荷を緩和したり、例えばボディ系、情報AV系、制御系毎の系統別にネットワークを構築するために利用される。管理ECU200はフィルタリングルールに基づきECUA~ECUCが送信した通信データをECU_Dに又はその逆に中継する。本実施形態では、管理ECU200がネットワーク1のECUA~ECUCにIDを付与する付与方法について説明する。これは、ネットワーク2は、メーカ出荷時に接続されるECUが固定図ではECU_Dされているのに対し、ネットワーク1はナビゲーションシステムなどのディーラオプションが接続可能なネットワークであるためである。ECUAは例えば、ナビゲーションシステム用のECU、ECUBはリモートスタート用のECU、ECUCはセキュリティアラーム用のECUであるが、どのようなECUが接続されてもIDを付与することは可能である。なお、リモートスタート用のECUは、所定距離内のリモコンからエンジンスタート信号を送ると、乗員がいなくてもエンジンをスタートさせるECUである。また、セキュリティアラーム用のECUは、センサーにより例えば、ドア開、トランク開、ボンネット開、侵入者、車両傾斜等を検知し、アラーム音を発生させるECUである。これらのECUはディーラやユーザが市販品を装着することができる場合がある。図3は、管理ECU200、ECUA~ECUCのハードウェア構成図の一例を示す。ECUA~ECUCは、マイコン50やトランシーバ17、不図示の電源IC、ドライバ回路等を有するコンピュータ装置の一形態である。マイコン50は、バスを介して接続されたCPU11、メモリ12、DMAC13、INTC14、通信装置15、及びADC16を有する。CPU11はバスを介してメモリ12からプログラムを読み込み、また、必要であればバスを介してメモリ12にデータを読み書きしてプログラムを実行する。このプログラムには、ECUA~ECUCに特有の機能の他、管理ECU200からIDを取得するための機能が含まれる。INTCInterruptController14は各種の周辺機器から入力された割り込み要求を、周辺機器の優先順位に基づき調停してCPU11に通知する。これによりCPU11は、割り込みした周辺機器に応じて決まった処理を実行する。例えば、図では通信装置15が通信データを受信するとINTC14を経由してCPU11に通知する。CPU11は通信データを読み出して処理をする。また、ADCanalogtodigitalconverter16は、センサが検出したアナログ信号をデジタル信号に変換する。ADC16にはΔΣ型、逐次比較型、二重積分型などがあるがどのような変換原理で変換してもよい。なお、ADC16もINTC14を介して変換の終了をCPU11に通知する。DMACDirectMemoryAccessController13は、CPU11からの指示によりメモリ12から周辺機器にデータを送信し、また、周辺機器から割り込みされたCPU11から指示を受けて、不図示のバッファに記憶されたデータを読み出しメモリ12に書き込む。これにより、CPU11は通信装置15やADC16が取得したデータを使用できるようになる。通信装置15は、CANやFlexRay等の通信プロトコルに従って、ネットワークに通信データを送信し又ネットワークから通信データを受信する。CPU11が通信データを送信する場合、通信装置15の送信バッファに通信データを記憶させる。通信装置15にトランシーバ17が接続されており、通信データをシリアルの送信信号に変換してトランシーバ17の端子Txに出力する。トランシーバ17の送信回路171は、データの送信時、通信装置15が端子Txに入力した論理レベルの送信信号を、トランシーバ17対応する差動電圧に変換して1対のバスに出力する。CAN又はFrexRayの場合、ノイズに強い2本の信号線の差動電圧により通信データを送信する。データの受信時、トランシーバ17の受信回路172は、差動電圧が所定の電圧範囲に含まれるように整形して受信信号を生成し、通信装置15に出力する。通信装置15は所定の閾値電圧と受信回路172からの受信信号とを比較して論理レベルの通信データを再現する。ネットワーク1には複数のECUA~ECUCが接続されているので、1つのECUが送信した通信データはネットワーク1に接続された自機を除くECUA~ECUC及び管理ECU200に同報的に送信される。このため、CANプロトコルによるデータの受信時、通信装置15は、後述する通信データのデータIDを、予め定められている受信対象のデータIDと比較し、受信すべきデータをCPU11に出力し、それ以外は破棄する。また、トランシーバ17では、送信回路171の送信線が受信回路172に接続されている。すなわち、通信装置15は自機が送信した通信データを監視しており、より優先順位の高いECUが通信データを送信しているか否かを監視している。より優先順位の高いECUが通信データを送信していることを検出すると、通信装置15は通信データの送信を停止し、ランダムな時間待機した後、通信データを再送するCSMA/CDCarrierSenseMultipleAccessCollisionDetection。管理ECU200のハードウェア構成図も図3とほぼ同様になるが、管理用ECUはネットワーク1と2用の2つの通信装置15及びトランシーバ17を有している。また、CPU11をマルチコア又はマルチCPUなどの高負荷に対応したものにしてもよい。CANIDFrexRayID図4aはCANプロトコルの通信データのフォーマットを模式的に説明する図の一例を、図4bはFlexRayプロトコルの通信データのフォーマットの一例をそれぞれ示す。CANプロトコルの場合、通信データはフレームという単位で送信され、1つのフレームは、SoF、CANID、RTR、コントロールフィールド、データフィールド、CRC、ACK、EoFの各フィールドを有する。図の数値は各フィールドのビット数を示す。SOFは通信データの開始を表し他のECUと同期するために使用され、CANIDには送信元のECUを識別するためのIDが格納される。CANIDはネットワーク1上で一意性が保証されている必要がある。本実施形態で決定されるIDはCANIDに格納される値になる。また、CSMA/CDによる調停ではドミナントがリセッシブにより優先されるので、同時に送信を開始した2つ以上のECUでは最もCANIDが小さいECUが送信権を取得する。RTRはデータフィールドとリモートフレームデータフレームを要求するフレームの別を示す。コントロールフィールドはデータフィールドのバイト数を示す。CRCには誤り訂正符号が格納される。ACKには受信側のECUがCRCまでを正確に受信できたことを応答する値ドミナントが格納される。FlexRayプロトコルの場合スタティックセグメント、大きく3つのセグメントで1つの通信データを構成する。ヘッダセグメントは送信データに関する情報が、ペイロードセグメントには送信対象のデータが、トレイラセグメントにはCRCがそれぞれ格納される。各ECUを識別するためのIDはヘッダセグメントの先頭の1~5ビットステータスビットに続く11ビットのFrameIDフレームIDに格納される。なお、FrexRayプロトコルでは、各ECU毎にスタティックスロットが確保されているので、送信タイミングが重なることはない。具体的には、各通信装置15は1つのスタティックスロット周期が経過する毎に1つ増えるカウンタを有し、予め決められたカウント値のスタティックスロットで通信データを送信する。機能ブロック図5は、管理ECU200及び各ECU100の機能ブロック図の一例を示す。各ECU_A~ECUCは、通信部35、ナンバー決定部31、決定可否判定部32、及び、ID保持部33を有する。これらの各機能は、各CPU11がプログラムを実行し、上記のハードウェア構成と協働することで実現される。また、共通ナンバーテーブル20と固有ID34は、ECUA~ECUCの不揮発メモリに記憶されている。共通ナンバーテーブル20には、少なくともネットワーク1に接続される可能性のある数以上の整数のナンバーが登録されている。例えば、図では一例として00、01、02、03、04、05、06、07、08の9個のナンバーが表示されている。共通ナンバーテーブル20のナンバーは各ECUA~ECUCに共通である。ただし、要素としてのナンバーが同じなら各ナンバーの配置場所は異なっていてもよい。なお、共通ナンバーテーブル20は、静的である必要はなく、例えば00~08の整数を生成する手段で代用することもできる。固有ID34は、ECUのシリアルナンバー製造番号、製品の型番、生産年月日、ロット番号、又は、これらの組合せである。同じ種類のECUナビならナビが複数個、搭載されないという前提では、製品の型番が一致することはなく、同じ種類のECUナビならナビが複数個搭載されるのであれば、シリアルナンバー製造番号が一致することはない。したがって、シリアルナンバー製造番号や製品の型番を固有ID34とすることができる。なお、固有ID34が数字だけで構成されているとは限らないが、アルファベットはアスキーコードで表現されているので実質的には数値と同様に扱うことができる。ナンバー決定部31は、共通ナンバーテーブル20から1つのナンバーを決定する。不作為に決定してもよいし、小さい値から順に決定してもよいし、左上又は右上などの決まった場所から順にナンバーを決定してもよい。決定可否判定部32は、通信部35を介して管理ECU200から受信した重複判定結果に基づき、送信したナンバーが自機のIDとして受け付けられたか否かを判定する。重複判定結果は以下のような内容を有する。重複しない場合...ECU100が送信したナンバー重複した場合...重複したという旨のメッセージや記号例えば、FFFFなど共通ナンバーテーブル20に存在しない番号管理ECU200により送信したナンバーが自機のIDとして受け付けられない場合重複したという重複判定結果を受信した場合、決定可否判定部32はナンバー決定部31に再度のナンバーの決定を要求する。管理ECU200により送信したナンバーが自機のIDとして受け付けられた場合重複しないという重複判定結果を受信した場合、決定可否判定部32はID保持部33にナンバーを保持させる。ID保持部33は、一度特定されたナンバーを保持する記憶手段である。ID保持部33は不揮発メモリでも揮発性メモリのどちらでもよい。揮発性メモリの場合、電源供給されない状態になると、再度、管理ECU200が全てのECUのIDを決定する必要がある。しかし、例えば、新しくECUがネットワーク1に加わる場合は、他のECU100も電源供給されない状態になるので、新しくECUがネットワーク1に加わったタイミングで、他のECUを含めIDを決定することができる。不揮発メモリの場合、IDが一度決定されたECUは、電源供給されない状態になっても、再度、管理ECU200が決定する必要がない。通信部35は、CANID又はフレームIDに設定する値を決定し、通信プロトコルに応じて通信データのフレームを生成する。受信時には、データフィールド又はペイロードセグメントの内容をアプリ等に送出する。ID決定前通信部35は、固有ID34をCANID又はフレームIDに設定する。または、固有ID34とナンバーを合体させてCANID又はフレームIDに設定してもよい。固有ID34が11ビット以上の場合、一意性が保証しやすいLSBから11ビットをCANID又はフレームIDに設定する。この場合、CANプロトコルのデータフィールド又はFlexRayプロトコルのペイロードセグメントには、ナンバー決定部31が決定したナンバーが設定される。ID決定後通信部35は、ID保持部33が保持しているIDをCANID又はフレームIDに設定する。なお、IDが決定されID保持部33がIDを保持していることは、決定可否判定部32が、例えばID保持部33にIDが決定されたことを示すフラグをセットすることで判定される。管理ECU200は、通信部26、自ID決定部21、重複判定部22、最小固有ID決定部23,結果通信部24、及び、新規ID付与部25を有する。これらの各機能は、各CPU11がプログラムを実行し、上記のハードウェア構成と協働することで実現される。自ID決定部21は、管理ECU200のIDを決定する。管理ECU200もネットワーク1ではECUA~ECUCと異なるIDを有している必要がある。また、CANプロトコルにおいて、ゲートウェイ装置は、通信データを送信する際の優先度が最も高く設定される。したがって、自ID決定部21は、共通ナンバーテーブル20から最も小さいナンバーを自機のIDに決定する。または、管理ECU200のIDは、車両の出荷時に予め固定されていてもよい。しかしながら、管理ECU200は上記のように最も優先度が高いことが好ましいので、管理ECU200のIDは共通ナンバーテーブル20内で最も小さい値、又は、共通ナンバーテーブル20に登録されているどのナンバーよりも小さい値であることが好ましい。重複判定部22は、管理ECU200のIDと各ECUが送信するナンバーが重複するか否か、及び、各ECUが送信するナンバー同士に重複するナンバーがあるか否か、を判定する。管理ECU200のIDが予め決まっている場合、前者の判定は不要になる。管理ECU200のIDとECUA~ECUCが送信するナンバーが重複する場合、重複判定部22は重複したこと及び重複したECU100を結果通知部24に通知する。結果通知部24は、重複する旨の重複判定結果を、ナンバーを送信したECU100に送信する。これにより、ECU100のナンバー決定部31は再度、共通ナンバーテーブル20からナンバーを決定する。また、各ECU100が送信するナンバー同士に重複するナンバーがある場合、重複判定部22は最小固有ID決定部23に、ナンバーが重複した全てのECU100の固有IDを通知する。最小固有ID決定部23は、ナンバーが重複した複数のECUの固有ID34のうち、最も小さい固有ID34を決定し、結果通知部24に通知する。結果通知部24は、最も小さい固有ID34のECU100にナンバーを含む重複判定結果を送信する。ナンバーを含む重複判定結果はそのナンバーがECU100のIDに決定されたことを意味する。なお、最小固有ID決定部23は、ナンバーが重複した複数のECUの固有ID34のうち、最も大きい固有ID34を決定してもよい。固有ID34はECUA~ECUCの元々の優位性とは関係がないためである。しかしながら、CANプロトコルではCSMA/CDにより同時に送信を開始したECUのうち小さい固有ID34のECUを優先する。このため、固有ID34が小さいECU100を優先することは、管理用ECUに先に通信データを送信したECUが優先してIDが決定されるという作用をもたらす。また、結果通知部24は、固有ID34が最も小さくはなかったECU100に重複する旨の重複判定結果を送信する。これにより、ECU100のナンバー決定部31は再度、共通ナンバーテーブル20からナンバーを決定する。また、ECUA~ECUCが送信するナンバー同士に重複するナンバーがない場合、重複判定部22はその判定結果を結果通知部24に通知する。結果通知部24は、全てのECUA~ECUCにナンバーを含む重複判定結果を送信する。重複判定及びナンバー付与例図6は、管理ECU200によるナンバーの重複判定と付与を模式的に説明する図の一例である。ECUAは固有ID=10010、ECUBは固有ID=10015、ECUCは固有ID=11004、である。1ECUA~ECUCはそれぞれの固有IDを仮のIDにして、ECUAはナンバー01を、ECUBはナンバー03を、ECUCはナンバー03を、それぞれ管理ECU200に送信する。2管理ECU200の重複判定部22は、重複するナンバーがあるか否かを判定する。この例では、ECUBとECUCのナンバーが03なので、重複している。3まず、結果通知部24はナンバーが重複していないECUAにナンバー01を含む重複判定結果を送信する。4最小固有ID決定部23は、ナンバー03が共通したECUBとECUCの固有ID34のうち小さい方を特定する。10015<11004なので、ECUBを優先する。よって、結果通知部24はECUBにナンバー03を含む重複判定結果を送信する。5結果通知部24はナンバーが重複し、固有ID34も最小値でなかったECUCに、重複する旨の重複判定結果を送信する。6ECUCは新たにナンバー07を決定し管理ECU200に送信する。7ナンバー07は他のECUA、ECUBのナンバーと重複しないので、結果通知部24はナンバー07を含む重複判定結果を送信する。動作手順図7は、本実施例の車載ネットワーク300がIDを決定する手順を示すフローチャート図の一例である。この例は、ID保持部33のIDが電力供給のオフにより消失されてもよい場合に対応している。なお、ECUA~ECUCの処理手順は同じなので1つのECU100のみを示した。この手順は、バッテリが外されるなどして、管理ECU200を含む全てのECUへの電力供給がオフの状態から、バッテリが装着されオンになるとスタートする。電力供給がオンになると、管理ECU200及び各ECU100は再起動またはリセットするので、ネットワーク1を介した通信のためIDの決定手順を開始する。まず、ECU100のナンバー決定部31が共通ナンバーテーブル20から1つのナンバーを決定するS10。そして、通信部35は、固有ID34をCANID等に設定しナンバーをデータフィールド等に格納して管理ECU200に送信するS20。すると、ECU100は重複判定結果を受信するまで待機しS30、重複判定結果を受信すると決定可否判定部32がナンバーを含む重複判定結果を受信したか否かを判定するS40。ナンバーを含む重複判定結果を受信した場合、決定可否判定部32はID保持部33にナンバーを記憶するS50。これによりナンバーが確定し当該ECU100の処理は終了する。ナンバーを含む重複判定結果を受信しない場合、この場合、重複判定結果FFFFを受信したことになるので、ナンバー決定部31がステップS10からの処理を繰り返す。しかしながら、最高でもネットワーク1のECU100の数だけ繰り返すと全てのECU100はナンバーを決定できる。次に、管理ECU200の処理に移る。管理ECU200の自ID決定部21は、マイコン50が再起動すると自機のIDを決定するS110。そして、通信部26がECU100からナンバー及び固有IDを受信するS120。重複判定部22は、通信部26が受信した固有ID34とナンバーを対応づけてメモリ12に記憶していく。複数のECU100はプロトコルの制約上、同時にはナンバーと固有IDを送信できないので、重複判定部22は自機のIDを決定してから所定時間待機し、その間、ナンバーと固有IDの受信を継続しているS130。所定時間が経過すると、重複判定部22は、まず自IDと重複するナンバーがあるか否かを判定するS140。自IDと重複するナンバーがある場合、結果通知部24が自IDと重複するナンバーを送信したECUに重複する旨の重複判定結果を送信するS150。次に、重複判定部22は、ECUA~ECUCが送信したナンバーに重複があるか否かを判定するS160。重複がなければ、結果通知部24はナンバーを含む重複判定結果をナンバーの送信元のECUに送信するS170。管理ECU200は、確定した各ECUのナンバーをメモリ12に記憶しておく。重複がある場合、最小固有ID決定部23は重複するナンバーを送ったECUの固有IDのうち最も小さい固有ID34を決定するS180。そして、結果通知部24は、固有ID34が最も小さいECU100にナンバーを含む重複判定結果を送信するS190。一方、結果通知部24は、固有ID34が最も小さいECU以外のECUに重複判定結果FFFFを送信するS200。管理ECU200は、S120で受信したナンバーの数と、IDを決定したECU100の数ナンバーを含む重複判定結果の送信回数を比較するなどして、全てのECU100のIDを決定したか否かを判定するS210。全てのECU100のIDを決定するまでは、S120以下の処理が繰り返され、全てのECU100のIDを決定すると図7の手順は終了する。このように、管理ECU200は、バッテリが外されるなどしてネットワーク1のECUA~ECUCがIDを消失したタイミングで、共通ナンバーテーブル20に登録されているナンバーの範囲で重複しないIDをECU100に付与することができる。動作手順2図8は、本実施例の車載ネットワーク300がIDを決定する手順を示すフローチャート図の一例である。この例は、新たなECU100がネットワーク1に接続された場合に対応している。新たなECUをECUCとする。管理ECU200及びECUA、Bがリセットされた場合ECU_Cの接続時には、バッテリが外されるなどして管理用ECU200及びECUA、Bへの電力供給がオフになることが多い。この場合、管理用ECU200はECUA~ECUCに対し、図7と同様の手順でIDを決定する。管理ECU200及びECUA、Bがリセットされない場合ユーザによってはECUCの接続時に、バッテリを外さない場合がある。この場合、ECUCだけIDが付与されていない状況が生じるので、管理ECU200がECUCにのみIDを付与できれば便利である。まず、ネットワーク1に接続されたECUCは、マイコン50が起動すると、存在を通知するため固有ID34をCANID等に設定して通信データを送信するS250。このような動作は車載ネットワーク300の通信仕様である。管理ECU200の新規ID付与部25は、ECUCから通信データを受信するとS310、CANID又はフレームIDを抽出して、これらの値が共通ナンバーテーブル20に登録されているか否かを判定するS320。登録されている場合は、新たに接続されたECUCにはすでに共通ナンバーテーブル20から重複しないナンバーがIDとして付与されているので、処理は終了する。このような状況は、ECUCのID保持部33が不揮発メモリであり、以前にECUCがネットワーク1に接続されていた場合に生じる。登録されていない場合は、新たに接続されたECUCに共通ナンバーテーブル20からIDを付与する必要があるので、新規ID付与部25は、すでに他のECUA、Bに付与しているID及び自機のIDと重複しないナンバーを共通ナンバーテーブル20から決定するS330。新規ID付与部25は決定したナンバーをIDとしてECUCに送信するS340。ECUCの通信部35がナンバーを受信するのでS260、ID保持部33がIDを記憶するS270。このように、管理ECU200はECUA、ECUBと重複しない、IDを新たなECUCに付与できる。以上のように、本実施例の車載ネットワークは、桁数が短く統一された数値が登録されている共通ナンバーテーブルの範囲でIDを各ECUに付与することができる。共通ナンバーテーブルのサイズは実用的なサイズに抑制できる。実施例1の動作手順2では、新たに装着されたECUCに対し、管理ECU200が単に重複しない共通ナンバーテーブル20から重複しないIDを付与した。しかし、新たなECUCを装着することで、ECUA、BのID保持部33がIDを消失し、管理ECU200もECUA、BのIDを消失した場合、これらのECUA、Bに再度、IDを付与する。この場合、ECUCが共通ナンバーテーブル20を有していれば、実施例1の動作手順1のように管理ECU200がECUA~ECUCのIDを決定すればよい。しかし、ECUCが共通ナンバーテーブル20を有していない場合、ECUCが共通ナンバーテーブル20を取得する仕組みがあることが好ましい。そこで、本実施例では、ECUが共通ナンバーテーブル20を後天的に取得可能な車載ネットワークについて説明する。図9は、本実施例の管理ECU200の機能ブロック図の一例である。図9において図5と同一部の説明は省略する。図示するように、管理ECU200は共通ナンバー提供部27を有する。共通ナンバー提供部27は、バッテリがオフからオンになると、同報的に共通ナンバーテーブル20をECUA~ECUCに送信する。または、ECUA~ECUCから受信した通信データのCANID又はフレームIDが、共通ナンバーテーブル20に登録されていない値の場合、該ECUに共通ナンバーテーブル20を送信する。図10は、本実施例の車載ネットワーク300がIDを決定する手順を示すフローチャート図の一例である。なお、図10において図7と同一ステップの説明は省略する。バッテリが外されるなどしてリセットされた管理ECU200は共通ナンバーテーブル20をネットワーク1のECUA~ECUCに配信するS102。各ECU100は、共通ナンバーテーブル20を受信するS2。すでに共通ナンバーテーブル20を記憶しているECUA、Bは受信した共通ナンバーテーブル20を破棄してもよいし、上書きしてもよい。また、共通ナンバーテーブル20を記憶していないECUCは、共通ナンバーテーブル20を好ましくは不揮発メモリに記憶する。これにより、ECUCは共通ナンバーテーブル20からナンバーを決定しS10、管理ECU200に送信することができるS20。以降の処理は実施例1と同様になる。本実施例の車載ネットワーク300は、新たに接続されたECUCが共通ナンバーテーブル20を有していなくても、ECUA~ECUCに同じ仕組みでIDを付与することができる。本実施例では、ECUA~ECUCが複数のナンバーを送信する車載ネットワーク300について説明する。複数のナンバーを送信することで、管理ECU200は1回のナンバー及び固有IDの受信で、重複しないナンバーをIDに決定しやすくなる。図11は、本実施例の車載ネットワーク300がIDを決定する手順を示すフローチャート図の一例である。この例は、ID保持部33のIDが電力供給のオフにより消失されてもよい場合に対応している。なお、図11において図7と同一ステップの説明は省略する。まず、ECUのナンバー決定部31が共通ナンバーテーブル20から2つのナンバーを決定するS12。そして、通信部35は、固有ID34をCANID等に設定し2つのナンバーをデータフィールド等に格納して管理ECU200に送信するS22。次に、管理ECU200の処理に移る。管理ECU200の自ID決定部21は、再起動により自機のIDを決定するS110。そして、通信部26が各ECU100からそれぞれ2つのナンバーを受信するS122。重複判定部22は、通信部26が受信した固有ID34と2つのナンバーを対応づけてメモリ12に記憶していく。図ではECUAが0102ECUBが0304ECUCが0305を送信した。この後、管理ECU200は自IDとの重複の有無を判定する。そして、S160以下の処理において、ECUAの01と重複するナンバーはないので、重複判定部22はECUAのIDを01に決定する。ECUBの03はECUCの03と重複しているので、実施例1と同様に、重複判定部22は、ECUBのIDを03に決定する。ECUCの03はすでにECUBのIDになったので、重複判定部22は05をECUCのIDに決定する。すなわち、重複判定部22は、ECUから受信した2つのナンバーのうちどちらが、他のECUの送信したナンバーと一致しなければ重複していないと判定できる。このように1つのECU100について複数のナンバーの候補があれば、重複判定部22は重複しないECUを1回のナンバーの受信で特定しやすい。このため、早期に各ECUのIDが決定されるし、ネットワーク1の通信量も低減できる。"