JP4807171B2 - 通信ネットワークシステム及びエラー検証方法 - Google Patents

Description

本発明は、時分割多重通信型の通信ネットワークシステム、及び、時分割多重通信型の通信ネットワークシステムにおけるエラー検証方法に関する。

車両に搭載される通信ネットワークシステムのプロトコルの１種として、ＦｌｅｘＲａｙ（Daimler Chrysler AGの登録商標）と呼ばれる通信プロトコルが知られている。このＦｌｅｘＲａｙは、高い信頼性を確保しながら最大１０Ｍｂｐｓ程度の通信速度を実現するものであり、車両走行に直接関わる部分の電子化制御（Ｘ−ｂｙ−ｗｉｒｅ）を実用化する上での重要な技術として注目されている。

ＦｌｅｘＲａｙでは、データ転送方式としてタイムトリガ方式を採用しており、ネットワーク上の各ノードのフレーム送受信のタイミングが予めスケジューリングされている。ＦｌｅｘＲａｙの一通信周期はコミュニケーション・サイクルと呼ばれ、このコミュニケーション・サイクルには、１つのフレームを送信する時間区分であるスロットの長さが固定長とされた静的領域（スタティック・セグメント）と、スロットの長さが可変長とされた動的領域（ダイナミック・セグメント）とが定義されている。ＦｌｅｘＲａｙでは、ネットワーク上の各ノードが、ネットワーク内における共通の時間認識であるグローバルタイムに従って、各コミュニケーション・サイクル内の静的領域や動的領域において自ノードに割り当てられたスロットのタイミングを認識し、当該スロット内で他ノードに転送すべきフレームを送信するとともに、自ノードが受信すべきフレームの送信用に割り当てられたスロットのタイミングを認識し、当該スロット内で他ノードから送信されたフレームを受信する。また、ネットワーク上の各ノードは、他ノードから送信されたフレームを受信する際には、スロット内でのフレーム受信状態を表す受信ステータス情報を取得して、この受信ステータス情報に基づいて、フレームを正常に受信できたか否かを診断する。

以上のようなＦｌｅｘＲａｙ通信では、ネットワーク上の全てのノードがグローバルタイムを正しく認識してフレームの送受信を行っている限り、ノード間で送受信されるフレームは全て対応するスロット内に収まっており、各スロットの境界は信号成分のないアイドル状態となる。しかしながら、ネットワーク上のノードの何れかに時間認識のずれ（同期ずれ）が発生した場合には、当該ノードから送信されるフレームが他のノードが認識するスロットの境界を跨いでしまうことにより、スロットの境界で信号成分が検出されることがある。このような場合、同期ずれが発生したノードからのフレームを他のノードが受信しようとした際に、他のノードは、境界違反のエラー発生を示す受信ステータス情報を取得する。そして、このような境界違反のエラー発生を示す受信ステータス情報を取得した場合、他のノードは、受信したフレームのデータを自ノードのアプリケーションで使用することなく、破棄するようにしている。なお、ＦｌｅｘＲａｙにおける受信ステータス情報については、下記非特許文献１に詳細が記載されている。
「FlexRay Communication System Protocol Specification Version2.1 RevisionA」，２００５年１２月，ｐ．２０４−２０７

ところで、上述した境界違反のエラー発生を示す受信ステータス情報は、スロットの境界で信号成分が検出されることで出力される情報であるため、この境界を挟んで隣接する前後２つのスロットのどちらでフレームのずれが生じているかによらず、これら２つのスロットの双方で同様に取得されることになる。したがって、ネットワーク上の各ノードは、自ノードが受信すべきフレームが送信されているスロットで当該フレームを受信する際に境界違反のエラー発生を示す受信ステータス情報を取得した場合、その境界違反の要因、つまり、自ノードが受信すべきフレームに異常が発生しているのか、或いは隣接するスロットのフレームに異常が発生しているのかを特定することができない。このため、例えば、自ノードが受信すべきフレームはスロット内で正常に送信されているが、隣接するスロットのフレームがずれてスロット境界を跨いで送信されたことに起因して、境界違反のエラー発生を示す受信ステータス情報を取得した場合、当該ノードは、正しいフレームを受信しているにも拘わらず、そのフレームのデータを自ノードのアプリケーションで使用することができず、効率の低下を招いてしまっていた。

本発明は、以上のような従来の実情に鑑みて創案されたものであって、受信ステータス情報で示されるエラーの要因を的確に判断し、エラー要因に応じた最適な対応を図れるようにして効率的な通信を実現する通信ネットワークシステム及びエラー検証方法を提供することを目的としている。

本発明は、ネットワーク上の各ノードが、各通信周期の中で時分割されたフレーム送信期間であるスロットを認識し、自ノードが受信すべきフレームの送信用に割り当てられた受信対象スロット内でフレームを受信するとともに、スロット内でのフレーム受信状態を表す受信ステータス情報を取得する時分割多重通信型の通信ネットワークシステムを対象とする。このような時分割多重通信型の通信ネットワークシステムにおいて、本発明では、ネットワーク上の各ノードに、受信対象スロットとその前後に隣接する２つの隣接スロットとの３つのスロットに亘って受信ステータス情報をそれぞれ取得する機能と、これら３つのスロットに関する受信ステータス情報に基づいて受信対象スロットにおけるエラーの有無及びエラー要因を検証する機能とを持たせることで、上述した課題を解決する。

本発明によれば、ネットワーク上の各ノードが受信対象スロットにおけるエラーの有無及びエラー要因を的確に判断することができ、エラー要因に応じた最適な対応を図ることが可能となるので、効率的な通信を実現することができる。

以下、本発明の実施形態として、通信プロトコルにＦｌｅｘＲａｙを採用した車載用の通信ネットワークシステムに本発明を適用した例について説明する。本実施形態の通信ネットワークシステムは、車載電装システムを制御する複数の電子制御装置（ＥＣＵ：Electronic Control Unit）にそれぞれ通信機能を搭載し、これらの各ＥＣＵをネットワーク上のノードとしてＦｌｅｘＲａｙバスに接続することで構成され、各ＥＣＵ間でＦｌｅｘＲａｙプロトコルに従った通信を行って情報を共有することで、複数のＥＣＵの協調動作による多彩な制御を実現するものである。

本実施形態の通信ネットワークシステムにおいて、通信プロトコルとして採用されるＦｌｅｘＲａｙでのデータ転送の仕組みを図１に概略的に示す。ＦｌｅｘＲａｙでのデータ転送方式は、ネットワーク上の各ノードが予めスケジューリングされた送信タイミングでフレームを送信するタイムトリガ方式である。各ノード間のデータ転送は、通信ネットワークシステムの稼動中に繰り返されるコミュニケーション・サイクル（通信周期）を単位として行われる。コミュニケーション・サイクルは、図１に示すように、スタティック・セグメント（静的領域）と、ダイナミック・セグメント（動的領域）と、シンボル・ウィンドウと、ネットワーク・アイドルタイムの４つのセグメントから構成される。

スタティック・セグメントは、フレームサイズ一定でデータ転送を行う期間であり、複数のスタティック・スロットから構成される。スタティック・スロットは、スタティック・セグメントにおいて１フレームを送信する時間区分（帯域）であり、全てのスタティック・スロットの時間は等しく、そのスロット内で送信されるフレームの長さも等しい。このスタティック・セグメントでは、ネットワーク上の各ノードが予め定められたスケジュールにのみ従って通信を行う。

ダイナミック・セグメントは、フレームサイズ可変でデータ転送を行う期間であり、複数のダイナミック・スロットから構成される。ダイナミック・スロットは、ダイナミック・セグメントにおいて１フレームを送信する時間区分であり、その長さは、ネットワーク上の各ノードの送信要求に従って変化させることが可能である。このダイナミック・セグメントでは、ネットワーク上の各ノードが優先度に従った通信を行うことが可能である。

シンボル・ウィンドウは、ネットワークのスタートアップ時やウェイクアップ時などに使用される領域であり、また、ネットワーク・アイドルタイムは、エラー訂正やクロック同期の同期補正量算出などで使用される領域である。なお、上述したコミュニケーション・サイクルにおけるダイナミック・セグメントとシンボル・ウィンドウは、オプションとして設定されるものであり、通信ネットワークシステムの構成や用途によっては不要とされる。

ＦｌｅｘＲａｙのフレーム・フォーマットを図２に概略的に示す。ＦｌｅｘＲａｙのフレームは、図２に示すように、ヘッダ・セグメント（５バイト）と、ペイロード・セグメント（０〜２５４バイト）と、トレイラ・セグメント（３バイト）の３つのセグメントで構成される。ヘッダ・セグメントには、送信するデータに関するヘッダ情報が格納され、ペイロード・セグメントには、データそのものが格納される。また、トレイラ・セグメントはフレーム全体でエラーがあるかどうかをチェックする機能を持ち、ヘッダ・セグメントとペイロード・セグメントをＣＲＣ（Cyclic Redundancy Check）にかけた結果が格納される。

本実施形態の通信ネットワークシステムでは、ネットワーク上の各ノードが、ネットワーク内における共通の時間認識であるグローバルタイムに従って、上述したコミュニケーション・サイクルのスタティック・セグメントやダイナミック・セグメントの中で自ノードのフレーム送信期間として割り当てられたスロットを認識し、当該スロット内で、自ノードのアプリケーションデータを含む上述したフォーマットのフレームを送信する。このとき、各スロットのサイズは送信するフレームが十分に収まる長さに設定されており、ネットワーク上の各ノードは、図３に模式的に示すように、スロット境界との間に余裕を持たせた状態で当該スロット内でフレームを送信する。つまり、コミュニケーション・サイクル内の各スロットには、当該スロット内で送信されるフレームの前後にアイドル期間が設けられ、フレームとフレームの間のアイドル期間と隣接するスロットの間のスロット境界は、信号成分のないアイドル状態となる。

また、ネットワーク上の各ノードは、ネットワーク内における共通の時間認識であるグローバルタイムに従って、上述したコミュニケーション・サイクルのスタティック・セグメントやダイナミック・セグメントの中で自ノードが受信すべきフレームの送信用に割り当てられたスロット（以下、受信対象スロットという。）を認識し、当該受信対象スロット内で他ノードが送信したフレームを受信する。このとき、各ノードは、スロットでのフレーム受信状態を表す受信ステータス情報、具体的には図４に示すような受信ステータス情報を取得して、これらの受信ステータス情報に基づいて、他ノードからのフレームを正常に受信できたか否かの受信診断を行う。この図４に示す受信ステータス情報のうち、有効なフレームを受信したか否かを示す「ValidFrame」、文法的に正しいフレームを受信したか否かを示す「SyntaxError」、内容的に正しいフレームを受信したか否かを示す「ContentError」は、全て、スロット内のフレームの正常性を表す情報である。以下では、これらの受信ステータス情報を「フレーム状態情報」と総称する。また、スロットのいずれかの境界で境界違反が起こったかどうかを示す「Bviolation」は、スロットのいずれかの境界で信号成分が検出された場合に「違反あり」とされる情報であり、以下では、この受信ステータス情報を「境界違反情報」と称する。

ネットワーク上の各ノードは、受信対象スロット内でフレームを受信したときに得られる受信ステータス情報のうち、フレーム状態情報の何れかが「異常受信」を示すものである場合は、そのフレーム自体に異常が発生していると判断できる。したがって、このような場合には、受信したフレームのデータを自ノードのアプリケーションで使用することなく破棄する。一方、受信対象スロット内でフレームを受信したときに得られる受信ステータス情報のうちの境界違反情報が「違反あり」を示すものである場合、その要因としては、図５（ａ）〜（ｆ）の６つの場合が考えられ、受信対象スロットに関する境界違反情報だけでは、これら図５（ａ）〜（ｆ）の何れの状況となっているのかを判別することができない。

すなわち、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、当該フレーム（ｍ）の送信元ノードの同期ずれなどにより、図５（ａ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の前の隣接スロット（ｎ−１）とのスロット境界を跨いだかたちでフレーム（ｍ）が送信されていた場合、この前側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

また、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、当該フレーム（ｍ）の送信元ノードの同期ずれなどにより、図５（ｂ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の後ろの隣接スロット（ｎ＋１）とのスロット境界を跨いだかたちでフレーム（ｍ）が送信されていた場合、この後ろ側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

また、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、受信対象スロット（ｎ）の前の隣接スロット（ｎ−１）でフレーム（ｍ−１）を送信したノードの同期ずれなどにより、図５（ｃ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の前の隣接スロット（ｎ−１）とのスロット境界を跨いだかたちでフレーム（ｍ−１）が送信されていた場合、この前側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

また、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、受信対象スロット（ｎ）の後ろの隣接スロット（ｎ＋１）でフレーム（ｍ＋１）を送信したノードの同期ずれなどにより、図５（ｄ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の後ろの隣接スロット（ｎ＋１）とのスロット境界を跨いだかたちでフレーム（ｍ＋１）が送信されていた場合、この後ろ側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

また、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、図５（ｅ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の前の隣接スロット（ｎ−１）とのスロット境界で瞬間的なノイズが発生した場合、この前側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

また、あるノードが、受信対象スロット（ｎ）内でフレーム（ｍ）を受信する際に、図５（ｆ）に示すように、受信対象スロット（ｎ）とこの受信対象スロット（ｎ）の後ろの隣接スロット（ｎ＋１）とのスロット境界で瞬間的なノイズが発生した場合、この後ろ側のスロット境界で通信バスの電圧変動（信号成分）が検出されることによって、境界違反情報は「違反あり」となる。

以上の図５（ａ）〜（ｆ）で示した境界違反の発生要因のうち、図５（ａ）及び図５（ｂ）の要因は受信したフレーム自体の異常であり、受信したフレームのデータをアプリケーションで使用することはできないが、図５（ｃ）〜（ｆ）の要因は、隣接スロットで送信されている他のフレームの異常やノイズの影響であり、受信したフレーム自体の異常ではないので、受信したフレームのデータを自ノードのアプリケーションで使用することが可能である。しかしながら、受信対象スロットに関する境界違反情報だけでは上述した図５（ａ）〜（ｆ）の状況を判別できないため、従来は、図５（ｃ）〜（ｆ）の要因で「違反あり」を示す境界違反情報が取得された場合でも、受信したフレームのデータを自ノードのアプリケーションで使用することなく破棄するようにしており、効率の低下を招いてしまっていた。

そこで、本実施形態の通信ネットワークシステムでは、ネットワーク上の各ノードが、受信対象スロットのフレームだけでなく、その前後に隣接するスロットのフレームも受信して、受信対象スロットとその前後に隣接する２つの隣接スロットとの３つのスロットに亘って受信ステータス情報を取得するようにしている。そして、これら３つのスロットに関する受信ステータス情報に基づいて受信対象スロットにおけるエラーの有無及びエラー要因を検証することで、例えば、受信対象スロットの境界違反情報が「違反あり」であった場合に、その要因が、上述した図５（ａ）〜（ｆ）の何れの状況によるものであるのかを判別できるようにして、図５（ａ）及び図５（ｂ）の状況であれば受信したフレームのデータを破棄し、図５（ｃ）〜（ｆ）の状況であれば受信したフレームのデータを自ノードのアプリケーションで使用するなど、適切な対応を図れるようにしている。

［第１実施例］
次に、以上のような本実施形態の通信ネットワークシステムを構成するノードの具体例（第１実施例）について、図６及び図７を参照して説明する。

本実施例のノード１０は、図６に示すように、ハード的な内部構成として、ホストＣＰＵ１１と、通信コントローラ１２と、バスドライバ１３とを備えている。ホストＣＰＵ１１は、ノード１０全体を動作を制御するコントローラであり、通信コントローラ１２は、ノード１０の通信を制御するコントローラである。また、バスドライバ１３は、通信バス１００と通信コントローラ１２との間での物理的信号と論理的信号との信号変換を行うものである。

ここで、本実施例のノード１０においては、通信コントローラ１２の制御のもとで他ノードから通信バス１００上に送出されたフレームを受信する際に、自ノードが受信すべきフレーム（以下、受信フレームという。）が格納されている受信対象スロットだけでなく、その前後に隣接するスロット（以下、受信対象スロットの前に隣接するスロットを前スロット、受信対象スロットの後ろに隣接するスロットを後スロットという。）においてもフレームの受信処理を行い、前スロット、受信対象スロット、後スロットの３つのスロットのそれぞれに関しての受信ステータス情報（境界違反情報及びフレーム状態情報）を取得する。そして、ホストＣＰＵ１１が、これら３つのスロットに関する受信ステータス情報に基づいて、受信対象スロットのエラーの有無及びその要因を検証し、その検証結果に基づいて、受信フレームのデータを自ノードのアプリケーションで使用するかどうかを判定するようにしている。

詳述すると、本実施例のノード１０では、ソフトウェアで実現されるホストＣＰＵ１１の機能として、境界違反検証機能１４と、エラー発生箇所特定機能１５と、エラー判別機能１６と、フレーム使用可否判定機能１７とが設けられる。

境界違反検証機能１４は、受信対象スロットの前後のスロット境界のいずれかで境界違反が発生しているかどうかを検証する機能である。この境界違反検証機能１４では、通信コントローラ１２が受信対象スロットで受信フレームの受信処理を行った際に取得される境界違反情報に基づいて、受信対象スロットの境界違反が検証される。

エラー発生箇所特定機能１５は、境界違反検証機能１４により受信対象スロットの前後のスロット境界のいずれかで境界違反が発生していると判定されたときに、前後どちらのスロット境界で境界違反が発生しているかを特定する機能である。このエラー発生箇所特定機能１５では、通信コントローラ１２が前スロットでフレーム（以下、前フレームという。）の受信処理を行った際に取得される境界違反情報と、後スロットでフレーム（以下、後フレームという。）の受信処理を行った際に取得される境界違反情報とに基づいて、境界違反が発生しているスロット境界が特定される。

エラー判別機能１６は、エラー発生箇所特定機能１５で特定されたスロット境界で発生している境界違反のエラー要因を判別する機能である。ここで、境界違反のエラー要因としては、受信フレームの境界越え、前フレームの境界越え、後フレームの境界越え、ノイズ発生、その他、が考えられる。エラー判別機能１６では、エラー発生箇所特定機能１５によって境界違反が発生しているスロット境界が受信対象スロットと前スロットとの境界であると特定された場合には、通信コントローラ１２が前スロットで前フレームの受信処理を行った際に取得されるフレーム状態情報と、受信対象スロットで受信フレームの受信処理を行った際に取得されるフレーム状態情報とに基づいて、境界違反のエラー要因が前記のいずれの要因であるかが判別される。また、エラー判別機能１６では、エラー発生箇所特定機能１５によって境界違反が発生しているスロット境界が受信対象スロットと後スロットとの境界であると特定された場合には、通信コントローラ１２が受信対象スロットで受信フレームの受信処理を行った際に取得されるフレーム状態情報と、後スロットで後フレームの受信処理を行った際に取得されるフレーム状態情報とに基づいて、境界違反のエラー要因が前記のいずれの要因であるかが判別される。

フレーム使用可否判定機能１７は、エラー判別機能１６により判別された境界違反のエラー要因に応じて、受信フレームのデータを自ノードのアプリケーションで使用できるか否かを判定する機能である。このフレーム使用可否判定機能１７では、エラー判別機能１６により判別された境界違反のエラー要因が前フレームの境界越えである場合や、後フレームの境界越えである場合、ノイズの発生である場合には、受信フレーム自体の異常ではないため、受信フレームのデータを自ノードのアプリケーションで使用できると判定される。また、フレーム使用可否判定機能１７では、エラー判別機能１６により判別された境界違反のエラー要因が受信フレームの境界越えである場合や、その他の要因（例えば通信コントローラ１２の異常など）である場合には、受信フレーム自体に異常が発生している、或いはその可能性が高いため、受信フレームのデータを自ノードのアプリケーションで使用できないと判定される。

図７は、本実施例のノード１０において、ホストＣＰＵ１１の上述した各機能により実行される一連の処理の流れを示すフローチャートである。以下、この図７のフローチャートに沿って、本発明に特徴的なホストＣＰＵ１１による処理について、具体的に説明する。なお、この図７の処理フローは、通信コントローラ１２により受信フレーム及び前後フレームの受信処理が行われ、受信対象スロット及び前・後スロットに関する受信ステータス情報（境界違反情報及びフレーム状態情報）が取得されるたびに、ホストＣＰＵ１１により繰り返し実行されるものである。

図７の処理フローが開始されると、ホストＣＰＵ１１は、まずステップＳ１０１において、受信対象スロットに関する境界違反情報が「違反あり」となっているか否かを確認する。そして、受信対象スロットに関する境界違反情報が「違反なし」であれば、エラータイプをエラーなし（タイプＡ）とする（ステップＳ１０２）。なお、エラータイプは、受信対象スロットに関する境界違反のエラー要因を識別する情報である。

一方、受信対象スロットに関する境界違反情報が「違反あり」の場合には、ホストＣＰＵ１１は、次のステップＳ１０３において、前スロットに関する境界違反情報が「違反あり」となっているか否かを確認する。ここで、前スロットに関する境界違反情報が「違反あり」であれば、受信対象スロットと前スロットとのスロット境界で境界違反が発生していると特定されるので、ホストＣＰＵ１１は、ステップＳ１０４において、受信対象スロットに関するフレーム状態情報が「異常受信」となっているか否かを確認する。そして、受信対象スロットに関するフレーム状態情報が「異常受信」であれば、エラータイプを受信フレーム境界越え（タイプＢ）とする（ステップＳ１０５）。また、ホストＣＰＵ１１は、受信対象スロットに関するフレーム状態情報が「正常受信」であれば、ステップＳ１０６において、前スロットに関するフレーム状態情報が「異常受信」となっているか否かを確認し、前スロットに関するフレーム状態情報が「異常受信」であれば、エラータイプを前フレーム境界越え（タイプＣ）とし（ステップＳ１０７）、前スロットに関するフレーム状態情報が「正常受信」であれば、エラータイプをノイズ発生（タイプＤ）とする（ステップＳ１０８）。

また、前スロットに関する境界違反情報が「違反なし」の場合には、ホストＣＰＵ１１は、次のステップＳ１０９において、後スロットに関する境界違反情報が「違反あり」となっているか否かを確認する。ここで、後スロットに関する境界違反情報が「違反あり」であれば、受信対象スロットと後スロットとのスロット境界で境界違反が発生していると特定されるので、ホストＣＰＵ１１は、ステップＳ１１０において、受信対象スロットに関するフレーム状態情報が「異常受信」となっているか否かを確認する。そして、受信対象スロットに関するフレーム状態情報が「異常受信」であれば、エラータイプを受信フレーム境界越え（タイプＢ）とする（ステップＳ１１１）。また、ホストＣＰＵ１１は、受信対象スロットに関するフレーム状態情報が「正常受信」であれば、ステップＳ１１２において、後スロットに関するフレーム状態情報が「異常受信」となっているか否かを確認し、後スロットに関するフレーム状態情報が「異常受信」であれば、エラータイプを後フレーム境界越え（タイプＥ）とし（ステップＳ１１３）、後スロットに関するフレーム状態情報が「正常受信」であれば、エラータイプをノイズ発生（タイプＤ）とする（ステップＳ１１４）。

また、後スロットに関する境界違反情報が「違反なし」の場合には、境界違反が発生しているスロット境界を特定できず、例えば通信コントローラ１２の異常などの他の要因により境界違反が発生しているものと考えられるので、この場合、ホストＣＰＵ１１は、エラータイプをその他エラー（タイプＦ）とする（ステップＳ１１５）。

次に、ホストＣＰＵ１１は、ステップＳ１１６において、以上の処理で判定したエラータイプを確認し、エラータイプがエラーなし（タイプＡ）、前フレーム境界越え（タイプＣ）、ノイズ発生（タイプＤ）、後フレーム境界越え（タイプＥ）のいずれかであれば、ステップＳ１１７において、受信フレーム自体に異常はないと判断して、受信フレームのデータを自ノードのアプリケーションで使用する。一方、ホストＣＰＵ１１は、エラータイプが受信フレーム境界越え（タイプＢ）又はその他エラー（タイプＦ）の場合には、受信フレーム自体に異常が発生している或いはその可能性が高いと判断して、受信フレームのデータを自ノードのアプリケーションで使用することなく破棄する。

［第２実施例］
次に、本実施形態の通信ネットワークシステムを構成するノードの他例（第２実施例）について、図８及び図９を参照して説明する。

本実施例のノード２０は、図８に示すように、ホストＣＰＵ１１の機能として、境界違反検証機能１４、エラー発生箇所特定機能１５、エラー判別機能１６、フレーム使用可否判定機能１７の各機能に加えて、同期ずれノード判定機能１８と、同期ずれ通知機能１９とを設けたものである。なお、その他の構成は、上述した第１実施例のノード１０と共通であるので、以下、第１実施例のノード１０と共通の部分は同一の符号を付して説明を省略し、本実施例に特徴的な部分についてのみ説明する。

本実施例のノード２０では、ホストＣＰＵ１１のエラー判定機能１６による判定結果が、フレーム使用可否判定機能１７だけでなく、同期ずれノード判定機能１８においても使用される。同期ずれノード判定機能１８は、エラー判別機能１６により判別された境界違反のエラー要因に応じて、フレーム送信元のノードで同期ずれが発生しているノードが存在するか否かを判定する機能である。この同期ずれノード判定機能１８では、エラー判別機能１６により判別された境界違反のエラー要因が受信フレームの境界越えである場合には、受信フレームの送信元ノードに同期ずれが発生していると判定される。また、この同期ずれノード判定機能１８では、エラー判別機能１６により判別された境界違反のエラー要因が前フレームの境界越えである場合には、前フレームの送信元ノードに同期ずれが発生していると判定され、エラー判別機能１６により判別された境界違反のエラー要因が後フレームの境界越えである場合には、後フレームの送信元ノードに同期ずれが発生していると判定される。

同期ずれ通知機能１９は、同期ずれノード判定機能１８により受信フレームの送信元ノード、前フレームの送信元ノード、後フレームの送信元ノードのいずれかに同期ずれが発生していると判定されたときに、当該ノードに対して、同期ずれが発生していることを通知する機能である。この同期ずれ通知機能では、例えば、同期ずれの発生を通知するための同期ずれ通知フレームが予め用意されており、同期ずれノード判定機能１８によって同期ずれが発生しているノードが特定されると、当該ノードが受信処理を行うスロットとして予め定められたスロット内で、同期ずれ通知フレームが送信される。なお、境界越えが生じているフレームの送信元ノードに同期ずれを通知するための手法は、以上例示した手法に限らず、様々な手法が適用できる。

図９は、本実施例のノード２０において、ホストＣＰＵ１１の上述した各機能により実行される一連の処理の流れを示すフローチャートである。この図９の処理フローは、通信コントローラ１２により受信フレーム及び前後フレームの受信処理が行われ、受信対象スロット及び前・後スロットに関する受信ステータス情報（境界違反情報及びフレーム状態情報）が取得されるたびに、ホストＣＰＵ１１により繰り返し実行されるものである。

本実施例のノード２０においても、上述した第１実施例のノード１０と同様に、受信対象スロット及び前・後スロットに関する受信ステータス情報が取得されると、図９のステップＳ２０１〜ステップＳ２１８の処理により、受信対象スロットに関する境界違反のエラー要因が判別され、エラータイプに応じて、受信フレームのデータを自ノードのアプリケーションで使用するかどうかが決定される。なお、図９のステップＳ２０１〜ステップＳ２１８の処理は、上述した図７のステップＳ１０１〜ステップＳ１１８の処理と同じであるので、詳細な説明は省略する。

その後、本実施例のノード２０では、ホストＣＰＵ１１が、ステップＳ２１９においてエラータイプを再度確認する。そして、エラータイプが受信フレーム境界越え（タイプＢ）、前フレーム境界越え（タイプＣ）、後フレーム境界越え（タイプＥ）のいずれかであれば、ステップＳ２２０において、境界越えが生じているフレームの送信元ノードに同期ずれが発生しているものと判断し、当該ノードに対して、同期ずれ通知フレームを送信する。

以上、具体的な例を挙げながら詳細に説明したように、本実施形態の通信ネットワークシステムでは、ネットワーク上の各ノードが、受信対象スロットのフレームだけでなく、その前後に隣接するスロットのフレームも受信して、受信対象スロットとその前後に隣接する２つの隣接スロットとの３つのスロットに亘って受信ステータス情報を取得するようにしている。そして、これら３つのスロットに関する受信ステータス情報に基づいて受信対象スロットにおけるエラーの有無及びエラー要因を検証するようにしている。したがって、本実施形態の通信ネットワークシステムによれば、ネットワーク上の各ノードが、受信対象スロットにおけるエラーの有無及びエラー要因を的確に判断することができ、例えば、受信対象スロットで境界違反のエラーが検出されても、受信フレーム自体に異常なければ受信フレームのデータを自ノードのアプリケーションで使用し、受信フレーム自体に異常があると判断される場合のみデータを破棄するといったように、エラー要因に応じた最適な対応を図ることが可能となるので、効率的な通信を実現することができる。

また、本実施形態の通信ネットワークシステムによれば、ネットワーク上の各ノードが、受信対象スロットにおける境界違反のエラー要因を検証することで、同期ずれが発生しているフレーム送信元ノードを特定することができるので、この同期ずれが発生しているフレーム送信元ノードに対して、同期ずれが発生している旨を通知することができ、フレーム送信元ノードに適切な対応を促すことで、より効率的な通信を実現することができる。

なお、以上説明した通信ネットワークシステムは本発明の一適用例を例示したものであり、本発明の技術的範囲は、以上の説明で開示した内容に限定されるものではなく、これらの開示から容易に導き得る様々な代替技術も含まれることは勿論である。

ＦｌｅｘＲａｙプロトコルにおけるデータ転送の仕組みを説明する図である。 ＦｌｅｘＲａｙプロトコルにおけるフレーム・フォーマットを示す図である。 スロット境界との間に余裕を持たせた状態でスロット内でフレームを送信する様子を示す図である。 フレームを受信した際に得られる受信ステータス情報の内容を説明する図である。 受信対象スロットに関する境界違反情報が「違反あり」となる要因を説明する図であり、（ａ）は受信フレームが前にずれて前側のスロット境界を跨いだ状態を示し、（ｂ）は受信フレームが後ろにずれて後ろ側のスロット境界を跨いだ状態を示し、（ｃ）は前フレームが後ろにずれて前側のスロット境界を跨いだ状態を示し、（ｄ）は後フレームが前にずれて後ろ側のスロット境界を跨いだ状態を示し、（ｅ）は前側のスロット境界で瞬間的なノイズが発生した状態を示し、（ｆ）は後ろ側のスロット境界で瞬間的なノイズが発生した状態を示している。 第１実施例のノードの構成を示す図である。 第１実施例のノードにおいて、ホストＣＰＵにより実行される一連の処理の流れを示すフローチャートである。 第２実施例のノードの構成を示す図である。 第２実施例のノードにおいて、ホストＣＰＵにより実行される一連の処理の流れを示すフローチャートである。

符号の説明

１０，２０ ノード
１１ ホストＣＰＵ
１２ 通信コントローラ
１３ バスドライバ
１４ 境界違反検証機能
１５ エラー発生箇所特定機能
１６ エラー判別機能
１７ フレーム使用可否判定機能
１８ 同期ずれノード判定機能
１９ 同期ずれ通知機能
１００ 通信バス

Claims (6)

1. ネットワーク上の各ノードが、各通信周期の中で時分割されたフレーム送信期間であるスロットを認識し、自ノードが受信すべきフレームの送信用に割り当てられた受信対象スロット内でフレームを受信するとともに、スロット内でのフレーム受信状態を表す受信ステータス情報を取得する時分割多重通信型の通信ネットワークシステムにおいて、
   前記ネットワーク上の各ノードが、
   前記受信対象スロットとその前後に隣接する２つの隣接スロットとの３つのスロットに亘って前記受信ステータス情報をそれぞれ取得する受信ステータス情報取得手段と、
   前記受信ステータス情報取得手段で取得された３つのスロットに関する受信ステータス情報に基づいて、前記受信対象スロットにおけるエラーの有無及びエラー要因を検証するエラー検証手段とを備えることを特徴とする通信ネットワークシステム。
2. 前記受信ステータス情報には、スロットの境界で信号成分が検出された場合に発生する境界違反の有無を表す境界違反情報と、スロット内のフレームの正常性を表すフレーム状態情報とが含まれ、
   前記エラー検証手段は、前記受信対象スロットに関する前記境界違反情報が境界違反の発生を示すものである場合に、２つの隣接スロットに関する前記境界違反情報の内容に基づいて境界違反が発生しているスロット境界を特定するとともに、前記受信対象スロットに関する前記フレーム状態情報と、境界違反が発生しているスロットを挟んで前記受信対象スロットと隣接する一方の隣接スロットに関する前記フレーム状態情報とに基づいて、境界違反の発生要因を特定することを特徴とする請求項１に記載の通信ネットワークシステム。
3. 前記フレーム状態情報は、有効フレームを受信したか否かを表す情報、文法的に正しいフレームを受信したか否かを表す情報、内容的に正しいフレームを受信したか否かを表す情報の少なくとも何れかであることを特徴とする請求項２に記載の通信ネットワークシステム。
4. 前記ネットワーク上の各ノードが、
   前記エラー検証手段による検証結果に基づいて、前記受信対象スロット内で受信したフレームのデータを使用できるか否かを判定するフレーム使用可否判定手段を更に備えることを特徴とする請求項１に記載の通信ネットワークシステム。
5. 前記ネットワーク上の各ノードが、
   前記エラー検証手段による検証結果に基づいて、フレーム送信元のノードで同期ずれが発生しているノードが存在するか否かを判定する同期ずれノード判定手段と、
   前記同期ずれノード判定手段により同期ずれが発生しているノードが存在すると判定された場合に、当該ノードに同期ずれが発生していることを通知する同期ずれ通知手段とを更に備えることを特徴とする請求項１に記載の通信ネットワークシステム。
6. ネットワーク上の各ノードが、各通信周期の中で時分割されたフレーム送信期間であるスロットを認識し、自ノードが受信すべきフレームの送信用に割り当てられた受信対象スロット内でフレームを受信するとともに、スロット内でのフレーム受信状態を表す受信ステータス情報を取得する時分割多重通信型の通信ネットワークシステムにおけるエラー検証方法であって、
   ネットワーク上の各ノードが、前記受信対象スロットとその前後に隣接する２つの隣接スロットとの３つのスロットに亘って前記受信ステータス情報をそれぞれ取得し、これら３つのスロットに関する受信ステータス情報に基づいて、前記受信対象スロットにおけるエラーの有無及びエラー要因を検証することを特徴とするエラー検証方法。

Images