JP5252374B2 - 車載通信ネットワークシステム - Google Patents

Description

この発明は車載通信ネットワークシステムに関する。

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

近年、自動車には多くの安全・快適機能が搭載され、こうした個々の機能の制御を司るＥＣＵ（electronic control unit）を車載ネットワークで接続して連携動作させることが行なわれている。こうした車載ネットワークとして代表的なものにＣＡＮ（Controller Area Network）があり、パワートレイン系、シャーシ系、ボデー系及び情報系の標準型シリアル通信ネットワークとして広く採用されている。ＣＡＮはデータ転送速度が最大１Ｍｂｐｓに規定された高速通信プロトコルであり、物理層は２線式（グランドを含めると３線）で、通信距離は最大１ｋｍである。すべてのノードは平等の立場であり、どのノードもマスターノードとなることができる。非同期式（調歩同期型）であるが、エッジ検出による再同期処理やビットスタッフィングなど、高精度のノード間同期を実現している。また、ノイズマージンを高めるためにツイストペア線を用いた差動伝送方式を採用し、バスアービトレーションや、エラーカウンタを用いたバス状態遷移など、信頼性の高いマルチマスタ方式通信を実現するため、プロトコル上種々の工夫がなされている。

しかし、上記のようなＣＡＮの特徴は、ネットワークコストの高騰化を招きやすい側面も有しており、例えばボデー系に分類される車体装備の中でも、電動ドアミラーやパワーウィンドウなど、高速できめ細かい制御がそれほど求められない機器制御用のネットワークとしては過剰スペックになりやすい欠点がる。そこで、この欠点を補うべく、簡易型のシリアル通信ネットワークとしてＬＩＮ（Local Interconnect Network）が提唱され、実搭載が進んでいる(特許文献１〜５）。ＬＩＮのデータ転送速度は最大１９．２ｋｂｐｓであり、半二重式ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）通信をもとにしたシンプルなプロトコルが採用され、一つの決まったマスターノードが複数のスレーブノードを管理する。ＬＩＮはＣＡＮと同様、非同期式（調歩同期型）であるが、シングマスタ方式であり、これを受けてＵＡＲＴによるノード構成やバスのシングルワイヤ化といった簡略なハードウェア構成に加え、マスタータスクをなすヘッダに同期フレームを組み込み、その時間補正用基準波形を参照してスレーブボーレートを補正する簡易型同期プロトコルを採用することにより、伝送レートは低いもののＣＡＮと比較して大幅なコスト削減が実現できる。

ところで、車載通信ネットワークを構築する際には、ＣＡＮとＬＩＮはそれぞれ独立に存在するのではなく、一つの車両上で共存させるケースが圧倒的に多い。具体的には、ＣＡＮクラスタを構成するノードのひとつをゲートウェイとして、これにＬＩＮクラスタを接続する形で複合ネットワークが構築される。ＬＩＮでは１マスター＋複数スレーブのプロトコルになっているので、ゲートウェイをなすＣＡＮノードをＬＩＮのマスターノードとして動作させる方式が一般的に多く採用されている。図２２は、ボデー系ＣＡＮクラスタにおける実例を示すもので、ボデー系主幹バス１０３（Ａ）により接続されたＣＡＮノード、具体的にはボデーＥＣＵ１０６（Ａ）とＡ／Ｃ（エアコン）ＥＣＵ１０６（Ｂ）とをそれぞれゲートウェイとして、Ｐ／Ｗ（パワーウィンドウ）ＥＣＵ１０４（Ａ）〜１０４（Ｄ）（「Ｄ」「Ｐ」「ＲＲ」「ＲＬ」は、それぞれ「運転席」「助手席」「後部右席」「後部左席」を示す）をスレーブノードとする２つのＬＩＮクラスタが形成されている。

図２２においては、同じＰ／ＷＥＣＵ１０４（Ａ）〜１０４（Ｄ）からなるスレーブノード群が、マスターノードをなすボデーＥＣＵ１０６（Ａ）とＡ／ＣＥＣＵ１０６（Ｂ）とに対応して冗長化して設けられており、それぞれ独立したＬＩＮクラスタを構成していたが、機能的には全く同一のスレーブノード群が重複して設けられているため高コスト化が避けがたい。この場合、ボデーＥＣＵ１０６（Ａ）とＡ／ＣＥＣＵ１０６（Ｂ）との間で１つのＬＩＮクラスタを共用化できれば無駄を省くことができるが、ＬＩＮはシングルマスタ方式であり、１本のＬＩＮ通信バス上に２つのマスターノードが存在することはプロトコル上許されない。

一方、プロトコル上の矛盾を生ずることなく、２つのマスターノードにより１つのスレーブノード群を共有化する接続方法としては、図２１に示すような方式が可能である。ここでは、ボデー系主幹バス１０３（Ａ）に接続されたボデー系ＥＣＵ１０６（Ａ）が一方のゲートウェイを、走行系専用バス１０３（Ａ）に接続された走行系ＥＣＵ１０６（Ｂ）が他方のゲートウェイを構成しており、これら２つのゲートウェイに４つのスレーブノード１０４（Ａ）〜１０４（Ｄ）からなるＬＩＮクラスタが共有化されている。４つのスレーブノード１０４（Ａ）〜１０４（Ｄ）は、具体的には、シート位置調整機構を制御するシートＥＣＵ１０４（Ａ）、ハンドルの上下位置ないし前後位置を調整するチルト・テレスコ機構を制御するチルテレＥＣＵ１０４（Ｂ）、アクセルやブレーキのペダル位置調整機構を制御するペダル調整ＥＣＵ１０４（Ｃ）、シートベルト位置調整機構を制御するシートベルトＥＣＵ１０４（Ｄ）からなる。

各スレーブノード１０４（Ａ）〜１０４（Ｄ）は、いずれもＬＩＮトランシーバを２個ずつ内蔵しており、それぞれ異なるゲートウェイにつながる２系統のＬＩＮ通信バス１０５（Ａ），１０５（Ｂ）により重複して接続されている。つまり、各スレーブノード１０４（Ａ）〜１０４（Ｄ）は、ボデー系ＥＣＵ１０６（Ａ）をマスターノードとする第一のＬＩＮクラスタ（１０５（Ａ））と、走行系ＥＣＵ１０６（Ｂ）をマスターノードとする第二のＬＩＮクラスタ（１０５（Ｂ））とに重複して所属する形となっている。

例えば、ユーザの利便や快適が優先されるシーンでは、上記ＬＩＮクラスタに、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置を、ユーザの運転しやすさや乗り込みやすさを考慮した適性位置に自動調整させる制御を行なうのが好適である。一方、衝突安全が重視されるシーンでは、上記各位置を、車がぶつかりそうなときの衝撃吸収を考慮した適性位置に自動調整させる制御を行なうのが好適である。しかし、各シーンの到来検知に必要なセンシングインフラ構成やシーン到来判定条件、及び目標となる適正位置はいずれも全く異なるので、前者においてはボデー系ＥＣＵ１０６（Ａ）をマスターノードとして、後者においては走行系ＥＣＵ１０６（Ｂ）をマスターノードとして、同じスレーブノード１０４（Ａ）〜１０４（Ｄ）を、敢えて異なるＬＩＮ通信バスを介して別系統制御する必要がある。

スレーブノード１０４（Ａ）〜１０４（Ｄ）を、どちらのＣＡＮノードをマスターノードとして制御するかは、上記のごとく到来しているシーン内容に応じて決定される。しかし、ゲートウェイをなす各ＣＡＮノード（１０６（Ａ），１０６（Ｂ））は、いずれも独立したＬＩＮマスターノードであり、シーン内容によってはそれら複数のＣＡＮノードが、同じスレーブノード１０４（Ａ）〜１０４（Ｄ）を同時に（つまり、競合して）制御しようとすることがありえる。この場合、いずれのＣＡＮノードがマスターノードの権限を獲得するかを、シーン内容に応じて調停する必要がある。これに対応して、次のような問題が発生する。
（１）上記調停を行なうための専用の通信線を上記ＣＡＮノード間に設ける必要がある。それらＣＡＮノードが同一のＣＡＮクラスタ上にある場合でも、ＣＡＮプロトコルに規定された調停方式は、ＣＳＭＡ／ＣＡ方式による、いわば早い者勝ちのバスアービトレーション方式が採用されているに過ぎず、特有のシーン到来に基づいて調停がなされるわけではないから、結局専用の通信線を設けるか、あるいは、設けない場合でも、ＬＩＮマスターノード調停を行なうためのＣＡＮ通信ソフトウェアを別途搭載する必要が生じる。
（２）ＬＩＮクラスタの物理層（通信線及びノード内のＬＩＮトランシーバ）を全て冗長化して設けなければならず、シングルワイヤ方式のＬＩＮのコストメリットが著しく阻害される。

本発明の課題は、シングルワイヤ方式のＬＩＮのコストメリットを損ねることなく、そのマスターノードを随時切替可能なＬＩＮクラスタを含む車載通信ネットワークシステムを提供することにある。

課題を解決するための手段及び発明の効果

本発明の車載通信ネットワークシステムは、複数のＬＩＮノードが単一のＬＩＮ通信バスにより接続されたＬＩＮクラスタを含むもので、上記の課題を解決するために、ＬＩＮクラスタをなすＬＩＮノードの２以上のものが、マスターノードとスレーブノードとの切り替えが可能な属性切替可能型ノードとされ、それら属性切替可能型ノードのいずれか１つをＬＩＮクラスタのマスターノードに、残余のものを該ＬＩＮクラスタのスレーブノードに、それぞれ切り替え可能に設定するマスター／スレーブ設定切替手段が設けられ、ＬＩＮ通信におけるデータ伝送に際してのメッセージフレーム構造が、マスタータスクとして送信されるヘッダと、スレーブタスクとして送信されるレスポンスとからなり、ヘッダ送受信とレスポンス送受信とを交互に繰り返す形で通信メッセージのやり取りがなされるとともに、前記属性切替可能型ノードには、前記マスターノードとして作動する際に前記ヘッダを前記ＬＩＮ通信バスに送出するヘッダ送出手段と、同じく前記レスポンスを受信するレスポンス受信手段と、前記スレーブノードとして作動する際に前記ヘッダを受信するヘッダ受信手段と、同じく前記レスポンスを前記通信バスに送出するレスポンス送出手段とが設けられていることを特徴とする。

この発明では、複数のＬＩＮノードが単一のＬＩＮ通信バスにより接続されたＬＩＮクラスタにおいて、含まれるＬＩＮノードの２以上のものを、マスターノードとスレーブノードとの切り替えが可能な属性切替可能型ノードとして構成し、それら属性切替可能型ノードのいずれか１つをＬＩＮクラスタのマスターノードに、残余のものを該ＬＩＮクラスタのスレーブノードに、それぞれ切り替え可能に設定するマスター／スレーブ設定切替手段を設けた。複数の属性切替可能型ノード間では、マスターノードの権限が随時受け渡し可能になるので、ある瞬間にマスターノードであるＬＩＮノードは常に１つに維持でき、ＬＩＮのプロトコルに反しない。従って、マスターノードとなりえるＬＩＮノードが同一スレーブノード群に対して複数設けられているにもかかわらず、ＬＩＮ通信バスは単一であり、物理層の無駄な冗長化を防止できる。また、属性切替可能型ノード間でどちらがマスターノードになるかの調停も、そのＬＩＮ通信バスを介して行なえばよいので、属性切替可能型ノード間に新たな通信線を設ける必要がない。

なお、属性切替可能型ノードは、マスターノードとスレーブノードとのいずれに設定されている場合でも、同じＬＩＮ通信バスによりＬＩＮクラスタ内の通信を行なうから、該属性切替可能型ノードを含めた各ＬＩＮノードは、ＬＩＮ通信バスに対応してＬＩＮトランシーバを１つのみ有したものとして構成すればよい。これにより、ＬＩＮ物理層の無駄な冗長化を防止する効果が一層高められる。

ＬＩＮ通信では、データ伝送に際してのメッセージフレーム構造がプロトコルにより規定されている。ＬＩＮ通信におけるデータ伝送に際してのメッセージフレーム構造は、マスタータスクとして送信されるヘッダと、スレーブタスクとして送信されるレスポンスとからなり、ＬＩＮプロトコルでは、ヘッダ送受信とレスポンス送受信とを交互に繰り返す形で通信メッセージのやり取りがなされる。本発明において各属性切替可能型ノードには、マスターノードとして作動する際にヘッダをＬＩＮ通信バスに送出するヘッダ送出手段と、同じくレスポンスを受信するレスポンス受信手段と、スレーブノードとして作動する際にヘッダを受信するヘッダ受信手段と、同じくレスポンスを通信バスに送出するレスポンス送出手段とが設けられる。つまり、従来のＬＩＮノードは、マスターノードかスレーブノードのどちらかに固定的に設定されていたので、マスターノードについてはヘッダ送信手段とレスポンス受信手段のみが、スレーブノードについてはヘッダ受信手段とレスポンス送信手段のみが設けられていた。しかし、本発明の属性切替可能型ノードは、ヘッダ及びレスポンスの送受信に係る上記４つの手段を全て具備することで、同一ＬＩＮノードでありながら、マスターノードとスレーブノードとのいずれかに随時切替が可能となる。

マスターノード権限の移転、すなわちノード属性切り替えの態様には、現在マスターノードとなっている属性切替可能型ノードが現在スレーブノードとなっている他の属性切替可能型ノードに対し、自分からマスターノード権限の委譲を申し出る委譲型移転パターンと、現在スレーブノードとなっている属性切替可能型ノードが、現在マスターノードとなっている他の属性切替可能型ノードにマスターノード権限の明け渡しを要求する要求型移転パターンとの２種類がある。いずれの場合も、委譲ないし要求を行なう相手のノードの了解を得た後、実際のマスターノード権限の移転が行なわれる形となる。しかし、マスターノードからのヘッダに対しスレーブノードがレスポンスにより応答するという、ヘッダ／レスポンスを単位としたメッセージ構造をプロトコルの基本とするＬＩＮにおいては、ＬＩＮ通信に基づく一連のノード属性切り替え処理が、スレーブノードからマスターノードへのレスポンス送信で終了しなければならない要請がある。この点を考慮すれば、ノード属性切り替え処理の開始側がマスターノードとなる委譲型移転パターンのほうが通信シーケンスは簡略となり、要求型移転パターンの通信シーケンスは、委譲型移転パターンの通信シーケンスを発展させる形で構築できる。以下、具体的に説明する。

まず、委譲型移転パターンを実現するには、各属性切替可能型ノードに次のような手段を設ける必要がある。
・マスター権限委譲申出通知手段：マスターノードに設定されている状態にて切替条件が成立した場合に、スレーブノードに設定されている他の属性切替可能型ノードのうち、当該切替条件と対応付けて予め指定されているものにマスター権限委譲を申し出るためのマスター権限委譲申出通知を、ＬＩＮ通信バスを介して行なう。この通知は、ＬＩＮプロトコルに従い、該マスターノードからのヘッダ送信にてなされる。
・マスター切替制御手段：スレーブノードに設定されている状態にてマスター権限委譲申出通知を受けた場合に、当該マスター権限を受諾するか否かを判定し、その判定結果を返信する。この返信は、ＬＩＮプロトコルに従い、該マスレーブノードからのレスポンス送信にてなされる。そして、権限を受諾する判定を行った場合に自身のノード設定をスレーブノードからマスターノードへ切り替える（スレーブノードでの内部処理である）。
・スレーブ切替制御手段：マスターノードに設定されている状態にて上記判定結果を受け、かつ、当該判定結果が権限受諾に関して肯定的であった場合に、自身のノード設定をマスターノードからスレーブノードに切り替える（マスターノードでの内部処理である）。

さて、ＬＩＮのメッセージ構造では、ヘッダにおいて、次の３つのフィールドを必須フィールドとして組み込むことがプロトコル上の要請となっている。
・ブレークフィールド（Ｓｙｎｃｈ Ｂｒｅａｋ）：メッセージの開始を示す。すなわち、ＬＩＮメッセージフレームの開始の通知を目的として、マスタータスクが送信する領域である。
・同期フィールド（Ｓｙｎｃｈ Ｆｉｅｌｄ）：時間補正用基準波形が組み込まれる。すなわち、クロック精度を必要とするスレーブノードが、クロック補正を行なうための領域である。
・識別子フィールド（Ｉｄｅｎｔ Ｆｉｅｌｄ）：通信先となるスレーブノードを特定する。すなわち、マスタータスクがレスポンス送信を行なうスレーブタスクを指定するための領域である。

また、レスポンスにおいては、次の２つのフィールドを必須フィールドとして組み込むことがプロトコル上の要請となっている。
・データフィールド（Ｄａｔａ Ｆｉｅｌｄ）：ヘッダの識別子フィールドにより通信先として指定されるに伴ない、送信対象となるデータを組み込まれる。つまり、スレーブタスクが、マスタータスクに対してデータを通知するための領域である。
・エラーチェックフィールド（Ｃｈｅｃｋ Ｓｕｍ）：スレーブタスクのレスポンスの正常／異常を判定するための領域である。異常判定はチェックサムにより行なわれる。

他方、ＬＩＮプロトコルは、ヘッダないしレスポンスから上記各フィールドが欠けることは禁じているが、上記以外のフィールドが含まれることについては特に禁じていない。委譲型移転パターンでは、マスターノード権限の委譲をマスターノード側から申し出る形となり、ヘッダ送信により該マスターノード権限の委譲申出通知を行なうので、この委譲申出通知を行なうための新たなフィールドをヘッダに設けることで、ＬＩＮプロトコルに整合しつつマスター権限委譲申出通知が可能となる。具体的には、ヘッダに次の追加フィールドを組み込む。
・委譲フィールド：マスターノードとなる属性切替可能型ノードがマスター権限委譲を行なうか否かを特定する。つまり、マスターノードがマスターの権限をスレーブノードに委任する領域である（以下、「Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ」とも称する）。

また、マスター権限委譲申出の対象となるスレーブノードでは、上記委譲フィールドによるマスターノードからの申出を受諾するか否かの判定結果をマスターノードに通知するための新たなフィールドをレスポンスに設けることで、ＬＩＮプロトコルに整合しつつマスター権限の委譲申出を受諾するか否かを通知することが可能となる。具体的には、レスポンスに次の追加フィールドを組み込む。
・委譲承認フィールド：スレーブノードとなる属性切替可能型ノードが、ヘッダの委譲フィールドが示すマスター権限委譲を承認するか否かを特定する。例えば、マスターノードからのマスター権限委任に対するエラー応答内容を返す領域（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ）として構成可能である。

ＬＩＮクラスタ内に複数のスレーブノードが含まれる場合、マスターノードは、いわゆるポーリング方式により、各スレーブノードに対し指定された順序にてヘッダ／レスポンスによるメッセージのやり取りを行なうことが可能である。ポーリング方式を採用する場合は、まず、属性切替可能型ノードを含む複数のＬＩＮノードに、予め定められたポーリングサイクルを規定するための通信順位が一義的に付与しておく。そして、各属性切替可能型ノードは、マスターノードに設定されている場合は、ヘッダ送出手段とレスポンス受信手段とに対し、ＬＩＮ通信バス上へのヘッダの送信を、対応するスレーブノードからのレスポンスの受信と交替しつつ、通信先となるスレーブノードをポーリングサイクルに従い順次変更しつつ繰り返し行なうようにする。

本発明において上記ポーリング方式を採用する場合、ＬＩＮクラスタ内の属性切替可能型ノードを含む全てのノードに上記通信順位が付与される。他方、本発明では、同じＬＩＮクラスタ内の複数の属性切替可能型ノード間でマスターノードが交代可能になっている点に特徴がある。こうしたマスターノードの交代を生じた場合も、上記ポーリングサイクルに従った通信シーケンスがなるべく維持されるように動作することが、該通信シーケンスへの各スレーブノードの参加公平性を保つ上で望ましいといえる。

例えば、マスター権限の委譲元となるマスターノードを委譲元ノード、マスター権限の委譲先となるスレーブノードを委譲先ノードとして、委譲型移転パターンでは、委譲元ノードは、ポーリングサイクルにおいて委譲先ノードの通信順位が到来するに伴ない、委譲フィールドに当該委譲先ノードをマスター権限委譲先として指定する内容を記述したヘッダを委譲先指定ヘッダとして送出することになる。委譲先ノードは該委譲先指定ヘッダを受信してマスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダに続くレスポンスを、委譲承認フィールドにマスター権限委譲を承認する内容を記述した委譲承認レスポンスとして送信するとともに自ノードをマスターノードに切り替え設定する。また、委譲元ノードは委譲承認レスポンスを受信して自ノードをスレーブノードに切り替え設定する。この場合、切り替え後のマスターノードは、自ノードの次に通信順位が定められたスレーブノードからポーリングサイクルを更新する形でヘッダの送信を開始するように定めておけば、切り替え前のマスターノードからのポーリングサイクルを円滑に引き継ぐことができる。

他方、マスターノードの切替が行なわれない場合、すなわち、委譲先ノードが委譲先指定ヘッダを受信した後、マスター権限の委譲を承認しない場合は、該委譲先ノードは、委譲先指定ヘッダに続くレスポンスを、委譲承認フィールドにマスター権限委譲を承認しない内容を記述して委譲非承認レスポンスとして送信するとともに自ノードをスレーブノードに設定維持するように構成する。他方、委譲元ノードは委譲非承認レスポンスを受信して自ノードをマスターノードに設定維持しつつ、委譲先ノードの次順位のスレーブノードを指定するヘッダを送出する。これにより、ポーリングサイクルに何ら乱れを生ずることなく継続することができる。

次に、要求型移転パターンを実現するには、各属性切替可能型ノードに次のような手段を設ける必要がある。
・マスター委譲要求通知手段：スレーブノードに設定されている状態にて切替条件が成立した場合に、マスターノードに設定されている他の属性切替可能型ノードに、マスター権限委譲を要求するマスター権限委譲要求通知を、ＬＩＮ通信バスを介して行なう。この通知は、ＬＩＮプロトコルに従い、該スレーブノードからのレスポンス送信にてなされる。
・スレーブ切替制御手段：マスターノードに設定されている状態にてマスター委譲要求通知を受けた場合に、要求されたマスター権限の委譲を受諾するか否かを判断し、その判断結果を返信する。この返信は、該マスターノードからのヘッダ送信にてなされる。そして、委譲受諾する場合に自身のノード設定をマスターノードからスレーブノードへ切り替える（マスターノードでの内部処理である）。
・マスター切替制御手段：スレーブノードに設定されている状態にて上記の判断結果を受け、かつ、当該判断結果がマスター権限の委譲に関して肯定的であった場合に、自身のノード設定をスレーブノードからマスターノードに切り替える（スレーブノードでの内部処理である）。

このように、要求型移転パターンでは、マスターノード権限の移転に直接関与する通信シーケンスが、委譲先ノードをなすスレーブノード（属性切替可能型ノード）のレスポンス送信から開始される。しかし、その後は、その要求を承認した委譲元ノードからのマスターノード権限の移転申出を行なうヘッダ（委譲フィールド）が続き、その申出を委譲先ノードが受諾するレスポンス（委譲承認フィールド）で通信シーケンスが完了する。つまり、要求型移転パターンでの通信シーケンスは、委譲型移転パターンの通信シーケンスの要部をなすヘッダ／レスポンスに先立って、権限要求のためのレスポンスが追加された構造をとることになる。

すなわち、要求型移転パターンでは、マスターノード権限の委譲をスレーブノード側から要求する形となり、レスポンス送信により該マスターノード権限の委譲要求を行なうので、この委譲要求を行なうための新たなフィールドをレスポンスに設けることで、ＬＩＮプロトコルに整合しつつマスター権限委譲要求が可能となる。具体的には、レスポンスに次の追加フィールドを組み込む。
・委譲要求フィールド：マスターノードとなる属性切替可能型ノードに対しマスター権限委譲を要求するか否かを特定する。つまり、スレーブノードからマスターノードになるという要求を出す領域である（以下、「Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ」ともいう）。

また、マスター権限委譲要求の対象となるマスターノードでは、上記委譲要求フィールドによるスレーブノードからの要求を受諾するか否かの判定結果をマスターノードに通知するための新たなフィールドをヘッダに設けることで、ＬＩＮプロトコルに整合しつつマスター権限の委譲要求を受諾するか否かを通知することが可能となる。具体的には、ヘッダに次の追加フィールドを組み込む。
・委譲要求承認フィールド：スレーブノードとなる属性切替可能型ノードがマスター権限委譲要求を承認するか否かを特定する。例えば、スレーブノードからのマスター権限委任要求に対するエラー応答内容を返す領域（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ）として構成可能である。

要求型移転パターンにおいては、委譲先ノードは、委譲要求フィールドに当該委譲先ノードをマスター権限委譲先とする要求を記述したレスポンスを委譲先指定レスポンスとして送出し、委譲元ノードは該委譲先指定レスポンスを受信してマスター権限の委譲を承認するか否かを判断する。そして、委譲元ノードが該委譲を承認する場合であるが、委譲型移転パターンと同様のシーケンスを採用すると、マスターノードの交代タイミングは、次にマスターノードとなるべき委譲先ノードの通信順位がすでに過ぎてしまっているので、委譲先ノードの通信順位が次に到来するまで、約１ポーリングサイクル分だけ待ち時間が生ずることとなる。もちろん、当該方式も本発明においては採用可能であるが、マスターノードの交代をより迅速に行なうには、次のような方式が好適である。

すなわち、委譲元ノードが該委譲を承認する場合は、現在マスターノードとなっている委譲元ノードがポーリングサイクルを、委譲先ノードから委譲先指定レスポンスを受けた段階で一旦打ち切る。そして、該委譲先指定レスポンスに続くヘッダを、委譲要求承認フィールドにマスター権限委譲要求を承認する内容を記述し、委譲フィールドに当該委譲先ノードをマスター権限委譲先として指定する内容を記述したヘッダを委譲先指定ヘッダとして、当該委譲先ノードからポーリングサイクルを再開する形で送出する。つまり、この場合に限っては、すでに過ぎたはずの委譲先ノードの通信順位を１回反復する形でポーリングサイクルを継続するのである。これにより、上記の待ち時間の短縮を図ることができる。その後、委譲先ノードは該委譲先指定ヘッダを受信してマスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダに続くレスポンスを、委譲承認フィールドにマスター権限委譲を承認する内容を記述した委譲承認レスポンスとして送信するとともに自ノードをマスターノードに切り替え設定し、自ノードの次に通信順位が定められたスレーブノードからポーリングサイクルを引き継ぐ形でヘッダの送信を新たに開始する。また、委譲元ノードは委譲承認レスポンスを受信して自ノードをスレーブノードに切り替え設定する。

なお、委譲元ノードが委譲先指定レスポンスを受信した後、マスター権限の委譲要求を拒否する場合は、委譲先指定レスポンスに続くヘッダを、委譲要求承認フィールドにマスター権限委譲要求を拒否する内容を記述した委譲要求拒否ヘッダとして送信するとともに自ノードをマスターノードに設定維持し、委譲先ノードの次順位のスレーブノードを指定するヘッダを送出する形でポーリングサイクルを継続する。これにより、ポーリングサイクルに何ら乱れを生ずることなく継続することができる。

メッセージフレームを、委譲型移転パターンと要求型移転パターンとの双方に対応可能に構築したい場合、ヘッダには委譲フィールドと委譲要求承認フィールドとの双方を、レスポンスには、委譲承認フィールドと委譲要求フィールドとの双方を設けることになる。ヘッダ及びレスポンスの各フィールドは、ヘッダないしレスポンスの先頭からの配置位置とフィールド長とを固定化することにより、それぞれスタートビットとストップビットとによりフィールドの切れ目さえ識別できれば、個々のフィールドを特定するための領域を設けずとも、受信側にて現在どのフィールドを受信中であるかを問題なく識別することができる。

次に、本発明の車載通信ネットワークシステムは、複数のＣＡＮノードがＣＡＮ通信バスにより接続されたＣＡＮクラスタと、複数のＬＩＮノードが単一のＬＩＮ通信バスにより接続され、前記ＣＡＮノードをゲートウェイノードとしてＣＡＮクラスタに接続されたＬＩＮクラスタとからなる複合車載通信ネットワークシステムとして構成できる。そして、複数のＣＡＮノードをゲートウェイノードとしてとして、ＬＩＮクラスタを構成する１つのＬＩＮ通信バスがそれら複数のゲートウェイノードに分配接続されるとともに、各ゲートウェイノードを属性切替可能型ノードとして構成することができる。

ＣＡＮノードをゲートウェイとして、これをＬＩＮマスターノードとして動作させる構成は、設計が簡単で安価であり、使用するマイコンに必要な数の通信チャネルとＣＰＵ性能があれば、一つのゲートウェイに複数のＬＩＮ通信バスを接続する設計も容易なので、車載通信ネットワークシステムの代表的なインフラ形態として幅広く実用化されている。しかし、この方式は、ゲートウェイとなるＣＡＮノードが故障すると、それにつながるＬＩＮクラスタ全体がダウンする恐れがあり、大きな欠点の一つとなっている。例えば、ＬＩＮノードのすべての機能が、接続先となるＣＡＮクラスタからの指令でのみ従属的に動作するような場合、特に、対象のＬＩＮクラスタがそれだけで機能的に閉じているような場合（例えば、スレーブノードにスイッチとランプが接続され、スイッチを入れればランプが点灯するといった機能）は、ゲートウェイが故障すれば、他のスレーブノードが全て正常であっても機能的には全く意味を成さず、そのＬＩＮクラスタが担う車載機能が一括して失われる可能性もある。

他方、上記のようなゲートウェイのトラブルからＬＩＮクラスタを守ることができる一つの方法として、ゲートウェイとなるＣＡＮノードをＬＩＮスレーブノードとして動作させる方式も実用化されている。例えば、ＬＩＮ２．０では、故障ノードの切り離しがプロトコルで規定されており、ゲートウェイの故障に対してはＣＡＮとほぼ同等の信頼性を確保することができる。しかしながら、ゲートウェイはＬＩＮスレーブノードとして働くので、ＬＩＮクラスタ内の(ゲートウェイをなさない）マスターノードには、ゲートウェイをなすＬＩＮスレーブノードに対し、ＣＡＮクラスタ側からのメッセージを定期的に確認するためのポーリング機能を追加しなければならない問題がある。

また、ＬＩＮでは、マスタータスクをなすヘッダに同期フレームを組み込み、その時間補正用基準波形を参照してスレーブボーレートを補正する簡易型同期プロトコルが採用されている。つまり、データ送信を行なう毎にマスターノードからの時間補正用基準波形に合わせてスレーブノードがボーレートを補正し、同期をとるようにしているのである。他方、ＣＡＮは比較的高伝送レートに対応できるマルチマスタ方式のシリアル通信プロトコルであり、エッジ検出による再同期処理やビットスタッフィングなど、より高精度のノード間同期機構を有する。従って、同期精度の高いＣＡＮノードを、ＬＩＮクラスタ内のマスターノードとして採用すれば、ＬＩＮクラスタ内の同期精度も高めることができる。しかし、ＣＡＮノードがスレーブノードとして使用される場合は、ＣＡＮ通信バスから切り離されたＬＩＮマスターノードが採用される限り、同等の同期精度を実現するのは困難になるか、たとえ実現できたとしても、ＬＩＮマスターノードの発振回路の高性能化や同期方式の複雑化など、コストアップが避けられなくなる。

しかしながら、本発明のごとく、ＬＩＮクラスタを構成する１つのＬＩＮ通信バスを、ＣＡＮノードをなす複数のゲートウェイノードに分配接続し、各ゲートウェイノードを属性切替可能型ノードとしてマスター／スレーブの切替を可能に構成しておくことで、現在マスターノードになっている属性切替可能型ノードが仮にダウンしても、他の生きている属性切替可能型ノードをマスターノードに切り替えることができる。これにより、当該ＬＩＮクラスタのフェールセーフ機能は格段に向上し、信頼性を飛躍的に高めることができる。また、マスターノードとなりうる属性切替可能型ノードはいずれもＣＡＮノードであるから、ＬＩＮクラスタ内の同期精度の確保も容易である。

マスター／スレーブ設定切替手段は、ＣＡＮクラスタ又はＬＩＮクラスタの通信状態を監視する通信状態監視手段を有し、監視中の通信状態において予め定められた切替条件が成立した場合に、複数の属性切替可能型ノードにおけるマスターノード及びスレーブノードの設定切替を行なうように構成できる。監視中の通信状態、つまり、複数の属性切替可能型ノードのうちシーンに応じてふさわしいものをマスターノードに随時切り替えることができ、よりきめ細かい制御が可能となる。この場合、通信状態（シーン）の予め定められた種別毎に、複数の属性切替可能型ノードについてマスターノードに設定するための優先順位を定めておくことができ、マスター／スレーブ設定切替手段は成立した通信状態（シーン）に対応する該優先順位に基づいて、マスターノード及びスレーブノードの設定切替を行なうように構成することができる。シーン別にマスターノードとするための優先順位を定めておくことで、マスターノード切り替えの判定アルゴリズムを大幅に簡略化することができる。

ＬＩＮ通信バスが分配接続される複数のゲートウェイノードは、互いに異なる制御系をなす複数のＣＡＮクラスタに振り分けて設けることができる。通信状態監視手段は、各ＣＡＮクラスタがＣＡＮ通信バスを介して取得する通信情報に基づき対応する制御系の制御状態を監視するものとして構成でき、マスター／スレーブ設定切替手段は、監視中の制御状態が予め定められた切替条件を成立した場合に、当該制御状態と対応付ける形で予め指定されたＣＡＮクラスタに属するゲートウェイノードをマスターノードに設定するように構成できる。制御目的の異なるＣＡＮクラスタ間で１つのＬＩＮクラスタを共有化することで、当該ＬＩＮクラスタが担う車載機能の適用対象シーンを顕著に拡大でき、ＬＩＮクラスタのさらなる有効活用を図ることができる。

一方、ＬＩＮ通信バスが分配接続される複数の上記ゲートウェイノードの一つを、ＬＩＮクラスタの正規マスターノードとして定める一方、残余のゲートウェイノードをなすスレーブノードを、正規マスターノードの機能の少なくとも一部を引継ぎ可能な代替マスターノード候補として定めておくこともできる。通信状態監視手段は、各ＣＡＮクラスタがＣＡＮ通信バスを介して取得する通信情報に基づき正規マスターノードの動作状態を監視するものであり、マスター／スレーブ設定切替手段は、監視中の正規マスターノードの動作状態に予め定められた内容の異常が検出された場合に、代替マスターノード候補をなすスレーブノードをマスターノードに設定切り替えするものとして構成できる。これにより、当該ＬＩＮクラスタの正規マスターノードがダウンしても、代替マスターノードによる引継ぎを迅速に行なうことができ、フェールセーフ機能を格段に向上させることができる。

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明の車載通信ネットワークシステムの一構成例を示すブロック図である。この車載通信ネットワークシステム１は、複数のＬＩＮノード４（Ａ）〜４（Ｄ），６（Ａ），６（Ｂ）が単一のＬＩＮ通信バス５により接続されたＬＩＮクラスタ５０を含む。ＬＩＮクラスタ５０をなすＬＩＮノード４（Ａ）〜４（Ｄ）、６（Ａ），６（Ｂ）の２以上のもの、すなわち、本実施形態においては、ノード６（Ａ），６（Ｂ）の２つが、マスターノードとスレーブノードとの切り替えが可能な属性切替可能型ノード６（Ａ），６（Ｂ）とされている。これら属性切替可能型ノード６（Ａ），６（Ｂ）のいずれか１つがＬＩＮクラスタ５０のマスターノードに、残余のものが該ＬＩＮクラスタ５０のスレーブノードに、それぞれ切り替え可能に設定される。

図１の構成においては、複数のＣＡＮノード（２（Ａ），６（Ａ）‥、及び２（Ｂ），６（Ｂ）‥）が、それぞれＣＡＮ通信バス３（Ａ），３（Ｂ）により接続されてＣＡＮクラスタ１００（Ａ），１００（Ｂ）を形成している。そして、そのうちのＣＡＮノード６（Ａ），６（Ｂ）をゲートウェイノード（以下、ゲートウェイノード６（Ａ），６（Ｂ）ともいう）として、上記のＬＩＮクラスタ５０がＣＡＮクラスタ１００（Ａ），１００（Ｂ）に接続され、複合車載通信ネットワークシステムが構成されている。ＬＩＮクラスタ５０を構成する単一のＬＩＮ通信バス５は、それら複数のゲートウェイノード６（Ａ），６（Ｂ）に分配接続されるとともに、各ゲートウェイノード６（Ａ），６（Ｂ）が属性切替可能型ノードとして構成されている。

ＬＩＮノード４（Ａ）〜４（Ｄ），６（Ａ），６（Ｂ）のうち、属性切替可能型ノード６（Ａ），６（Ｂ）を除いた残りのもの４（Ａ）〜４（Ｄ）は、ＬＩＮのスレーブノードとしてのみ機能することが可能であり、図２に示すように、それぞれ、例えば８ビットマイコン（１６ビットマイコンでもよい）を主体とするＵＡＲＴコントローラ４１を有し、ＬＩＮトランシーバ４２を介してシングルメタルワイヤからなるＬＩＮ通信バス５に接続される。

一方、ＣＡＮノード（２（Ａ），６（Ａ）‥、及び２（Ｂ），６（Ｂ）‥）のうち、属性切替可能型ノード６（Ａ），６（Ｂ）を除いた残りのもの２（Ａ），２（Ｂ）は、図２に示すように、それぞれ例えば３２ビットマイコン（１６ビットマイコンあるいは８ビットマイコンでもよい）を主体とするＣＡＮコントローラ４１を有し、ＣＡＮトランシーバ４２を介してツイストペア線からなるＣＡＮ通信バス３に接続される。

そして、ゲートウェイノード６（Ａ），６（Ｂ）は、それぞれ例えば３２ビットマイコンを主体とするＣＡＮ／ＬＩＮゲートウェイプロセッサ６１を有し、ＣＡＮトランシーバ２２を介してＣＡＮ通信バス３に、さらに、ＬＩＮトランシーバ４２を介してＬＩＮ通信バス５に、それぞれ接続される。

本発明においてＣＡＮ／ＬＩＮゲートウェイプロセッサ６１の動作には、ＬＩＮマスターノード、ＬＩＮスレーブノード及びＣＡＮノードとして動作することに加えて、データのバッファリング、タイミング制御、ＬＩＮとＣＡＮのプロトコル変換などのソフトウェアが必要となる。図３に、必要となる主なソフトウェアモジュールを、その相互関係ととともに図示する。

・ＬＩＮドライバ６０９：ＬＩＮ通信を実現するためのソフトウェアである。ＬＩＮマスターノードとして動作させるためのマスタードライバ６２２と、ＬＩＮスレーブノードとして動作させるためのスレーブドライバ６２３と、属性切替部６２１とを有し、属性切替部６２１は、メッセージ・スケジューラ６０７を経由して送られてくる、後述のＬＩＮメッセージフレーム（ヘッダないしレスポンス）の記述内容に従い、マスタードライバ６２２とスレーブドライバ６２３とのどちらかを動作させる。これにより、ＬＩＮマスターノード及びＬＩＮスレーブノードのいずれかとして、マイコン内のＵＡＲＴやタイマなどを制御しつつ通信を行なう。
・ＣＡＮドライバ６１０：ＣＡＮ通信を実現するためのソフトウェア。マイコン内のＣＡＮコントローラを制御して通信を行なう。

・ＩＤマッピング・テーブル６０６／メッセージ・フィルタ６０３：プロトコル変換を司る。ＩＤマッピング・テーブル６０６には、ＬＩＮとＣＡＮのＩＤ（識別子）変換情報を格納している。ゲートウェイ通信が必要なＩＤの場合、メッセージ・フィルタ６０３はＩＤマッピング・テーブル６０６に従って、ＣＡＮプロトコルのＩＤとＬＩＮプロトコルのＩＤを変換する。また、ＬＩＮメッセージ・バッファ６０４及びＣＡＮメッセージ・バッファ６０５へのメッセージ送受信要求の格納処理も行なう。
・エラー・ハンドラ６０８：エラー制御を司る。ＬＩＮドライバ６０９、ＣＡＮドライバ６１０、又は、ゲートウェイ自身からのエラーを含むエラー処理を行なう。

・ＬＩＮメッセージ・バッファ６０４／ＣＡＮメッセージ・バッファ６０５：データ・バッファリングを司る。ＦＩＦＯ（first-in first-out）リング・バッファで構成されており、ＬＩＮ又はＣＡＮへのメッセージ送受信要求を格納する。ＬＩＮ用及びＣＡＮ用の各独立のバッファで構成される。
・メッセージ・スケジューラ６０７：タイミング制御を司り、各メッセージ・バッファ６０４，６０５に問い合わせるためのタイミング機能を提供する。また、ＬＩＮメッセージ・バッファ６０４又はＣＡＮメッセージ・バッファ６０５から送受信要求を取得し、送受信データをＬＩＮドライバ６０９やＣＡＮドライバ６１０に引き渡す。

・ゲートウェイＡＰＩ（Application Programming Interface）６０２：各ノードからのデータ・フォワーディングのほか、ゲートウェイ自身の送受信機能を備える。基本ＡＰＩは、例えば、ＣＡＮネットワークへの送信要求、ＣＡＮネットワークへの受信要求（以上、マスター／スレーブ共通）、ＬＩＮマスターノードへの受信要求（ヘッダ受信＋レスポンス送信：スレーブノードとして機能時）、ＬＩＮスレーブノードへの送信要求（ヘッダ送信のみ）、ＬＩＮスレーブノードからの受信要求（ヘッダ送信＋レスポンス受信）、ＬＩＮスリープ・コマンド送信、ＬＩＮウェイクアップ送信（以上、マスターノードとして機能時）などからなる。
・ユーザ・アプリケーション６０１：後述のごとく、シーンに応じたマスター／スレーブの切替指令ならびに各スレーブノードでの上位制御指令とを司る。

図１のシステム構成においては、ＬＩＮクラスタ５０が接続されるゲートウェイノードはボデー系ＥＣＵ６（Ａ）と走行系ＥＣＵ６（Ｂ）であり、これらゲートウェイノードがそれぞれ属性切替可能型ノードとして、それぞれ異なるＣＡＮクラスタ１００Ａ，１００Ｂ上に設けられている。ＬＩＮクラスタ５０を構成する単一のＬＩＮ通信バス５は、これら２つのゲートウェイノード６（Ａ），６（Ｂ）に分配接続され、４つのスレーブノード４（Ａ）〜４（Ｄ）が上記ＣＡＮクラスタ１００Ａ，１００Ｂに共有化されている。

４つのスレーブノード４（Ａ）〜４（Ｄ）は、具体的には、シート位置調整機構を制御するシートＥＣＵ４（Ａ）、ハンドルの上下位置ないし前後位置を調整するチルト・テレスコ機構を制御するチルテレＥＣＵ４（Ｂ）、アクセルやブレーキのペダル位置調整機構を制御するペダル調整ＥＣＵ４（Ｃ）、シートベルト位置調整機構を制御するシートベルトＥＣＵ４（Ｄ）からなる。

ユーザの利便や快適が優先されるシーンでは、上記ＬＩＮクラスタ５０に、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置を、ユーザの運転しやすさや乗り込みやすさを考慮した適性位置に自動調整させる制御を行なう。一方、衝突安全が重視されるシーンでは、上記各位置を、車がぶつかりそうなときの衝撃吸収を考慮した適性位置に自動調整させる制御を行なう。前者においては、図４に示すようにボデー系ＥＣＵ６（Ａ）をマスターノード、走行系ＥＣＵ６（Ｂ）をスレーブノードとする形で、後者においては図６に示すように、走行系ＥＣＵ６（Ｂ）をマスターノード、ボデー系ＥＣＵ６（Ａ）をスレーブノードとする形で、ノード属性を切り替えつつ制御がなされる。以下、ノード属性設定状態を区別して表示する必要がある場合には、スレーブノードに設定されているゲートウェイードの符号には「’(ダッシュ）」を付与し、マスターノードに設定されているゲートウェイードの符号には「’(ダッシュ）」を付与しないことにより、両者を区別して表示するものとする。

属性切替可能型ノードとして構成される各ゲートウェイノード６（Ａ），６（Ｂ）は、図２に示すごとく、マスタードライバ６２２とスレーブドライバ６２３との双方を備えており（例えば、図１のスレーブノード４（Ａ）〜４（Ｄ）にはスレーブドライバ６２３のみが設けられる）、マスターノードとして作動する際にはＬＩＮメッセージフレームのヘッダを送出し（ヘッダ送出手段）、レスポンスを受信する（レスポンス受信手段）。他方、スレーブノード４として作動する際にはヘッダを受信し（ヘッダ受信手段）、レスポンスを送出する（レスポンス送出手段）。

ゲートウェイノード６（Ａ），６（Ｂ）の間でのノード属性切り替えパターン、すなわち、マスターノード権限の移転パターンには、次の２種類がある。
・委譲型移転パターン：現在マスターノードとなっているゲートウェイノード(図４では走行系ＥＣＵ６（Ｂ））が現在スレーブノードとなっているゲートウェイノード(図４ではボデー系ＥＣＵ６（Ａ）’）に対し、自分からマスターノード権限の委譲を申し出る。
・要求型移転パターン：現在スレーブノードとなっているゲートウェイノード(図４ではボデー系ＥＣＵ６（Ａ）’）が、現在マスターノードとなっているゲートウェイノード(図４では走行系ＥＣＵ６（Ｂ））にマスターノード権限の明け渡しを要求する。いずれの場合も、委譲ないし要求を行なう相手のノードの了解を得た後、実際のマスターノード権限の移転が行なわれる形となる。

ＬＩＮプロトコルでは、マスターノードからのヘッダに対しスレーブノードがレスポンス返すメッセージフレーム構造が基本となる。従って上記ノード属性の切替処理に係るシーケンスも、スレーブノードからマスターノードへのレスポンス送信で終了しなければならない要請がある。

本発明においては、図７に示すごとく、ＬＩＮのメッセージ構造に、プロトコル上必須のフィールドを維持しつつ、マスター権限の移転シーケンスを実現するための新たなフィールドを組み込むことにより、同一ノードのマスター／スレーブ属性切り替えを実現している。ヘッダには次のようなフィールドが設けられる。いずれのフィールドもスタートビットとストップビットとを除いて、
・ブレークフィールド（Ｓｙｎｃｈ Ｂｒｅａｋ）：ＬＩＮメッセージフレームの開始の通知を目的として、マスタータスクが送信する領域である。
・同期フィールド（Ｓｙｎｃｈ Ｆｉｅｌｄ）：クロック精度を必要とするスレーブノードが、クロック補正を行なうための領域である。
・識別子フィールド（Ｉｄｅｎｔ Ｆｉｅｌｄ）：マスタータスクが、レスポンス送信を行なうスレーブタスクを指定するための領域である。
・委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ）：マスターノードとなるゲートウェイノードがマスター権限委譲を行なうか否かを特定する。つまり、マスターノードがマスターの権限をスレーブノードに委任する領域である。
・委譲要求承認フィールド（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ）：スレーブノードとなる属性切替可能型ノードがマスター権限委譲要求を承認するか否かを特定する。スレーブノードからのマスター権限委任要求に対するエラー応答内容を返す領域として構成される。

また、レスポンスにおいては、次の２つのフィールドを必須フィールドとして組み込むことがプロトコル上の要請となっている。
・データフィールド（Ｄａｔａ Ｆｉｅｌｄ）：ヘッダの識別子フィールドにより通信先として指定されるに伴ない、送信対象となるデータを組み込まれる。つまり、スレーブタスクが、マスタータスクに対してデータを通知するための領域である。
・エラーチェックフィールド（Ｃｈｅｃｋ Ｓｕｍ）：スレーブタスクのレスポンスの正常／異常を判定するための領域である。異常判定はチェックサムにより行なわれる。
・委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ）：スレーブノードとなるゲートウェイノードが、ヘッダの委譲フィールドが示すマスター権限委譲を承認するか否かを特定する。マスターノードからのマスター権限委任に対するエラー応答内容を返す領域として構成される。
・委譲要求フィールド（Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ）：マスターノードとなるゲートウェイノードに対しマスター権限委譲を要求するか否かを特定する。つまり、スレーブノードからマスターノードになるという要求を出す領域である。

すなわち、図７の上に示す従来のＬＩＮメッセージフレーム構造に対し、本実施形態においては、委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ）と委譲要求承認フィールド（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ）とがヘッダに、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ）と委譲要求フィールド（Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ）とがレスポンスにそれぞれ追加された特有のメッセージフレーム構造が採用され、これによって委譲型移転パターンと要求型移転パターンとのいずれにも対応可能となっている。

ブレークフィールド、同期フィールド、識別子フィールド、データフィールド及びエラーチェックフィールドの構造については周知であるので、詳細な説明は略する。他方、本発明に特有の新たな４つのフィールドの構成例を図８〜図１１に示す。いずれのフィールドも、先頭にスタートビット、末尾にストップビットが付与される点については、上記周知のフィールドと同様である。

図８は、委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ）の構成例を示すもので、委譲元ノード（マスター）のＩＤと委譲先ノード（スレーブ）のＩＤとを特定するそれぞれ所定数ビット(この実施形態では各４ビット）のコード領域が形成されている。

図９は、委譲要求承認フィールド（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ）の構成例を示すもので、スレーブノードからのマスター権限委任要求に対するエラー応答内容として、エラー種別を特定する所定数ビット（この実施形態では８ビット）のコード領域が形成されている。該領域に記述されるエラー種別特定コードは、「マスター権限委譲要求」の承認及び非承認が互いに識別可能に記述される（例えば、特定ビット（例えば先頭ビット（ＩＤ０））が「１」のとき「承認」、「０」のとき非承認とするなど。このとき、残余ビットは、エラー詳細内容などの記述等に自由に使用可能である)。

図１０は、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ）の構成例を示すもので、マスターノードからのマスター権限委譲申出に対するエラー応答内容として、エラー種別を特定する所定数ビット（この実施形態では８ビット）のコード領域が形成されている。該領域に記述されるエラー種別特定コードは、「マスター権限委譲申出」の承認及び非承認が互いに識別可能に記述される（例えば、特定ビット（例えば先頭ビット（ＩＤ０））が「１」のとき「承認」、「０」のとき非承認とするなど。このとき、残余ビットは、エラー詳細内容などの記述等に自由に使用可能である)。

図１１は、委譲要求フィールド（Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ）の構成例を示すもので、委譲元ノード（マスター）のＩＤと委譲先ノード（スレーブ）のＩＤとを特定するそれぞれ所定数ビット（この実施形態では各４ビット）のコード領域が形成されている。

以下、図１の車載通信ネットワークシステム１の具体的な作動形態について説明する。図６を参照して説明すれば、ボデー系ＥＣＵ６（Ａ）がマスターノードとして設定されている場合、該マスターノード６（Ａ）は、ＬＩＮクラスタ５０内の複数のスレーブノード４（Ａ）〜４（Ｄ）及び６（Ｂ）’に対し、ポーリング方式により指定された順序にてヘッダ／レスポンスによるメッセージのやり取りを順次行なう。具体的には、ゲートウェイノード（属性切替可能型ノード）を含む複数のＬＩＮノード６（Ａ），６（Ｂ），４（Ａ）〜４（Ｄ）に、ポーリングサイクルを規定するための通信順位を一義的に付与しておく（例えば、６（Ａ）→６（Ｂ）→４（Ａ）→４（Ｂ）→４（Ｃ）→４（Ｄ）（→６（Ａ））：これを、以下ベースサイクルという）。そして、各ゲートウェイノード６（Ａ），６（Ｂ）は、自分がマスターノードに設定されている場合は（例えば、６（Ａ）とする）、上記ベースサイクルから自分自身を除いたものをポーリングサイクル（６（Ｂ）→４（Ａ）→４（Ｂ）→４（Ｃ）→４（Ｄ）（→６（Ｂ））として、ＬＩＮ通信バス５上へのヘッダの送信を、対応するスレーブノードからのレスポンスの受信と交替しつつ、通信先となるスレーブノードを該ポーリングサイクルに従い順次変更しつつ繰り返し行なう。

ＬＩＮクラスタ５０において、ゲートウェイノード６（Ａ），６（Ｂ）以外のＬＩＮノード４（Ａ）〜４（Ｄ）は、前述のごとく、ゲートウェイノード６（Ａ），６（Ｂ）に共有化されている形となっているが、この場合、２つのゲートウェイノード６（Ａ），６（Ｂ）のうち、ＬＩＮノード４（Ａ）〜４（Ｄ）に対して通常時にマスターノードとなる主ゲートウェイノード６（Ａ）と、予め定められたマスター権限移転条件が成立した場合にのみマスターノードとなる副ゲートウェイノード６（Ｂ）とを定めておくことができる。そして、マスター権限移転条件が成立したか否かを副ゲートウェイノード６（Ｂ）側で判定し、成立した場合は、副ゲートウェイノード６（Ｂ）から主ゲートウェイノード６（Ａ）にマスター権限委譲要求を行なう要求型移転パターンにより、マスター権限を副ゲートウェイノード６（Ｂ）に移転させ、その後、マスター権限移転条件の成立状態が解消された場合は、副ゲートウェイノード６（Ｂ）から主ゲートウェイノード６（Ａ）にマスター権限委譲申出を行なう委譲型移転パターンにより、副ゲートウェイノード６（Ｂ）から主ゲートウェイノード６（Ａ）にマスター権限を返還するように構成すると、より円滑な制御が可能となる。

例えば、図４に示す例では、４つのスレーブノード４（Ａ）〜４（Ｄ）が、シート位置調整機構、ハンドルの上下位置ないし前後位置を調整するチルト・テレスコ機構、アクセルやブレーキのペダル位置調整機構及びシートベルト位置調整機構の各制御ＥＣＵを構成している。これら機構は、いずれもユーザの運転しやすさや乗り込みやすさを考慮して、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置を適性位置に調整させるのが通常時に求められる機能である（つまり、ユーザの利便や快適が優先されるシーンに該当する）。従って、ボデー系ＥＣＵ６（Ａ）が主ゲートウェイノードとして定められ、通常時は上記４つのスレーブノード４（Ａ）〜４（Ｄ）に対するマスターノードとなって各機構の上位制御を司る。ボデー系ＥＣＵ６（Ａ）は、図１のＣＡＮクラスタ１００（Ａ）を構成する他のＣＡＮノード２（Ａ）‥から、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置に係る適正値を取得するか、あるいは、ユーザの身体サイズを計測するセンサ群の出力情報（これも、ＣＡＮクラスタ１００（Ａ）から取得する）に基づき、上記各位置の適正地を自律的に作成して、ＬＩＮ通信によりスレーブノード４（Ａ）〜４（Ｄ）に送信する。

一方、通常時にスレーブノードとなっている走行系ＥＣＵ６（Ｂ）は副ゲートウェイノードとして定められ、ＣＡＮクラスタ１００（Ｂ）を構成する他のＣＡＮノード２（Ｂ）‥から、衝突情報（例えば、衝突検出用加速度センサの出力値）を取得して、衝突の有無を判定する。そして、衝突ありと判定した場合は、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置を、車がぶつかりそうなときの衝撃吸収を考慮した適性位置に調整させるための制御を、スレーブノード４（Ａ）〜４（Ｄ）を介して緊急対応的に実施する。この場合、走行系ＥＣＵ６（Ｂ）は、マスター権限を走行系ＥＣＵ６（Ｂ）から一時的に譲り受けることで、スレーブノード４（Ａ）〜４（Ｄ）に対するマスターノードとして機能することが可能となる。

図１２は、この場合のポーリングシーケンスを示すものであり、走行系ＥＣＵ６（Ｂ）が委譲先ノード、ボデー系ＥＣＵ６（Ａ）が委譲元ノードとなる。まず、走行系ＥＣＵ６（Ｂ）は、ボデー系ＥＣＵ６（Ａ）からの先行するヘッダＨＰへ応答する形で、自身をマスター権限委譲先とする要求を委譲要求フィールド（Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ：図１１）に記述したレスポンスを委譲先指定レスポンスＲＢとして送出する。委譲元ノードであるボデー系ＥＣＵ６（Ａ）は、該委譲先指定レスポンスＲＢを受信してマスター権限の委譲を承認するか否かを判断する（衝突対応の場合は緊急性を有するので、走行系ＥＣＵ６（Ｂ）からのマスター権限委譲要求は最優先させる形で受諾するように構成しておくことが望ましい）。

ボデー系ＥＣＵ６（Ａ）（委譲元ノード）が該委譲を承認する場合は、現在のマスターノードであるボデー系ＥＣＵ６（Ａ）がポーリングサイクルを、走行系ＥＣＵ６（Ｂ）（委譲先ノード）からの委譲先指定レスポンスＲＢを受けた段階で一旦打ち切る。そして、該委譲先指定レスポンスＲＢに続くヘッダにおいて、委譲要求承認フィールド（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ：図９）にマスター権限委譲要求を承認する内容（すなわち、エラー種別特定コードの内容＝「正常」）を記述し、かつ、委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ：図８）に、走行系ＥＣＵ６（Ｂ）をマスター権限委譲先として（また、ボデー系ＥＣＵ６（Ａ）をマスター権限委譲元として）指定する内容を記述し、これを委譲先指定ヘッダＨＡとして送出する。委譲先ノードである走行系ＥＣＵ６（Ｂ）は、該委譲先指定ヘッダＨＡを受信してマスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダＨＡに続くレスポンスに、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ：図１０）にマスター権限委譲を承認する内容（エラー種別特定コードの内容＝「正常」）を記述して、これを委譲承認レスポンスＲＡとして送信するとともに自ノードをマスターノードに切り替え設定する。そして、自ノードの次に通信順位が定められたスレーブノード（図１２ではシートＥＣＵ２（Ａ））からポーリングサイクルを引き継ぐ形でヘッダの送信を新たに開始する。他方、委譲元ノードであるボデー系ＥＣＵ６（Ａ）は、該委譲承認レスポンスＲＡを受信して自ノードをスレーブノードに切り替え設定する。

なお、ボデー系ＥＣＵ６（Ａ）（委譲元ノード）が委譲先指定レスポンスＲＢを受信した後、マスター権限の委譲要求を拒否する場合は、図１３に示すように、委譲先指定レスポンスＲＢに続くヘッダを、委譲要求承認フィールドにマスター権限委譲要求を拒否する内容（エラー種別特定コードの内容＝「異常」）を記述した委譲要求拒否ヘッダＨＡ’として送信する。そして、自ノードをマスターノードに設定維持し、走行系ＥＣＵ６（Ｂ）（要求としては「委譲先ノード」であるが、実際には権限委譲はなされない）の次順位のスレーブノード（図１３ではシートＥＣＵ２（Ａ））を指定するヘッダを送出する形でポーリングサイクルを継続する。結局、ポーリングサイクルは、通信順位の飛びや重複を生ずることなく継続されていることがわかる。

この状態で、衝突検出状態が解消され、シート位置、ハンドル位置、ペダル位置及びシートベルト位置の衝突対応制御が不要となった場合は、スレーブノード４（Ａ）〜４（Ｄ）に係る上位制御主体、すなわちマスターノードを、通常通り主ゲートウェイノードであるボデー系ＥＣＵ６（Ａ）に速やかに復帰させる必要がある。衝突検出は引き続き走行系ＥＣＵ６（Ｂ）が行なうので、衝突検出状態が解消された場合は、走行系ＥＣＵ６（Ｂ）が委譲元ノード、ボデー系ＥＣＵ６（Ａ）が委譲先ノードとなる形で、委譲型移転パターンでによりマスター権限がボデー系ＥＣＵ６（Ａ）に移転・返還される。

図１２は、この場合のポーリングシーケンスを示すものである。委譲元ノードである走行系ＥＣＵ６（Ｂ）は、ポーリングサイクルにおいて委譲先ノードであるボデー系ＥＣＵ６（Ａ）の通信順位が到来するに伴ない、委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ：図８））に、ボデー系ＥＣＵ６（Ａ）をマスター権限委譲先として（また走行系ＥＣＵ６（Ｂ）をマスター権限委譲元として）指定する内容を記述し、これを委譲先指定ヘッダＨＡとして送出する。ボデー系ＥＣＵ６（Ａ）は該委譲先指定ヘッダＨＡを受信してマスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダＨＡに続くレスポンスにおいて、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ：図１０）にマスター権限委譲を承認する内容（エラー種別特定コードの内容＝「正常」）を記述し、これを委譲承認レスポンスＲＡとして送信するとともに自ノードをマスターノードに切り替え設定する。また、走行系ＥＣＵ６（Ｂ）は委譲承認レスポンスＲＡを受信して自ノードをスレーブノードに切り替え設定する。切り替え後のマスターノードであるボデー系ＥＣＵ６（Ａ）は、自ノードの次に通信順位が定められたスレーブノード（図１４では、走行系ＥＣＵ６（Ｂ））からポーリングサイクルを更新する形でヘッダの送信を開始する。

他方、マスターノードの切替が行なわれない場合、すなわち、ボデー系ＥＣＵ６（Ａ）が委譲先指定ヘッダＨＡを受信した後、マスター権限の委譲を承認しない場合は、図１５に示すように、該ボデー系ＥＣＵ６（Ａ）は、委譲先指定ヘッダＨＡに続くレスポンスにおいて、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ：図１０）にマスター権限委譲を承認しない内容（エラー種別特定コードの内容＝「異常」）を記述し、委譲非承認レスポンスＲＡ’として送信するとともに自ノードをスレーブノードに設定維持する。他方、走行系ＥＣＵ６（Ｂ）は委譲非承認レスポンスＲＡ’を受信して自ノードをマスターノードに設定維持しつつ、委譲先ノードの次順位のスレーブノード（図１５ではシートＥＣＵ２（Ａ））を指定するヘッダを送出する。

なお、上記実施形態では、ＬＩＮのメッセージフレームを、図７に示すように、委譲型移転パターンと要求型移転パターンとの双方に対応可能とするため、ヘッダには委譲フィールド（Ｄｅｌｅｇａｔｉｏｎ＿１ Ｆｉｅｌｄ）と委譲要求承認フィールド（Ｍａｓｔｅｒ Ｅｒｒｏｒ Ｆｉｅｌｄ）との双方を、レスポンスには、委譲承認フィールド（Ｓｌａｖｅ Ｅｒｒｏｒ Ｆｉｅｌｄ）と委譲要求フィールド（Ｄｅｌｅｇａｔｉｏｎ＿２ Ｆｉｅｌｄ）との双方を設けている。マスター権限の移転を行なうか否かは、委譲型移転パターンにおいてはヘッダに含まれる委譲フィールドの記述内容と、レスポンスに含まれる委譲承認フィールドの記述内容とを特定できれば十分であり、要求型移転パターンにおいてはレスポンスに含まれる委譲要求フィールドの記述内容と、ヘッダに含まれる委譲要求承認フィールドの記述内容とを特定できれば十分である（これらのフィールドを、以下、「有効フィールド」と称する）。従って、委譲型移転パターンにおいては委譲要求承認フィールドと委譲要求フィールドとが、要求型移転パターンにおいては委譲フィールドと委譲承認フィールドとが、それぞれ一見不要に見える（これらのフィールドを、以下、「冗長フィールド」と称する）。しかし、委譲型移転パターンと要求型移転パターンとのいずれを実施中であるかを判断して、個々の移転パターンでの冗長フィールドをその都度削除したりすると、ヘッダないしレスポンス中の追加フィールドが何を目的とした追加フィールドであるかを特定するのに、移転パターン種別の判別を含めた煩雑な内部処理が必要となる。従って、どちらの移転パターンが実施中であっても、ヘッダないしレスポンス内のフィールド構成は常に一定とされ、個々の移転パターンで冗長フィールドとなる追加フィールドも特に削除等は行なわれないようになっている。

上記実施形態の車載通信ネットワークシステム１の構成によると、ＬＩＮクラスタ５０において、複数のＬＩＮノード（ゲートウェイノード）６（Ａ），６（Ｂ）がマスターノードとスレーブノードとの切り替えが可能な属性切替可能型ノードとして構成され、それら属性切替可能型ノードのいずれか１つがＬＩＮクラスタ５０のマスターノードに、残余のものが該ＬＩＮクラスタ５０のスレーブノードに、シーンに応じて随時切り替え設定される（マスター／スレーブ設定切替手段）。それら属性切替可能型ノード６（Ａ），６（Ｂ）間では、マスターノードの権限が随時受け渡し可能になるので、ある瞬間にマスターノードであるＬＩＮノード４は常に１つに維持でき、ＬＩＮのプロトコルに反しない。従って、マスターノードとなりえるＬＩＮノード６（Ａ），６（Ｂ）が同一スレーブノード群に対して複数設けられているにもかかわらず、ＬＩＮ通信バス５は単一であり、物理層の無駄な冗長化を防止できる。また、属性切替可能型ノード（Ａ），６（Ｂ）間でどちらがマスターノードになるかの調停も、そのＬＩＮ通信バス５を介して行なえばよいので、両ノード（Ａ），６（Ｂ）間に図２１のような新たな通信線１０７を設ける必要もない。

そして、属性切替可能型ノード（ゲートウェイノード）６（Ａ），６（Ｂ）は、マスターノードとスレーブノードとのいずれに設定されている場合でも、同じＬＩＮ通信バス５によりＬＩＮクラスタ５０内の通信を行なう。従って、図２に示すように、各ＬＩＮノード（図２では、６（Ａ），６（Ｂ），４（Ａ）のみを図示）は、ＬＩＮ通信バス５に対応してＬＩＮトランシーバを１つのみ有したものとして構成できる。これにより、ＬＩＮ物理層の無駄な冗長化を防止する効果が一層高められている。

次に、ＬＩＮクラスタ５０を構成する１つのＬＩＮ通信バス５を、ＣＡＮノードをなす複数のゲートウェイノード６（Ａ），６（Ｂ）に分配接続し、各ゲートウェイノード６（Ａ），６（Ｂ）を属性切替可能型ノードとしてマスター／スレーブの切替を可能に構成しているので、現在マスターノードになっている属性切替可能型ノード（例えばボデー系ＥＣＵ６（Ａ））が仮にダウンしても、他の生きている属性切替可能型ノード（例えば走行系ＥＣＵ６（Ｂ））をマスターノードに切り替えることができる。これにより、当該ＬＩＮクラスタ５０のフェールセーフ機能は格段に向上し、信頼性を飛躍的に高めることができる。また、マスターノードとなりうるゲートウェイノード（属性切替可能型ノード）６（Ａ），６（Ｂ）はいずれもＣＡＮノードでもあるから、ＬＩＮクラスタ５０内の同期精度の確保も容易である。

この場合、ボデー系ＥＣＵ６（Ａ）をＬＩＮクラスタ５０の正規マスターノードとして定め、走行系ＥＣＵ６（Ｂ）を、その正規マスターノードの機能の少なくとも一部、例えばシート位置、ハンドル位置、ペダル位置あるいはシートベルト位置の、設定値（快適優先時）に自動調整する機能を引継ぎ可能な代替マスターノード候補として定めておけばよい。

図４を用いて説明したごとく、属性切替可能型ノードをなすボデー系ＥＣＵ６（Ａ）と走行系ＥＣＵ６（Ｂ）とは、それぞれ各ノードが監視中の通信状態に応じ、ユーザの利便や快適が優先されるシーン（つまり、通常時）と、安全性が優先されるシーン（つまり、衝突検出時）とを判別・検出し、各シーンふさわしいノード、すなわち前者においてはボデー系ＥＣＵ６（Ａ）を、後者においては走行系ＥＣＵ６（Ｂ）を、それぞれマスターノードに随時切り替えるので、シーンに応じたきめ細かい制御が可能となっている。なお、ユーザの利便や快適が優先されるシーン（通信状態）ではボデー系ＥＣＵ６（Ａ）に、安全性が優先されるシーン（通信状態）では走行系ＥＣＵ６（Ｂ）に、マスターノードに設定するための優先順位がそれぞれ高く設定され、各シーンに対応する該優先順位に基づいて、マスターノード及びスレーブノードの設定切替が行なわれていることも明らかである。

また、図１に示すごとく、ＬＩＮ通信バス５が分配接続される複数のゲートウェイノード６（Ａ），６（Ｂ）は、互いに異なる制御系（つまり、ボデー系と走行系）をなす複数のＣＡＮクラスタ１００（Ａ）と１００（Ｂ）とに振り分けて設けされている。制御目的の異なるＣＡＮクラスタ１００（Ａ），１００（Ｂ）間で１つのＬＩＮクラスタ５０を共有化することで、当該ＬＩＮクラスタ５０が担う車載機能（図１では、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置の自動調整機能）の適用対象シーンを、例えばボデー系が担う快適・利便性優先シーンだけでなく、走行系が担う安全優先シーンにも拡大でき、ＬＩＮクラスタ５０のさらなる有効活用が図られている。

なお、図１の車載通信ネットワークシステム１は、次のように動作させることも可能である。具体的には、駐車時のキースイッチポジションに応じて、ゲートウェイノード（属性切替可能型ノード）６（Ａ），６（Ｂ）の属性を切り替える態様である。車両には周知のスマートエントリー機能が実装されているものとする。車両が駐車状態であることは、車速センサの検出値が０で、シフトポジションセンサがパーキング（Ｐ）を検出していることで特定できる。図５に示すように、ＩＧ信号がＯＦＦ状態を示し、かつ、バッテリー電圧＋Ｂを受電している状態では、ボデー系ＥＣＵ６（Ａ）がマスターノード設定され、走行系ＥＣＵ６（Ｂ）は動作停止（つまり、電源ＯＦＦ）される。この状態では、ボデー系ＥＣＵ６（Ａ）は、例えばキー（無線携帯機）の接近を検知して、キーＩＤを検出・照合し、ドアロック施開錠制御のための制御指令等を行なう。

次に、図６に示すように、ＩＧ信号がＯＮとなり、かつ、車室内に乗員が検出されていない場合は、走行系ＥＣＵ６（Ｂ）はノードとしての作動を開始するが、駐車状態であることをボデー系ＥＣＵ６（Ａ）が検知し、ボデー系ＥＣＵ６（Ａ）は走行系ＥＣＵ６（Ｂ）にスレーブノード設定（つまり、マスター機能の停止）を要求する。そして、キーのＩＤから乗員を特定できた場合に、当該乗員が、運転しやすさや乗り込みやすさを考慮して予め設定登録した、シート位置、ハンドル位置、ペダル位置あるいはシートベルト位置を適性位置に自動調整する。

この状態で、車速が一定以上に増加して走行検出状態に移行した場合は、快適性を優先した各位置の調整はすでに終わっているので、走行系ＥＣＵ６（Ｂ）にマスター権限の委譲を申し出ることで、走行系ＥＣＵ６（Ｂ）を上記位置調整機構に係るＬＩＮクラスタ５０のマスターノードに切り替える。走行系ＥＣＵ６（Ｂ）は、ボデー系ＥＣＵ６（Ａ）が設定済みの各位置を基本位置として、衝突時（あるいは急加速、急減速等）等の衝撃吸収のために必要な各位置の制御を行なう。

次に、図１６は、他の制御系への本発明の適用例を示すものである。該例においては、ボデーＥＣＵ６（Ａ）とＡ／Ｃ（エアコン）ＥＣＵ６（Ｂ）とが属性切替可能型ノード（それぞれ、図示しないＣＡＮクラスタ上に設けられたゲートウェイノードである）とされている。また、ＬＩＮクラスタ５０の残余のスレーブノード４（Ａ）〜４（Ｄ）は、それぞれＰ／Ｗ（パワーウィンドウ）ＥＣＵ１０４（Ａ）〜１０４（Ｄ）（「Ｄ」「Ｐ」「ＲＲ」「ＲＬ」は、それぞれ「運転席」「助手席」「後部右席」「後部左席」を示す）である。

上記の構成は、エアコンをより効率的に動作させるために、パワーウィンドウをエアコンと連係制御することを目的とする。図１６の上に示すように、ボデー系ＥＣＵ６（Ａ）は、ドアロックやＩＧ信号の状態あるいはシフトポジションセンサの検出状態などを参照することにより駐車状態かどうかを判断し、Ａ／Ｃ ＥＣＵ６（Ｂ）にその判断結果に係る情報を送信する。この時、ボデー系ＥＣＵ６（Ａ）はマスターノードに設定され、Ａ／ＣＥＣＵ６（Ｂ）はスレーブノードに設定される。

この状態でＡ／ＣＥＣＵ６（Ｂ）によるエアコン制御が開始された場合、ボデー系ＥＣＵ６（Ａ）のシーン判断情報、例えば窓に設けられた凍結センサが凍結状態を検出した場合は、ボデー系ＥＣＵ６（Ａ）からＡ／ＣＥＣＵ６（Ｂ）にマスター権限委譲申出がなされ、マスターノードをＡ／ＣＥＣＵ６（Ｂ）に切り替える。図１７は、この場合のノード属性切替えを含むポーリングシーケンスを示すものであるが、基本的な流れは図１４と全く同じなので、詳細な説明は略する（図１９は、Ａ／ＣＥＣＵ６（Ｂ）が該委譲申出を拒否する場合のポーリングシーケンスを示す：基本的な流れは図１５と全く同じである）。Ａ／ＣＥＣＵ６（Ｂ）がマスターノードとなってパワーウィンドウを制御する場合は、パワーウィンドウスイッチがユーザにより手動操作された場合も、例えば凍結状態が解消されるまでは特定座席（例えば運転席以外の全ての座席）のパワーウィンドウ動作を禁止する態様を例示できる。一方、凍結状態が解消されてエアコン制御との連携が不要となった場合は、ボデー系ＥＣＵ６（Ａ）からＡ／ＣＥＣＵ６（Ｂ）にマスター権限委譲要求がなされ、マスターノードをデー系ＥＣＵ６（Ａ）に復帰させる。図１８は、この場合のノード属性切替えを含むポーリングシーケンスを示すものであるが、基本的な流れは図１２と全く同じなので、詳細な説明は略する。

なお、凍結時以外にも、例えば炎天下の駐車状態にてエアコンが作動したとき、パワーウィンドウを開方向に作動させ、車室内の熱気の車外放出促進を行なうような制御態様を例示できる。この場合は、車室内温度が閾値異常に上昇している場合、ボデー系ＥＣＵ６（Ａ）からＡ／ＣＥＣＵ６（Ｂ）にマスターノードを切り替える。このとき、Ａ／ＣＥＣＵ６（Ｂ）は、パワーウィンドウスイッチがユーザにより手動操作されずとも、特定座席（例えば全ての座席）のパワーウィンドウを自動的に開動作させる制御等を行なう。そして、車室内温度が一定レベル以下に下がり、連携制御の必要がなくなった場合は、ボデー系ＥＣＵ６（Ａ）をマスターノードに復帰させる。

次に、図２０は、パワーウィンドウ制御系をなすＬＩＮクラスタ５０において、ボデー系ＥＣＵ６（Ａ）をＬＩＮクラスタ５０の正規マスターノードとし、ボデー系ＥＣＵ６（Ａ）と同じＣＡＮクラスタ上にある管理ＥＣＵ６（Ｂ）（通常時はスレーブノード）を、正規マスターノードの機能の少なくとも一部を引継ぎ可能な代替マスターノード候補として定めている。管理ＥＣＵ６（Ｂ）は、各ＣＡＮクラスタ１００がＣＡＮ通信バス３を介して取得する通信情報に基づき正規マスターノードであるボデー系ＥＣＵ６（Ａ）の動作状態を監視する。そして、監視中のボデー系ＥＣＵ６（Ａ）（正規マスターノード）の動作状態に予め定められた内容の異常が検出された場合は、代替マスターノード候補をなす管理ＥＣＵ６（Ｂ）をマスターノードに設定切り替えする。これにより、当該ＬＩＮクラスタ５０の正規マスターノードがダウンしても、代替マスターノードによる引継ぎを迅速に行なうことができ、フェールセーフ機能を格段に向上させることができる。

この場合、管理ＥＣＵ６（Ｂ）は、例えばＣＡＮ通信にてボデー系ＥＣＵ６（Ａ）との交信を試み、交信不能になった場合はＬＩＮクラスタ５０のマスターノードに切り替える。このとき、正規マスターノードであるボデー系ＥＣＵ６（Ａ）は、ＬＩＮフレームを経由したマスター権限移転のシーケンスが実行不能になっている可能性が高いので、上位プロトコルをなすＣＡＮ通信側からの指令によりボデー系ＥＣＵ６（Ａ）をＬＩＮ通信バス５から切り離し、管理ＥＣＵ６（Ｂ）をマスターノードに切り替える。

なお、以上説明した実施形態においては、１つのＬＩＮクラスタに含まれる属性切替可能型ノードの数は２つであったが、これは３つ以上であってもよい。この場合、３つ以上の属性切替可能型ノードの一つをマスターノードに設定し、残余のものはスレーブノードに設定するか、ＬＩＮクラスタから切り離す。また、属性切替可能型ノードは必ずしもＣＡＮノード（すなわち、ゲートウェイノード）である必要はなく、例えば、ＣＡＮクラスタから独立したＬＩＮクラスタにおいても本発明の概念は適用可能である。また、複数の属性切替可能型ノードの一部のみをゲートウェイノードとし、残余のものを、ゲートウェイノードを構成しないＬＩＮノードとして構成してもよい。

本発明の車載通信ネットワークシステムの第一構成例を示す概略ブロック図。 図１の車載通信ネットワークシステムの要部を、各ノードの内部ブロックとともに示す図。 ゲートウェイノードのソフトウェアモジュール構造の一例を示すブロック図。 図１の車載通信ネットワークシステムの第一の作用説明図。 図１の車載通信ネットワークシステムの第二の作用説明図。 図１の車載通信ネットワークシステムの第三の作用説明図。 図１の車載通信ネットワークシステムにて使用するＬＩＮフレーム構造を、従来のＬＩＮフレーム構造と対比して示す説明図。 委譲フィールドの構成例を示す説明図。 委譲要求承認フィールドの構成例を示す説明図。 委譲承認フィールドの構成例を示す説明図。 委譲要求フィールドの構成例を示す説明図。 図１の車載通信ネットワークシステムにおける要求型移転パターンでのポーリングシーケンスを示す図（正常時）。 図１の車載通信ネットワークシステムにおける要求型移転パターンでのポーリングシーケンスを示す図（異常時）。 同じく委譲型移転パターンでのポーリングシーケンスを示す図（正常時）。 同じく委譲型移転パターンでのポーリングシーケンスを示す図（異常時）。 本発明の車載通信ネットワークシステムの第二構成例を示す概略ブロック図。 図１６の車載通信ネットワークシステムにおける委譲型移転パターンでのポーリングシーケンスを示す図（正常時）。 同じく要求型移転パターンでのポーリングシーケンスを示す図（正常時）。 同じく委譲型移転パターンでのポーリングシーケンスを示す図（異常時）。 本発明の車載通信ネットワークシステムの第三構成例を示す概略ブロック図。 従来の車載通信ネットワークシステムの構成を示す第一のブロック図。 従来の車載通信ネットワークシステムの構成を示す第二のブロック図。

符号の説明

１ 車載通信ネットワークシステム
２ ＣＡＮノード
３ ＣＡＮ通信バス
５ ＬＩＮ通信バス
４ ＬＩＮノード（スレーブノード）
６ ゲートウェイノード（属性切替可能型ノード）
ＨＡ 委譲先指定ヘッダ
ＲＡ 委譲承認レスポンス
ＲＢ 委譲先指定レスポンス

Claims (14)

1. 複数のＬＩＮノードが単一のＬＩＮ通信バスにより接続されたＬＩＮクラスタを含む車載通信ネットワークシステムであって、
   前記ＬＩＮクラスタをなす前記ＬＩＮノードの２以上のものが、マスターノードとスレーブノードとの切り替えが可能な属性切替可能型ノードとされ、それら属性切替可能型ノードのいずれか１つを前記ＬＩＮクラスタのマスターノードに、残余のものを該ＬＩＮクラスタのスレーブノードに、それぞれ切り替え可能に設定するマスター／スレーブ設定切替手段が設けられ、
   ＬＩＮ通信におけるデータ伝送に際してのメッセージフレーム構造が、マスタータスクとして送信されるヘッダと、スレーブタスクとして送信されるレスポンスとからなり、ヘッダ送受信とレスポンス送受信とを交互に繰り返す形で通信メッセージのやり取りがなされるとともに、
   前記属性切替可能型ノードには、前記マスターノードとして作動する際に前記ヘッダを前記ＬＩＮ通信バスに送出するヘッダ送出手段と、同じく前記レスポンスを受信するレスポンス受信手段と、前記スレーブノードとして作動する際に前記ヘッダを受信するヘッダ受信手段と、同じく前記レスポンスを前記通信バスに送出するレスポンス送出手段とが設けられていることを特徴とする車載通信ネットワークシステム。
2. 前記属性切替可能型ノードには、
   前記マスターノードに設定されている状態にて前記切替条件が成立した場合に、前記スレーブノードに設定されている他の前記属性切替可能型ノードのうち、当該切替条件と対応付けて予め指定されているものにマスター権限委譲を申し出るためのマスター権限委譲申出通知を、前記ＬＩＮ通信バスを介して行なうマスター権限委譲申出通知手段と、
   前記スレーブノードに設定されている状態にて前記マスター権限委譲申出通知を受けた場合に、当該マスター権限を受諾するか否かを判定し、その判定結果を返信するとともに、権限を受諾する判定を行った場合に自身のノード設定をスレーブノードから前記マスターノードへ切り替えるマスター切替制御手段と、
   前記マスターノードに設定されている状態にて前記判定結果を受け、かつ、当該判定結果が前記権限受諾に関して肯定的であった場合に、自身のノード設定をマスターノードから前記スレーブノードに切り替えるスレーブ切替制御手段と、
   を有する請求項１記載の車載通信ネットワークシステム。
3. 前記ヘッダには、メッセージの開始を示すブレークフィールドと、時間補正用基準波形を組み込んだ同期フィールドと、通信先となるスレーブノードを特定する識別子フィールドと、前記マスターノードとなる属性切替可能型ノードが前記マスター権限委譲を行なうか否かを特定するための委譲フィールドとが組み込まれ、
   他方、前記レスポンスには、前記ヘッダの前記識別子フィールドにより通信先として指定されるに伴ない、送信対象となるデータを組み込んだデータフィールドと、エラーチェックフィールドと、前記スレーブノードとなる属性切替可能型ノードが、前記ヘッダの前記委譲フィールドが示す前記マスター権限委譲を承認するか否かを特定する委譲承認フィールドとが組み込まれている請求項１記載の車載通信ネットワークシステム。
4. 前記属性切替可能型ノードを含む複数の前記ＬＩＮノードには、予め定められたポーリングサイクルを規定するための通信順位が一義的に付与されており、
   各前記属性切替可能型ノードは、前記マスターノードに設定されている場合は、前記ヘッダ送出手段と前記レスポンス受信手段とに対し、前記ＬＩＮ通信バス上への前記ヘッダの送信を、対応するスレーブノードからの前記レスポンスの受信と交替しつつ、通信先となるスレーブノードを前記ポーリングサイクルに従い順次変更しつつ繰り返し行なうものであり、
   前記マスター権限の委譲元となるマスターノードを委譲元ノード、前記マスター権限の委譲先となるスレーブノードを委譲先ノードとして、
   前記委譲元ノードは、前記ポーリングサイクルにおいて前記委譲先ノードの通信順位が到来するに伴ない、前記委譲フィールドに当該委譲先ノードをマスター権限委譲先として指定する内容を記述したヘッダを委譲先指定ヘッダとして送出し、
   前記委譲先ノードは該委譲先指定ヘッダを受信して前記マスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダに続くレスポンスを、前記委譲承認フィールドに前記マスター権限委譲を承認する内容を記述した委譲承認レスポンスとして送信するとともに自ノードをマスターノードに切替設定し、自ノードの次に通信順位が定められたスレーブノードから前記ポーリングサイクルを更新する形で前記ヘッダの送信を開始する一方、
   前記委譲元ノードは前記委譲承認レスポンスを受信して自ノードをスレーブノードに切替設定する請求項３記載の車載通信ネットワークシステム。
5. 前記委譲先ノードが前記委譲先指定ヘッダを受信した後、前記マスター権限の委譲を承認しない場合は前記委譲先指定ヘッダに続くレスポンスを、前記委譲承認フィールドに前記マスター権限委譲を承認しない内容を記述して委譲非承認レスポンスとして送信するとともに自ノードをスレーブノードに設定維持し、
   前記委譲元ノードは前記委譲非承認レスポンスを受信して自ノードをマスターノードに設定維持しつつ、前記委譲先ノードの次順位のスレーブノードを指定するヘッダを送出する形で前記ポーリングサイクルを継続する請求項４記載の車載通信ネットワークシステム。
6. 前記属性切替可能型ノードには、
   前記スレーブノードに設定されている状態にて前記切替条件が成立した場合に、前記マスターノードに設定されている他の前記属性切替可能型ノードに、マスター権限委譲を要求するマスター権限委譲要求通知を、前記ＬＩＮ通信バスを介して行なうマスター委譲要求通知手段と、
   前記マスターノードに設定されている状態にて前記マスター委譲要求通知を受けた場合に、要求されたマスター権限の委譲を受諾するか否かを判断し、その判断結果を返信するとともに、委譲受諾する場合に自身のノード設定をマスターノードから前記スレーブノードへ切り替えるスレーブ切替制御手段と、
   前記スレーブノードに設定されている状態にて前記判断結果を受け、かつ、当該判断結果が前記マスター権限の委譲に関して肯定的であった場合に、自身のノード設定をスレーブノードから前記マスターノードに切り替えるマスター切替制御手段と、
   を有する請求項２ないし請求項５のいずれか１項に記載の車載通信ネットワークシステム。
7. 請求項３に記載の要件を備え、
   前記レスポンスには、前記マスターノードとなる属性切替可能型ノードに対し前記マスター権限委譲を要求するか否かを特定する委譲要求フィールドが組み込まれ、
   前記ヘッダには、前記スレーブノードとなる属性切替可能型ノードが前記マスター権限委譲要求を承認するか否かを特定するための委譲要求承認フィールドが組み込まれている請求項６記載の車載通信ネットワークシステム。
8. 前記属性切替可能型ノードを含む複数の前記ＬＩＮノードには、予め定められたポーリングサイクルを規定するための通信順位が一義的に付与されており、
   各前記属性切替可能型ノードは、前記マスターノードに設定されている場合は、前記ヘッダ送出手段と前記レスポンス受信手段とに対し、前記ＬＩＮ通信バス上への前記ヘッダの送信を、対応するスレーブノードからの前記レスポンスの受信と交替しつつ、通信先となるスレーブノードを前記ポーリングサイクルに従い順次変更しつつ繰り返し行なうものであり、
   前記委譲先ノードは、前記委譲要求フィールドに当該委譲先ノードをマスター権限委譲先とする要求を記述したレスポンスを委譲先指定レスポンスとして送出し、
   前記委譲元ノードは該委譲先指定レスポンスを受信して前記マスター権限の委譲を承認するか否かを判断し、承認する場合は、前記ポーリングサイクルを前記委譲先ノードから前記委譲先指定レスポンスを受けた段階で一旦打ち切るとともに、該委譲先指定レスポンスに続くヘッダを、前記委譲要求承認フィールドに前記マスター権限委譲要求を承認する内容を記述し、前記委譲フィールドに当該委譲先ノードをマスター権限委譲先として指定する内容を記述したヘッダを委譲先指定ヘッダとして、当該委譲先ノードから前記ポーリングサイクルを再開する形で送出し、
   前記委譲先ノードは該委譲先指定ヘッダを受信して前記マスター権限の委譲を承認するか否かを判断し、承認する場合は該委譲先指定ヘッダに続くレスポンスを、前記委譲承認フィールドに前記マスター権限委譲を承認する内容を記述した委譲承認レスポンスとして送信するとともに自ノードをマスターノードに切替設定し、自ノードの次に通信順位が定められたスレーブノードから前記ポーリングサイクルを引き継ぐ形で前記ヘッダの送信を新たに開始する一方、
   前記委譲元ノードは前記委譲承認レスポンスを受信して自ノードをスレーブノードに切替設定する請求項７記載の車載通信ネットワークシステム。
9. 前記委譲元ノードが前記委譲先指定レスポンスを受信した後、前記マスター権限の委譲要求を拒否する場合は、前記委譲先指定レスポンスに続くヘッダを、前記委譲要求承認フィールドに前記マスター権限委譲要求を拒否する内容を記述した委譲要求拒否ヘッダとして送信するとともに自ノードを前記マスターノードに設定維持し、前記委譲先ノードの次順位のスレーブノードを指定するヘッダを送出する形で前記ポーリングサイクルを継続する請求項８記載の車載通信ネットワークシステム。
10. 複数のＣＡＮノードがＣＡＮ通信バスにより接続されたＣＡＮクラスタと、複数の前記ＬＩＮノードが単一の前記ＬＩＮ通信バスにより接続され、前記ＣＡＮノードをゲートウェイノードとして前記ＣＡＮクラスタに接続された前記ＬＩＮクラスタとからなる複合車載通信ネットワークシステムとして構成され、
    複数の前記ＣＡＮノードを前記ゲートウェイノードとして、前記ＬＩＮクラスタを構成する１つの前記ＬＩＮ通信バスがそれら複数のゲートウェイノードに分配接続されるとともに、各ゲートウェイノードが前記属性切替可能型ノードとして構成されてなる請求項１ないし請求項９のいずれか１項に記載の車載通信ネットワークシステム。
11. 前記マスター／スレーブ設定切替手段は、前記ＣＡＮクラスタ又は前記ＬＩＮクラスタの通信状態を監視する通信状態監視手段を有し、監視中の通信状態において予め定められた切替条件が成立した場合に、複数の前記属性切替可能型ノードにおける前記マスターノード及び前記スレーブノードの設定切替を行なう請求項１０記載の車載通信ネットワークシステム。
12. 前記通信状態の予め定められた種別毎に、複数の前記属性切替可能型ノードについて前記マスターノードに設定するための優先順位が定められており、前記マスター／スレーブ設定切替手段は成立した通信状態に対応する該優先順位に基づいて、前記マスターノード及び前記スレーブノードの設定切替を行なう請求項１１記載の車載通信ネットワークシステム。
13. 前記ＬＩＮ通信バスが分配接続される複数の前記ゲートウェイノードが、互いに異なる制御系をなす複数のＣＡＮクラスタに振り分けて設けられ、
    前記通信状態監視手段は、各前記ＣＡＮクラスタが前記ＣＡＮ通信バスを介して取得する通信情報に基づき対応する前記制御系の制御状態を監視するものであり、前記マスター／スレーブ設定切替手段は、監視中の制御状態が予め定められた切替条件を成立した場合に、当該制御状態と対応付ける形で予め指定されたＣＡＮクラスタに属するゲートウェイノードを前記マスターノードに設定するものである請求項１１又は請求項１２に記載の車載通信ネットワークシステム。
14. 前記ＬＩＮ通信バスが分配接続される複数の前記ゲートウェイノードの一つが、前記ＬＩＮクラスタの正規マスターノードとして定められる一方、残余のゲートウェイノードをなすスレーブノードが、前記正規マスターノードの機能の少なくとも一部を引継ぎ可能な代替マスターノード候補として定められ、
    前記通信状態監視手段は、各前記ＣＡＮクラスタが前記ＣＡＮ通信バスを介して取得する通信情報に基づき前記正規マスターノードの動作状態を監視するものであり、前記マスター／スレーブ設定切替手段は、監視中の前記正規マスターノードの動作状態に予め定められた内容の異常が検出された場合に、前記代替マスターノード候補をなすスレーブノードを前記マスターノードに設定切り替えするものである請求項１３記載の車載通信ネットワークシステム。

Images