(57)【要約】【課題】ステータス管理方式の異なるノードが混在するシステムにおいて、全てのノードのスリープ／ウェイクアップを管理できるようにする。【解決手段】スリープ遷移では、一方のステータス管理方式に対応した全ノードでスリープ条件成立したときに、他方のステータス管理方式に従ってスリープ状態を通知し、他方のステータス管理方式に対応した全ノードでスリープ条件成立したときは、一方のステータス管理方式に従ってスリープ状態を通知すると共に、ウェイクアップ遷移では、一方のステータス管理方式に対応する、少なくとも１つのノードでウェイクアップ条件が成立したときは、他方のステータス管理方式に従ってウェイクアップ状態を通知し、他方のステータス管理方式に対応する、少なくとも１つのノードでウェイクアップ条件が成立したときは、一方のステータス管理方式に従ってウェイクアップ状態を通知するゲートウェイ装置を設ける。【選択図】      図１
2005159864.tif 000002
【特許請求の範囲】
【請求項１】
第１のステータス管理方式によりスリープ／ウェイクアップが制御される複数のノードからなる第１のノード群と、第２のステータス管理方式によりスリープ／ウェイクアップが制御される複数のノードからなる第２のノード群とを伝送路上に接続してなるデータ通信システムにおいて、
前記第１のノード群に所属する全ノードでスリープ条件が成立したときは、前記第２のノード群に所属する各ノードに対し、前記第２のステータス管理方式に従ってスリープ状態を通知し、また前記第２のノード群に所属する全ノードでスリープ条件が成立したときは、前記第１のノード群に所属する各ノードに対し、前記第１のステータス管理方式に従ってスリープ状態を通知し、且つ、前記第１のノード群に所属する、少なくとも１つのノードでウェイクアップ条件が成立したときは、前記第２のノード群に所属する各ノードに対し、前記第２のステータス管理方式に従ってウェイクアップ状態を通知し、また前記第２のノード群に所属する、少なくとも１つのノードでウェイクアップ条件が成立したときは、前記第１のノード群に所属する各ノードに対し、前記第１のステータス管理方式に従ってウェイクアップ状態を通知するゲートウェイ装置を設けたことを特徴とするデータ通信システム。
【請求項２】
前記ゲートウェイ装置は、前記第１のノード群に所属する全ノードからスリープ条件成立のステータス情報を含むデータフレームを受信したときは、スリープ条件非成立のステータス情報を含むステータスフレームの送信を停止し、また、前記第２のノード群に所属するノードからスリープ条件非成立のステータス情報を含むステータスフレームを所定時間受信しないときは、スリープ条件成立のステータス情報を含むデータフレームを送信し、且つ、前記第１のノード群に所属する、少なくとも１つのノードからスリープ条件非成立のステータス情報を含むデータフレームを受信したときは、スリープ条件非成立のステータス情報を含むステータスフレームを送信し、また前記第２のノード群に所属するノードからスリープ条件非成立のステータス情報を含むステータスフレームを受信したときは、スリープ条件非成立のステータス情報を含むデータフレームを送信することを特徴とする請求項１に記載のデータ通信システム。
【請求項３】
前記第１のノード群に所属する各ノードは、第１のステータス管理方式として、自ノードのスリープ条件が成立したときは、スリープ条件成立のステータス情報を含むデータフレームを送信し、所定時間内に他のノード又は前記ゲートウェイ装置からスリープ条件非成立のステータス情報を含むデータフレームを受信しないときはスリープ状態へ移行し、また自ノードのウェイクアップ条件が成立したときは、所定時間経過後にスリープ条件非成立のステータス情報を含むデータフレームを送信してウェイクアップ状態へ移行する処理を実行し、
前記第２のノード群に所属する各ノードは、第２のステータス管理方式として、自ノードのスリープ条件が成立したときは、スリープ条件非成立のステータス情報を含むステータスフレームの送信を停止し、所定時間内に他のノード又は前記ゲートウェイ装置からスリープ条件非成立のステータス情報を含むステータスフレームを受信しないときはスリープ状態へ移行し、また自ノードのウェイクアップ条件が成立したときは、所定時間経過後にスリープ条件非成立のステータス情報を含むステータスフレームを送信してウェイクアップ状態へ移行する処理を実行すること、
を特徴とする請求項１又は２に記載のデータ通信システム。
【請求項４】
前記第１のノード群に所属する各ノードは、第１のステータス管理方式として、ウェイクアップ状態では、スリープ条件非成立又はスリープ条件成立のステータス情報を含むデータスフレームを定期送信し、スリープ状態では、前記データフレームの定期送信を停止し、
前記第２のノード群に所属する各ノードは、第２のステータス管理方式として、ウェイクアップ状態では、スリープ条件非成立のステータス情報を含むステータスフレームを定期送信し、スリープ状態では、前記ステータスフレームの定期送信を停止すること、
を特徴とする請求項１乃至３のいずれか一項に記載のデータ通信システム。
【請求項５】
前記ゲートウェイ装置は、少なくとも、
スリープ条件成立又はスリープ条件非成立のステータス情報を含むデータフレームを作成するデータフレーム作成手段と、
スリープ条件非成立のステータス情報を含むステータスフレームを作成するステータスフレーム作成手段と、
前記伝送路に接続され、自装置で作成したデータフレーム又はステータスフレームを他のノードに送信し、また、他のノードから送信されたデータフレーム又はステータスフレームを受信する通信制御部と、
他のノードから送信された前記データフレームを受信する複数のデータ受信用バッファと、
他のノードから送信された前記ステータスフレームを受信するステータス受信用バッファと、
受信したフレームに含まれる識別情報に基づいて当該フレームの種類を判別し、受信したフレームがデータフレームであれば前記識別情報で特定される前記データ受信用バッファに受信し、また受信したフレームがステータスフレームであれば前記ステータス受信用バッファに受信するフレーム識別部と、
ウェイクアップ状態において、前記第１のノード群に所属する全ノードからスリープ条件成立のステータス情報を含むデータフレームを受信したときは、前記ステータスフレームの送信を停止させ、また前記第２のノード群に所属するノードから前記ステータスフレームを所定時間受信しないときは、スリープ条件成立のステータス情報を含むデータフレームを送信させる処理を実行し、スリープ状態において、前記第１のノード群に所属する少なくとも１つのノードからスリープ条件非成立のステータス情報を含むデータフレームを受信したときは、前記ステータスフレームを送信させ、また前記第２のノード群に所属するノードから前記ステータスフレームを受信したときは、スリープ条件非成立のステータス情報を含むデータフレームを送信させる処理を実行するＩＤ管理部と、
を備えることを特徴とする請求項２乃至４のいずれか一項に記載のデータ通信システム。
【請求項６】
前記ゲートウェイ装置は、前記第１のノード群又は前記第２のノード群に所属する１つのノードに設けられることを特徴とする請求項１乃至５のいずれか一項に記載のデータ通信システム。
【請求項７】
前記ゲートウェイ装置を設けるノードは、表示系ノードであることを特徴とする請求項１乃至６のいずれか一項に記載のデータ通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、車両などの各部に配置されたノードをネットワークで接続したデータ通信システムに関し、詳しくは、ステータス管理方式の異なる２つのネットワークシステム間でのネットワークマネージメントに関する。
【背景技術】
【０００２】
従来より、車両内の各部に配置されたスイッチ系ノード、ランプ系ノード、メータ系ノードなどの各ノードをネットワークで接続した車両用データ通信システムが知られている。このシステムでは、各ノード毎に固有のＩＤ（識別情報）が割り当てられ、各ノードが固有のＩＤを付加したデータフレームをネットワークを介して他のノードへ定期送信することで、各ノード間で相互に多重通信を行うことができる。
【０００３】
このような多重通信を行うシステムとして、１つのデータＩＤを複数のノードで共有することにより、効率良くデータＩＤを割り付けることができるようにした多重伝送装置がある（例えば、特許文献１参照）。
【特許文献１】特開２０００−８３０３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記のようなデータ通信システムにおいて、各ノードは他のノードから送信されたデータフレームをＩＤで識別し、ＩＤ毎に個別の受信バッファで受信している。これにより、各ノードにおいて他の全てのノードのステータス（スリープ／ウェイクアップ）を管理することができる。
【０００５】
しかしながら、機能の多様化に伴い、既存のシステムに新規のシステムが接続されることがある。すなわち、既存のシステムとはステータス管理方式が異なるノードにより構成された新規のシステムが、既存のシステムに統合されるケースである。
【０００６】
上記のようなシステム統合が行われた場合、既存のシステムに対応する各ノードでは、新規のシステムに対応するノードから送信されたフレームを受信してもステータスを認識することができず、スリープ／ウェイクアップの管理をすることはできない。同様に、新規のシステムに対応する各ノードでは、既存のシステムに対応するノードから送信されたフレームを受信してもステータスを認識することができず、スリープ／ウェイクアップの管理をすることはできないこともあり得る。
【０００７】
したがって、既存のシステムと新規のシステムとを統合して、ステータス管理方式の異なるノードが混在するシステムを構築するときは、既存のシステムに接続されている全ノードのソフトウェアを変更して、新規のシステムに対応するノードのステータスを認識できるようにする必要があり、コストアップや開発工数の増加を招くことになる。
【０００８】
なお、ここでは、すでに存在するシステムを「既存のシステム」、新たに構築されたシステムを「新規のシステム」として説明したが、「既存のシステム」、「新規のシステム」の意味は上記例に限定されるものではなく、すでに存在するシステム同士、或いは新たに構築されたシステム同士の統合であっても、ステータス管理方式が異なる場合には同様の問題が起こりうる。
【０００９】
本発明の目的は、ステータス管理方式の異なるノードが混在するシステムにおいて、全てのノードのスリープ／ウェイクアップを管理することができるデータ通信システムを提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、請求項１の発明は、第１のステータス管理方式によりスリープ／ウェイクアップが制御される複数のノードからなる第１のノード群と、第２のステータス管理方式によりスリープ／ウェイクアップが制御される複数のノードからなる第２のノード群とを伝送路上に接続してなるデータ通信システムにおいて、前記第１のノード群に所属する全ノードでスリープ条件が成立したときは、前記第２のノード群に所属する各ノードに対し、前記第２のステータス管理方式に従ってスリープ状態を通知し、また前記第２のノード群に所属する全ノードでスリープ条件が成立したときは、前記第１のノード群に所属する各ノードに対し、前記第１のステータス管理方式に従ってスリープ状態を通知し、且つ、前記第１のノード群に所属する、少なくとも１つのノードでウェイクアップ条件が成立したときは、前記第２のノード群に所属する各ノードに対し、前記第２のステータス管理方式に従ってウェイクアップ状態を通知し、また前記第２のノード群に所属する、少なくとも１つのノードでウェイクアップ条件が成立したときは、前記第１のノード群に所属する各ノードに対し、前記第１のステータス管理方式に従ってウェイクアップ状態を通知するゲートウェイ装置を設けたことを特徴とする。
【００１１】
請求項２の発明は、請求項１において、前記ゲートウェイ装置は、前記第１のノード群に所属する全ノードからスリープ条件成立のステータス情報を含むデータフレームを受信したときは、前記第２のノード群に所属する各ノードに対し、スリープ条件非成立のステータス情報を含むステータスフレームの送信を停止し、また、前記第２のノード群に所属するノードからスリープ条件非成立のステータス情報を含むステータスフレームを所定時間受信しないときは、前記第１のノード群に所属する各ノードに対し、スリープ条件成立のステータス情報を含むデータフレームを送信し、且つ、前記第１のノード群に所属する、少なくとも１つのノードからスリープ条件非成立のステータス情報を含むデータフレームを受信したときは、前記第２のノード群に所属する各ノードに対し、スリープ条件非成立のステータス情報を含むステータスフレームを送信し、また前記第２のノード群に所属するノードからスリープ条件非成立のステータス情報を含むステータスフレームを受信したときは、前記第１のノード群に所属する各ノードに対し、スリープ条件非成立のステータス情報を含むデータフレームを送信することを特徴とする。
【００１２】
請求項３の発明は、請求項１又は２において、前記第１のノード群に所属する各ノードは、第１のステータス管理方式として、自ノードのスリープ条件が成立したときは、スリープ条件成立のステータス情報を含むデータフレームを送信し、所定時間内に他のノード又は前記ゲートウェイ装置からスリープ条件非成立のステータス情報を含むデータフレームを受信しないときはスリープ状態へ移行し、また自ノードのウェイクアップ条件が成立したときは、所定時間経過後にスリープ条件非成立のステータス情報を含むデータフレームを送信してウェイクアップ状態へ移行し、前記第２のノード群に所属する各ノードは、第２のステータス管理方式として、自ノードのスリープ条件が成立したときは、スリープ条件非成立のステータス情報を含むステータスフレームの送信を停止し、所定時間内に他のノード又は前記ゲートウェイ装置からスリープ条件非成立のステータス情報を含むステータスフレームを受信しないときはスリープ状態へ移行し、また自ノードのウェイクアップ条件が成立したときは、所定時間経過後にスリープ条件非成立のステータス情報を含むステータスフレームを送信してウェイクアップ状態へ移行することを特徴とする。
【００１３】
請求項４の発明は、請求項１乃至３のいずれか一項において、前記第１のノード群に所属する各ノードは、第１のステータス管理方式として、ウェイクアップ状態では、スリープ条件非成立又はスリープ条件成立のステータス情報を含むデータスフレームを定期送信し、スリープ状態では、前記データフレームの定期送信を停止し、前記第２のノード群に所属する各ノードは、第２のステータス管理方式として、ウェイクアップ状態では、スリープ条件非成立のステータス情報を含むステータスフレームを定期送信し、スリープ状態では、前記ステータスフレームの定期送信を停止することを特徴とする。
【００１４】
請求項５の発明は、請求項２乃至４のいずれか一項において、前記ゲートウェイ装置は、少なくとも、スリープ条件成立又はスリープ条件非成立のステータス情報を含むデータフレームを作成するデータフレーム作成手段と、スリープ条件非成立のステータス情報を含むステータスフレームを作成するステータスフレーム作成手段と、前記伝送路に接続され、自装置で作成したデータフレーム又はステータスフレームを他のノードに送信し、また、他のノードから送信されたデータフレーム又はステータスフレームを受信する通信制御部と、他のノードから送信された前記データフレームを受信する複数のデータ受信用バッファと、他のノードから送信された前記ステータスフレームを受信するステータス受信用バッファと、受信したフレームに含まれる識別情報に基づいて当該フレームの種類を判別し、受信したフレームがデータフレームであれば前記識別情報で特定される前記データ受信用バッファに受信し、また受信したフレームがステータスフレームであれば前記ステータス受信用バッファに受信するフレーム識別部と、ウェイクアップ状態において、前記第１のノード群に所属する全ノードからスリープ条件成立のステータス情報を含むデータフレームを受信したときは、前記ステータスフレームの送信を停止させ、また前記第２のノード群に所属するノードから前記ステータスフレームを所定時間受信しないときは、スリープ条件成立のステータス情報を含むデータフレームを送信させる処理を実行し、スリープ状態において、前記第１のノード群に所属する少なくとも１つのノードからスリープ条件非成立のステータス情報を含むデータフレームを受信したときは、前記ステータスフレームを送信させ、また前記第２のノード群に所属するノードから前記ステータスフレームを受信したときは、スリープ条件非成立のステータス情報を含むデータフレームを送信させる処理を実行するＩＤ管理部とを備えることを特徴とする。
【００１５】
請求項６の発明は、請求項１乃至５のいずれか一項において、前記ゲートウェイ装置は、前記第１のノード群又は前記第２のノード群に所属する１つのノードに設けられることを特徴とする。
【００１６】
請求項７の発明は、請求項１乃至６のいずれか一項において、前記ゲートウェイ装置を設けるノードは、表示系ノードであることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、異なるステータス管理方式に対応したゲートウェイ装置を設けることにより、システム上の全てのノードについてスリープ／ウェイクアップを管理することができるため、既存のシステムと新規のシステムとを統合して、ステータス管理方式の異なるノードが混在するシステムを構築する際に、既存のシステムに所属する全ノードのソフトウェアを変更する必要がなく、コストダウンや開発工数低減を図ることができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明に係わるデータ通信システムを車両用データ通信システムに適用した場合の実施例について説明する。
【実施例１】
【００１９】
図１は、本実施例に係わる車両用データ通信システムの全体構成図である。データを送受信するためのバスライン（伝送路）４０上には、電気的に制御される各機器に対応したノード１１Ａ，１１Ｂ，１１Ｃと、ノード２１Ａ，２１Ｂ，２１Ｃが接続されている。各ノードは、例えば、スイッチ系ノード、ランプ系ノード、メータ系ノード、ドア制御系ノード等にそれぞれ相当する。
【００２０】
本実施例において、ノード１１Ａ，１１Ｂ，１１Ｃは第１のステータス管理方式によりスリープ／ウェイクアップが制御される第１のノード群であり、第１のネットワークマネージメントシステム（以下、第１のＮＭシステムという）１０に所属するノードとして管理される。また、ノード２１Ａ，２１Ｂ，２１Ｃは第２のステータス管理方式によりスリープ／ウェイクアップが制御される第２のノード群であり、第２のネットワークマネージメントシステム（以下、第２のＮＭシステムという）２０に所属するノードとして管理される。
【００２１】
上記第１のＮＭシステム１０と第２のＮＭシステム２０は、それぞれステータス管理方式が異なるため、相手側システムから送信されたデータフレーム等に基づいてスリープ／ウェイクアップの管理を行うことはできない。したがって、各システムに所属する各々のノードでは、相手側システムのノードから受信したデータフレーム等に対しての処理を実行していない。
【００２２】
以下の説明において、ノード１１Ａ〜１１Ｃを総称するときは「ノード１１」と表記し、ノード２１Ａ〜２１Ｃを総称するときは「ノード２１」と表記する。また、ノード１１Ａ〜１１Ｃ、及びノード２１Ａ〜２１Ｃを総称するときは単に「ノード」と表記する。
【００２３】
ゲートウェイ装置（以下、ＧＷ）３０は、共通のバスライン４０上に接続された第１のＮＭシステム１０と第２のＮＭシステム２０に所属する全てのノードに関するステータス（スリープ／ウェイクアップ）の管理を実行する。ゲートウェイ装置３０の構成及び動作については後述する。
【００２４】
次に、第１のＮＭシステム１０に所属するノード１１の構成とステータス管理方式について説明する。
【００２５】
図２は、ノード１１の機能的な構成を示すブロック図であり、ノード１１Ａ，１１Ｂ，１１Ｃのうちの任意の一つについての構成を示している。
【００２６】
ノード１１は、通信ＩＣ１２，バッファ部１３，ステータス制御部１４，ＣＰＵ１５により構成され、更に上述したスイッチやランプなどに相当する機能部１６と接続されている。
【００２７】
通信ＩＣ１２は、バスライン４０に接続され、第１のＮＭシステム１０に所属する他のノード１１又はＧＷ３０から送信されたフレームを受信し、また自ノードで作成したフレームをバスライン４０から送信する。通信ＩＣ１２では、バスライン４０が光ファイバーケーブルである場合、電気信号−光信号の変換処理を行う。
【００２８】
バッファ部１３は、第１のＮＭシステム１０に所属する他のノード１１又はＧＷ３０から送信されるデータフレームを受信するための、データ受信用の受信バッファを備えている。
【００２９】
ステータス制御部１４は、機能部１６から送信されてくるデータやバッファ部１３の後述する受信バッファを参照して、自ノードのスリープ／ウェイクアップを制御する。
【００３０】
ＣＰＵ１５は、機能部１６からのデータに従って各種の制御を実行するとともに、自ノードに接続された機能部１６からのデータと、このデータを識別するための固有のＩＤとを付加してデータフレームを作成するデータフレーム作成手段としての処理を実行する。
【００３１】
なお、図２ではノード１１で実現される機能を分かりやすくするため、機能毎にＣＰＵ１５、ステータス制御部１４として示したが、これらの機能は１チップのＣＰＵで実現されるものであってもよい。
【００３２】
次に、第１のステータス管理方式について説明する。図３は、第１のステータス管理方式におけるデータフレームのデータ構造を示す説明図である。データフレームは、各ノードに固有のＩＤとなるヘッダ部と、機能部１６の状態を示すデータ部とから構成される。ヘッダ部は１１ビットからなり、３ビットのデータＩＤと、８ビットの物理ノードアドレス（送り元アドレス）で構成される。本実施例におけるデータＩＤは“０１１”で固定されている。また、データ部は２ビットのステータス（ステータス情報）と、１〜８バイトのデータとから構成される。本実施例では、スリープ条件成立のときはステータスを“００”とし、スリープ条件非成立のときはステータスを“０１”としている。
【００３３】
ノード１１は、通常送信待機状態（ウェイクアップ状態）では、スリープ条件非成立のステータス“０１”を含むデータスフレームを、一定間隔（例えば、１００ｍｓ毎）で定期送信する。また、自ノードのスリープ条件が成立したときは、スリープ条件成立のステータス“００”を含むデータフレームを送信し、所定時間（例えば、２００ｍｓ）内に他のノード１１又はＧＷ３０から、スリープ条件非成立のステータス“０１”を含むデータフレームを受信しないときはスリープ状態へ移行する。そして、スリープ状態へ移行後は、上記スリープ条件成立又はスリープ条件非成立のステータスを含むデータフレームの送信を停止する。更に、自ノードのウェイクアップ条件が成立したときは、所定時間（例えば、５０ｍｓ）経過後にスリープ条件非成立のステータス“０１”を含むデータフレームを送信して通常送信待機状態へ移行する。
【００３４】
ここで、ノード１１の受信バッファについて説明する。ノード１１に設けられたデータ受信用の受信バッファは、図３に示すように、受信バッファ１〜３で構成されている。このうち、受信バッファ１，２は、第１のＮＭシステム１０に所属する他の２つのノード１１から送信されてきたデータフレームを受信するためのバッファであり、受信バッファ３は、ＧＷ３０から送信されてきたデータフレームを受信するためのバッファである。各ノード１１では、受信したデータフレームのヘッダ部の１１ビットを参照し、その１１ビットで特定されるデータ受信用の受信バッファ１〜３に、データフレームを格納する。これらの受信バッファでは、受信したデータフレームが逐次上書きされる。すなわち、受信バッファ１〜３の内容は、リアルタイムで更新される。
【００３５】
なお、上述したスリープ／ウェイクアップの制御は、第１のステータス管理方式における基本動作を示したものであり、実際にはこれ以外のフレーム送信や内部制御を実行している。
【００３６】
次に、第２のＮＭシステム２０に所属するノード２１の構成とステータス管理方式について説明する。
【００３７】
図４は、ノード２１の機能的な構成を示すブロック図であり、ノード２１Ａ，２１Ｂ，２１Ｃのうちの任意の一つについての構成を示している。
【００３８】
ノード２１は、通信ＩＣ２２，フレーム識別部２３，バッファ部２４，ステータス制御部２５，ＣＰＵ２６により構成され、更に上述したスイッチやランプなどに相当する機能部２７と接続されている。
【００３９】
通信ＩＣ２２は、バスライン４０に接続され、第２のＮＭシステム２０に所属する他のノード２１又はＧＷ３０から送信されたフレームを受信し、また自ノードで作成したフレームを各ノード及びＧＷ３０に対して送信する。通信ＩＣ２２では、バスライン４０が光ファイバーケーブルである場合、電気信号−光信号の変換処理を行う。
【００４０】
フレーム識別部２３は、第２のＮＭシステム２０に所属する他のノード２１又はＧＷ３０から送信されてきたフレームのＩＤ（識別情報）を参照して、そのフレームがデータフレームかステータスフレームかを識別する。ここでは、ＩＤのビット列が先頭に“１”を含むときはステータスフレームと判断して、バッファ部２４の図示しないステータス受信用の受信バッファに受信する。また、ＩＤのビット列が先頭に“１”を含まない、例えば“０１１…”というようなビット列であればデータフレームと判断して、そのＩＤの１１ビットで特定される、バッファ部２４の図示しないデータ受信用の受信バッファに受信する。ステータスフレームのデータ構造については後述する。
【００４１】
バッファ部２４は、第２のＮＭシステム２０に所属する他のノード２１、及びＧＷ３０から送信されるデータフレームを受信するための、データ受信用の受信バッファと、ステータスフレームを受信するための、ステータス受信用の受信バッファとを備えている。
【００４２】
ステータス制御部２５は、機能部２７から送信されてくるデータやバッファ部２４の後述する受信バッファを参照して、自ノードのスリープ／ウェイクアップを制御する。
【００４３】
ＣＰＵ２６は、機能部２７からのデータに従って各種の制御を実行するとともに、自ノードに接続された機能部２７からのデータと、このデータを識別するための固有のＩＤとを付加してデータフレームを作成するデータフレーム作成手段としての処理と、自ノードの現在のステータス（スリープ／ウェイクアップ）に前記ＩＤを付加して、ステータスフレームを作成するステータスフレーム作成手段としての処理を実行する。
【００４４】
なお、図４ではノード２１で実現される機能を分かりやすくするため、機能毎にＣＰＵ２６、ステータス制御部２５、フレーム識別部２３として示したが、これらの機能は１チップのＣＰＵで実現されるものであってもよい。
【００４５】
次に、第２のステータス管理方式について説明する。図５は、データフレームとステータスフレームのデータ構造を示す説明図である。
【００４６】
本実施例において、第２のＮＭシステム２０におけるデータフレームの構造は第１のＮＭシステム１０（図３参照）と同じであり、２ビットのデータ部には、スリープ条件成立のときはステータス“００”が、またスリープ条件非成立のときはステータス“０１”がセットされる。
【００４７】
一方、ステータスフレームのヘッダ部は１１ビットからなり、３ビットのステータスＩＤと、８ビットの物理ノードアドレスで構成されている。本実施例におけるステータスＩＤは“１１１”で固定され、データ部のステータスはスリープ条件非成立の“０１”で固定されている。以下の説明においては、スリープ条件非成立のステータス“０１”を含むステータスフレームを適宜に「ステータスフレーム」と略して表記する。
【００４８】
ノード２１は、通常送信待機状態では、スリープ条件非成立のステータス“０１”を含むデータスフレームとステータスフレームを、一定間隔（例えば、１００ｍｓ毎）で定期送信する。また、自ノードのスリープ条件が成立したときは、前記ステータスフレームの定期送信を停止し、所定時間（例えば、２００ｍｓ）内に他のノード２１又はＧＷ３０から前記ステータスフレームを受信しないときはスリープ状態へ移行する。スリープ状態へ移行後は、ステータスフレームだけでなく、データフレームの送信を停止する。更に、自ノードのウェイクアップ条件が成立したときは、所定時間（例えば、５０ｍｓ）経過後に、ステータスフレームを送信して通常送信待機状態へ移行する。
【００４９】
ここで、ノード２１の受信バッファについて説明する。ノード２１に設けられたデータ受信用の受信バッファは、図５に示すように、受信バッファ１〜４で構成されている。このうち、受信バッファ１は、第２のＮＭシステム２０に所属する他の２つのノード２１又はＧＷ３０から送信されてきたステータスフレームを受信するためのバッファである。また、受信バッファ２，３は、第２のＮＭシステム２０に所属する他の２つのノード２１から送信されてきたデータフレームを受信するためのバッファであり、受信バッファ４は、ＧＷ３０から送信されてきたデータフレームを受信するためのバッファである。
【００５０】
ノード２１では、他のノード２１又はＧＷ３０からのフレームを受信すると、そのフレームのヘッダ部に基づいてデータフレームかステータスフレームかを識別する。例えば、受信したフレームのヘッダ部が先頭に“１”を含むときはステータスフレームと判断して、バッファ部２４のステータス受信用の受信バッファ１に受信する。この場合、ノード２１では、どのノードから送信されたステータスフレームであるかを認識する必要はないため、先頭のビットが“１”であれば、ヘッダ部を“１xxxxxxxxxx”でマスクして（その後ろの値に係わらず）、ステータスフレームをステータス受信用の受信バッファ１に受信する。このように、ヘッダ部の一部をマスクして受信する制御は、例えばＣＡＮコントローラのマスク機能として提供されている。
【００５１】
また、読み出しツールを使用して１１ビットのヘッダ部を解析することにより、どのノードから送信されたステータスフレームであるかを判別することができる。
【００５２】
ステータス受信用の受信バッファ１には、他のノード２１又はＧＷ３０から受信したステータスフレームが逐次上書きされる。ステータス制御部２５では、定期的にステータス受信用の受信バッファ１からの読み出し行い、ステータスフレームの受信があったかどうかを確認する。
【００５３】
また、受信したフレームのヘッダ部が先頭に“１”を含まない“０１１…”というようなビット列であればデータフレームと判断して、そのヘッダ部の１１ビットで特定されるデータ受信用の受信バッファ２〜４にデータフレームを格納する。このデータ受信用の受信バッファ２〜４についても、それぞれ対応するノード２１又はＧＷ３０から受信したデータフレームが逐次上書きされる。すなわち、受信バッファ１及び２〜４の内容は、リアルタイムで更新される。
【００５４】
なお、上述したスリープ／ウェイクアップの制御は、第２のステータス管理方式における基本動作を示したものであり、実際にはこれ以外のフレーム送信や内部制御を実行している。
【００５５】
上述した第２のＮＭシステム２０では、各ノード２１及びＧＷ３０間でステータス管理用のステータスフレームを送受信するとともに、他のノード２１及びＧＷ３０からのステータスフレームを既存のマスク機能を用いて共通の受信バッファで受信することにより、各ノード２１及びＧＷ３０はシステム構築時に想定されていない未想定ノード（ＩＤが識別できないノード）が接続された場合でも、そのステータスを認識して、そのスリープ／ウェイクアップを管理することができる。
【００５６】
これによれば、未想定ノードが接続される度にシステムに接続されている全ノード２１及びＧＷ３０のソフトウェアを変更する必要がなく、コストアップや開発工程の増加を招くことがない。また、接続されるノードの数だけ専用の受信バッファを持つ必要がないため、受信バッファ数の削減が可能となり、システムの拡張性を向上させることができる。
【００５７】
なお、第２のＮＭシステム２０では、ステータスフレームだけでなく、データフレームに含まれるスリープ条件成立／スリープ条件非成立のステータスを参照することによって、他のノードのスリープ／ウェイクアップを管理することができる。したがって、第１のＮＭシステム１０を既存のシステムとし、第２のＮＭシステム２０を新規のシステムとした場合、第２のＮＭシステム２０に所属する各ノード２１では、ＧＷ３０を介さなくても、第１のＮＭシステム１０に所属する各ノード１１のＩＤを識別して、各ＩＤ毎に個別の受信バッファで受信することができる。この場合は、接続されている全てのノードに対応する受信バッファを設ける必要があるが、ステータスフレームのみで他のノードのスリープ／ウェイクアップを管理する場合は、共通の受信バッファだけで済むため、バッファの容量を少なくすることができる。
【００５８】
次に、上記各システムに所属するノード１１、ノード２１において、スリープ／ウェイクアップを制御する際の処理手順について説明する。
【００５９】
図６は、第１のＮＭシステム１０に所属するノード１１において、ウェイクアップ遷移する場合の処理手順を示すフローチャートである。
【００６０】
ノード１１のステータス制御部１４は、自ノードでのウェイクアップ条件が成立したかどうかを判断し（ステップＳ１）、Ｙｅｓであれば、ウェイクアップＩＤコードを送信する（ステップＳ２）。ウェイクアップＩＤコードとは、ウェイクアップ事由が発生したときに送信されるウェイクアップ専用のデータフレームであり、スリープ条件非成立のステータス“０１”を含むデータフレームを送信する前に送られる。
【００６１】
ウェイクアップＩＤコードを送信後、５０ｍｓ経過すると（ステップＳ３でＹｅｓ）、ＣＰＵ１５はスリープ条件非成立のステータス“０１”を含むデータフレームを作成し、他のノード１１及びＧＷ３０へ送信する（ステップＳ４）。上記データフレーム送信後は、通常送信待機状態へ移行する（ステップＳ５）。
【００６２】
通常送信待機状態とは、他のノード１１及びＧＷ３０との間でデータフレーム等の送受信が可能な状態をいう。この後、ノード１１は、自ノードのスリープ条件が成立するまでスリープ条件非成立のステータス“０１”を含むデータフレームを定期送信する。
【００６３】
上記ステップＳ１〜Ｓ５までの処理は、自ノードからのウェイクアップ遷移を示している。
【００６４】
一方、ステップＳ１でＮｏであれば、他のノード１１又はＧＷ３０からのウェイクアップＩＤコードの受信があったかどうか判断し（ステップＳ６）、Ｎｏであれば処理を終了する。またＹｅｓであれば、ウェイクアップ待機状態へ移行し（ステップＳ７）、他のノード１１又はＧＷ３０からのスリープ条件非成立のステータス“０１”を含むデータフレームを、１００ｍｓ経過までに受信したかどうかを判断する（ステップＳ８、Ｓ９）。ここで、１００ｍｓ経過前に上記データフレームを受信したときは、（ステップＳ８でＹｅｓ）、通常送信待機状態へ移行する（ステップＳ５）。また上記データフレームを受信することなく１００ｍｓ経過したときは（ステップＳ９でＹｅｓ）、スリープ状態へ移行して（ステップＳ１０）処理を終了する。
【００６５】
上記ステップＳ６〜Ｓ１０までの処理は、他のノード１１又はＧＷ３０からのウェイクアップ遷移を示している。
【００６６】
図７は、スリープ遷移する場合の処理手順を示すフローチャートである。ノード１１のステータス制御部１４は、自ノードでのスリープ条件が成立したかどうかを判断し（ステップＳ１１）、Ｙｅｓであれば、スリープ条件成立のステータス“００”を含むデータフレームの定期送信を行い（ステップＳ１２）、他のノード１１又はＧＷ３０からのスリープ条件非成立のステータス“０１”を含むデータフレームを、２００ｍｓ経過までに受信したかどうかを判断する（ステップＳ１３、Ｓ１４）。ここで、２００ｍｓ経過前に上記データフレームを受信したときは（ステップＳ１３でＹｅｓ）、スリープ状態へ移行しないで処理を終了する（ステップＳ１１でＮｏのときも同じ）。一方、上記データフレームを受信することなく２００ｍｓ経過したときは（ステップＳ１４でＹｅｓ）、スリープ待機状態へ移行する（ステップＳ１５）。その後、更に３ｓ経過したときは（ステップＳ１６でＹｅｓ）、スリープ状態へ移行する（ステップＳ１７）。なお、スリープ状態へ移行した後は、スリープ条件成立のステータス“００”を含むデータフレームの定期送信を停止する。
【００６７】
図８は、第２のＮＭシステム２０に所属するノード２１において、ウェイクアップ遷移する場合の処理手順を示すフローチャートである。
【００６８】
ノード２１のステータス制御部２５は、自ノードでのウェイクアップ条件が成立したかどうかを判断し（ステップＳ２１）、Ｙｅｓであれば、ウェイクアップＩＤコードを送信する（ステップＳ２２）。
【００６９】
ウェイクアップＩＤコードを送信後、５０ｍｓ経過すると（ステップＳ２３でＹｅｓ）、ＣＰＵ２６はステータスフレームを作成し、他のノード２１及びＧＷ３０へ送信する（ステップＳ２４）。上記ステータスフレーム送信後は、通常送信待機状態へ移行する（ステップＳ２５）。この後、ノード２１は、自ノードのスリープ条件が成立するまでスリープ条件非成立のステータス“０１”を含むデータフレームとステータスフレームを定期送信する。
【００７０】
上記ステップＳ２１〜Ｓ２５までの処理は、自ノードからのウェイクアップ遷移を示している。
【００７１】
一方、ステップＳ２１でＮｏであれば、他のノード２１又はＧＷ３０からのウェイクアップＩＤコードの受信があったかどうか判断し（ステップＳ２６）、Ｎｏであれば処理を終了する。またＹｅｓであれば、ウェイクアップ待機状態へ移行し（ステップＳ２７）、他のノード２１又はＧＷ３０からのステータスフレームの受信があったかどうかを、１００ｍｓ経過前に受信したかどうかを判断する（ステップＳ２８、Ｓ２９）。ここで、１００ｍｓ経過前にステータスフレームを受信したときは（ステップｓ２８でＹｅｓ）、通常送信待機状態へ移行する（ステップＳ２５）。またステータスフレーム受信することなく１００ｍｓ経過したときは（ステップＳ２９でＹｅｓ）、スリープ状態へ移行して（ステップＳ３０）処理を終了する。
【００７２】
上記ステップＳ２６〜Ｓ３０までの処理は、他のノード２１又はＧＷ３０からのウェイクアップ遷移を示している。
【００７３】
図９は、スリープ遷移する場合の処理手順を示すフローチャートである。ここでは、スリープ条件非成立のステータス“０１”を含むデータフレームの送受信を省略して説明する。
【００７４】
ノード２１のステータス制御部２５は、自ノードでのスリープ条件が成立したかどうかを判断し（ステップＳ３１）、Ｙｅｓであれば、ステータスフレームの定期送信を停止し（ステップＳ３２）、他のノード２１又はＧＷ３０からのステータスフレームを２００ｍｓ経過前に受信したかどうかを判断する（ステップＳ３３、Ｓ３４）。ここで、２００ｍｓ経過前にステータスフレームを受信したときは（ステップＳ３３でＹｅｓ）、スリープ状態へ移行しないで処理を終了する（ステップＳ３１でＮｏのときも同じ）。一方、ステータスフレームを受信することなく２００ｍｓ経過したときは（ステップＳ３４でＹｅｓ）、スリープ待機状態へ移行する（ステップＳ３５）。その後、更に３ｓ経過したときは（ステップＳ３６でＹｅｓ）、スリープ状態へ移行する（ステップＳ３７）。
【００７５】
なお、ステップＳ３２において、ステータスフレームの定期送信を停止した後も、スリープ状態へ移行するまでの間はスリープ条件成立のステータス“００”を含むデータフレームの送信は継続する。
【００７６】
上記第２のＮＭシステム２０では、スリープ条件が成立した時点でステータスフレームのみ定期送信を停止し、スリープ状態に移行するまでデータフレームの定期送信は継続するようにしている。これは、スリープ条件が成立したときにデータフレームの定期送信を停止してしまうと、ステータスフレーム送信後に通信途絶（エラー等による通信不能状態）が発生したときに、スリープによりフレーム送信が停止したのか、バスライン上で通信途絶が発生したのかが判断できないためである。そこで、ステータスフレームの定期送信を停止しても、データフレームの定期送信を継続することにより、通信途絶の原因を判断することができる。この場合、通信途絶直前のデータフレーム内のステータスが“００”の場合は、既にスリープ条件が成立していると考えられるため、通信が途絶しても問題なしと判断できる。一方、通信途絶直前のデータフレーム内のステータスが“０１”の場合は、通信中（アプリケーション動作中）のエラー発生と判断できるため、そのノードのアプリケーションに対して適切な処置をとる必要がある。例えば、オートスライドドアの閉動作中にエラーが発生したと判断した場合にはドアの駆動を停止するなどの処置をとる。
【００７７】
次に、ＧＷ３０の構成と各ＮＭシステムに対するステータス管理について説明する。
【００７８】
図１０は、ＧＷ３０の機能的な構成を示すブロック図である。ＧＷ３０は、通信ＩＣ３１，フレーム識別部３２，バッファ部３３，ＩＤ管理部３４，ＣＰＵ３５により構成されている。
【００７９】
通信ＩＣ３１は、バスライン４０に接続され、第１のＮＭシステム１０に所属するノード１１、及び第２のＮＭシステム２０に所属するノード２１から送信されたフレームを受信するとともに、後述の各部により作成されたフレームを、バスライン４０を介して第１のＮＭシステム１０に所属するノード１１、及び第２のＮＭシステム２０に所属するノード２１に送信する。通信ＩＣ３１では、バスライン４０が光ファイバーケーブルである場合、電気信号−光信号の変換処理を行う。
【００８０】
フレーム識別部３２は、第２のＮＭシステム２０に所属するノード２１から送信されてきたフレームのＩＤ（識別情報）を参照して、そのフレームがデータフレームかステータスフレームかを識別する。ここでは、ＩＤのビット列が先頭に“１”を含むときはステータスフレームと判断して、バッファ部３３の図示しないステータス受信用の受信バッファに受信する。また、ＩＤのビット列が先頭に“１”を含まない、例えば“０１１…”というようなビット列であればデータフレームと判断して、そのＩＤの１１ビットで特定される、バッファ部３３の図示しないデータ受信用の受信バッファに受信する。ＧＷ３０では、第１のＮＭシステム１０及び第２のＮＭシステム２０に所属する全てのノードについて、そのＩＤを認識しているため、受信したデータフレームのヘッダ部を参照することにより、そのデータフレームを送信してきたノードとその所属するＮＭシステムを特定することができる。
【００８１】
バッファ部３３は、第１のＮＭシステム１０に所属するノード１１から送信されるデータフレームや、第２のＮＭシステム２０に所属するノード２１から送信されるデータフレームを受信するためのデータ受信用の受信バッファと、第２のＮＭシステム２０に所属するノード２１から送信されるステータスフレームを受信するためのステータス受信用の受信バッファとを備えている（いずれも図示せず）。
【００８２】
ＩＤ管理部３４は、バッファ部３３を参照して、第１のＮＭシステム１０に所属する全ノード１１からスリープ条件成立のステータス“００”を含むデータフレームを受信したときは、ステータスフレームの送信を停止するようにＣＰＵ３５に送信停止要求を発行する。すなわち、ＧＷ３０は、第１のＮＭシステム１０に所属するノード１１からスリープ条件非成立のステータス“０１”を含むデータフレームを受信している間は、（各ノード２１に対して）ステータスフレームを送信しているため、第１のＮＭシステム１０に所属する全ノード１１がスリープ待機状態となったときには、ステータスフレームを送信しないようにしている。
【００８３】
また、第２のＮＭシステム２０に所属するノード２１からステータスフレームを所定時間受信しないときは、スリープ条件成立のステータス“００”を含むデータフレームを送信するように、ＣＰＵ３５に対し送信要求を発行する。すなわち、ＧＷ３０は、第２のＮＭシステム２０に所属するノード２１からステータスフレームを受信している間は、（各ノード１１に対して）スリープ条件非成立のステータス“０１”を含むデータフレームを送信しているため、第２のＮＭシステム２０に所属する全ノード２１がスリープ待機状態となったときには、スリープ条件成立のステータス“００”を含むデータフレームを送信するようにしている。
【００８４】
また、第１のＮＭシステム１０に所属する、少なくとも１つのノード１１からスリープ条件非成立のステータス“０１”を含むデータフレームを受信したときは、（各ノード２１に対して）ステータスフレームを送信するように、ＣＰＵ３５に対し送信要求を発行する。
【００８５】
更に、第２のＮＭシステム２０に所属するノード２１からステータスフレームを受信したときは、（各ノード１１に対して）スリープ条件非成立のステータス“０１”を含むデータフレームを送信するように、ＣＰＵ３５に送信要求を発行する。
【００８６】
ＣＰＵ３５は、ＧＷ３０全体を制御するとともに、ＩＤ管理部３４から発行された送信停止要求に応じて、通信ＩＣ３１からのステータスフレームの送信を停止する処理と、ＩＤ管理部３４から発行された送信要求に応じて、スリープ条件非成立のステータス“０１”を含むデータフレーム、又はスリープ条件成立のステータス“００”を含むデータフレームを作成するデータフレーム作成手段としての処理と、ＩＤ管理部３４から発行された送信要求に応じて、ステータスフレームを作成するステータス作成手段としての処理を実行する。
【００８７】
なお、図１０ではＧＷ３０で実現される機能を分かりやすくするため、機能毎にフレーム識別部３２、ＩＤ管理部３４、ＣＰＵ３５として示したが、これらの機能は１チップのＣＰＵで実現されるものであってもよい。
【００８８】
次に、ＧＷ３０において、第１のＮＭシステム１０及び第２のＮＭシステム２０間でスリープ／ウェイクアップを制御する際の処理手順について説明する。なお、ここでは、スリープ／ウェイクアップ制御に必要なフレームのやり取りについてのみ説明するものとし、それ以外の処理、例えば受信したフレームを識別する処理や、ウェイクアップＩＤコード等の送受信については説明を省略する。
【００８９】
図１１は、両ＮＭシステム間でウェイクアップ遷移する場合の処理手順を示すフローチャートである。
【００９０】
ＧＷ３０は、第１のＮＭシステム１０に所属するノード１１からスリープ条件非成立のステータス“０１”を含むデータフレームを受信したときは（ステップＳ４１でＹｅｓ）、３０ｍｓ経過後に（ステップＳ４２でＹｅｓ）、ステータスフレームを作成し、バスライン４０から各ノードに送信する（ステップＳ４３）。このステータスフレームの送信により、第２のＮＭシステム２０に所属する各ノード２１は、スリープ条件が成立していないノードがバスライン４０上に存在することを認識することができる。また、ステップＳ４１でＮｏであれば、第２のＮＭシステム２０に所属するノード２１からステータスフレームを受信したかどうかを判断し（ステップＳ４４）、Ｎｏであれば処理を終了する。ここで、Ｙｅｓであれば、３０ｍｓ経過後に（ステップＳ４５でＹｅｓ）、スリープ条件非成立のステータス“０１”を含むデータフレームを作成し、バスライン４０から送信する（ステップＳ４６）。このデータフレームの送信により、第１のＮＭシステム１０に所属する各ノード１１は、スリープ条件が成立していないノードがバスライン４０上に存在することを認識することができる。
【００９１】
図１２は、両ＮＭシステム間でスリープ遷移する場合の処理手順を示すフローチャートである。
【００９２】
ＧＷ３０は、第１のＮＭシステム１０に所属する全ノード１１の受信バッファを参照して、すべてのステータスがスリープ条件成立のステータス“００”であるときは（ステップＳ５１でＹｅｓ）、ステータスフレームの送信を停止する（ステップＳ５２）。すなわち、ＧＷ３０では、第１のＮＭシステム１０に所属するノード１１から、スリープ条件非成立のステータス“０１”を含むデータフレームを受信している間は、ステータスフレームを送信しているため、このステータスフレームの送信を停止することにより、第２のＮＭシステム２０に所属するノード２１は、図９に示すようにスリープ待機状態への移行を判断することができる。また、ステップＳ５１でＮｏであれば、第２のＮＭシステム２０に所属するノード２１からステータスフレームを受信したかどうかを判断し（ステップＳ５３）、Ｙｅｓであれば処理を終了する。ここで、Ｎｏであれば、３０ｍｓ経過後に（ステップＳ５４でＹｅｓ）、スリープ条件成立のステータス“００”を含むデータフレームを作成し、バスライン４０から送信する（ステップＳ５５）。このデータフレームの送信により、第１のＮＭシステム１０に所属する各ノード１１は、ＧＷ３０が管理している第２のＮＭシステム２０に所属する全ノード２１においてスリープ条件が成立したことを認識することができる。
【００９３】
以上説明したように、ステータス管理方式の異なるノードが混在するデータ通信システムに、それぞれのステータス管理方式に対応したゲートウェイ装置を設けることにより、全てのノードについてスリープ／ウェイクアップを管理することができる。したがって、既存のシステムに、未想定ノードにより構成された新規のシステムを接続する場合において、既存のシステムに接続されている全ノードのソフトウェアを変更して、未想定ノードからのステータスを認識できるようにする必要がなく、またソフト変更を必要としない既存のノードをそのまま接続することができるので、コストダウンや開発工数の低減を達成することができる。
【００９４】
上記実施例では、ＧＷ３０をバスライン上に独立した装置として接続した例について示したが、特定のノードにＧＷの機能を持たせることもできる。図１３は、第２のＮＭシステム２０に所属するノード２１にＧＷの機能を持たせた場合の構成を示すブロック図であり、図４と同等部分を同一符号で示している。図１０に示すように、ＣＰＵ２６とバッファ部２４との間にＩＤ管理部３４（図１０参照）を接続することにより、特定のノード２１にＧＷの機能を持たせることができる。  
なお、特定のノード２１にＧＷの機能を持たせた場合は、ＧＷによるウェイクアップ遷移／スリープ遷移の処理において、自ノードのスリープ条件成立／非成立を判断する必要がある。
【００９５】
また、ＧＷの機能を持たせるノードとしては、ＣＰＵやバッファ部の容量に余裕のあるノードが適している。具体的には、システム上で重要な役割を担い、同ノードのダウンがアプリケーションのダウンに繋がるようなノード、例えば、メータなどを制御する表示系ノードなどが好ましい。
【００９６】
更に、上記実施例では、データフレームによりステータスを管理する第１のＮＭシステム１０と、ステータスフレームによりステータスを管理する第２のＮＭシステム２０を例として説明したが、データフレームのステータス情報によりステータスを管理する方式のシステム同士であっても、ステータス情報のデータ構造等が異なる場合には互いのノードのステータスを管理することができない。このため、本実施例のような相手側システムのステータス管理方式に対応したＧＷを設けることにより、全てのノードについてスリープ／ウェイクアップを管理することが可能となる。
【００９７】
また、同じステータスフレームによりステータスを管理するシステム同士であっても、ステータスフレームのデータ構造等が異なる場合は互いのノードのステータスを管理することができないため、本実施例のような相手側システムのステータス管理方式に対応したＧＷを設けることにより、全てのノードについてスリープ／ウェイクアップを管理することが可能となる。
【図面の簡単な説明】
【００９８】
【図１】実施例に係わる車両用データ通信システムの全体構成図。
【図２】第１のＮＭシステムに所属するノードの機能的な構成を示すブロック図。
【図３】第１のステータス管理方式におけるデータフレームのデータ構造を示す説明図。
【図４】第２のＮＭシステムに所属するノードの機能的な構成を示すブロック図。
【図５】第２のステータス管理方式におけるデータフレームとステータスフレームのデータ構造を示す説明図。
【図６】第１のＮＭシステムに所属するノードでウェイクアップ遷移する場合の処理手順を示すフローチャート。
【図７】第１のＮＭシステムに所属するノードでスリープ遷移する場合の処理手順を示すフローチャート。
【図８】第２のＮＭシステムに所属するノードでウェイクアップ遷移する場合の処理手順を示すフローチャート。
【図９】第２のＮＭシステムに所属するノードでスリープ遷移する場合の処理手順を示すフローチャート。
【図１０】ＧＷの機能的な構成を示すブロック図。
【図１１】ＧＷにおいて両ＮＭシステム間でウェイクアップ遷移する場合の処理手順を示すフローチャート。
【図１２】ＧＷにおいて両ＮＭシステム間でスリープ遷移する場合の処理手順を示すフローチャート。
【図１３】第２のＮＭシステムに所属するノードにＧＷの機能を持たせた場合の構成を示すブロック図。
【符号の説明】
【００９９】
１〜４…受信バッファ
１０…第１のＮＭシステム
１１，２１…ノード
１２，２２，３１…通信ＩＣ
１３，２４，３３…バッファ部
１４，２５…ステータス制御部
１５，２６，３５…ＣＰＵ
１６，２７…機能部
２０…第２のＮＭシステム
２３，３２…フレーム識別部
３０…ＧＷ
３４…ＩＤ管理部
４０…バスライン
【図１】
2005159864.tif 000003
【図２】
2005159864.tif 000004
【図３】
2005159864.tif 000005
【図４】
2005159864.tif 000006
【図５】
2005159864.tif 000007
【図６】
2005159864.tif 000008
【図７】
2005159864.tif 000009
【図８】
2005159864.tif 000010
【図９】
2005159864.tif 000011
【図１０】
2005159864.tif 000012
【図１１】
2005159864.tif 000013
【図１２】
2005159864.tif 000014
【図１３】
2005159864.tif 000015