(57)【要約】【課題】通信ノードが故障した場合であっても、通信を破綻させずに維持する。【解決手段】通信システム１を構成する複数の通信ノード１０＿１〜１０＿８は、タイムトリガ型の通信プロトコル(例えばＦｌｅｘＲａｙ)に則して、伝送路２を介した相互通信を行う。各通信ノード１０＿１〜１０＿８は、自ノードの障害状況を定期的に検出すると共に、前記障害状況を含む診断フレームを伝送路２へ送出する。バックアップノード２０は、前記診断フレームを監視し、前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、各通信ノード１０＿１〜１０＿８の機能を実行するためのリソースを用いて代替実行する。【選択図】図１
2011211485.tif 000002
【特許請求の範囲】
【請求項１】
タイムトリガ型の通信プロトコルに則し、伝送路を介して他の通信ノードと通信する通信部と、
自ノードの障害状況を定期的に検出すると共に、前記通信部に、前記障害状況を含む第１の診断フレームを前記伝送路へ送出させる制御部と、
を備えた通信ノード。
【請求項２】
請求項１において、
前記通信部は、前記他の通信ノードから第２の診断フレームを定期的に受信し、
前記制御部は、前記第２の診断フレームに含まれる障害状況が前記他の通信ノードによる一部動作の継続不可を示す場合、又は前記第２の診断フレームが受信されない場合、前記通信部に、前記他の通信ノード宛てに送信した最新のデータを前記伝送路へ再送出させる、ことを特徴とした通信ノード。
【請求項３】
請求項１又は２において、
前記制御部は、前記検出した障害状況が自ノードによる動作の継続不可を示す場合、前記通信部に対して前記通信を停止するよう指示することを特徴とした通信ノード。
【請求項４】
タイムトリガ型の通信プロトコルに則して、伝送路を介した相互通信を行う複数の通信ノード各々の機能を実行するためのリソースと、
各通信ノードから前記伝送路へ定期的に送出され、且つ各通信ノードの障害状況を含む診断フレームを監視する監視部と、
前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行する実行部と、
を備えたバックアップノード。
【請求項５】
請求項４において、
前記実行部は、前記障害状況が前記一の通信ノードによる一部動作の継続不可を示す場合、前記一の通信ノードの機能の内の受信機能を他の機能に先立って実行し、他の通信ノードから、前記他の通信ノードが前記一の通信ノード宛てに送信した最新のデータを受信することを特徴としたバックアップノード。
【請求項６】
請求項４において、
前記実行部は、前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能の内の受信機能を他の機能に先立って代替実行し、他の通信ノードから、前記他の通信ノードが前記一の通信ノード宛てに送信した最新のデータを受信することを特徴としたバックアップノード。
【請求項７】
タイムトリガ型の通信プロトコルに則して、伝送路を介した相互通信を行う複数の通信ノードと、
各通信ノードの機能を実行するためのリソースを有するバックアップノードと、を備え、
各通信ノードは、各通信ノードの障害状況を定期的に検出すると共に、前記障害状況を含む診断フレームを前記伝送路へ送出し、
前記バックアップノードは、前記診断フレームを監視し、前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行する、
通信システム。
【請求項８】
タイムトリガ型の通信プロトコルに則して、相互通信を行う複数の通信ノード各々の機能を実行するためのリソースを保有し、
各通信ノードから伝送路へ定期的に送出され、且つ各通信ノードの障害状況を含む診断フレームを監視し、
前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行する、
ことを含む通信ノードのバックアップ方法。
【請求項９】
請求項８において、
前記障害状況が前記一の通信ノードによる一部動作の継続不可を示す場合、前記一の通信ノードの機能の内の受信機能を他の機能に先立って実行し、他の通信ノードから、前記他の通信ノードが前記一の通信ノード宛てに送信した最新のデータを受信する、ことをさらに含む通信ノードのバックアップ方法。
【請求項１０】
請求項８において、
前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能の内の受信機能を他の機能に先立って代替実行し、他の通信ノードから、前記他の通信ノードが前記一の通信ノード宛てに送信した最新のデータを受信する、ことをさらに含む通信ノードのバックアップ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ノード、バックアップノード、通信システム、及び通信ノードのバックアップ方法に関し、特にＦｌｅｘＲａｙ等のタイムトリガ型の通信プロトコルを採用する通信ノードを、その故障に際してバックアップする技術に関する。
【背景技術】
【０００２】
近年、車両内機器等を制御するための通信プロトコルとして、ＦｌｅｘＲａｙが注目されている(例えば、非特許文献１及び２参照)。ＦｌｅｘＲａｙは、タイムトリガ型の通信方式を採用しており、イベントトリガ型の通信方式を採用するＣＡＮ(Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ)と比較して、高速且つ信頼性の高い通信システムを構築することが可能である。
【０００３】
ここで、タイムトリガ型の通信方式とは、通信システムを構成する通信ノード毎にフレームを送信するための帯域(以下、スロットと呼称する)を排他的に割り当て、以て各通信ノードに、周期的なデータ伝送を行わせる方式のことである。なお、イベントトリガ型の通信方式とは、各通信ノードが事象に合わせて通信要求を発生する方式のことである。
【０００４】
図７に、ＦｌｅｘＲａｙを適用する一般的な通信システム１ｘの構成例を示す。この通信システム１ｘは、複数の通信ノード１０ｘ＿１〜１０ｘ＿８を備えている。図示の例では、通信ノード１０ｘ＿２及び１０ｘ＿３が、通信ノード１０ｘ＿１で終端される伝送路２に分岐接続され、以てパッシブバス型ネットワーク３を形成している。また、通信ノード１０ｘ＿４〜１０ｘ＿５は、スイッチングハブ等と同様の機能を有するアクティブスター３０＿１及び３０＿２を介して伝送路２に接続され、以てアクティブスター型ネットワーク４を形成している。さらに、通信ノード１０ｘ＿７及び１０ｘ＿８は、伝送路２中の接続点に相互接続され、以てパッシブスター型ネットワーク５を形成している。なお、ＦｌｅｘＲａｙを適用する通信システムにおいては、バス型ネットワークとスター型ネットワークとを組み合わせたハイブリット型ネットワークが形成される場合もある。
【０００５】
ここで、各通信ノードは、図８(ａ)に例示する如く、通信システムの用途に応じた個別の機能を有する。この例では、通信システムを車両内機器の制御に用いるケースが示されている。具体的には、ＥＰＳ(Ｅｌｅｃｔｒｉｃ Ｐｏｗｅｒ Ｓｔｅｅｒｉｎｇ)を制御するノード４１、Ｇａｔｅｗａｙとして機能するノード４２、ＡＢＳ(Ａｎｔｉｌｏｃｋ Ｂｒａｋｅ Ｓｙｓｔｅｍ)を制御するノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒとして機能するノード４４、ＡＴ(Ａｕｔｏｍａｔｉｃ Ｔｒａｎｓｍｉｓｓｉｏｎ)を制御するノード４５が、伝送路２を介して相互接続されている。また、伝送路２は、例えば２対のツイストペアケーブルで構成され、ノード４１〜４５間を２つのチャネル"Ａｃｈ"及び"Ｂｃｈ"で接続している。このため、一方のチャネル(例えば"Ａｃｈ")に障害が発生した場合であっても、各ノード４１〜４５は、他方のチャネル("Ｂｃｈ")を用いてフレームを送受信することが可能であり、以て信頼性の高い通信を保証できる。
【０００６】
また、図８(ｂ)に示すように、ＦｌｅｘＲａｙにおける１つの通信サイクル(Ｃｙｃｌｅ０〜Ｃｙｃｌｅ６３の各々)は、複数のＳｌｏｔ１〜Ｓｌｏｔ１６で構成される。図示の例では、Ｃｙｃｌｅ３において、ＥＰＳノード４１にＳｌｏｔ１、Ｇａｔｅｗａｙノード４２にＳｌｏｔ２、ＡＢＳノード４３にＳｌｏｔ３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４にＳｌｏｔ４、ＡＴノード４５にＳｌｏｔ１６が、それぞれ割り当てられている。各ノード４１〜４５は、割り当てられたスロットでフレームを送信する。
【０００７】
このように、ＦｌｅｘＲａｙにおいては、通信ノードがフレームを送信可能なスロットは予め定められている。通信ノードは、スロットの割り当て結果としての通信スケジュールに従ってフレームを送受信する。なお、以降の説明においては、通信スケジュールに従ってフレームを送受信する処理を、"通信スケジュールの実行"と表記することがある。
【０００８】
より詳細には、ＦｌｅｘＲａｙにおけるフレームの送信タイミングは、フレームＩＤとスロット番号で決定される。例えば、ＥＰＳノード４１のフレームＩＤが"１"である場合、ＥＰＳノード４１は、スロット番号＝"１"のタイミングでフレームの送信が許可される。また、フレームの受信タイミングは、フレームＩＤによって決定される。通信ノードは、受信対象とするフレームＩＤを予め設定し、通信スケジュールに従って、当該フレームＩＤが付加されたフレームを受信する。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】ＦｌｅｘＲａｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ２．１
【非特許文献２】技術解説(ＦｌｅｘＲａｙとは)、ｈｔｔｐ：／／ｊｐ.ｆｕｊｉｔｓｕ.ｃｏｍ／ｍｉｃｒｏｅｌｅｃｔｒｏｎｉｃｓ／ｔｅｃｈｎｉｃａｌ／ｆｌｅｘｒａｙ／ｉｎｄｅｘ＿ｐ６.ｈｔｍｌ、２００９年１１月７日検索
【発明の概要】
【発明が解決しようとする課題】
【００１０】
近年の車両の高機能化に伴い、さらに信頼性の高い通信システムが望まれている。しかしながら、上記の通信システム１ｘには、いずれかの通信ノードが故障した際に、通信が破綻する虞があるという課題があった。
【００１１】
具体的には、ＦｌｅｘＲａｙに則した通信を行う全ての通信ノードは、共通の時間認識(以下、グローバルタイムと呼称する)を有しており、このグローバルタイムに同期して通信スケジュールを実行する。各通信ノードが同期することは、スケジュールを用いた通信が行われるＦｌｅｘＲａｙにとって重要である。同期が成立しない場合、通信が破綻することとなる。同期が成立する条件は、同期を維持するためのフレーム(以下、シンクフレームと呼称する)を送信する役割を果たす通信ノード(以下、シンクノードと呼称する)が、２台以上、ネットワーク内に存在していることである。
【００１２】
例えば、図７に示した通信ノード１０ｘ＿２及び１０ｘ＿３をシンクノードとした場合、パッシブバス型ネットワーク３内には、シンクノードが２台以上存在することとなる。しかしながら、通信ノード１０ｘ＿２において障害等に因る同期外れが生じた場合、正常なシンクノードは通信ノード１０ｘ＿３だけとなる。このため、同期を維持できず、以て通信が破綻する。同様にして、通信ノード１０ｘ＿３において障害等に因る同期外れが生じた場合も、正常なシンクノードが通信ノード１０ｘ＿２だけとなり、以て通信が破綻する。
【課題を解決するための手段】
【００１３】
本発明の一態様に係る通信ノードは、タイムトリガ型の通信プロトコルに則し、伝送路を介して他の通信ノードと通信する通信部と、自ノードの障害状況を定期的に検出すると共に、前記通信部に、前記障害状況を含む診断フレームを前記伝送路へ送出させる制御部とを備える。
【００１４】
また、本発明の一態様に係るバックアップノードは、タイムトリガ型の通信プロトコルに則して、伝送路を介した相互通信を行う複数の通信ノード各々の機能を実行するためのリソースと、各通信ノードから前記伝送路へ定期的に送出され、且つ各通信ノードの障害状況を含む診断フレームを監視する監視部と、前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行する実行部とを備える。
【００１５】
また、本発明の一態様に係る通信システムは、タイムトリガ型の通信プロトコルに則して、伝送路を介した相互通信を行う複数の通信ノードと、各通信ノードの機能を実行するためのリソースを有するバックアップノードとを備える。各通信ノードは、各通信ノードの障害状況を定期的に検出すると共に、前記障害状況を含む診断フレームを前記伝送路へ送出する。前記バックアップノードは、前記診断フレームを監視し、前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行する。
【００１６】
さらに、本発明の一態様に係る通信ノードのバックアップ方法は、タイムトリガ型の通信プロトコルに則して、相互通信を行う複数の通信ノード各々の機能を実行するためのリソースを保有し、各通信ノードから伝送路へ定期的に送出され、且つ各通信ノードの障害状況を含む診断フレームを監視し、前記障害状況が一の通信ノードによる動作の継続不可を示す場合、又は前記一の通信ノードによる前記診断フレームの送出が停止した場合、前記一の通信ノードの機能を、前記リソースを用いて代替実行することを含む。
【００１７】
すなわち、本発明では、診断フレームを用いて故障ノードの発生を検知し、故障ノードの機能をバックアップする。
【発明の効果】
【００１８】
本発明によれば、通信ノードが故障した場合であっても、通信を破綻させずに維持することができ、以て通信システムの信頼性を、上記の通信システム１ｘと比較して大幅に向上させることが可能である。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施の形態に係る通信システムの構成例を示したブロック図である。
【図２】本発明の実施の形態に係る通信ノードの構成例を示したブロック図である。
【図３】本発明の実施の形態に係るバックアップノードの構成例を示したブロック図である。
【図４】本発明の実施の形態に係る通信ノードにおける、診断フレームの送信処理例を示したフローチャート図である。
【図５】本発明の実施の形態に係る通信ノードにおける、診断フレームの受信処理例を示したフローチャート図である。
【図６】本発明の実施の形態に係るバックアップノードの動作例を示したフローチャート図である。
【図７】ＦｌｅｘＲａｙを適用する一般的な通信システムの構成例を示したブロック図である。
【図８】ＦｌｅｘＲａｙを適用する一般的な通信システムにおける、通信ノードに対する機能及びスロットの割当例を示した図である。
【発明を実施するための形態】
【００２０】
以下、本発明に係る通信ノード及びバックアップノード、並びにこれらを適用する通信システムの実施の形態を、図１〜図６を参照して説明する。なお、各図面において同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００２１】
図１に示すように、本実施の形態に係る通信システム１は、複数の通信ノード１０＿１〜１０＿８(以下、符号１０で総称することがある)と、バックアップノード２０とを備えている。図示の例では、通信ノード１０＿２及び１０＿３が、通信ノード１０＿１で終端される伝送路２に分岐接続され、以てパッシブバス型ネットワーク３を形成している。また、通信ノード１０＿４〜１０＿５は、アクティブスター３０＿１及び３０＿２を介して伝送路２に接続され、以てアクティブスター型ネットワーク４を形成している。さらに、通信ノード１０＿７及び１０＿８は、伝送路２中の接続点に相互接続され、以てパッシブスター型ネットワーク５を形成している。なお、通信システム１においては、バス型ネットワークとスター型ネットワークとを組み合わせたハイブリット型ネットワークが形成されても良い。この場合も、以降の説明は同様に適用される。
【００２２】
この内、通信ノード１０は、図２に示すように、通信部１１と、制御部１２とを含む。通信部１１は、伝送路２に接続され、タイムトリガ型の通信プロトコルの一例としてのＦｌｅｘＲａｙに則して、他の通信ノード(例えば通信ノード１０＿１であれば、他の通信ノード１０＿２〜１０＿８の少なくとも１つ)との相互通信を行う。
【００２３】
また、制御部１２は、通信部１１を制御し、下記(Ａ)〜(Ｅ)に示す処理を実行する。
【００２４】
(Ａ)通信ノード１０の障害状況を定期的に検出する処理。
(Ｂ)上記の処理(Ａ)で得た障害状況を含む診断フレームを生成すると共に、生成した診断フレームを伝送路２へ送出する処理。
(Ｃ)上記の処理(Ａ)で得た障害状況が通信ノード１０による動作の継続不可を示す場合(すなわち、通信ノード１０が故障した場合)、通信部１１に対して通信停止を指示する処理。
(Ｄ)他の通信ノードにより生成された診断フレームを定期的に受信する処理。
(Ｅ)上記の処理(Ｄ)で受信した診断フレームを解析すると共に、その解析結果に応じて、他の通信ノード宛てに送信した最新データを伝送路２へ再送出する処理。
【００２５】
なお、以降の説明においては、上記の処理(Ａ)〜(Ｃ)から成る一連の処理を、"診断フレーム送信処理"と呼称することがある。また、上記の処理(Ｄ)及び(Ｅ)から成る一連の処理を、"診断フレーム受信処理"と呼称することがある。
【００２６】
また、制御部１２は、一般的な通信ノードと同様、通信ノード１０に割り当てられた機能を果たすための処理も実行する。ここで、通信ノード１０に割り当てられた機能とは、通信ノード１０が図８に示したＥＰＳノード４１として動作する場合を例に取ると、ＥＰＳを制御する機能のことである。また、この機能を果たすための処理とは、ＥＰＳからの各種のデータ信号をデータフレームに変換して、他の通信ノードへ送信する処理や、他の通信ノードから受信したデータフレームの内容に応じて、ＥＰＳに対する各種の制御信号を発生する処理等のことである。
【００２７】
一方、バックアップノード２０は、図３に示すように、リソース２１と、監視部２２と、実行部２３とを含む。この内、リソース２１は、大略、通信ノード１０＿１〜１０＿８各々が有する機能を実行するためのリソースである。具体的には、リソース２１は、フレームの送受信に使用するバッファ、通信ノード１０＿１〜１０＿８各々についての通信スケジュールや各種の設定情報(以下、バックアップデータと呼称する)、上記の通信部１１に相当する回路リソース、及び上記の信号−フレーム間の変換処理や制御信号の発生処理に係る回路リソース等を含む。
【００２８】
また、監視部２２は、伝送路２に接続され、各通信ノード１０＿１〜１０＿８から送出される診断フレームを定期的に監視すると共に、その監視結果を実行部２３へ出力する。
【００２９】
さらに、実行部２３は、監視部２２から入力された監視結果が通信ノード１０＿１〜１０＿８のいずれかの故障を示す場合、対応する通信ノードの機能(すなわち、故障ノードの機能)を、リソース２１を用いて代替実行する。この時、実行部２３は、監視部２２を介して、上記の処理(Ｅ)で再送出される最新データを受信し、利用する。
【００３０】
以下、本実施の形態の動作を説明するが、まず、通信ノード１０における診断フレーム送信処理例を、図４を参照して説明する。次いで、通信ノード１０における診断フレーム受信処理例を、図５を参照して説明する。最後に、バックアップノード２０の動作例を、図６を参照して説明する。
【００３１】
[診断フレーム送信処理例]
図４に示すように、通信ノード１０内の制御部１２は、データフレームの送受信を行わないアイドル期間毎に、通信ノード１０に発生している障害を検出する(ステップＳ１０１)。障害を検出した場合、制御部１２は、障害フラグ１０１を更新する(ステップＳ１０２)。ここで、障害フラグ１０１は、複数のフラグ１０１＿１〜１０１＿ｎで構成される。これらのフラグ１０１＿１〜１０１＿ｎには、互いに異なる障害の発生有無が設定される。
【００３２】
次いで、制御部１２は、ＦｌｅｘＲａｙに則したフォーマットを有する診断フレーム１０２を生成すると共に、生成した診断フレーム１０２中(例えばペイロード部)に障害フラグ１０１を含める(ステップＳ１０３)。
【００３３】
次いで、制御部１２は、診断フレーム１０２を通信部１１に与え、以て診断フレーム１０２を伝送路２へ送出する(ステップＳ１０４)。ここで、診断フレーム１０２を送信可能なスロットは、通信スケジュールにより、通信ノード毎に予め定められている。なお、上記のステップＳ１０３で生成した診断フレーム１０２は、次の送信タイミングで流用することができる。具体的には、上記のステップＳ１０２で障害フラグ１０１が更新されない場合、診断フレーム１０２をそのまま利用できる。一方、障害フラグ１０１が更新された場合には、診断フレーム１０２中の障害フラグ１０１に相当する部分のみを、更新後の障害フラグ１０１で置換すれば良い。
【００３４】
また、制御部１２は、障害フラグ１０１を参照し、通信ノード１０が機能切替レベルに在るか否かを判定する(ステップＳ１０５)。ここで、機能切替レベルとは、大略、通信ノード１０が自身の動作を継続できず、バックアップノード２０による機能の代替実行を必要とする状態に在ることを意味し、具体的には、障害フラグ１０１＿１〜１０１＿ｎの内、所定の閾値を超える数分のフラグが"障害有り"に設定されていることを意味する。
【００３５】
この結果、通信ノード１０が機能切替レベルに在ると判定した場合、制御部１２は、通信部１１に対して通信停止(ＨＡＬＴ)を指示し、以て通信ノード１０の機能を停止させる(ステップＳ１０６)。
【００３６】
これにより、バックアップノード２０が診断フレーム１０２に基づき通信ノード１０の機能を代替実行しても、バックアップノード２０とのフレーム送信の衝突を回避することができる。
【００３７】
一方、上記のステップＳ１０５で通信ノード１０が機能切替レベルに無いと判定した場合、制御部１２は、診断フレーム送信処理を終了し、以て通常の通信スケジュールの実行に戻る。
【００３８】
[診断フレーム受信処理例]
図５に示すように、通信部１１は、通信スケジュールにより予め定められたスロットで、他の通信ノードからの診断フレーム１０２を定期的に受信する(ステップＳ２０１)。診断フレーム１０２が受信されると、制御部１２は、診断フレーム１０２を解析する(ステップＳ２０２)。具体的には、制御部１２は、診断フレーム１０２に含まれる障害フラグ１０１を参照し、診断フレーム１０２の送信元ノードがどのような障害状況に在るか判定する。
【００３９】
この結果、診断フレーム１０２の送信元ノードが機能移行レベルに在ると判定した場合(ステップＳ２０３)、制御部１２は、診断フレーム１０２の送信元ノード宛てに送信済みの最新データ１０３を通信部１１に与え、以て最新データ１０３を含むフレームを伝送路２へ再送出する(ステップＳ２０４)。ここで、最新データ１０３を送信可能なスロットは、通信スケジュールにより、通信ノード毎に予め定められている。また、機能移行レベルとは、大略、診断フレーム１０２の送信元ノードが上記の機能切替レベルには至らず一部動作を継続できるが、後にバックアップノード２０による機能の代替実行が必要となり得る状態に在ることを意味し、具体的には、障害フラグ１０１＿１〜１０１＿ｎの内、上記の閾値を超過しないものの幾つかのフラグが"障害有り"に設定されていることを意味する。すなわち、通信ノード１０の障害状況は、機能切替レベル、機能移行レベル、及び正常レベル(通信ノード１０が全ての動作を継続できる状態)に段階的に区別される。
【００４０】
また、上記のステップＳ２０１で他の通信ノードからの診断フレーム１０２が受信されない場合(すなわち、他の通信ノードが完全に故障し、既に診断フレーム１０２を送信できない状態に在る場合)も、制御部１２は、上記のステップＳ２０４を実行し、以て最新データ１０３を含むフレームを伝送路２へ再送出する。
【００４１】
これにより、バックアップノード２０が診断フレーム１０２の送信元ノードの機能を代替実行することとなった際には、送信元ノード宛ての最新データ１０３がバックアップノード２０へ既に引き継がれているため(すなわち、送信元ノードが保持するデータと同一のデータが復元されているため)、バックアップノード２０は、送信元ノードの機能を正確且つ滞り無く代替実行することができる。
【００４２】
この後、制御部１２は、診断フレーム受信処理を終了し、以て通常の通信スケジュールの実行に戻る。
【００４３】
[バックアップノード２０の動作例]
図６に示すように、バックアップノード２０内の監視部２２は、初期状態(例えば、バックアップノード２０の起動時)において、各通信ノード１０＿１〜１０＿８からの診断フレーム１０２の監視を開始する(ステップＳ３０１)。ここで、各通信ノード１０＿１〜１０＿８からの診断フレーム１０２を受信すべきスロットは、通信スケジュールにより予め定められている。
【００４４】
監視部２２は、診断フレーム１０２を受信すると(ステップＳ３０２)、診断フレーム１０２を解析する(ステップＳ３０３)。そして、監視部２２は、診断フレーム１０２に含まれる障害フラグ１０１を参照し、診断フレーム１０２の送信元ノードが機能切替レベル、機能移行レベル、及び正常レベルのいずれに在るか判定する(ステップＳ３０４)。
【００４５】
この結果、診断フレーム１０２の送信元ノードが正常レベルに在ると判定した場合、監視部２２は、上記のステップＳ３０２に戻って、診断フレーム１０２の監視を継続する。
【００４６】
また、上記のステップＳ３０４で診断フレーム１０２の送信元ノードが機能移行レベルに在ると判定された場合、実行部２３は、送信元ノードの受信機能を実行する(ステップＳ３０５)。具体的には、実行部２３は、上述したリソース２１中のバックアップデータ(設定情報)に基づき受信バッファの初期設定を行う。また、実行部２３は、バックアップデータに含まれる通信スケジュールに従い、送信元ノードに割り当てられたスロットで送信元ノード宛てのデータフレームを受信する。ここで、実行部２３が受信機能のみを実行するのは、送信元ノードとのフレーム送信の衝突を回避するためである。
【００４７】
そして、実行部２３は、上記のステップＳ２０４で他の通信ノードから送出された最新データ１０３を受信する(ステップＳ３０６)。ここで、各通信ノードからの最新データ１０３を受信すべきスロットは、通信スケジュールにより予め定められている。これと並行して、監視部２２は、上記のステップＳ３０２に戻って、診断フレーム１０２の監視を継続する。
【００４８】
一方、上記のステップＳ３０４で診断フレーム１０２の送信元ノードが機能切替レベルに在ると判定された場合、実行部２３は、最新データ１０３を受信済みか否か判定する(ステップＳ３０７)。今、最新データ１０３を受信済みであるため、実行部２３は、リソース２１を用いて、送信元ノードの全機能を代替実行する(ステップＳ３０８)。
【００４９】
また、上記のステップＳ３０２で診断フレーム１０２が受信されない場合(すなわち、送信元ノードが完全に故障し、診断フレーム１０２を送信できない状態に在る場合)にも、実行部２３は、上記のステップＳ３０７を実行し、以て最新データ１０３を受信済みか否か判定する。例えば、送信元ノードが突然故障し、機能移行レベルを経ること無く機能切替レベルに達した場合、最新データ１０３が未受信であるため、実行部２３は、図６に一点鎖線で示す如く上記のステップＳ３０５及びＳ３０６を経由して、送信元ノードの受信機能を代替実行し、以て最新データ１０３を受信する。さらに、実行部２３は、上記のステップＳ３０８に進んで、送信元ノードの受信機能以外の他の機能を代替実行する。
【００５０】
このように、本実施の形態においては、故障ノードの発生を検知し、故障ノードの機能をバックアップすることができる。従って、故障ノードが発生した場合であっても、通信を破綻させずに維持することができる。
【００５１】
また、故障ノードが保持するデータを復元でき、以て故障ノードの機能を正確且つ滞り無くバックアップすることができる。
【００５２】
さらに、診断フレームを用いて通信ノードの障害状況を確認するため、通信ノード間の接続体系(ネットワークトポロジ)に依存せず、故障ノードの機能をバックアップできるというメリットもある。
【００５３】
以下、本実施の形態のより詳細な動作を、通信ノード１０を図８(ａ)に示したＥＰＳノード４１、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、ＡＴノード４５として機能させ、且つＥＰＳノード４１を故障ノードとした場合を例に取って説明する。
【００５４】
ここで、通信スケジュールの一例として、ＥＰＳノード４１には、任意の通信サイクルのＳｌｏｔ１が診断フレーム１０２の送信用に割り当てられていることとする。また、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５には、同通信サイクルのＳｌｏｔ１０〜Ｓｌｏｔ１３が最新データ１０３の送信用にそれぞれ割り当てられていることとする。なお、他のスロット及び他の通信サイクルは、ノード４１〜４５間における通常のデータフレームの送受信に使用される。
【００５５】
ＥＰＳノード４１は、通常の通信スケジュールを実行した後、図４に示した上記のステップＳ１０１で機能移行レベルに至る障害を検出した場合、上記のステップＳ１０２で、障害フラグ１０１＿１〜１０１＿ｎを更新する。
【００５６】
そして、ＥＰＳノード４１は、上記のステップＳ１０３で、更新後の障害フラグ１０１＿１〜１０１＿ｎを含む診断フレーム１０２を生成する。ＥＰＳノード４１は、上記のステップＳ１０４に進み、例えばＣｙｃｌｅ５のＳｌｏｔ１で、診断フレーム１０２を伝送路２(チャネル"Ａｃｈ"若しくは"Ｂｃｈ"、又はその両方)へ送出する。この時、ＥＰＳノード４１は、上記のステップＳ１０５で、自ノードが未だ機能切替レベルに達していないと判定して、診断フレーム送信処理を終了し、以て通常の通信スケジュールの実行に戻る。
【００５７】
一方、図５に示した上記のステップＳ２０１において、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５は、同Ｃｙｃｌｅ５のＳｌｏｔ１で、ＥＰＳノード４１からの診断フレーム１０２をそれぞれ受信する。そして、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５は、上記のステップＳ２０２で、受信した診断フレーム１０２をそれぞれ解析する。この結果、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５は、上記のステップＳ２０３で、ＥＰＳノード４１が機能移行レベルに在るとそれぞれ判定する。そして、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５は、上記のステップＳ２０４に進み、同Ｃｙｃｌｅ５の例えばＳｌｏｔ１０〜Ｓｌｏｔ１３で、ＥＰＳノード４１宛てに送信済みの最新データ１０３を伝送路２(チャネル"Ａｃｈ"若しくは"Ｂｃｈ"、又はその両方)へそれぞれ再送出する。この後、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５は、診断フレーム受信処理を終了し、通常の通信スケジュールの実行に戻る。
【００５８】
また、バックアップノード２０は、図６に示した上記のステップＳ３０２において、同Ｃｙｃｌｅ５のＳｌｏｔ１でＥＰＳノード４１からの診断フレーム１０２を受信する。そして、バックアップノード２０は、上記のステップＳ３０３で、受信した診断フレーム１０２を解析する。この結果、バックアップノード２０は、上記のステップＳ３０４で、ＥＰＳノード４１が機能移行レベルに在ると判定する。そして、バックアップノード２０は、上記のステップＳ３０５及びＳ３０６を実行し、以て同Ｃｙｃｌｅ５のＳｌｏｔ１０〜Ｓｌｏｔ１３で、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５からの最新データ１０３を順次受信する。なお、最新データ１０３の送受信処理は、ＥＰＳノード４１が機能切替レベルに達するまで繰り返し実行される。
【００５９】
この後、ＥＰＳノード４１は、通常の通信スケジュールを実行した後、上記のステップＳ１０１で機能切替レベルに至る障害を検出した場合、上記のステップＳ１０２で、障害フラグ１０１＿１〜１０１＿ｎを更新する。
【００６０】
そして、ＥＰＳノード４１は、上記のステップＳ１０３で、更新後の障害フラグ１０１＿１〜１０１＿ｎを含む診断フレーム１０２を生成する。ＥＰＳノード４１は、上記のステップＳ１０４に進み、例えばＣｙｃｌｅ１５のＳｌｏｔ１で、診断フレーム１０２を伝送路２(チャネル"Ａｃｈ"若しくは"Ｂｃｈ"、又はその両方)へ送出する。この時、ＥＰＳノード４１は、上記のステップＳ１０５で、自ノードが機能切替レベルに達した判定して、上記のステップＳ１０６に進み、以て通信を停止する。
【００６１】
一方、バックアップノード２０は、上記のステップＳ３０２において、同Ｃｙｃｌｅ１５のＳｌｏｔ１でＥＰＳノード４１からの診断フレーム１０２を受信する。そして、バックアップノード２０は、上記のステップＳ３０３で、受信した診断フレーム１０２を解析する。この結果、バックアップノード２０は、上記のステップＳ３０４で、ＥＰＳノード４１が機能切替レベルに在ると判定する。そして、バックアップノード２０は、上記のステップＳ３０７を経由して上記のステップＳ３０８に進み、以てＥＰＳノード４１の全機能を代替実行する。
【００６２】
これらの一連の処理により、ＥＰＳノード４１が故障した場合であっても、その機能がバックアップノード２０によって代替実行される。このため、ＥＰＳノード４１として機能するバックアップノード２０と、Ｇａｔｅｗａｙノード４２、ＡＢＳノード４３、Ｓｔｅｅｒｉｎｇ Ｓｅｎｓｏｒノード４４、及びＡＴノード４５との間の通信が破綻せずに維持される。従って、車両は、安全に制御されることとなる。
【００６３】
なお、上記の実施の形態によって本発明は限定されるものではなく、特許請求の範囲の記載に基づき、当業者によって種々の変更が可能なことは明らかである。例えば、診断フレーム１０２には、障害フラグ１０１に代えて、上記の機能切替レベル、機能移行レベル、及び正常レベルを、通信ノード１０の障害状況として含めるようにしても良い。この場合、通信ノード１０及びバックアップノード２０における診断フレーム１０２の解析処理に係る負荷が軽減されることとなる。
【符号の説明】
【００６４】
１  通信システム
２  伝送路
３  パッシブバス型ネットワーク
４  アクティブスター型ネットワーク
５  パッシブスター型ネットワーク
１０, １０＿１〜１０＿８  通信ノード
１１  通信部
１２  制御部
２０  バックアップノード
２１  リソース
２２  監視部
２３  実行部
３０＿１, ３０＿２  アクティブスター
１０１, １０１＿１〜１０１＿ｎ  障害フラグ
１０２  診断フレーム
１０３  最新データ
【図１】
2011211485.tif 000003
【図２】
2011211485.tif 000004
【図３】
2011211485.tif 000005
【図４】
2011211485.tif 000006
【図５】
2011211485.tif 000007
【図６】
2011211485.tif 000008
【図７】
2011211485.tif 000009
【図８】
2011211485.tif 000010