性能監視を使用するマルチパスネットワーク常用冗長性
送信ネットワークノード(230)からの初期送信の時間が異なる受信パケットから選択するように構成され、初期送信時間に基づいて、選択されたパケットをアプリケーション層(740)に送信することを許容する受信ネットワークノード(210)。(a)受信パケットメッセージのシーケンス番号及び送信元識別子を読み取り(810)、(b)送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を、受信したパケットシーケンス番号と比較し(820)、(c)受信したパケットシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、受信パケットを破棄し(840)、(d)受信したパケットシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位プロトコルに基づいて、受信パケットのメッセージをアプリケーションに送る(860)ように構成された相互接続ネットワークのプロセッサノード。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、2009年9月23日に出願された米国仮特許出願第61/245,170号の利益を主張すると共に、2010年3月31日に出願された米国仮特許出願第61/319,363号の利益を主張するものであり、これら出願の開示は参照により本明細書に援用される。
【0002】
実施形態は、冗長メッセージ処理に関し、より詳細には、同じ送信元ノードから始まり、異なるIPアドレスを有する冗長メッセージのメッセージ層処理に関する。
【背景技術】
【0003】
図1は、開放型システム相互接続(OSI)モデルの表形式のリストである。OSIモデルは、ビット、フレーム、及びパケットのデータ単位を有する媒体層並びにデータ及びデータセグメントを有するホスト層として表し得る。層は、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層としてさらに細分化し得る。ユーザデータグラムプロトコル(UDP)は、限られたサービスを提供する通信プロトコル、すなわち、インターネットプロトコル(IP)を使用するネットワーク内のコンピュータ間でメッセージを交換するための軽量プロトコルである。UDPは、IPを使用してデータ単位、すなわち、データグラムをあるコンピュータ/ノードから別のコンピュータ/ノードに運ぶ。特に、UDPは、パケットの到着の順序付けを提供しない。
【発明の概要】
【0004】
実施形態は、プロセッサと、アドレス指定可能なメモリとを含む相互接続ネットワーク内のノードを含み得、プロセッサは、(a)メッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取り、(b)送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を、受信パケットのシーケンス番号と比較し、(c)受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、受信パケットを破棄し、(d)受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位層プロトコルに基づいて受信パケットのメッセージをアプリケーションに送るように構成される。ノードは、任意選択的に、2つ以上のパスから同じ送信元識別子を有するパケットを受信するように構成し得る。送信元は、準リアルタイムコントローラを備えることができ、ノードは、ゲートウェイと、(1)受信フレームのペイロード情報に応答するエフェクタ、(2)無線周波数送信器、(3)無線周波数受信器、及び(4)センサのうちの少なくとも1つとを備え得る。
【0005】
例えば、実施形態は、冗長メッセージ処理の方法であって、(a)送信元ノードのプロセッサが、(i)フレームシーケンス番号を第1のパケットのフレームに割り当て、(ii)送信元識別番号を第1のパケットのフレームに割り当て、(iii)フレームシーケンス番号を第2のパケットのフレームに割り当て、(iv)送信元識別番号を第2のパケットのフレームに割り当てるステップと、(b)宛先ノードのプロセッサが、第1のパケット及び第2のパケットを含む組のうちの第1の受信パケットのフレームシーケンス番号及び送信元番号を記録するステップと、(c)宛先ノードのプロセッサが、記録されたフレームシーケンス番号及び記録された送信元番号を有する第2の受信パケットを破棄するステップとを含む、方法でもあり得る。方法のいくつかの実施形態は、破棄するステップの前に、宛先ノードのプロセッサが、第2の受信パケットのフレームシーケンス番号と第1の受信パケットの記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、第1の受信パケットの記録された送信元番号を有する第2の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含み得る。方法のいくつかの実施形態は、送信元ノードが、第1のネットワークインタフェース回路を介して第1のパケットを送信すると共に、第2のネットワークインタフェース回路を介して第2のパケットを送信することをさらに含み得る。
【0006】
方法の実施形態は、ネットワークノード健康評価の方法であって、(a)健康要求をネットワークの複数のネットワークノードにマルチキャストするステップと、(b)複数のネットワークノードのうちの少なくとも1つから健康要求応答メッセージを受信するステップであって、受信する健康要求応答メッセージは、応答ノードのイーサネットMACアドレスを含むステップと、(c)タイムスタンプを受信した健康要求応答メッセージに関連付けるステップと、(d)応答ノードの受信したイーサネットMACアドレス及び関連付けられたタイムスタンプを記憶するステップと、(e)2つ以上のネットワークインタフェース回路(NIC)のイーサネットドライバに、1つ又は複数のノードへの同一の出力メッセージを、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスに基づいて提供するステップとを含む、方法も含む。例示的な方法の実施形態は、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワークの変更を評価することも含み得る。例示的な方法の実施形態は、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワークの健康を評価することも含み得る。例示的な方法の実施形態は、2つ以上のNICパスを介して送信されたパケットを、2つ以上のNICパスを介して受信されたパケットと比較するステップと、2つ以上のNICパスのそれぞれの損失パケットの数量を特定するステップとをも含み得る。
【0007】
実施形態は、添付図面の図に限定ではなく例として示される。
【図面の簡単な説明】
【0008】
【図1】図1は、開放型システム相互接続モデルの表形式のリストである。
【図2】図2は、例示的な最上位システム図である。
【図3】図3は、実施形態の例示的な層を示す。
【図4】図4は、最上位関係インタフェースチャートを示す。
【図5】図5は、関係インタフェースチャートを示す。
【図6】図6は、例示的なフレームヘッダ内容構成及びメッセージ内容構成を示す。
【図7】図7は、例示的なシーケンスフィルタリング及びping要求処理を示す最上位フローチャートである。
【図8】図8は、例示的なシーケンスフィルタリング実施形態を示すフローチャートである。
【図9】図9は、健康評価のためのデータを収集する例示的なイーサネットに基づく通信フローを示す機能ブロック図である。
【図10】図10は、GoComMux流れ図として例示的なアルゴリズム構造を示す。
【発明を実施するための形態】
【0009】
例示的な実施形態を示す図を参照する。図2は、例示的な最上位システム図200である。プロセッサは、本明細書では、中央演算処理装置(CPU)と、アドレス指定可能なメモリとを有するコンピュータ又は計算装置として定義され、計算装置は、実行可能な機械可読命令、回路、又はこれら両方の組み合わせにより構成されて、特別な計算装置として機能し得る。ネットワークは、プロセッサを備えた送信元ノードと、プロセッサを備えた宛先ノードと、ノード間に配置されるネットワークリンクとを備え得る。送信元ノードは、宛先ノードへのコマンド等のメッセージを生成し得る。例示的なメッセージは、複数のネットワークインタフェースカードにより準備し送信し得る。図2の例示的な図では、送信元ノード210は、ネットワークインタフェースカード(NIC)であり得る2つのネットワークインタフェース装置215、220又はコンピュータ回路基板を介してネットワークとインタフェースする。次に、各NICは、ルーティングスイッチ231〜234、例えば、ポートルーティングを指示するテーブルを有するスイッチに接続し得る。図2の例示的なネットワークでは、第1のNICは、第1のスイッチ(SW_1)231に送信し得、第1のスイッチは第2のスイッチ(SW_2)232に送信し得る。図2の例示的なネットワークでは、第2のNIC220も、第1のNIC215と同じメッセージを第4のスイッチ(SW_4)234に送信し得、第4のスイッチ234は第3のスイッチ(SW_3)233に送信し得る。第2のスイッチ232及び第3のスイッチ233は、パケット/データグラムを宛先ノード230に送信し得る。したがって、宛先ノード230は、1つの送信元ノード210から、例えば、2つ以上のチャネルを介して冗長メッセージを受信し得る。
【0010】
図3は、物理層310からUDP/IP320、ショートメッセージプロトコル330、そしてアプリケーション層340までの実施形態の例示的な層300を示す。図3には、大きなデータストリーム350、ソケットラッパー360、及びネットワーク制御スタック370も示される。図4は、ソケット層420とアプリケーション層430との間に配置されたメッセージ処理層410を示す最上位関係インタフェースチャート400である。この例のソケット層420は、ソケットの開閉を管理し、UDPパケットの送受信を処理し、UDPデータグラムのユニキャスト及びマルチキャストの両方をサポートする。この例のメッセージ処理層410は、pingメッセージに応答し、埋め込まれたシーケンスを使用してメッセージをフィルタリングし、リアルタイムオペレーティングシステム(RTOS)ノードと動作可能な場合、新しいメッセージがあるときにアプリケーション層430を呼び出し得る。図5は、例示的なアプリケーションインタフェース510を示す関係インタフェースチャート500である。この図は、アプリケーション層とのメッセージのやりとりの例示的な流れを示す。
【0011】
図6は、例示的なフレームヘッダ内容構成及びメッセージ内容構成600を示す。フレームヘッダ610は、シーケンス番号615及び送信元識別情報(ID)625を有して示される。アプリケーションレベルでの連続性を達成するために、シーケンス番号615を送信元ID625と併せて参照し得る。シーケンス番号615は、特定の送信元により送信される16ビットの整数カウントであり得る。各送信元ノードは、2つ以上のNICを有し得、各NICは異なるIPアドレスを有する。送信元ID625は、フレームの送信元であるノードを一意に識別する8ビットの整数であり得る。ノードIDヘッダファイルを使用して、ノード番号のリストを捕捉し得る。
【0012】
図7は、シーケンスフィルタリング710及びping要求処理720の例示的なプロセスを示す最上位フローチャート700である。2つ以上の送信元がフレーム内にメッセージを提供し得、メッセージは同一であり、シーケンス番号は同一である。メッセージ処理層730は、最も新しく受信したシーケンス番号を記憶し、その番号を受信フレームのシーケンス番号と比較し得る。ネットワークコントローラノードが、埋め込まれたシーケンス番号を使用してメッセージをフィルタリングし、新しいメッセージがある場合にアプリケーション層740を呼び出し、pingメッセージをすべてのノードに送信することにより、ネットワーク接続及び/又は健康を特定し、各応答を処理し得る。ネットワークコントローラノードは、周期的なpingメッセージからの応答の有無に基づいてネットワーク接続マップ750又は関係テーブルを構築し、接続情報を取得するためのアプリケーション層740のコールバックを提供し得る。
【0013】
図8は、本発明の例示的なシーケンスフィルタリング実施形態を示すフローチャート800である。例示的な受信実施形態は、パケットを受信して読み出すと(ステップ810)、新たに受信したパケットのシーケンス番号を、同じ送信元IDを有する最も新しい以前に受信したパケットと比較し得る820。新たに受信したパケットのシーケンス番号が、既に記録された番号以下である場合(ステップ830)、新たに受信したパケットを破棄し得る(ステップ840)。いくつかの実施形態では、受信ノードのメッセージ処理層は、既に記録された番号のシーケンス番号と新たに受信したパケットのシーケンス番号との差の大きさを比較し得る。次に、受信側は、新しいシーケンス番号にリセットされ、シーケンスロールオーバーイベントを記録し、それに従って新たに受信したパケットを処理のために保持し得る(ステップ860)。
【0014】
例示的な実施形態は、航空機の飛行ネットワーク内の2つ以上の飛行制御コンピュータ(FCC)を有する航空機のシステム内であり得る。各FCCは2つのネットワークインタフェース回路又はネットワークインタフェースカード(NIC)を有し、ネットワークインタフェース回路又はネットワークインタフェースカード(NIC)は、それに従って、2つのアクセスポイントを航空機の飛行ネットワークに提供する。上述したように、上述したネットワークの例示的なアーキテクチャは、各NICが、ネットワークセグメントを介して重複しない接続を各サブシステムに提供し得るようなものである。すなわち、特定のFCCの第1のNICから任意の特定のサブシステムへのパスは、特定のFCCの第2のNICからそのサブシステムへのパスと共通する物理層ネットワーク接続を有さない。例示的な耐故障性ネットワークの実施形態は、部分的に、FCCが各NICからの冗長メッセージを生成するように構成されることに基づく。FCCで使用し得るネットワークスタックは、特定のNICへの直接のユニキャストトラフィックの方向付けをサポートしない場合がある。この実施形態でのスタックは、任意の特定のサブネットに1つの接続があり、したがって、トラフィックを自動的に適切なNICにルーティングするという仮定に従って動作する。特に、スタックにより保持されるアドレス解決プロトコル(ARP)テーブルは、同じサブネット上に2つのNICを予想せず、したがって、サブシステムへの冗長ユニキャストの送信からネットワークスタックを除外し得る。代替の一実施形態は、ネットワークスタックにより、特定のNICへのマルチキャストの方向付けが期待するように動作していると判断する場合、ユニキャストを使用しなくてもよい。
【0015】
例示的な実施形態は、例えば、通常のVxWokrsスタックと組み合わせて動作するVxWorks muxLibインタフェースを使用することにより、二重冗長イーサネットパケットを2つのNICに直接送信することを含む。二重冗長イーサネットパケットを2つのNICに直接送信することにより、一般に、ユニキャストを2つの接続があるサブネットに送信しようとする場合に直面するユニキャストルーティング及びARPテーブル参照呼び掛けが回避される。
【0016】
IPデータグラムがマルチホームホストから送信される場合、IPデータグラムを、宛先への最も明白なルートを有するインタフェースに渡し得る。したがって、データグラムは、マルチホームホスト内の1つのインタフェースの送信元IPアドレスを含むが、それでもやはり異なるインタフェースにより媒体上に配置し得る。フレーム上の送信元媒体アクセス制御アドレスは、フレームを媒体に実際に送信したインタフェースのものであり、送信元IPアドレスは、送信元の送信側アプリケーションのものであり、必ずしも、ネットワーク接続UI内の送信側インタフェースに関連付けられたIPアドレスのうちの1つであるわけではない。アドレスがインタフェースではなくホストを参照するいわゆる「弱エンドモデル(weak end model)」のシステムは、Microsoft(登録商標)Windows(登録商標)を含むいくつかのオペレーティングシステム内に含まれる。この「弱エンドモデル」は、パケットがマルチホームシステム上のインタフェースのうちの1つに到着した場合、宛先アドレスがアドレスのうちの1つのアドレスに一致する限り、ネットワークスタックにより捕捉されることを意味する。他方、いわゆる「強エンドモデル(strong end model)」システムでは、パケットの宛先アドレスが、パケットが到着する基礎となるインタフェースアドレスに一致することが必要とされる。パケットの送信と同様に、弱エンドシステムは、パケットの送信元IPアドレスに一致しないインタフェースからパケットを送信し、その一方で、強エンドシステムは、パケットの送信元IPアドレスに一致しないインタフェースからパケットを送信しない。
【0017】
一般に、例示的なシステムアーキテクチャに関して、図9を参照し、図9では、FCCアプリケーション900が、カーネル空間910とリアルタイムプロセス(RTP)970とに分割される。カーネル910はドライバインタフェースを処理し、RTP970は、航空機実施形態でのメッセージング及び飛行制御機能を処理する。標準のIP UDP イーサネットフレームのペイロードの一部として、「goCom」層911と呼ばれる層を含めて、以下の容易化を行い得る:(a)goFrameヘッダ内のシーケンス番号の重複に基づく冗長受信メッセージの破棄及び(b)複製メッセージの統計生成。収集されたデータを参照し、使用して、任意及びすべての冗長パスの健康を監視し得る。例示的な実施形態では、VxWorksは、muxLibインタフェース912を提供して、ネットワークインタフェース上で受信されるイーサネットパケットへのアクセスを提供する。muxLibは、特定のネットワークインタフェースからイーサネットメッセージを送出するためにも使用される。
【0018】
パケットを受信した場合、アプリケーションにインストールされているコールバックを、受信割り込みの状況で実行し得る。受信パケットを含むバッファへのポインタが、muxインタフェースにより提供される。パケットは、一連のフィルタにより検査して、有効な「goCom」フレームであることを確立し得る。メッセージが、ネットワーク、例えば、センサノード、エフェクタノード、及び/又は送受信器ノードの航空機ネットワーク上のサブシステムからのものである場合、サブシステムのイーサネットアドレスを、サブシステムIPアドレスにより索引付けられたテーブル913に記憶し得る。したがって、索引付けられたサブシステムイーサネットアドレスのテーブルを参照して、ユニキャストメッセージを、記憶されたアドレスに対応するサブシステムに返信し得る。例示的なテーブルは、部分的に、ARPが航空機二重ネットワークパス実施形態において一貫して機能しない場合があるため、ARPの代わりに動作し得る−単独実施形態メカニズム。したがって、FCCがFCCにまだメッセージを送信していない任意のサブシステムにメッセージを送信できないことに留意する−FCCがサブシステムのイーサネットMACアドレスにアクセス又は学習し得るのは、索引付きテーブルによってであるため。テーブルに先を見越して入力するために、例示的な実施形態は、ネットワーク上のすべてのノードに、マルチキャストされた「健康要求」に応答するように要求する。この健康要求は、システムの典型的又は通常の機能から選択し得る。すなわち、利用可能な健康要求への調整又は変更は、必ずしも、二重ユニキャスト耐故障ネットワーク設計のサポートに必要であるわけではない。したがって、サブシステムが、健康応答メッセージで健康要求に応答する場合、FCCは即座に、ネットワーク上のあらゆるノードのイーサネットMACアドレスを学習する。パケットがサブシステムからいつ受信されたかのタイムスタンプもテーブルに記憶される。これにより、パス毎の最近の接続に基づいてネットワークの健康を評価することができる。いくつのパケットがいずれかのパスで失われたかについての統計も収集される。そのような統計の収集により、信号パケット損失であっても高感度の検出が可能である。高レベル感度の検出は、ネットワーク問題を早期に検出して切り離す潜在性を提供する。
【0019】
RTPからカーネルへのメッセージチャネルインタフェースを使用して、両方のNICから冗長的に送信すべきユニキャストメッセージを通信し得る。例示的な実施形態は、システムが生成すると予期される、サポートされる最大のイーサネットパケット又は媒体転送単位(MTU)を含むのに十分な大きさの固定サイズのバッファを有するメッセージチャネルを有する。例示的な実施形態は、1536バイトサイズのMTUを有し得る。メッセージチャネル920インタフェースは柔軟であるように構成し得、広範囲のユニキャストをネットワークの任意のサブシステムに送信することができる。メッセージバッファの冒頭にあるメタデータを参照して、メッセージの送信が意図されるIPアドレス及びポートを識別し得る。
【0020】
カーネル910は、特定のサブシステムに送信すべきメッセージをRTP970から受信すると、まず、サブシステムの有効なイーサネットアドレスがイーサネットテーブル913に記憶されているか否かをチェックして判断し得る。記憶されていない場合、メッセージを静かに破棄し得る。すなわち、ネットワークの他の要素及びFCCアプリケーションRTPに通知せずにメッセージを破棄し得る。イーサネットアドレスがサブシステムに提供される場合、2つのパケットが、メッセージ920に基づいて形成される930。2つのメッセージは、送信元であるNIC以外は同一である。特に、同じシーケンス番号が両方のパケットに使用される。次に、パケットは2つのNIC、特に、各NICのイーサネットドライバ951、952に送信され、muxLibインタフェース912を介して送信される。
【0021】
VxWorksカーネルとして実施されるカーネル910には、共有データライブラリサポート、例えば、sdLibサポートを構築して、統計をパケット受信ハンドラから、ネットワーク統計を使用してgoComメッセージを生成するRTP符号に渡す効率的なメカニズムを提供し得る。カーネルの実施形態は、ネットワークスタックが使用する標準インタフェースとしてmuxLibを有する。
【0022】
不揮発性記憶装置、例えば、フラッシュメモリ又はNVRAMを使用して、受信したイーサネットパケットにタイムスタンプを付与するために使用される飛行時間、すなわち、経過時間を記憶し得る。比較的高速であるが、NVRAMアクセスはRAMアクセスよりも遅く、あらゆる受信パケットにタイムスタンプが付与されるため、読み出し性能が考慮事項である。NVRAMは、32ビットアクセス装置であり得るRAMとは対照的に、8ビットアクセス装置であり得る。8ビットアクセスは、秒カウンタの長たらしい4バイトにわたってデータの一貫性判断を行うが、32ビットアクセスは本質的に原子的である。したがって、飛行秒カウンタがRAM並びにNVRAMに記憶され、1秒の割り込み処理の一環として両位置で更新することができる。
【0023】
VxWorks標準RAMマップ等の標準RAMマップを使用し得、ブートローダは、アプリケーションを低いメモリにロードする間、高いメモリを使用する。起動時、アプリケーションは、SYSMEMTOPで始まる高いメモリを使用して、スタックを構築する。スタックはビルドダウンされる。OS又はコンパイラにより管理されないあらゆる固定メモリ割り振りも、SYSTEMTOPよりも上に配置し得る。カーネルアプリケーションは、sdLibを使用して、カーネルにより管理される名前付きの共有データ領域を作成する。次に、名前付き領域は、RTPアプリケーションにより開かれ、イーサネットパケット統計性を読み出し得る。
【0024】
VxWorks用のCurtis WrightのBSPを使用して、イーサネットドライバを提供し得る。したがって、muxLib イーサネットドライバインタフェースは、MUX_PROTO_SNARFモードで動作するように構成し得る。この構成では、すべての受信パケットを無差別に検査することができる。次に、パケットは、任意選択的に、muxLibに戻されて、通常処理のために標準のネットワークスタックに送信される。
【0025】
例示的なアルゴリズム構造が、図10のGoComMux流れ図に示される。アプリケーション層は、goComMuxモジュール1010の手続きを初期化又は生成し得る。モジュールが初期化されると1020、goComMuxモジュールは、第1のNICをバインドする1030と共に、第2のNICをバインドし得1040、それにより、送信元であるNICの特定が可能になる。メッセージ送信を初期化する手続き1050を実行し得、カーネルは、ドライバインタフェースを処理し、RTPメッセージ、例えば、パケット/データグラムをカーネル送信チャネルに読み出し得る1060。GoComMuxモジュールは、フレーム1070をFCCアプリケーションRTP970に送信可能であり得る。GoComMuxモジュールは、第1のNIC1080及び第2のNIC1085の割り込みを受け入れ、MuxLibからのパケットを受信する手続き1090を呼び出し得る。
【0026】
上記実施形態の特定の特徴及び態様の様々な組み合わせ及び/又は下位組み合わせを行うことが可能であり、それでも本発明の範囲内にあることが意図される。したがって、開示される実施形態の様々な特徴及び態様を互いに結合又は置換して、開示される本発明の変形モードを形成し得ることを理解されたい。さらに、本明細書において例として開示される本発明の範囲を、開示される上述した特定の実施形態によって限定されるべきではないことが意図される。
【技術分野】
【0001】
関連出願の相互参照
本願は、2009年9月23日に出願された米国仮特許出願第61/245,170号の利益を主張すると共に、2010年3月31日に出願された米国仮特許出願第61/319,363号の利益を主張するものであり、これら出願の開示は参照により本明細書に援用される。
【0002】
実施形態は、冗長メッセージ処理に関し、より詳細には、同じ送信元ノードから始まり、異なるIPアドレスを有する冗長メッセージのメッセージ層処理に関する。
【背景技術】
【0003】
図1は、開放型システム相互接続(OSI)モデルの表形式のリストである。OSIモデルは、ビット、フレーム、及びパケットのデータ単位を有する媒体層並びにデータ及びデータセグメントを有するホスト層として表し得る。層は、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、及びアプリケーション層としてさらに細分化し得る。ユーザデータグラムプロトコル(UDP)は、限られたサービスを提供する通信プロトコル、すなわち、インターネットプロトコル(IP)を使用するネットワーク内のコンピュータ間でメッセージを交換するための軽量プロトコルである。UDPは、IPを使用してデータ単位、すなわち、データグラムをあるコンピュータ/ノードから別のコンピュータ/ノードに運ぶ。特に、UDPは、パケットの到着の順序付けを提供しない。
【発明の概要】
【0004】
実施形態は、プロセッサと、アドレス指定可能なメモリとを含む相互接続ネットワーク内のノードを含み得、プロセッサは、(a)メッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取り、(b)送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を、受信パケットのシーケンス番号と比較し、(c)受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、受信パケットを破棄し、(d)受信パケットのシーケンス番号が、送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位層プロトコルに基づいて受信パケットのメッセージをアプリケーションに送るように構成される。ノードは、任意選択的に、2つ以上のパスから同じ送信元識別子を有するパケットを受信するように構成し得る。送信元は、準リアルタイムコントローラを備えることができ、ノードは、ゲートウェイと、(1)受信フレームのペイロード情報に応答するエフェクタ、(2)無線周波数送信器、(3)無線周波数受信器、及び(4)センサのうちの少なくとも1つとを備え得る。
【0005】
例えば、実施形態は、冗長メッセージ処理の方法であって、(a)送信元ノードのプロセッサが、(i)フレームシーケンス番号を第1のパケットのフレームに割り当て、(ii)送信元識別番号を第1のパケットのフレームに割り当て、(iii)フレームシーケンス番号を第2のパケットのフレームに割り当て、(iv)送信元識別番号を第2のパケットのフレームに割り当てるステップと、(b)宛先ノードのプロセッサが、第1のパケット及び第2のパケットを含む組のうちの第1の受信パケットのフレームシーケンス番号及び送信元番号を記録するステップと、(c)宛先ノードのプロセッサが、記録されたフレームシーケンス番号及び記録された送信元番号を有する第2の受信パケットを破棄するステップとを含む、方法でもあり得る。方法のいくつかの実施形態は、破棄するステップの前に、宛先ノードのプロセッサが、第2の受信パケットのフレームシーケンス番号と第1の受信パケットの記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、第1の受信パケットの記録された送信元番号を有する第2の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含み得る。方法のいくつかの実施形態は、送信元ノードが、第1のネットワークインタフェース回路を介して第1のパケットを送信すると共に、第2のネットワークインタフェース回路を介して第2のパケットを送信することをさらに含み得る。
【0006】
方法の実施形態は、ネットワークノード健康評価の方法であって、(a)健康要求をネットワークの複数のネットワークノードにマルチキャストするステップと、(b)複数のネットワークノードのうちの少なくとも1つから健康要求応答メッセージを受信するステップであって、受信する健康要求応答メッセージは、応答ノードのイーサネットMACアドレスを含むステップと、(c)タイムスタンプを受信した健康要求応答メッセージに関連付けるステップと、(d)応答ノードの受信したイーサネットMACアドレス及び関連付けられたタイムスタンプを記憶するステップと、(e)2つ以上のネットワークインタフェース回路(NIC)のイーサネットドライバに、1つ又は複数のノードへの同一の出力メッセージを、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスに基づいて提供するステップとを含む、方法も含む。例示的な方法の実施形態は、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワークの変更を評価することも含み得る。例示的な方法の実施形態は、1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワークの健康を評価することも含み得る。例示的な方法の実施形態は、2つ以上のNICパスを介して送信されたパケットを、2つ以上のNICパスを介して受信されたパケットと比較するステップと、2つ以上のNICパスのそれぞれの損失パケットの数量を特定するステップとをも含み得る。
【0007】
実施形態は、添付図面の図に限定ではなく例として示される。
【図面の簡単な説明】
【0008】
【図1】図1は、開放型システム相互接続モデルの表形式のリストである。
【図2】図2は、例示的な最上位システム図である。
【図3】図3は、実施形態の例示的な層を示す。
【図4】図4は、最上位関係インタフェースチャートを示す。
【図5】図5は、関係インタフェースチャートを示す。
【図6】図6は、例示的なフレームヘッダ内容構成及びメッセージ内容構成を示す。
【図7】図7は、例示的なシーケンスフィルタリング及びping要求処理を示す最上位フローチャートである。
【図8】図8は、例示的なシーケンスフィルタリング実施形態を示すフローチャートである。
【図9】図9は、健康評価のためのデータを収集する例示的なイーサネットに基づく通信フローを示す機能ブロック図である。
【図10】図10は、GoComMux流れ図として例示的なアルゴリズム構造を示す。
【発明を実施するための形態】
【0009】
例示的な実施形態を示す図を参照する。図2は、例示的な最上位システム図200である。プロセッサは、本明細書では、中央演算処理装置(CPU)と、アドレス指定可能なメモリとを有するコンピュータ又は計算装置として定義され、計算装置は、実行可能な機械可読命令、回路、又はこれら両方の組み合わせにより構成されて、特別な計算装置として機能し得る。ネットワークは、プロセッサを備えた送信元ノードと、プロセッサを備えた宛先ノードと、ノード間に配置されるネットワークリンクとを備え得る。送信元ノードは、宛先ノードへのコマンド等のメッセージを生成し得る。例示的なメッセージは、複数のネットワークインタフェースカードにより準備し送信し得る。図2の例示的な図では、送信元ノード210は、ネットワークインタフェースカード(NIC)であり得る2つのネットワークインタフェース装置215、220又はコンピュータ回路基板を介してネットワークとインタフェースする。次に、各NICは、ルーティングスイッチ231〜234、例えば、ポートルーティングを指示するテーブルを有するスイッチに接続し得る。図2の例示的なネットワークでは、第1のNICは、第1のスイッチ(SW_1)231に送信し得、第1のスイッチは第2のスイッチ(SW_2)232に送信し得る。図2の例示的なネットワークでは、第2のNIC220も、第1のNIC215と同じメッセージを第4のスイッチ(SW_4)234に送信し得、第4のスイッチ234は第3のスイッチ(SW_3)233に送信し得る。第2のスイッチ232及び第3のスイッチ233は、パケット/データグラムを宛先ノード230に送信し得る。したがって、宛先ノード230は、1つの送信元ノード210から、例えば、2つ以上のチャネルを介して冗長メッセージを受信し得る。
【0010】
図3は、物理層310からUDP/IP320、ショートメッセージプロトコル330、そしてアプリケーション層340までの実施形態の例示的な層300を示す。図3には、大きなデータストリーム350、ソケットラッパー360、及びネットワーク制御スタック370も示される。図4は、ソケット層420とアプリケーション層430との間に配置されたメッセージ処理層410を示す最上位関係インタフェースチャート400である。この例のソケット層420は、ソケットの開閉を管理し、UDPパケットの送受信を処理し、UDPデータグラムのユニキャスト及びマルチキャストの両方をサポートする。この例のメッセージ処理層410は、pingメッセージに応答し、埋め込まれたシーケンスを使用してメッセージをフィルタリングし、リアルタイムオペレーティングシステム(RTOS)ノードと動作可能な場合、新しいメッセージがあるときにアプリケーション層430を呼び出し得る。図5は、例示的なアプリケーションインタフェース510を示す関係インタフェースチャート500である。この図は、アプリケーション層とのメッセージのやりとりの例示的な流れを示す。
【0011】
図6は、例示的なフレームヘッダ内容構成及びメッセージ内容構成600を示す。フレームヘッダ610は、シーケンス番号615及び送信元識別情報(ID)625を有して示される。アプリケーションレベルでの連続性を達成するために、シーケンス番号615を送信元ID625と併せて参照し得る。シーケンス番号615は、特定の送信元により送信される16ビットの整数カウントであり得る。各送信元ノードは、2つ以上のNICを有し得、各NICは異なるIPアドレスを有する。送信元ID625は、フレームの送信元であるノードを一意に識別する8ビットの整数であり得る。ノードIDヘッダファイルを使用して、ノード番号のリストを捕捉し得る。
【0012】
図7は、シーケンスフィルタリング710及びping要求処理720の例示的なプロセスを示す最上位フローチャート700である。2つ以上の送信元がフレーム内にメッセージを提供し得、メッセージは同一であり、シーケンス番号は同一である。メッセージ処理層730は、最も新しく受信したシーケンス番号を記憶し、その番号を受信フレームのシーケンス番号と比較し得る。ネットワークコントローラノードが、埋め込まれたシーケンス番号を使用してメッセージをフィルタリングし、新しいメッセージがある場合にアプリケーション層740を呼び出し、pingメッセージをすべてのノードに送信することにより、ネットワーク接続及び/又は健康を特定し、各応答を処理し得る。ネットワークコントローラノードは、周期的なpingメッセージからの応答の有無に基づいてネットワーク接続マップ750又は関係テーブルを構築し、接続情報を取得するためのアプリケーション層740のコールバックを提供し得る。
【0013】
図8は、本発明の例示的なシーケンスフィルタリング実施形態を示すフローチャート800である。例示的な受信実施形態は、パケットを受信して読み出すと(ステップ810)、新たに受信したパケットのシーケンス番号を、同じ送信元IDを有する最も新しい以前に受信したパケットと比較し得る820。新たに受信したパケットのシーケンス番号が、既に記録された番号以下である場合(ステップ830)、新たに受信したパケットを破棄し得る(ステップ840)。いくつかの実施形態では、受信ノードのメッセージ処理層は、既に記録された番号のシーケンス番号と新たに受信したパケットのシーケンス番号との差の大きさを比較し得る。次に、受信側は、新しいシーケンス番号にリセットされ、シーケンスロールオーバーイベントを記録し、それに従って新たに受信したパケットを処理のために保持し得る(ステップ860)。
【0014】
例示的な実施形態は、航空機の飛行ネットワーク内の2つ以上の飛行制御コンピュータ(FCC)を有する航空機のシステム内であり得る。各FCCは2つのネットワークインタフェース回路又はネットワークインタフェースカード(NIC)を有し、ネットワークインタフェース回路又はネットワークインタフェースカード(NIC)は、それに従って、2つのアクセスポイントを航空機の飛行ネットワークに提供する。上述したように、上述したネットワークの例示的なアーキテクチャは、各NICが、ネットワークセグメントを介して重複しない接続を各サブシステムに提供し得るようなものである。すなわち、特定のFCCの第1のNICから任意の特定のサブシステムへのパスは、特定のFCCの第2のNICからそのサブシステムへのパスと共通する物理層ネットワーク接続を有さない。例示的な耐故障性ネットワークの実施形態は、部分的に、FCCが各NICからの冗長メッセージを生成するように構成されることに基づく。FCCで使用し得るネットワークスタックは、特定のNICへの直接のユニキャストトラフィックの方向付けをサポートしない場合がある。この実施形態でのスタックは、任意の特定のサブネットに1つの接続があり、したがって、トラフィックを自動的に適切なNICにルーティングするという仮定に従って動作する。特に、スタックにより保持されるアドレス解決プロトコル(ARP)テーブルは、同じサブネット上に2つのNICを予想せず、したがって、サブシステムへの冗長ユニキャストの送信からネットワークスタックを除外し得る。代替の一実施形態は、ネットワークスタックにより、特定のNICへのマルチキャストの方向付けが期待するように動作していると判断する場合、ユニキャストを使用しなくてもよい。
【0015】
例示的な実施形態は、例えば、通常のVxWokrsスタックと組み合わせて動作するVxWorks muxLibインタフェースを使用することにより、二重冗長イーサネットパケットを2つのNICに直接送信することを含む。二重冗長イーサネットパケットを2つのNICに直接送信することにより、一般に、ユニキャストを2つの接続があるサブネットに送信しようとする場合に直面するユニキャストルーティング及びARPテーブル参照呼び掛けが回避される。
【0016】
IPデータグラムがマルチホームホストから送信される場合、IPデータグラムを、宛先への最も明白なルートを有するインタフェースに渡し得る。したがって、データグラムは、マルチホームホスト内の1つのインタフェースの送信元IPアドレスを含むが、それでもやはり異なるインタフェースにより媒体上に配置し得る。フレーム上の送信元媒体アクセス制御アドレスは、フレームを媒体に実際に送信したインタフェースのものであり、送信元IPアドレスは、送信元の送信側アプリケーションのものであり、必ずしも、ネットワーク接続UI内の送信側インタフェースに関連付けられたIPアドレスのうちの1つであるわけではない。アドレスがインタフェースではなくホストを参照するいわゆる「弱エンドモデル(weak end model)」のシステムは、Microsoft(登録商標)Windows(登録商標)を含むいくつかのオペレーティングシステム内に含まれる。この「弱エンドモデル」は、パケットがマルチホームシステム上のインタフェースのうちの1つに到着した場合、宛先アドレスがアドレスのうちの1つのアドレスに一致する限り、ネットワークスタックにより捕捉されることを意味する。他方、いわゆる「強エンドモデル(strong end model)」システムでは、パケットの宛先アドレスが、パケットが到着する基礎となるインタフェースアドレスに一致することが必要とされる。パケットの送信と同様に、弱エンドシステムは、パケットの送信元IPアドレスに一致しないインタフェースからパケットを送信し、その一方で、強エンドシステムは、パケットの送信元IPアドレスに一致しないインタフェースからパケットを送信しない。
【0017】
一般に、例示的なシステムアーキテクチャに関して、図9を参照し、図9では、FCCアプリケーション900が、カーネル空間910とリアルタイムプロセス(RTP)970とに分割される。カーネル910はドライバインタフェースを処理し、RTP970は、航空機実施形態でのメッセージング及び飛行制御機能を処理する。標準のIP UDP イーサネットフレームのペイロードの一部として、「goCom」層911と呼ばれる層を含めて、以下の容易化を行い得る:(a)goFrameヘッダ内のシーケンス番号の重複に基づく冗長受信メッセージの破棄及び(b)複製メッセージの統計生成。収集されたデータを参照し、使用して、任意及びすべての冗長パスの健康を監視し得る。例示的な実施形態では、VxWorksは、muxLibインタフェース912を提供して、ネットワークインタフェース上で受信されるイーサネットパケットへのアクセスを提供する。muxLibは、特定のネットワークインタフェースからイーサネットメッセージを送出するためにも使用される。
【0018】
パケットを受信した場合、アプリケーションにインストールされているコールバックを、受信割り込みの状況で実行し得る。受信パケットを含むバッファへのポインタが、muxインタフェースにより提供される。パケットは、一連のフィルタにより検査して、有効な「goCom」フレームであることを確立し得る。メッセージが、ネットワーク、例えば、センサノード、エフェクタノード、及び/又は送受信器ノードの航空機ネットワーク上のサブシステムからのものである場合、サブシステムのイーサネットアドレスを、サブシステムIPアドレスにより索引付けられたテーブル913に記憶し得る。したがって、索引付けられたサブシステムイーサネットアドレスのテーブルを参照して、ユニキャストメッセージを、記憶されたアドレスに対応するサブシステムに返信し得る。例示的なテーブルは、部分的に、ARPが航空機二重ネットワークパス実施形態において一貫して機能しない場合があるため、ARPの代わりに動作し得る−単独実施形態メカニズム。したがって、FCCがFCCにまだメッセージを送信していない任意のサブシステムにメッセージを送信できないことに留意する−FCCがサブシステムのイーサネットMACアドレスにアクセス又は学習し得るのは、索引付きテーブルによってであるため。テーブルに先を見越して入力するために、例示的な実施形態は、ネットワーク上のすべてのノードに、マルチキャストされた「健康要求」に応答するように要求する。この健康要求は、システムの典型的又は通常の機能から選択し得る。すなわち、利用可能な健康要求への調整又は変更は、必ずしも、二重ユニキャスト耐故障ネットワーク設計のサポートに必要であるわけではない。したがって、サブシステムが、健康応答メッセージで健康要求に応答する場合、FCCは即座に、ネットワーク上のあらゆるノードのイーサネットMACアドレスを学習する。パケットがサブシステムからいつ受信されたかのタイムスタンプもテーブルに記憶される。これにより、パス毎の最近の接続に基づいてネットワークの健康を評価することができる。いくつのパケットがいずれかのパスで失われたかについての統計も収集される。そのような統計の収集により、信号パケット損失であっても高感度の検出が可能である。高レベル感度の検出は、ネットワーク問題を早期に検出して切り離す潜在性を提供する。
【0019】
RTPからカーネルへのメッセージチャネルインタフェースを使用して、両方のNICから冗長的に送信すべきユニキャストメッセージを通信し得る。例示的な実施形態は、システムが生成すると予期される、サポートされる最大のイーサネットパケット又は媒体転送単位(MTU)を含むのに十分な大きさの固定サイズのバッファを有するメッセージチャネルを有する。例示的な実施形態は、1536バイトサイズのMTUを有し得る。メッセージチャネル920インタフェースは柔軟であるように構成し得、広範囲のユニキャストをネットワークの任意のサブシステムに送信することができる。メッセージバッファの冒頭にあるメタデータを参照して、メッセージの送信が意図されるIPアドレス及びポートを識別し得る。
【0020】
カーネル910は、特定のサブシステムに送信すべきメッセージをRTP970から受信すると、まず、サブシステムの有効なイーサネットアドレスがイーサネットテーブル913に記憶されているか否かをチェックして判断し得る。記憶されていない場合、メッセージを静かに破棄し得る。すなわち、ネットワークの他の要素及びFCCアプリケーションRTPに通知せずにメッセージを破棄し得る。イーサネットアドレスがサブシステムに提供される場合、2つのパケットが、メッセージ920に基づいて形成される930。2つのメッセージは、送信元であるNIC以外は同一である。特に、同じシーケンス番号が両方のパケットに使用される。次に、パケットは2つのNIC、特に、各NICのイーサネットドライバ951、952に送信され、muxLibインタフェース912を介して送信される。
【0021】
VxWorksカーネルとして実施されるカーネル910には、共有データライブラリサポート、例えば、sdLibサポートを構築して、統計をパケット受信ハンドラから、ネットワーク統計を使用してgoComメッセージを生成するRTP符号に渡す効率的なメカニズムを提供し得る。カーネルの実施形態は、ネットワークスタックが使用する標準インタフェースとしてmuxLibを有する。
【0022】
不揮発性記憶装置、例えば、フラッシュメモリ又はNVRAMを使用して、受信したイーサネットパケットにタイムスタンプを付与するために使用される飛行時間、すなわち、経過時間を記憶し得る。比較的高速であるが、NVRAMアクセスはRAMアクセスよりも遅く、あらゆる受信パケットにタイムスタンプが付与されるため、読み出し性能が考慮事項である。NVRAMは、32ビットアクセス装置であり得るRAMとは対照的に、8ビットアクセス装置であり得る。8ビットアクセスは、秒カウンタの長たらしい4バイトにわたってデータの一貫性判断を行うが、32ビットアクセスは本質的に原子的である。したがって、飛行秒カウンタがRAM並びにNVRAMに記憶され、1秒の割り込み処理の一環として両位置で更新することができる。
【0023】
VxWorks標準RAMマップ等の標準RAMマップを使用し得、ブートローダは、アプリケーションを低いメモリにロードする間、高いメモリを使用する。起動時、アプリケーションは、SYSMEMTOPで始まる高いメモリを使用して、スタックを構築する。スタックはビルドダウンされる。OS又はコンパイラにより管理されないあらゆる固定メモリ割り振りも、SYSTEMTOPよりも上に配置し得る。カーネルアプリケーションは、sdLibを使用して、カーネルにより管理される名前付きの共有データ領域を作成する。次に、名前付き領域は、RTPアプリケーションにより開かれ、イーサネットパケット統計性を読み出し得る。
【0024】
VxWorks用のCurtis WrightのBSPを使用して、イーサネットドライバを提供し得る。したがって、muxLib イーサネットドライバインタフェースは、MUX_PROTO_SNARFモードで動作するように構成し得る。この構成では、すべての受信パケットを無差別に検査することができる。次に、パケットは、任意選択的に、muxLibに戻されて、通常処理のために標準のネットワークスタックに送信される。
【0025】
例示的なアルゴリズム構造が、図10のGoComMux流れ図に示される。アプリケーション層は、goComMuxモジュール1010の手続きを初期化又は生成し得る。モジュールが初期化されると1020、goComMuxモジュールは、第1のNICをバインドする1030と共に、第2のNICをバインドし得1040、それにより、送信元であるNICの特定が可能になる。メッセージ送信を初期化する手続き1050を実行し得、カーネルは、ドライバインタフェースを処理し、RTPメッセージ、例えば、パケット/データグラムをカーネル送信チャネルに読み出し得る1060。GoComMuxモジュールは、フレーム1070をFCCアプリケーションRTP970に送信可能であり得る。GoComMuxモジュールは、第1のNIC1080及び第2のNIC1085の割り込みを受け入れ、MuxLibからのパケットを受信する手続き1090を呼び出し得る。
【0026】
上記実施形態の特定の特徴及び態様の様々な組み合わせ及び/又は下位組み合わせを行うことが可能であり、それでも本発明の範囲内にあることが意図される。したがって、開示される実施形態の様々な特徴及び態様を互いに結合又は置換して、開示される本発明の変形モードを形成し得ることを理解されたい。さらに、本明細書において例として開示される本発明の範囲を、開示される上述した特定の実施形態によって限定されるべきではないことが意図される。
【特許請求の範囲】
【請求項1】
相互接続ネットワーク内のノードであって、
プロセッサと、アドレス指定可能なメモリとを備え、前記プロセッサは、
送信元からのメッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取るステップと、
前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を前記受信パケットの前記シーケンス番号と比較するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、前記受信パケットを破棄するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位プロトコルに基づいて前記受信パケットの前記メッセージをアプリケーションに送るステップと
を行うように構成されることを特徴とする、ノード。
【請求項2】
請求項1に記載のノードにおいて、2つ以上のパスから同じ送信元識別子を有するパケットを受信するようにさらに構成されることを特徴とする、ノード。
【請求項3】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、前記受信フレームのペイロード情報に応答するエフェクタとを備えることを特徴とする、ノード。
【請求項4】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数送信器とを備えることを特徴とする、ノード。
【請求項5】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数受信器とを備えることを特徴とする、ノード。
【請求項6】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、センサとを備えることを特徴とする、ノード。
【請求項7】
冗長メッセージ処理の方法であって、
送信元ノードのプロセッサが、
フレームシーケンス番号を第1のパケットのフレームに割り当て、
送信元識別番号を前記第1のパケットの前記フレームに割り当て、
前記フレームシーケンス番号を第2のパケットのフレームに割り当て、
送信元識別番号を前記第2のパケットの前記フレームに割り当てるステップと、
宛先ノードのプロセッサが、前記第1のパケット及び前記第2のパケットを含む組のうちの第1の受信パケットの前記フレームシーケンス番号及び前記送信元番号を記録するステップと、
前記宛先ノードの前記プロセッサが、前記記録されたフレームシーケンス番号及び前記記録された送信元番号を有する第2の受信パケットを破棄するステップと
を含むことを特徴とする、方法。
【請求項8】
請求項7に記載の方法において、
前記破棄するステップの前に、
前記宛先ノードの前記プロセッサが、前記第2の受信パケットの前記フレームシーケンス番号と前記第1の受信パケットの前記記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、前記第1の受信パケットの前記記録された送信元番号を有する第2の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含むことを特徴とする、方法。
【請求項9】
請求項7に記載の方法において、前記送信元ノードが、第1のネットワークインタフェース回路を介して前記第1のパケットを送信し、第2のネットワークインタフェース回路を介して送前記第2のパケットを送信することをさらに含むことを特徴とする、方法。
【請求項10】
ネットワークノード健康評価の方法であって、
ネットワークの複数のネットワークノードに健康要求をマルチキャスト又はブロードキャストするステップと、
前記複数のネットワークノードのうちの少なくとも1つから健康要求応答を受信するステップであって、前記受信する健康要求応答メッセージは、前記応答ノードのイーサネットMACアドレスを含むステップと、
タイムスタンプを前記受信した健康要求応答メッセージに関連付けるステップと、
前記応答ノードの前記受信したイーサネットMACアドレス及び関連付けられたタイムスタンプを記憶するステップと、
2つ以上のネットワークインタフェース回路(NIC)のイーサネットドライバに、1つ又は複数のノードへの同一の出力メッセージを、前記1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスに基づいて提供するステップと
を含むことを特徴とする、方法。
【請求項11】
請求項10に記載の方法において、前記1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワーク健康を評価することをさらに含むことを特徴とする、方法。
【請求項12】
請求項10に記載の方法において、
2つ以上のNICパスを介して送信されたパケットを、2つ以上のNICパスを介して受信されたパケットと比較するステップと、
前記2つ以上のNICパスのそれぞれの損失パケット数量を特定するステップと
をさらに含むことを特徴とする、方法。
【請求項1】
相互接続ネットワーク内のノードであって、
プロセッサと、アドレス指定可能なメモリとを備え、前記プロセッサは、
送信元からのメッセージを有する受信パケットのシーケンス番号及び送信元識別子を読み取るステップと、
前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号を前記受信パケットの前記シーケンス番号と比較するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号以下である場合、前記受信パケットを破棄するステップと、
前記受信パケットの前記シーケンス番号が、前記送信元識別子に関連付けられた記憶されている最も高いシーケンス番号よりも大きい場合、上位プロトコルに基づいて前記受信パケットの前記メッセージをアプリケーションに送るステップと
を行うように構成されることを特徴とする、ノード。
【請求項2】
請求項1に記載のノードにおいて、2つ以上のパスから同じ送信元識別子を有するパケットを受信するようにさらに構成されることを特徴とする、ノード。
【請求項3】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、前記受信フレームのペイロード情報に応答するエフェクタとを備えることを特徴とする、ノード。
【請求項4】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数送信器とを備えることを特徴とする、ノード。
【請求項5】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、無線周波数受信器とを備えることを特徴とする、ノード。
【請求項6】
請求項1に記載のノードにおいて、前記送信元は準リアルタイムコントローラを備え、前記ノードは、ゲートウェイと、センサとを備えることを特徴とする、ノード。
【請求項7】
冗長メッセージ処理の方法であって、
送信元ノードのプロセッサが、
フレームシーケンス番号を第1のパケットのフレームに割り当て、
送信元識別番号を前記第1のパケットの前記フレームに割り当て、
前記フレームシーケンス番号を第2のパケットのフレームに割り当て、
送信元識別番号を前記第2のパケットの前記フレームに割り当てるステップと、
宛先ノードのプロセッサが、前記第1のパケット及び前記第2のパケットを含む組のうちの第1の受信パケットの前記フレームシーケンス番号及び前記送信元番号を記録するステップと、
前記宛先ノードの前記プロセッサが、前記記録されたフレームシーケンス番号及び前記記録された送信元番号を有する第2の受信パケットを破棄するステップと
を含むことを特徴とする、方法。
【請求項8】
請求項7に記載の方法において、
前記破棄するステップの前に、
前記宛先ノードの前記プロセッサが、前記第2の受信パケットの前記フレームシーケンス番号と前記第1の受信パケットの前記記録されたフレームシーケンス番号との差が、上限閾値を上回るか、又は下限閾値を下回る場合、前記第1の受信パケットの前記記録された送信元番号を有する第2の受信パケットのフレームシーケンス番号及び送信元番号を記録することをさらに含むことを特徴とする、方法。
【請求項9】
請求項7に記載の方法において、前記送信元ノードが、第1のネットワークインタフェース回路を介して前記第1のパケットを送信し、第2のネットワークインタフェース回路を介して送前記第2のパケットを送信することをさらに含むことを特徴とする、方法。
【請求項10】
ネットワークノード健康評価の方法であって、
ネットワークの複数のネットワークノードに健康要求をマルチキャスト又はブロードキャストするステップと、
前記複数のネットワークノードのうちの少なくとも1つから健康要求応答を受信するステップであって、前記受信する健康要求応答メッセージは、前記応答ノードのイーサネットMACアドレスを含むステップと、
タイムスタンプを前記受信した健康要求応答メッセージに関連付けるステップと、
前記応答ノードの前記受信したイーサネットMACアドレス及び関連付けられたタイムスタンプを記憶するステップと、
2つ以上のネットワークインタフェース回路(NIC)のイーサネットドライバに、1つ又は複数のノードへの同一の出力メッセージを、前記1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスに基づいて提供するステップと
を含むことを特徴とする、方法。
【請求項11】
請求項10に記載の方法において、前記1つ又は複数のノードの受信され記憶されたイーサネットMACアドレスの1つ又は複数のタイムスタンプに基づいて、ネットワーク健康を評価することをさらに含むことを特徴とする、方法。
【請求項12】
請求項10に記載の方法において、
2つ以上のNICパスを介して送信されたパケットを、2つ以上のNICパスを介して受信されたパケットと比較するステップと、
前記2つ以上のNICパスのそれぞれの損失パケット数量を特定するステップと
をさらに含むことを特徴とする、方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【公表番号】特表2013−511857(P2013−511857A)
【公表日】平成25年4月4日(2013.4.4)
【国際特許分類】
【出願番号】特願2012−531038(P2012−531038)
【出願日】平成22年9月23日(2010.9.23)
【国際出願番号】PCT/US2010/050051
【国際公開番号】WO2011/038153
【国際公開日】平成23年3月31日(2011.3.31)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
2.ETHERNET
【出願人】(512059877)エアロバイロメント,インコーポレイテッド (8)
【氏名又は名称原語表記】AEROVIRONMENT,INC.
【Fターム(参考)】
【公表日】平成25年4月4日(2013.4.4)
【国際特許分類】
【出願日】平成22年9月23日(2010.9.23)
【国際出願番号】PCT/US2010/050051
【国際公開番号】WO2011/038153
【国際公開日】平成23年3月31日(2011.3.31)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
2.ETHERNET
【出願人】(512059877)エアロバイロメント,インコーポレイテッド (8)
【氏名又は名称原語表記】AEROVIRONMENT,INC.
【Fターム(参考)】
[ Back to top ]