JP2019506094A - メッセージハンドラ - Google Patents

Abstract

メッセージハンドラ（６１、６２）を開示する。メッセージハンドラは、ＣＡＮまたはイーサネット（登録商標）など、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２；図４）およびペイロードデータ（２３；図４）を含むデータパッケージ（１３１、１３２）を受信することに応答して、ヘッダ（２４；図４）およびペイロードデータ（２５；図４）を含む、予め定められたデータフォーマットを有するパッケージ（１４）、たとえば、レイヤ２またはレイヤ３パッケージを生成するように構成される。ヘッダは、パッケージ誘導データに応じて生成されたアドレスを含み、ペイロードは、データパッケージを含む。予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＥＥＥ １７２２フレームであってもよい。

Description

発明の分野
本発明は、メッセージハンドラ、および、少なくとも２つのメッセージハンドラと、メッセージハンドラ間でデータパッケージをスイッチングまたはルーティングするように構成されたメッセージ・フォワーダとを備える制御ユニットに関する。

背景
ゲートウェイによって、異なるネットワークインターフェース間の情報やり取りが可能になる。ネットワークインターフェースは、イーサネット（登録商標）、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＦｌｅｘＲａｙ、およびＭＯＳＴ（Ｍｅｄｉａ Ｏｒｉｅｎｔａｔｅｄ Ｓｙｓｔｅｍｓ Ｔｒａｎｓｐｏｒｔ）など、同じまたは異なるＯＳＩ物理層（「第１層」）、データリンク（「第２層」）、および／またはネットワーク層（「第３層」）プロトコル（複数可）を使用できる。ゲートウェイには、イーサネット（登録商標）スイッチ、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）、およびフィールドバスゲートウェイなどがある。

イーサネット（登録商標）１０／１００／１０００スイッチおよびＣＡＮ／ＣＡＮゲートウェイなど、同じプロトコル内のレイヤ２ゲートウェイは、データ伝送速度は変わり得るが、データリンク層のフレームは同一であるため、単純である傾向がある。ＣＡＮ／ＣＡＮ−ＦＤゲートウェイなど、プロトコルを跨ぐレイヤ２ゲートウェイでは、ネットワーク層上でパケット（または、「パッケージ」）を変更することなく、再フレーミングすることができる。ＩＰｖ４／ＩＰｖ６ゲートウェイまたはＣＡＮ／イーサネット（登録商標）ゲートウェイなど、レイヤ３ゲートウェイは、異なるアドレス指定要件およびトラフィック制御要件に合わせてパケットを再構築できる。ＴＣＰ／ＵＤＰゲートウェイおよびＡＵＴＯＳＡＲ信号ゲートウェイなど、レイヤ４〜７ゲートウェイでは、互いに異なるトランスポートプロトコル間での変更ができ、情報の再アセンブリが可能である。

同じプロトコルまたはプロトコルファミリー内のレイヤ２ゲートウェイは、ハードウェアで実現される傾向があり、このようなゲートウェイには、ルネサスのＲＨ８５０／Ｃ１ＭマイクロコントローラにおけるＣＡＮ／ＣＡＮゲートウェイ、およびルネサスのＲＨ８５０／Ｄ１ＭマイクロコントローラにおけるＣＡＮ／ＣＡＮ−ＦＤゲートウェイなどがある。

図１を参照すると、レイヤ３ゲートウェイは、ソフトウェアで実現されることが多い。マイクロコントローラは、ネットワークインターフェースのセットと、構成マトリックスに基づいてパケットを再アセンブリできるマイクロコントローラの中央処理装置によって実行されるソフトウェアとを有する。このようなゲートウェイには、ＵＳＢ／ＵＡＲＴコンバータ、および自動車関係のＣＡＮ／ＬＩＮ／ＦｌｅｘＲａｙゲートウェイなどがある。通信プロトコルがそれぞれ異なるアドレス指定方式、異なるメッセージ構造を有するので、ソフトウェアが、異なるプロトコル間で変換できる柔軟性を提供する。

レイヤ４〜７ゲートウェイは、一般に、ソフトウェアで実現される。上位層においてデータを再アセンブリするには、かなりのコンフィギュアビリティおよび柔軟性が必要になる傾向があり、これは、たとえば、映像データなど、スピードが重視される変換に固有な場合において、ハードウェアベースのソリューションは可能ではあるが、ソフトウェアベースの実装を利用することでしか実際のところ実現できない。

ネットワーク層のパッケージのフレーミングは、通常、ハードウェアで実施され、ルーティング・メカニズムには見えないようになっている。パケットフレーミングが生じる例に、イーサネット（登録商標）ＭＡＣ、ＦｌｅｘＲａｙ通信コントローラ、およびＣＡＮプロトコルエンジンなどがある。すべてのプロトコルは、上位層と情報をやり取りするために、個々の最適化されたインターフェースを有する傾向がある。

また、同じプロトコルファミリー内のレイヤ３ゲートウェイも、ハードウェアで実現することが容易である傾向がある。たとえば、ＣＡＮ／ＣＡＮ−ＦＤ変換およびＩＰｖ４／ＩＰｖ６変換を伴う状況では、パケット構造の最低限の変更しか必要としない。

それぞれ異なるプロトコルを要するレイヤ３ゲートウェイは、異なるアドレス指定、ルーティング方式、およびトラフィック制御方式に適応できるように、パケットを再フォーマットする必要があるので、ハードウェアで実現することが難しい傾向にある。パケット変換は、一般に、柔軟性のある、構成可能なデータ操作装置を必要とする。これによって、情報の欠落が生じてしまう。イーサネット（登録商標）の長さをＣＡＮ ＤＬＣに変換する場合など、すべてのフレーム情報が変換可能であるわけではないためである。

アドレス指定方式の変換は、両方のネットワーク層の間に構成可能変換テーブルを必要とする。トラフィック制御方式の変換は、通常、新しいレイヤ４トランスポートプロトコル、または他の上位層によるサポートを必要とする。

ますます、通信システムは、互いに接続された２種類以上のバスシステムを備えるようになっている。これによって、データの転送がより複雑になっている。

米国第２０１４／０１３３３５０Ａ１号では、第１および第２の通信プロトコルにそれぞれ応じてデータ伝送をサポートする第１および第２のサブネットワークを含む少なくとも２つのサブネットワークを接続するためのゲートウェイモジュールが開示されている。ゲートウェイモジュールは、第１および第２の通信プロトコルを考慮しつつ、データを操作して第１サブネットワークから第２サブネットワークに転送するようになされた構成可能ハードウェア回路を有する。しかしながら、通信プロトコルの数および種類が増えると、この種類のゲートウェイは、ますます複雑になるまたはハードウェア変更を必要とする。したがって、新しい通信インターフェースが導入されると、新しいインターフェースモジュールを追加しなければならないだけではなく、ゲートウェイモジュールも変更が必要になる場合がある。

概要
本発明の第１の態様によれば、メッセージハンドラが提供される。メッセージハンドラは、所定の通信プロトコルに応じてフォーマットされた、パッケージ誘導データおよびペイロードデータを含むデータパッケージ受信することに応答して、たとえば、レイヤ２またはレイヤ３パッケージなど、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを生成するように構成される。ヘッダは、パッケージ誘導データに応じて生成されたアドレスを含み、ペイロードは、パッケージを含む。

したがって、通信プロトコルごとに異なるメッセージハンドラを制御ユニットに設けることができ、共通のデータフォーマットを有するパッケージを生成するために使用できる。これは、２つ以上の通信バスとホストプロセッサとの間のデータのやり取りを容易にすることに役立ち、バス間でデータをやり取りするためにハードウェアベースのスイッチまたはルータを使用することを可能にする。したがって、使用中の固有の通信プロトコルが同じプロトコルであるか異なるプロトコルであるかに関係なく、同じルーティング・メカニズムを使用できる。

着信データパッケージは、巡回冗長検査データを含まなくてもよい。着信データパッケージは、タイムスタンプを含んでもよい。

パッケージ誘導データは、メッセージ識別情報あるいはメッセージコンテンツ識別子（マルチキャストの宛先を特定するために使用できる）、または宛先ノードアドレスを含んでもよい。アドレスは、ストリーム識別子であってもよい。

メッセージハンドラは、パッケージ誘導データの第１のフィールドから、ヘッダの対応するフィールドにデータをコピーするように構成されてもよい。メッセージハンドラは、ヘッダの第２のフィールドに、予め定められたデータを追加するように構成されてもよい。予め定められたデータは、ホストプロセッサによって供給されてもよい。メッセージハンドラは、第１のフィールドおよび／または第２のフィールドのデータに応じて算出されたデータを、ヘッダの第２のフィールドに追加するように構成されてもよい。

メッセージハンドラは、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データおよびペイロードデータを含むデータパッケージを取り出すように構成されてもよい。

本発明の第２の態様によれば、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データおよびペイロードデータを含むデータパッケージを取り出すように構成されたメッセージハンドラが提供される。

予め定められたデータフォーマットを有するパッケージは、ＩＥＥＥ １７２２フレームであってもよい。予め定められたデータフォーマットは、ＩＥＥＥ １７２２に準拠してもよい。予め定められたデータフォーマットを有するパッケージは、ＡＶＴＰ制御メッセージであってもよい。アドレスは、ストリームＩＤであってもよい。予め定められたデータフォーマットを有するパッケージは、レイヤ２フレームであってもよい。予め定められたデータフォーマットを有するパッケージは、ＩＰパケット、たとえば、ＩＰｖ４またはＩＰｖ６パケットであってもよい。

所定の通信プロトコルは、ＩＳＯ １１８９８−１（または、「ＣＡＮ２．０」）であってもよい。所定の通信プロトコルは、ＣＡＮ−ＦＤ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｆｌｅｘｉｂｌｅ Ｄａｔａ ｒａｔｅ ｐｒｏｔｏｃｏｌ）プロトコルであってもよい。所定の通信プロトコルは、ＦｌｅｘＲａｙプロトコルであってもよい。所定の通信プロトコルは、ＩＥＥＥ ８０２．３（つまり、イーサネット（登録商標））であってもよい。所定の通信プロトコルは、ＭＯＳＴ（Ｍｅｄｉａ Ｏｒｉｅｎｔｅｄ Ｓｙｓｔｅｍｓ Ｔｒａｎｓｐｏｒｔ）プロトコルであってもよい。所定の通信プロトコルは、イーサネット（登録商標）ベースのプロトコルであってもよい。所定の通信プロトコルは、ＥｔｈｅｒＣＡＴ、ＣＣ−Ｌｉｎｋ ＩＥ Ｆｉｅｌｄ、ＰＲＯＦＩＮＥＴ、ＥｔｈｅｒＮｅｔ（登録商標）／ＩＰ、Ｍｏｄｂｕｓ ＴＣＰ、またはＦＬ−ｎｅｔであってもよい。

本発明の第３の態様によれば、ハードウェアで実現され、プロトコルエンジンとメッセージハンドラとを含み、プロトコルエンジンと、所定の通信プロトコルに応じてフォーマットされたデータパッケージをやり取りするように構成されたネットワークインターフェースモジュールが提供される。

本発明の第４の態様によれば、中央処理装置と、メモリと、メモリまたは他の記憶装置に格納されたコンピュータプログラムとを備え、コンピュータプログラムは、中央処理装置によって実行されると、中央処理装置に、メッセージハンドラを実行させる、中央処理装置サブシステムが提供される。

本発明の第５の態様によれば、第１および第２の通信プロトコルに応じてそれぞれメッセージを扱うための第１および第２のメッセージハンドラと、予め定められたデータフォーマットを有するパッケージをやり取りするように構成されたメッセージ・フォワーダが提供される。メッセージ・フォワーダは、レイヤ２スイッチおよび／またはレイヤ３ルータであってもよい。

本発明の第６の態様によれば、第１の通信プロトコルに応じてフォーマットされたデータパッケージを扱うように構成された第１のメッセージハンドラまたはネットワークインターフェースモジュールと、第２の通信プロトコルに応じてフォーマットされたデータパッケージを扱うように構成された第２のメッセージハンドラまたはネットワークインターフェースモジュールと、予め定められたデータフォーマットを有するパッケージを第１のメッセージハンドラと第２のメッセージハンドラとの間でやり取りするように構成されたメッセージ・フォワーダとを備える制御ユニットが提供される。メッセージ・フォワーダは、レイヤ２スイッチまたはレイヤ３ルータであってもよい。

第１および第２の通信プロトコルは、互いに異なってもよい。第１および第２の通信プロトコルは、同じであってもよい。

制御ユニットは、第３の通信プロトコル（第１の通信プロトコルおよび／または第２の通信プロトコルと同じであっても異なってもよい）に応じてフォーマットされたデータパッケージを扱うように構成された第３のメッセージをさらに備えてもよい。

制御ユニットは、中央処理装置システムをさらに備えてもよく、メッセージ・フォワーダは、中央処理装置サブシステムと第１および／または第２のメッセージハンドラとの間でやり取りするように構成される。

制御ユニットは、マイクロコントローラまたはＳｏＣ（ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）など、集積回路であってもよい。

本発明の第７の態様によれば、少なくとも２セットのバスラインと、バスに接続された、本発明の第２の態様に係る少なくとも１つの制御ユニット（複数可）とを備える通信システムが提供される。バスは、異なる種類のバス（ＣＡＮ、ＣＡＮ−ＦＤ、およびイーサネット（登録商標）など）を含んでもよい。

本発明の第８の態様によれば、通信システムを備える車両が提供される。
車両は、自動車であってもよい。自動車は、オートバイ、乗用車（「車」と称する場合もある）、ミニバス、バス、トラック、または大型トラックであってもよい。自動車は、内燃機関および／または１つ以上の電動機によって電源が供給されてもよい。車両は、機関車、客車、または複数のユニットなど、電車または電車の一部であってもよい。

車両は、航空機であってもよい。通信システムは、ＡＦＤＸ（Ａｖｉｏｎｉｃｓ Ｆｕｌｌ−Ｄｕｐｌｅｘ Ｓｗｉｔｃｈｅｄ Ｅｔｈｅｒｎｅｔ）システムであってもよい。

本発明の第９の態様によれば、通信システムを備える、プラントまたは機械などの産業用システムが提供される。プラントまたは機械は、製造または加工の際に使用するための産業用システムを備えてもよい。

本発明の第１０の態様によれば、通信システムを備える医療システムが提供される。
添付の図面のうちの図２〜図８を参照して、例として、本発明のいくつかの実施形態をここに説明する。

ソフトウェアにおいてバス間でデータをやり取りできる通信システムの概略ブロック図である。 ハードウェアにおいてバス間でデータをやり取りできる通信システムの概略ブロック図である。 制御ユニットの概略ブロック図である。 通信プロトコルに依存したパッケージの、共通フォーマットのパッケージへの変換を示す図である。 共通フォーマットのパッケージの、通信プロトコルに依存したパッケージへの変換を示す図である。 ＣＡＮ依存のパッケージを含むＣＡＮフレームを示す図である。 ＡＶＴＰの共通メッセージを示す図である。 車両通信ネットワークおよび車両の概略図である。 産業用通信ネットワークおよびロボットの概略図である。

いくつかの実施形態の詳細な説明
通信システム１
図２は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）およびイーサネット（登録商標）など、第１および第２の通信プロトコルの最下位のプロトコル層を実現するための、第１および第２セットのバスライン３_１、３_２に接続された第１および第２のセクション２_１、２_２を含む通信システム１を示す。

第１セクション２_１は、物理層モジュール４_１と、プロトコルエンジンモジュール５_１と、メッセージハンドラ６_１とを含む。プロトコルエンジンモジュール５_１およびメッセージハンドラ６_１は、ネットワークインターフェースモジュール７_１（図３）内に、ハードウェアで実現される。

第２セクション２_２は、物理層モジュール４_２と、プロトコルエンジンモジュール５_２と、メッセージハンドラ６_２とを含む。プロトコルエンジンモジュール５_２およびメッセージハンドラ６_２は、ネットワークインターフェースモジュール７_２（図３）内に、ハードウェアで実現される。

メッセージハンドラ６_１、６_２は、レイヤ２スイッチまたはレイヤ３ルータの形を取り得るパッケージまたはメッセージ・フォワーダ８によって、互いに接続される。メッセージ・フォワーダ８は、適切なハードウェア論理、ハードウェアレジスタなどを備えるハードウェアで実現されることが好ましい。メッセージ・フォワーダ８は、いずれのプロトコル変換も行わない。また、メッセージ・フォワーダ８は、統合（ｕｎｉｆｉｅｄ）ネットワークスタック９を介して、上位層１０に接続される。統合ネットワークスタック９および上位層１０は、ソフトウェアで実現される。

物理層モジュール４_１、４_２は、着信フレーム１２_１、１２_２をプロトコルエンジン５_１、５_２に渡す。プロトコルエンジン５_１、５_２は、フレームチェックシーケンス（ＦＣＳ：Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）などのフレームコンポーネントを除去し、パッケージ１３_１、１３_２を生成することができる。プロトコルエンジン５_１、５_２は、タイムスタンプなどの情報をパッケージ１３_１、１３_２に追加してもよい。

プロトコルエンジン５_１、５_２は、パッケージ１３_１、１３_２をメッセージハンドラ６_１、６_２に渡す。メッセージハンドラ６_１、６_２は、共通フォーマットのパッケージ１４を生成する。詳細は後述するが、メッセージハンドラ６_１、６_２は、共通フォーマットのパッケージ１４を別のメッセージハンドラ６_１、６_２および／または統合ネットワークスタック９にスイッチングまたはルーティングするためのメッセージ・フォワーダ８に、共通フォーマットのパッケージ１４を渡すことができる。したがって、パッケージは、メッセージハンドラ６_１、６_２間だけではなく、上位層１０にも転送され得る。

３つ以上のメッセージハンドラ６_１、６_２がある場合、メッセージ・フォワーダ８は、２つ以上のメッセージハンドラ６_１、６_２および、必要であれば、上位層１０に、パッケージをスイッチングまたはルーティングできる。メッセージ・フォワーダ８は、メッセージをユニキャストまたはマルチキャストしてもよい。

また、図３を参照すると、物理層モジュール４_１、４_２は、ＰＨＹトランシーバ４_１、４_２の形を取る。プロトコル層５_１、５_２、メッセージハンドラ６_１、６_２、メッセージ・フォワーダ８、統合スタック９、および上位層１０は、マイクロコントローラまたはＳｏＣ（ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）の形で、制御ユニット１６において実装される。制御ユニット１６は、プロトコルエンジン５_１、５_２およびメッセージハンドラ６_１、６_２を提供するネットワークインターフェースモジュール７_１、７_２（または、「通信コントローラ」）を備える。制御ユニット１６は、少なくとも１つの中央処理装置（ＣＰＵ）１８と、メモリ１９と、オンチップインターコネクト（図示せず）とを含む中央処理装置サブシステム１７を備える。また、物理層モジュール４_１、４_２は、マイクロコントローラまたはＳｏＣにおいて実装することもできる。

ＣＰＵ１８は、ネットワークインターフェースモジュール７_１、７_２およびメッセージ・フォワーダ８を設定できる。また、ＣＰＵ１８は、フレームをより直接読み出し、書き込み、および処理できるように、メッセージ・フォワーダ８をバイパスしてメッセージハンドラ６_１、６_２にアクセスすることも可能である。したがって、すべてのフレームに対してメッセージ転送メカニズムを用いる必要はない。たとえば、メッセージ転送は、特定の、予め定められた種類のフレームに対して自動的にフレームをルーティングするために使用できる。メッセージ・フォワーダ８をバイパスできるにもかかわらず、ＣＰＵ１８は、ＣＡＮなどの固有の媒体フォーマットのデータを扱えるのに、それでもなお、共通のフォーマットを使用し得る。

ＣＰＵ１８は、ソフトウェアベースのメッセージハンドラ２０を実行してもよい。これによって、ＣＰＵ１８は、共通フォーマットのメッセージ１４を作成できるようになり、共通フォーマットのメッセージ１４は、その後、１つ以上のメッセージハンドラ６_１、６_２に直接またはメッセージ・ルータ８を介して送られ得る。

メッセージハンドラ６ _１ 、６ _２
先に述べたように、メッセージハンドラ６_１、６_２は、ＣＡＮプロトコルエンジンなど、それぞれのプロトコルエンジン５_１、５_２からデータパッケージ１３_１、１３_２を受信し、共通フォーマットのパッケージ１４を生成する。

また、図４を参照すると、各データパッケージ１３_１、１３_２は、プロトコル依存のアドレス２２と、ペイロード２３とを含む。

アドレス２２のフォーマット、およびどのようにアドレス２２が使用されるのかは、通信プロトコルによって異なる。たとえば、イーサネット（登録商標）は、パケットをユニキャストまたはマルチキャストするために、４８ビットのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを用いて宛先ノードを特定できる。ＣＡＮは、メッセージをマルチキャストするために、１１ビットまたは２９ビットのメッセージ識別子を用いてメッセージコンテンツを特定できる。ＦｌｅｘＲａｙは、メッセージをマルチキャストするために、一時的なリレーションを用いてメッセージコンテンツを特定する。

優先制御は、アドレスやペイロード２３に含める、または、ほかの方法で信号で送ることができる。たとえば、イーサネット（登録商標）では、優先情報は、ペイロードに含まれるのに対して、ＣＡＮでは、メッセージ優先順位は、メッセージ識別情報に含まれる。ＦｌｅｘＲａｙでは、メッセージ優先順位は、既定の周期での繰り返しに基づく。

メッセージハンドラ６_１、６_２は、プロトコル依存のアドレス２２をデータパッケージ１３_１、１３_２から取り出し、共通フォーマットのヘッダ２４およびペイロード２５を作成する。共通フォーマットのヘッダ２４は、共通フォーマットのアドレス２６を含む。

メッセージハンドラ６_１、６_２は、プロトコル依存のアドレス２２を、共通フォーマットのアドレス２６にマッピングする。アドレスとメッセージ識別情報とは、別のフィールドに分割されることが好ましい。これは、共通フォーマットのパッケージ１４のルーティングを簡素化するのに役立ち得る。メッセージハンドラ６_１、６_２は、プロトコルエンジン５_１、５_２から受信したデータパッケージ１３_１、１３_２を、共通フォーマットのメッセージ１４のペイロード２５にカプセル化する。したがって、共通フォーマットのメッセージ１４は、ＣＡＮメッセージＩＤおよび共通フォーマットのアドレスなど、すべてのサポートされたデータリンク層についての情報を運ぶことができる。すべてのフィールド（ＣＡＮのボーレートのビットなど）のトンネリングができないレイヤ２またはレイヤ３プロトコルを共通フォーマットのメッセージ１４が使用し、それによって情報が欠落してしまう場合、メッセージハンドラ６_１、６_２は、欠落した情報を埋めるように構成されてもよく、たとえば、ＣＰＵ１８上で実行中のソフトウェアによって設定されてもよい。

また、図５を参照すると、メッセージハンドラ６_１、６_２は、メッセージ・フォワーダ１０から共通フォーマットのパッケージ１４を受信すると、ペイロード２５からヘッダ２６を破棄し、データパッケージ１３_１、１３_２を抽出する。次に、メッセージハンドラ７_１、７_２は、パッケージ１３_１、１３_２を、プロトコルエンジン５_１、５_２に転送する。

先に説明したように、メッセージ・フォワーダ８は、共通フォーマットのパッケージ１４を、２つ以上の対象に転送してもよい。１つ以上の対象は、２つ以上のメッセージハンドラ６_１、６_２を含んでもよい。１つ以上の対象は、ＣＰＵ１８を含んでもよい。

共通フォーマットのパッケージ１４によって、制御ユニット１６（図３）の外部の対象ノード（図示せず）、またはＣＰＵ１８上で実行中の対象サービス（図示せず）の特定を可能にする共通のアドレス指定形式がもたらされる。また、共通のアドレス指定形式は、サービス品質（ＱｏＳ）レベルも提供することが好ましい。共通のアドレス指定形式は、スイッチングまたはルーティングを行えるようにする最小セットの情報を提供する。

共通フォーマットのパッケージ１４は、イーサネット（登録商標）、ＣＡＮ、またはＦｌｅｘＲａｙなどの通信プロトコルが、そのプロトコル固有のメッセージフォーマットにそのメッセージをマッピングし戻せるコンテナを提供する。

共通フォーマットのパッケージ１４は、任意の適した種類のレイヤ２またはレイヤ３データコンテナであり得る。共通フォーマットのパッケージ１４は、６４ビットのストリームＩＤを共通フォーマットのアドレス２６として使用し、優先レベルを信号で送るためにＩＥＥＥ ８０２．１Ｑに準じた８レベルのＱｏＳを使用する、ＩＥＥＥ １７２２に準じて定義されたＡＣＦ（ＡＶＴＰ （Ａｕｄｉｏ Ｖｉｄｅｏ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ） Ｃｏｎｔｒｏｌ Ｆｏｒｍａｔ）メッセージの形を取ることが好ましい。これによって、レイヤ２イーサネット（登録商標）スイッチをメッセージ・フォワーダ８として使用できるようになる。

ストリームＩＤを共通フォーマットのアドレスとして使用するＡＣＦメッセージ使用する必要はない。（たとえば、ＩＰｖ４またはＩＰｖ６に基づく）ＩＰアドレスを共通フォーマットのアドレスとして使用するレイヤ３データグラム（つまり「ＩＰパケット」、または、単に、「パケット」）または、ＭＡＣアドレスを共通フォーマットのアドレスとして使用するレイヤ２データグラム（つまり、「フレーム」）など、他の種類のデータコンテナを使用できる。

図６は、プロトコルエンジン５_１からメッセージハンドラ６_１に渡される、ＣＡＮデータフレームから取り出されたデータパッケージ１３_１を示す図である。

図７は、図６に示すデータパッケージ１３_１がどのように共通フォーマットのパッケージ１４に変換されるかを示す図である。

図６に示すように、ＲＴＲ、ＩＤＥ、およびＤＡＴＡ（つまり、ペイロードデータ）など、フィールドのうちのいくつかにおけるデータは、データパッケージ１３_１からデータをコピーすることによって取得される。データは、ＡＦＬ（Ａｃｃｅｐｔａｎｃｅ Ｆｉｌｔｅｒ Ｌｉｓｔ）またはルックアップテーブルに基づき得る既定の方式に応じて、他のフィールドに追加される。データは、データパッケージ１３_１のフィールドで見つかったデータに応じて、他のフィールドに追加される。メッセージハンドラ６_１は、ハードウェアで実現されるが、ＣＰＵ１８によって設定できる。

ＩＥＥＥ １７２２メッセージが、通常、イーサネット（登録商標）パッケージにカプセル化されるので、ＩＥＥＥ ８０２．１ヘッダおよび８０２．１Ｑヘッダは、必要ではないが、有用である。

図８を参照すると、車両通信ネットワーク３１が示される。ネットワーク３１は、ＣＡＮおよびイーサネット（登録商標）などの複数の異なるバス３_１、３_２、３_３を含む。ネットワークは、複数の制御ユニット３２を含み、複数の制御ユニット３２は、バス３_１、３_２、３_３に接続されたマイクロコントローラの形を取り得る。制御ユニット３２のうちの少なくともいくつかは、ネットワークインターフェースモジュール７_１、７_２（図３）とメッセージ・フォワーダ８とを備える制御ユニット１６である。車両通信ネットワーク３１は、車両３３に導入される。

図９を参照すると、産業用通信ネットワーク４１が示されている。ネットワーク４１は、ＣＡＮおよびイーサネット（登録商標）などの複数の異なるバス３_１、３_２、３_３を含む。ネットワークは、バス３_１、３_２、３_３に接続されたマイクロコントローラの形を取り得る複数の制御ユニット４２を含む。制御ユニット４２のうちの少なくともいくつかは、ネットワークインターフェースモジュール７_１、７_２（図３）と、メッセージ・フォワーダ８とを備える制御ユニット１６である。産業用通信ネットワーク４１は、製造または加工システムなど、プラント、機械、またはシステム４３に導入される。

メッセージハンドラ６_１、６_２は、１つ以上の利益を有し得る。
メッセージハンドラ６_１、６_２は、バスの種類、および、メッセージが通信バス上に到着したか、またはＣＰＵによって生成されたかに関係なく、メッセージが転送される方法を一様にするのに役立ち得る。メッセージを複数の対象に転送できるなど、構成可能な柔軟性も提供できる。

さらに、共通のネットワークスタックの使用によって、新しいプロトコルを追加するときのレイヤ３ソフトウェアスタックの適合度が下げられる。また、（たとえば、ＣＡＮ上でＩＤにマッピング、イーサネット（登録商標）上で８０２．１Ｑ ＰＣＰにマッピングおよび、ＦｌｅｘＲａｙ上でスケジューリングにマッピングされる）抽象的なＱｏＳの仕組み、（たとえば、ＣＡＮ上でＩＤにマッピング、イーサネット（登録商標）上でＭＡＣ、ＶＬＡＮ、ＡＶＴＰ、またはＩＰｖ４にマッピングされる）抽象的なノードアドレス指定メカニズム、および（たとえば、８０２．１ＡＳに基づいた）統合タイムスタンプ・メカニズムなど、プロトコルを問わない共通の機能セットが利用可能である。これに加えて、プロトコルを変更する（たとえば、ＣＡＮベースの制御ユニットをイーサネット（登録商標）に移植する）ときのソフトウェア保守を簡素化できる。

変更例
以上に説明した実施形態に対して、多くの変更がなされてもよいことがわかるだろう。

制御ユニットは、３つ以上のネットワークインターフェースモジュールを備えてもよい。ネットワークインターフェースモジュールのうちの２つ以上は、たとえば、ＣＡＮコントローラなど、同じ種類のものであってもよい。したがって、制御ユニットは、３つ以上の種類のバスに接続されてもよい。メッセージ・フォワーダは、３つ以上のネットワークインターフェースモジュールに接続されてもよい。したがって、制御ユニットは、同じ種類の３つ以上のバスに接続されてもよい。メッセージ・フォワーダは、３つ以上のネットワークインターフェースモジュールに接続されてもよい。したがって、メッセージ・フォワーダは、３つ以上のメッセージハンドラ間で、共通フォーマットのメッセージをスイッチングまたはルーティングしてもよい。

Claims (29)

1. 所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３_１、１３_２）を受信することに応答して、ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を生成するように構成され、前記ヘッダは、前記パッケージ誘導データに応じて生成されたアドレスを含み、前記ペイロードは、前記データパッケージを含む、メッセージハンドラ（６_１、６_２；２０）。
2. 前記予め定められたデータフォーマットを有するパッケージ（１４）は、レイヤ２またはレイヤ３パッケージである、請求項１に記載のメッセージハンドラ。
3. 前記パッケージ誘導データの第１のフィールドから、前記ヘッダの対応するフィールドにデータをコピーするように構成された、請求項１または２に記載のメッセージハンドラ。
4. 前記ヘッダの第２のフィールドに、予め定められたデータを追加するように構成された、請求項１〜３のうちのいずれか１項に記載のメッセージハンドラ。
5. 前記第１のフィールドおよび／または第２のフィールドのデータに応じて算出されたデータを、前記ヘッダの第２のフィールドに追加するように構成された、請求項１〜４のうちのいずれか１項に記載のメッセージハンドラ。
6. ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３_１、１３_２）を取り出すように構成された、請求項１〜５のうちのいずれか１項に記載のメッセージハンドラ。
7. ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３_１、１３_２）を取り出すように構成された、メッセージハンドラ（６_１、６_２、２０）。
8. 前記予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＥＥＥ １７２２フレームである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
9. 前記予め定められたデータフォーマットを有するパッケージ（１４）は、レイヤ２フレームである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
10. 前記予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＰパケットである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
11. 前記所定の通信プロトコルは、ＩＳＯ １１８９８−１である、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
12. 前記所定の通信プロトコルは、ＣＡＮ−ＦＤ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｆｌｅｘｉｂｌｅ Ｄａｔａ Ｒａｔｅ）プロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
13. 前記所定の通信プロトコルは、ＦｌｅｘＲａｙプロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
14. 前記所定の通信プロトコルは、ＭＯＳＴ（Ｍｅｄｉａ Ｏｒｉｅｎｔｅｄ Ｓｙｓｔｅｍｓ Ｔｒａｎｓｐｏｒｔ）プロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
15. 前記所定の通信プロトコルは、イーサネット（登録商標）ベースのプロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
16. 前記所定の通信プロトコルは、ＥｔｈｅｒＣＡＴ、ＣＣ−Ｌｉｎｋ ＩＥ Ｆｉｅｌｄ、ＰＲＯＦＩＮＥＴ、ＥｔｈｅｒＮｅｔ／ＩＰ、Ｍｏｄｂｕｓ ＴＣＰ、またはＦＬ−ｎｅｔである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
17. ハードウェアで実現され、
    プロトコルエンジン（５_１、５_２）と、
    前記プロトコルエンジンと、所定の通信プロトコルに応じてフォーマットされたデータパッケージ（１３_１、１３_２）をやり取りするように構成された請求項１〜１６のうちのいずれか１項に記載のメッセージハンドラ（６_１、６_２）とを備える、ネットワークインターフェースモジュール（７_１、７_２）。
18. 中央処理装置（１８）と、
    メモリ（１９）と、
    メモリまたは他の記憶装置に格納されたコンピュータプログラムとを備え、前記コンピュータプログラムは、前記中央処理装置によって実行されると、前記中央処理装置に、請求項１〜１６のうちのいずれか１項に記載のメッセージハンドラを実行させる、中央処理装置サブシステム。
19. 第１および第２のそれぞれの通信プロトコルに応じてメッセージを扱うための第１および第２のメッセージハンドラ（６_１、６_２）と、予め定められたデータフォーマットを有するパッケージをやり取りするように構成された、メッセージ・フォワーダ（８）。
20. 第１の通信プロトコルに応じてフォーマットされたデータパッケージ（１３_１、１３_２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第１のメッセージハンドラ（６_１）または請求項１７に記載のネットワークインターフェースモジュール（７_１）と、
    第２の通信プロトコルに応じてフォーマットされたデータパッケージ（１３_１、１３_２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第２のメッセージハンドラ（６_２）または請求項１７に記載のネットワークインターフェースモジュール（７_２）と、
    前記予め定められたデータフォーマットを有するパッケージを、前記第１のメッセージハンドラと第２のメッセージハンドラとの間でやり取りするように構成されたメッセージ・フォワーダ（８）とを備える、制御ユニット（１６）。
21. 前記メッセージ・フォワーダは、レイヤ２スイッチおよび／またはレイヤ３ルータである、請求項２０に記載の制御ユニット。
22. 前記第１の通信プロトコルと前記第２の通信プロトコルは、同じでない、請求項２０または２１に記載の制御ユニット。
23. 第３の通信プロトコルに応じてフォーマットされたデータパッケージ（１３_１、１３_２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第３のメッセージハンドラをさらに備える、請求項２０、２１、または２２に記載の制御ユニット。
24. 中央処理装置サブシステム（１７）をさらに備え、
    前記メッセージ・フォワーダは、前記中央処理装置サブシステムと前記第１のメッセージハンドラとの間、および／または前記中央処理装置サブシステムと第２のメッセージハンドラとの間でやり取りするように構成される、請求項２０〜２３のうちのいずれか１項に記載の制御ユニット。
25. 集積回路である、請求項２０〜２４のうちのいずれか１項に記載の制御ユニット。
26. マイクロコントローラである、請求項２０〜２５のうちのいずれか１項に記載の制御ユニット。
27. 少なくとも２セットのバスライン（３_１、３_２）と、
    前記バスに接続された、少なくとも１つの請求項２０〜２６のうちのいずれか１項に記載の制御ユニット（１６）とを備える、通信システム（３１）。
28. 請求項２７に記載の通信システム（３１）を備える、車両（３２）。
29. 請求項２７に記載の通信システム（３１）を備える、産業用システム（３３）。

Images