JP4034243B2

JP4034243B2 - データ通信システム

Info

Publication number: JP4034243B2
Application number: JP2003188834A
Authority: JP
Inventors: 晃法月
Original assignee: Yazaki Corp
Current assignee: Yazaki Corp
Priority date: 2003-06-30
Filing date: 2003-06-30
Publication date: 2008-01-16
Anticipated expiration: 2023-06-30
Also published as: JP2005026906A

Description

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

Claims

伝送路に複数のノードが接続されたデータ通信システムにおいて、
各ノードは、他のノードから送信されたデータ管理用のデータフレームを当該データフレームの識別情報で特定される専用のバッファに受信し、また他のノードから送信されたステータス管理用のステータスフレームを共通のバッファに受信して、自ノードのスリープ／ウェイクアップの遷移を前記共通のバッファに受信したステータスフレームに基づいて管理することを特徴とするデータ通信システム。
前記各ノードは、
自ノードに接続された機能部のデータと識別情報とを含むデータフレームを作成するデータフレーム作成手段と、
少なくとも自ノードのステータス情報を含むデータと識別情報とを含むステータスフレームを作成するステータスフレーム作成手段と、
前記伝送路に接続され、自ノードで作成したフレームを他のノードに送信し、また他のノードから送信したフレームを受信する通信制御部と、
他のノードから送信された前記データフレームを受信する複数のデータ受信用バッファと、
他のノードから送信された前記ステータスフレームを受信するステータス受信用バッファと、
受信したフレームに含まれる識別情報に基づいて当該フレームの種類を判別し、受信したフレームがデータフレームであれば前記識別情報で特定される前記データ受信用バッファに受信し、また受信したフレームがステータスフレームであれば前記ステータス受信用バッファに受信するフレーム識別部と、
自ノードのスリープ／ウェイクアップの遷移を、前記ステータス受信用バッファに受信した前記ステータスフレームの有無に基づいて管理するステータス制御部と、
を備えることを特徴とする請求項１に記載のデータ通信システム。
前記フレーム識別部は、
受信したフレームの識別情報が先頭に所定値を含まないビット列であるときは、当該フレームをデータフレームと判断して前記識別情報の全ビットにより特定される前記データ受信用バッファに受信し、
受信したフレームの識別情報が先頭に所定値を含むビット列であるときは、当該フレームをステータスフレームと判断して前記ステータス受信用バッファに受信すること、
を特徴とする請求項２に記載のデータ通信システム。
前記ステータス制御部は、
自ノードのスリープ条件が成立したときには前記ステータスフレームの送信を停止し、所定時間内に他のノードからのステータスフレームを受信しないときはスリープ状態へ移行し、
自ノードのウェイクアップ条件が成立したときには所定時間経過後にステータスフレームを他のノードへ送信して通常送信待機状態へ移行し、
他のノードでウェイクアップ事由が発生してから所定時間内に他のノードからのステータスフレームを受信したときは通常送信待機状態へ移行すること、
を特徴とする請求項２に記載のデータ通信システム。
前記各ノードは、
通常送信待機状態では、自ノードで作成したデータフレーム及びステータスフレームを他のノードへ定期送信し、
スリープ状態では、前記データフレームと前記ステータスフレームの定期送信を停止すること、
を特徴とする請求項１乃至４のいずれか一項に記載のデータ通信システム。
前記各ノードは、
通常送信待機状態では、自ノードで作成したデータフレーム及びステータスフレームを他のノードへ定期送信し、
スリープ待機状態では、前記ステータスフレームの定期送信を停止すること、
を特徴とする請求項１乃至４のいずれか一項に記載のデータ通信システム。