(57)【要約】  メッセージハンドラ（６１、６２）を開示する。メッセージハンドラは、ＣＡＮまたはイーサネット（登録商標）など、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２；図４）およびペイロードデータ（２３；図４）を含むデータパッケージ（１３１、１３２）を受信することに応答して、ヘッダ（２４；図４）およびペイロードデータ（２５；図４）を含む、予め定められたデータフォーマットを有するパッケージ（１４）、たとえば、レイヤ２またはレイヤ３パッケージを生成するように構成される。ヘッダは、パッケージ誘導データに応じて生成されたアドレスを含み、ペイロードは、データパッケージを含む。予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＥＥＥ  １７２２フレームであってもよい。
2019506094.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３１、１３２）を受信することに応答して、ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を生成するように構成され、前記ヘッダは、前記パッケージ誘導データに応じて生成されたアドレスを含み、前記ペイロードは、前記データパッケージを含む、メッセージハンドラ（６１、６２；２０）。
【請求項２】
前記予め定められたデータフォーマットを有するパッケージ（１４）は、レイヤ２またはレイヤ３パッケージである、請求項１に記載のメッセージハンドラ。
【請求項３】
前記パッケージ誘導データの第１のフィールドから、前記ヘッダの対応するフィールドにデータをコピーするように構成された、請求項１または２に記載のメッセージハンドラ。
【請求項４】
前記ヘッダの第２のフィールドに、予め定められたデータを追加するように構成された、請求項１〜３のうちのいずれか１項に記載のメッセージハンドラ。
【請求項５】
前記第１のフィールドおよび／または第２のフィールドのデータに応じて算出されたデータを、前記ヘッダの第２のフィールドに追加するように構成された、請求項１〜４のうちのいずれか１項に記載のメッセージハンドラ。
【請求項６】
ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３１、１３２）を取り出すように構成された、請求項１〜５のうちのいずれか１項に記載のメッセージハンドラ。
【請求項７】
ヘッダ（２４）およびペイロードデータ（２５）を含む予め定められたデータフォーマットを有するパッケージ（１４）を受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データ（２２）およびペイロードデータ（２３）を含むデータパッケージ（１３１、１３２）を取り出すように構成された、メッセージハンドラ（６１、６２、２０）。
【請求項８】
前記予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＥＥＥ  １７２２フレームである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
【請求項９】
前記予め定められたデータフォーマットを有するパッケージ（１４）は、レイヤ２フレームである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１０】
前記予め定められたデータフォーマットを有するパッケージ（１４）は、ＩＰパケットである、請求項１〜７のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１１】
前記所定の通信プロトコルは、ＩＳＯ  １１８９８−１である、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１２】
前記所定の通信プロトコルは、ＣＡＮ−ＦＤ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ  Ｒａｔｅ）プロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１３】
前記所定の通信プロトコルは、ＦｌｅｘＲａｙプロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１４】
前記所定の通信プロトコルは、ＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）プロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１５】
前記所定の通信プロトコルは、イーサネット（登録商標）ベースのプロトコルである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１６】
前記所定の通信プロトコルは、ＥｔｈｅｒＣＡＴ、ＣＣ−Ｌｉｎｋ  ＩＥ  Ｆｉｅｌｄ、ＰＲＯＦＩＮＥＴ、ＥｔｈｅｒＮｅｔ／ＩＰ、Ｍｏｄｂｕｓ  ＴＣＰ、またはＦＬ−ｎｅｔである、請求項１〜１０のうちのいずれか１項に記載のメッセージハンドラ。
【請求項１７】
ハードウェアで実現され、
プロトコルエンジン（５１、５２）と、
前記プロトコルエンジンと、所定の通信プロトコルに応じてフォーマットされたデータパッケージ（１３１、１３２）をやり取りするように構成された請求項１〜１６のうちのいずれか１項に記載のメッセージハンドラ（６１、６２）とを備える、ネットワークインターフェースモジュール（７１、７２）。
【請求項１８】
中央処理装置（１８）と、
メモリ（１９）と、
メモリまたは他の記憶装置に格納されたコンピュータプログラムとを備え、前記コンピュータプログラムは、前記中央処理装置によって実行されると、前記中央処理装置に、請求項１〜１６のうちのいずれか１項に記載のメッセージハンドラを実行させる、中央処理装置サブシステム。
【請求項１９】
第１および第２のそれぞれの通信プロトコルに応じてメッセージを扱うための第１および第２のメッセージハンドラ（６１、６２）と、予め定められたデータフォーマットを有するパッケージをやり取りするように構成された、メッセージ・フォワーダ（８）。
【請求項２０】
第１の通信プロトコルに応じてフォーマットされたデータパッケージ（１３１、１３２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第１のメッセージハンドラ（６１）または請求項１７に記載のネットワークインターフェースモジュール（７１）と、
第２の通信プロトコルに応じてフォーマットされたデータパッケージ（１３１、１３２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第２のメッセージハンドラ（６２）または請求項１７に記載のネットワークインターフェースモジュール（７２）と、
前記予め定められたデータフォーマットを有するパッケージを、前記第１のメッセージハンドラと第２のメッセージハンドラとの間でやり取りするように構成されたメッセージ・フォワーダ（８）とを備える、制御ユニット（１６）。
【請求項２１】
前記メッセージ・フォワーダは、レイヤ２スイッチおよび／またはレイヤ３ルータである、請求項２０に記載の制御ユニット。
【請求項２２】
前記第１の通信プロトコルと前記第２の通信プロトコルは、同じでない、請求項２０または２１に記載の制御ユニット。
【請求項２３】
第３の通信プロトコルに応じてフォーマットされたデータパッケージ（１３１、１３２）を扱うように構成された、請求項１〜１６のうちのいずれか１項に記載の第３のメッセージハンドラをさらに備える、請求項２０、２１、または２２に記載の制御ユニット。
【請求項２４】
中央処理装置サブシステム（１７）をさらに備え、
前記メッセージ・フォワーダは、前記中央処理装置サブシステムと前記第１のメッセージハンドラとの間、および／または前記中央処理装置サブシステムと第２のメッセージハンドラとの間でやり取りするように構成される、請求項２０〜２３のうちのいずれか１項に記載の制御ユニット。
【請求項２５】
集積回路である、請求項２０〜２４のうちのいずれか１項に記載の制御ユニット。
【請求項２６】
マイクロコントローラである、請求項２０〜２５のうちのいずれか１項に記載の制御ユニット。
【請求項２７】
少なくとも２セットのバスライン（３１、３２）と、
前記バスに接続された、少なくとも１つの請求項２０〜２６のうちのいずれか１項に記載の制御ユニット（１６）とを備える、通信システム（３１）。
【請求項２８】
請求項２７に記載の通信システム（３１）を備える、車両（３２）。
【請求項２９】
請求項２７に記載の通信システム（３１）を備える、産業用システム（３３）。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、メッセージハンドラ、および、少なくとも２つのメッセージハンドラと、メッセージハンドラ間でデータパッケージをスイッチングまたはルーティングするように構成されたメッセージ・フォワーダとを備える制御ユニットに関する。
【背景技術】
【０００２】
背景
ゲートウェイによって、異なるネットワークインターフェース間の情報やり取りが可能になる。ネットワークインターフェースは、イーサネット（登録商標）、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、ＦｌｅｘＲａｙ、およびＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔａｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）など、同じまたは異なるＯＳＩ物理層（「第１層」）、データリンク（「第２層」）、および／またはネットワーク層（「第３層」）プロトコル（複数可）を使用できる。ゲートウェイには、イーサネット（登録商標）スイッチ、ＤＳＬＡＭ（Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ  Ａｃｃｅｓｓ  Ｍｕｌｔｉｐｌｅｘｅｒ）、およびフィールドバスゲートウェイなどがある。
【０００３】
イーサネット（登録商標）１０／１００／１０００スイッチおよびＣＡＮ／ＣＡＮゲートウェイなど、同じプロトコル内のレイヤ２ゲートウェイは、データ伝送速度は変わり得るが、データリンク層のフレームは同一であるため、単純である傾向がある。ＣＡＮ／ＣＡＮ−ＦＤゲートウェイなど、プロトコルを跨ぐレイヤ２ゲートウェイでは、ネットワーク層上でパケット（または、「パッケージ」）を変更することなく、再フレーミングすることができる。ＩＰｖ４／ＩＰｖ６ゲートウェイまたはＣＡＮ／イーサネット（登録商標）ゲートウェイなど、レイヤ３ゲートウェイは、異なるアドレス指定要件およびトラフィック制御要件に合わせてパケットを再構築できる。ＴＣＰ／ＵＤＰゲートウェイおよびＡＵＴＯＳＡＲ信号ゲートウェイなど、レイヤ４〜７ゲートウェイでは、互いに異なるトランスポートプロトコル間での変更ができ、情報の再アセンブリが可能である。
【０００４】
同じプロトコルまたはプロトコルファミリー内のレイヤ２ゲートウェイは、ハードウェアで実現される傾向があり、このようなゲートウェイには、ルネサスのＲＨ８５０／Ｃ１ＭマイクロコントローラにおけるＣＡＮ／ＣＡＮゲートウェイ、およびルネサスのＲＨ８５０／Ｄ１ＭマイクロコントローラにおけるＣＡＮ／ＣＡＮ−ＦＤゲートウェイなどがある。
【０００５】
図１を参照すると、レイヤ３ゲートウェイは、ソフトウェアで実現されることが多い。マイクロコントローラは、ネットワークインターフェースのセットと、構成マトリックスに基づいてパケットを再アセンブリできるマイクロコントローラの中央処理装置によって実行されるソフトウェアとを有する。このようなゲートウェイには、ＵＳＢ／ＵＡＲＴコンバータ、および自動車関係のＣＡＮ／ＬＩＮ／ＦｌｅｘＲａｙゲートウェイなどがある。通信プロトコルがそれぞれ異なるアドレス指定方式、異なるメッセージ構造を有するので、ソフトウェアが、異なるプロトコル間で変換できる柔軟性を提供する。
【０００６】
レイヤ４〜７ゲートウェイは、一般に、ソフトウェアで実現される。上位層においてデータを再アセンブリするには、かなりのコンフィギュアビリティおよび柔軟性が必要になる傾向があり、これは、たとえば、映像データなど、スピードが重視される変換に固有な場合において、ハードウェアベースのソリューションは可能ではあるが、ソフトウェアベースの実装を利用することでしか実際のところ実現できない。
【０００７】
ネットワーク層のパッケージのフレーミングは、通常、ハードウェアで実施され、ルーティング・メカニズムには見えないようになっている。パケットフレーミングが生じる例に、イーサネット（登録商標）ＭＡＣ、ＦｌｅｘＲａｙ通信コントローラ、およびＣＡＮプロトコルエンジンなどがある。すべてのプロトコルは、上位層と情報をやり取りするために、個々の最適化されたインターフェースを有する傾向がある。
【０００８】
また、同じプロトコルファミリー内のレイヤ３ゲートウェイも、ハードウェアで実現することが容易である傾向がある。たとえば、ＣＡＮ／ＣＡＮ−ＦＤ変換およびＩＰｖ４／ＩＰｖ６変換を伴う状況では、パケット構造の最低限の変更しか必要としない。
【０００９】
それぞれ異なるプロトコルを要するレイヤ３ゲートウェイは、異なるアドレス指定、ルーティング方式、およびトラフィック制御方式に適応できるように、パケットを再フォーマットする必要があるので、ハードウェアで実現することが難しい傾向にある。パケット変換は、一般に、柔軟性のある、構成可能なデータ操作装置を必要とする。これによって、情報の欠落が生じてしまう。イーサネット（登録商標）の長さをＣＡＮ  ＤＬＣに変換する場合など、すべてのフレーム情報が変換可能であるわけではないためである。
【００１０】
アドレス指定方式の変換は、両方のネットワーク層の間に構成可能変換テーブルを必要とする。トラフィック制御方式の変換は、通常、新しいレイヤ４トランスポートプロトコル、または他の上位層によるサポートを必要とする。
【００１１】
ますます、通信システムは、互いに接続された２種類以上のバスシステムを備えるようになっている。これによって、データの転送がより複雑になっている。
【００１２】
米国第２０１４／０１３３３５０Ａ１号では、第１および第２の通信プロトコルにそれぞれ応じてデータ伝送をサポートする第１および第２のサブネットワークを含む少なくとも２つのサブネットワークを接続するためのゲートウェイモジュールが開示されている。ゲートウェイモジュールは、第１および第２の通信プロトコルを考慮しつつ、データを操作して第１サブネットワークから第２サブネットワークに転送するようになされた構成可能ハードウェア回路を有する。しかしながら、通信プロトコルの数および種類が増えると、この種類のゲートウェイは、ますます複雑になるまたはハードウェア変更を必要とする。したがって、新しい通信インターフェースが導入されると、新しいインターフェースモジュールを追加しなければならないだけではなく、ゲートウェイモジュールも変更が必要になる場合がある。
【発明の概要】
【課題を解決するための手段】
【００１３】
概要
本発明の第１の態様によれば、メッセージハンドラが提供される。メッセージハンドラは、所定の通信プロトコルに応じてフォーマットされた、パッケージ誘導データおよびペイロードデータを含むデータパッケージ受信することに応答して、たとえば、レイヤ２またはレイヤ３パッケージなど、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを生成するように構成される。ヘッダは、パッケージ誘導データに応じて生成されたアドレスを含み、ペイロードは、パッケージを含む。
【００１４】
したがって、通信プロトコルごとに異なるメッセージハンドラを制御ユニットに設けることができ、共通のデータフォーマットを有するパッケージを生成するために使用できる。これは、２つ以上の通信バスとホストプロセッサとの間のデータのやり取りを容易にすることに役立ち、バス間でデータをやり取りするためにハードウェアベースのスイッチまたはルータを使用することを可能にする。したがって、使用中の固有の通信プロトコルが同じプロトコルであるか異なるプロトコルであるかに関係なく、同じルーティング・メカニズムを使用できる。
【００１５】
着信データパッケージは、巡回冗長検査データを含まなくてもよい。着信データパッケージは、タイムスタンプを含んでもよい。
【００１６】
パッケージ誘導データは、メッセージ識別情報あるいはメッセージコンテンツ識別子（マルチキャストの宛先を特定するために使用できる）、または宛先ノードアドレスを含んでもよい。アドレスは、ストリーム識別子であってもよい。
【００１７】
メッセージハンドラは、パッケージ誘導データの第１のフィールドから、ヘッダの対応するフィールドにデータをコピーするように構成されてもよい。メッセージハンドラは、ヘッダの第２のフィールドに、予め定められたデータを追加するように構成されてもよい。予め定められたデータは、ホストプロセッサによって供給されてもよい。メッセージハンドラは、第１のフィールドおよび／または第２のフィールドのデータに応じて算出されたデータを、ヘッダの第２のフィールドに追加するように構成されてもよい。
【００１８】
メッセージハンドラは、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データおよびペイロードデータを含むデータパッケージを取り出すように構成されてもよい。
【００１９】
本発明の第２の態様によれば、ヘッダおよびペイロードデータを含む予め定められたデータフォーマットを有するパッケージを受信することに応答して、所定の通信プロトコルに応じてフォーマットされ、パッケージ誘導データおよびペイロードデータを含むデータパッケージを取り出すように構成されたメッセージハンドラが提供される。
【００２０】
予め定められたデータフォーマットを有するパッケージは、ＩＥＥＥ  １７２２フレームであってもよい。予め定められたデータフォーマットは、ＩＥＥＥ  １７２２に準拠してもよい。予め定められたデータフォーマットを有するパッケージは、ＡＶＴＰ制御メッセージであってもよい。アドレスは、ストリームＩＤであってもよい。予め定められたデータフォーマットを有するパッケージは、レイヤ２フレームであってもよい。予め定められたデータフォーマットを有するパッケージは、ＩＰパケット、たとえば、ＩＰｖ４またはＩＰｖ６パケットであってもよい。
【００２１】
所定の通信プロトコルは、ＩＳＯ  １１８９８−１（または、「ＣＡＮ２．０」）であってもよい。所定の通信プロトコルは、ＣＡＮ−ＦＤ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ  Ｆｌｅｘｉｂｌｅ  Ｄａｔａ  ｒａｔｅ  ｐｒｏｔｏｃｏｌ）プロトコルであってもよい。所定の通信プロトコルは、ＦｌｅｘＲａｙプロトコルであってもよい。所定の通信プロトコルは、ＩＥＥＥ  ８０２．３（つまり、イーサネット（登録商標））であってもよい。所定の通信プロトコルは、ＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）プロトコルであってもよい。所定の通信プロトコルは、イーサネット（登録商標）ベースのプロトコルであってもよい。所定の通信プロトコルは、ＥｔｈｅｒＣＡＴ、ＣＣ−Ｌｉｎｋ  ＩＥ  Ｆｉｅｌｄ、ＰＲＯＦＩＮＥＴ、ＥｔｈｅｒＮｅｔ（登録商標）／ＩＰ、Ｍｏｄｂｕｓ  ＴＣＰ、またはＦＬ−ｎｅｔであってもよい。
【００２２】
本発明の第３の態様によれば、ハードウェアで実現され、プロトコルエンジンとメッセージハンドラとを含み、プロトコルエンジンと、所定の通信プロトコルに応じてフォーマットされたデータパッケージをやり取りするように構成されたネットワークインターフェースモジュールが提供される。
【００２３】
本発明の第４の態様によれば、中央処理装置と、メモリと、メモリまたは他の記憶装置に格納されたコンピュータプログラムとを備え、コンピュータプログラムは、中央処理装置によって実行されると、中央処理装置に、メッセージハンドラを実行させる、中央処理装置サブシステムが提供される。
【００２４】
本発明の第５の態様によれば、第１および第２の通信プロトコルに応じてそれぞれメッセージを扱うための第１および第２のメッセージハンドラと、予め定められたデータフォーマットを有するパッケージをやり取りするように構成されたメッセージ・フォワーダが提供される。メッセージ・フォワーダは、レイヤ２スイッチおよび／またはレイヤ３ルータであってもよい。
【００２５】
本発明の第６の態様によれば、第１の通信プロトコルに応じてフォーマットされたデータパッケージを扱うように構成された第１のメッセージハンドラまたはネットワークインターフェースモジュールと、第２の通信プロトコルに応じてフォーマットされたデータパッケージを扱うように構成された第２のメッセージハンドラまたはネットワークインターフェースモジュールと、予め定められたデータフォーマットを有するパッケージを第１のメッセージハンドラと第２のメッセージハンドラとの間でやり取りするように構成されたメッセージ・フォワーダとを備える制御ユニットが提供される。メッセージ・フォワーダは、レイヤ２スイッチまたはレイヤ３ルータであってもよい。
【００２６】
第１および第２の通信プロトコルは、互いに異なってもよい。第１および第２の通信プロトコルは、同じであってもよい。
【００２７】
制御ユニットは、第３の通信プロトコル（第１の通信プロトコルおよび／または第２の通信プロトコルと同じであっても異なってもよい）に応じてフォーマットされたデータパッケージを扱うように構成された第３のメッセージをさらに備えてもよい。
【００２８】
制御ユニットは、中央処理装置システムをさらに備えてもよく、メッセージ・フォワーダは、中央処理装置サブシステムと第１および／または第２のメッセージハンドラとの間でやり取りするように構成される。
【００２９】
制御ユニットは、マイクロコントローラまたはＳｏＣ（ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）など、集積回路であってもよい。
【００３０】
本発明の第７の態様によれば、少なくとも２セットのバスラインと、バスに接続された、本発明の第２の態様に係る少なくとも１つの制御ユニット（複数可）とを備える通信システムが提供される。バスは、異なる種類のバス（ＣＡＮ、ＣＡＮ−ＦＤ、およびイーサネット（登録商標）など）を含んでもよい。
【００３１】
本発明の第８の態様によれば、通信システムを備える車両が提供される。
車両は、自動車であってもよい。自動車は、オートバイ、乗用車（「車」と称する場合もある）、ミニバス、バス、トラック、または大型トラックであってもよい。自動車は、内燃機関および／または１つ以上の電動機によって電源が供給されてもよい。車両は、機関車、客車、または複数のユニットなど、電車または電車の一部であってもよい。
【００３２】
車両は、航空機であってもよい。通信システムは、ＡＦＤＸ（Ａｖｉｏｎｉｃｓ  Ｆｕｌｌ−Ｄｕｐｌｅｘ  Ｓｗｉｔｃｈｅｄ  Ｅｔｈｅｒｎｅｔ）システムであってもよい。
【００３３】
本発明の第９の態様によれば、通信システムを備える、プラントまたは機械などの産業用システムが提供される。プラントまたは機械は、製造または加工の際に使用するための産業用システムを備えてもよい。
【００３４】
本発明の第１０の態様によれば、通信システムを備える医療システムが提供される。
添付の図面のうちの図２〜図８を参照して、例として、本発明のいくつかの実施形態をここに説明する。
【図面の簡単な説明】
【００３５】
【図１】ソフトウェアにおいてバス間でデータをやり取りできる通信システムの概略ブロック図である。
【図２】ハードウェアにおいてバス間でデータをやり取りできる通信システムの概略ブロック図である。
【図３】制御ユニットの概略ブロック図である。
【図４】通信プロトコルに依存したパッケージの、共通フォーマットのパッケージへの変換を示す図である。
【図５】共通フォーマットのパッケージの、通信プロトコルに依存したパッケージへの変換を示す図である。
【図６】ＣＡＮ依存のパッケージを含むＣＡＮフレームを示す図である。
【図７】ＡＶＴＰの共通メッセージを示す図である。
【図８】車両通信ネットワークおよび車両の概略図である。
【図９】産業用通信ネットワークおよびロボットの概略図である。
【発明を実施するための形態】
【００３６】
いくつかの実施形態の詳細な説明
通信システム１
図２は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）およびイーサネット（登録商標）など、第１および第２の通信プロトコルの最下位のプロトコル層を実現するための、第１および第２セットのバスライン３１、３２に接続された第１および第２のセクション２１、２２を含む通信システム１を示す。
【００３７】
第１セクション２１は、物理層モジュール４１と、プロトコルエンジンモジュール５１と、メッセージハンドラ６１とを含む。プロトコルエンジンモジュール５１およびメッセージハンドラ６１は、ネットワークインターフェースモジュール７１（図３）内に、ハードウェアで実現される。
【００３８】
第２セクション２２は、物理層モジュール４２と、プロトコルエンジンモジュール５２と、メッセージハンドラ６２とを含む。プロトコルエンジンモジュール５２およびメッセージハンドラ６２は、ネットワークインターフェースモジュール７２（図３）内に、ハードウェアで実現される。
【００３９】
メッセージハンドラ６１、６２は、レイヤ２スイッチまたはレイヤ３ルータの形を取り得るパッケージまたはメッセージ・フォワーダ８によって、互いに接続される。メッセージ・フォワーダ８は、適切なハードウェア論理、ハードウェアレジスタなどを備えるハードウェアで実現されることが好ましい。メッセージ・フォワーダ８は、いずれのプロトコル変換も行わない。また、メッセージ・フォワーダ８は、統合（ｕｎｉｆｉｅｄ）ネットワークスタック９を介して、上位層１０に接続される。統合ネットワークスタック９および上位層１０は、ソフトウェアで実現される。
【００４０】
物理層モジュール４１、４２は、着信フレーム１２１、１２２をプロトコルエンジン５１、５２に渡す。プロトコルエンジン５１、５２は、フレームチェックシーケンス（ＦＣＳ：Ｆｒａｍｅ  Ｃｈｅｃｋ  Ｓｅｑｕｅｎｃｅ）などのフレームコンポーネントを除去し、パッケージ１３１、１３２を生成することができる。プロトコルエンジン５１、５２は、タイムスタンプなどの情報をパッケージ１３１、１３２に追加してもよい。
【００４１】
プロトコルエンジン５１、５２は、パッケージ１３１、１３２をメッセージハンドラ６１、６２に渡す。メッセージハンドラ６１、６２は、共通フォーマットのパッケージ１４を生成する。詳細は後述するが、メッセージハンドラ６１、６２は、共通フォーマットのパッケージ１４を別のメッセージハンドラ６１、６２および／または統合ネットワークスタック９にスイッチングまたはルーティングするためのメッセージ・フォワーダ８に、共通フォーマットのパッケージ１４を渡すことができる。したがって、パッケージは、メッセージハンドラ６１、６２間だけではなく、上位層１０にも転送され得る。
【００４２】
３つ以上のメッセージハンドラ６１、６２がある場合、メッセージ・フォワーダ８は、２つ以上のメッセージハンドラ６１、６２および、必要であれば、上位層１０に、パッケージをスイッチングまたはルーティングできる。メッセージ・フォワーダ８は、メッセージをユニキャストまたはマルチキャストしてもよい。
【００４３】
また、図３を参照すると、物理層モジュール４１、４２は、ＰＨＹトランシーバ４１、４２の形を取る。プロトコル層５１、５２、メッセージハンドラ６１、６２、メッセージ・フォワーダ８、統合スタック９、および上位層１０は、マイクロコントローラまたはＳｏＣ（ｓｙｓｔｅｍ−ｏｎ−ａ−ｃｈｉｐ）の形で、制御ユニット１６において実装される。制御ユニット１６は、プロトコルエンジン５１、５２およびメッセージハンドラ６１、６２を提供するネットワークインターフェースモジュール７１、７２（または、「通信コントローラ」）を備える。制御ユニット１６は、少なくとも１つの中央処理装置（ＣＰＵ）１８と、メモリ１９と、オンチップインターコネクト（図示せず）とを含む中央処理装置サブシステム１７を備える。また、物理層モジュール４１、４２は、マイクロコントローラまたはＳｏＣにおいて実装することもできる。
【００４４】
ＣＰＵ１８は、ネットワークインターフェースモジュール７１、７２およびメッセージ・フォワーダ８を設定できる。また、ＣＰＵ１８は、フレームをより直接読み出し、書き込み、および処理できるように、メッセージ・フォワーダ８をバイパスしてメッセージハンドラ６１、６２にアクセスすることも可能である。したがって、すべてのフレームに対してメッセージ転送メカニズムを用いる必要はない。たとえば、メッセージ転送は、特定の、予め定められた種類のフレームに対して自動的にフレームをルーティングするために使用できる。メッセージ・フォワーダ８をバイパスできるにもかかわらず、ＣＰＵ１８は、ＣＡＮなどの固有の媒体フォーマットのデータを扱えるのに、それでもなお、共通のフォーマットを使用し得る。
【００４５】
ＣＰＵ１８は、ソフトウェアベースのメッセージハンドラ２０を実行してもよい。これによって、ＣＰＵ１８は、共通フォーマットのメッセージ１４を作成できるようになり、共通フォーマットのメッセージ１４は、その後、１つ以上のメッセージハンドラ６１、６２に直接またはメッセージ・ルータ８を介して送られ得る。
【００４６】
メッセージハンドラ６１、６２
先に述べたように、メッセージハンドラ６１、６２は、ＣＡＮプロトコルエンジンなど、それぞれのプロトコルエンジン５１、５２からデータパッケージ１３１、１３２を受信し、共通フォーマットのパッケージ１４を生成する。
【００４７】
また、図４を参照すると、各データパッケージ１３１、１３２は、プロトコル依存のアドレス２２と、ペイロード２３とを含む。
【００４８】
アドレス２２のフォーマット、およびどのようにアドレス２２が使用されるのかは、通信プロトコルによって異なる。たとえば、イーサネット（登録商標）は、パケットをユニキャストまたはマルチキャストするために、４８ビットのＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスを用いて宛先ノードを特定できる。ＣＡＮは、メッセージをマルチキャストするために、１１ビットまたは２９ビットのメッセージ識別子を用いてメッセージコンテンツを特定できる。ＦｌｅｘＲａｙは、メッセージをマルチキャストするために、一時的なリレーションを用いてメッセージコンテンツを特定する。
【００４９】
優先制御は、アドレスやペイロード２３に含める、または、ほかの方法で信号で送ることができる。たとえば、イーサネット（登録商標）では、優先情報は、ペイロードに含まれるのに対して、ＣＡＮでは、メッセージ優先順位は、メッセージ識別情報に含まれる。ＦｌｅｘＲａｙでは、メッセージ優先順位は、既定の周期での繰り返しに基づく。
【００５０】
メッセージハンドラ６１、６２は、プロトコル依存のアドレス２２をデータパッケージ１３１、１３２から取り出し、共通フォーマットのヘッダ２４およびペイロード２５を作成する。共通フォーマットのヘッダ２４は、共通フォーマットのアドレス２６を含む。
【００５１】
メッセージハンドラ６１、６２は、プロトコル依存のアドレス２２を、共通フォーマットのアドレス２６にマッピングする。アドレスとメッセージ識別情報とは、別のフィールドに分割されることが好ましい。これは、共通フォーマットのパッケージ１４のルーティングを簡素化するのに役立ち得る。メッセージハンドラ６１、６２は、プロトコルエンジン５１、５２から受信したデータパッケージ１３１、１３２を、共通フォーマットのメッセージ１４のペイロード２５にカプセル化する。したがって、共通フォーマットのメッセージ１４は、ＣＡＮメッセージＩＤおよび共通フォーマットのアドレスなど、すべてのサポートされたデータリンク層についての情報を運ぶことができる。すべてのフィールド（ＣＡＮのボーレートのビットなど）のトンネリングができないレイヤ２またはレイヤ３プロトコルを共通フォーマットのメッセージ１４が使用し、それによって情報が欠落してしまう場合、メッセージハンドラ６１、６２は、欠落した情報を埋めるように構成されてもよく、たとえば、ＣＰＵ１８上で実行中のソフトウェアによって設定されてもよい。
【００５２】
また、図５を参照すると、メッセージハンドラ６１、６２は、メッセージ・フォワーダ１０から共通フォーマットのパッケージ１４を受信すると、ペイロード２５からヘッダ２６を破棄し、データパッケージ１３１、１３２を抽出する。次に、メッセージハンドラ７１、７２は、パッケージ１３１、１３２を、プロトコルエンジン５１、５２に転送する。
【００５３】
先に説明したように、メッセージ・フォワーダ８は、共通フォーマットのパッケージ１４を、２つ以上の対象に転送してもよい。１つ以上の対象は、２つ以上のメッセージハンドラ６１、６２を含んでもよい。１つ以上の対象は、ＣＰＵ１８を含んでもよい。
【００５４】
共通フォーマットのパッケージ１４によって、制御ユニット１６（図３）の外部の対象ノード（図示せず）、またはＣＰＵ１８上で実行中の対象サービス（図示せず）の特定を可能にする共通のアドレス指定形式がもたらされる。また、共通のアドレス指定形式は、サービス品質（ＱｏＳ）レベルも提供することが好ましい。共通のアドレス指定形式は、スイッチングまたはルーティングを行えるようにする最小セットの情報を提供する。
【００５５】
共通フォーマットのパッケージ１４は、イーサネット（登録商標）、ＣＡＮ、またはＦｌｅｘＲａｙなどの通信プロトコルが、そのプロトコル固有のメッセージフォーマットにそのメッセージをマッピングし戻せるコンテナを提供する。
【００５６】
共通フォーマットのパッケージ１４は、任意の適した種類のレイヤ２またはレイヤ３データコンテナであり得る。共通フォーマットのパッケージ１４は、６４ビットのストリームＩＤを共通フォーマットのアドレス２６として使用し、優先レベルを信号で送るためにＩＥＥＥ  ８０２．１Ｑに準じた８レベルのＱｏＳを使用する、ＩＥＥＥ  １７２２に準じて定義されたＡＣＦ（ＡＶＴＰ  （Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）  Ｃｏｎｔｒｏｌ  Ｆｏｒｍａｔ）メッセージの形を取ることが好ましい。これによって、レイヤ２イーサネット（登録商標）スイッチをメッセージ・フォワーダ８として使用できるようになる。
【００５７】
ストリームＩＤを共通フォーマットのアドレスとして使用するＡＣＦメッセージ使用する必要はない。（たとえば、ＩＰｖ４またはＩＰｖ６に基づく）ＩＰアドレスを共通フォーマットのアドレスとして使用するレイヤ３データグラム（つまり「ＩＰパケット」、または、単に、「パケット」）または、ＭＡＣアドレスを共通フォーマットのアドレスとして使用するレイヤ２データグラム（つまり、「フレーム」）など、他の種類のデータコンテナを使用できる。
【００５８】
図６は、プロトコルエンジン５１からメッセージハンドラ６１に渡される、ＣＡＮデータフレームから取り出されたデータパッケージ１３１を示す図である。
【００５９】
図７は、図６に示すデータパッケージ１３１がどのように共通フォーマットのパッケージ１４に変換されるかを示す図である。
【００６０】
図６に示すように、ＲＴＲ、ＩＤＥ、およびＤＡＴＡ（つまり、ペイロードデータ）など、フィールドのうちのいくつかにおけるデータは、データパッケージ１３１からデータをコピーすることによって取得される。データは、ＡＦＬ（Ａｃｃｅｐｔａｎｃｅ  Ｆｉｌｔｅｒ  Ｌｉｓｔ）またはルックアップテーブルに基づき得る既定の方式に応じて、他のフィールドに追加される。データは、データパッケージ１３１のフィールドで見つかったデータに応じて、他のフィールドに追加される。メッセージハンドラ６１は、ハードウェアで実現されるが、ＣＰＵ１８によって設定できる。
【００６１】
ＩＥＥＥ  １７２２メッセージが、通常、イーサネット（登録商標）パッケージにカプセル化されるので、ＩＥＥＥ  ８０２．１ヘッダおよび８０２．１Ｑヘッダは、必要ではないが、有用である。
【００６２】
図８を参照すると、車両通信ネットワーク３１が示される。ネットワーク３１は、ＣＡＮおよびイーサネット（登録商標）などの複数の異なるバス３１、３２、３３を含む。ネットワークは、複数の制御ユニット３２を含み、複数の制御ユニット３２は、バス３１、３２、３３に接続されたマイクロコントローラの形を取り得る。制御ユニット３２のうちの少なくともいくつかは、ネットワークインターフェースモジュール７１、７２（図３）とメッセージ・フォワーダ８とを備える制御ユニット１６である。車両通信ネットワーク３１は、車両３３に導入される。
【００６３】
図９を参照すると、産業用通信ネットワーク４１が示されている。ネットワーク４１は、ＣＡＮおよびイーサネット（登録商標）などの複数の異なるバス３１、３２、３３を含む。ネットワークは、バス３１、３２、３３に接続されたマイクロコントローラの形を取り得る複数の制御ユニット４２を含む。制御ユニット４２のうちの少なくともいくつかは、ネットワークインターフェースモジュール７１、７２（図３）と、メッセージ・フォワーダ８とを備える制御ユニット１６である。産業用通信ネットワーク４１は、製造または加工システムなど、プラント、機械、またはシステム４３に導入される。
【００６４】
メッセージハンドラ６１、６２は、１つ以上の利益を有し得る。
メッセージハンドラ６１、６２は、バスの種類、および、メッセージが通信バス上に到着したか、またはＣＰＵによって生成されたかに関係なく、メッセージが転送される方法を一様にするのに役立ち得る。メッセージを複数の対象に転送できるなど、構成可能な柔軟性も提供できる。
【００６５】
さらに、共通のネットワークスタックの使用によって、新しいプロトコルを追加するときのレイヤ３ソフトウェアスタックの適合度が下げられる。また、（たとえば、ＣＡＮ上でＩＤにマッピング、イーサネット（登録商標）上で８０２．１Ｑ  ＰＣＰにマッピングおよび、ＦｌｅｘＲａｙ上でスケジューリングにマッピングされる）抽象的なＱｏＳの仕組み、（たとえば、ＣＡＮ上でＩＤにマッピング、イーサネット（登録商標）上でＭＡＣ、ＶＬＡＮ、ＡＶＴＰ、またはＩＰｖ４にマッピングされる）抽象的なノードアドレス指定メカニズム、および（たとえば、８０２．１ＡＳに基づいた）統合タイムスタンプ・メカニズムなど、プロトコルを問わない共通の機能セットが利用可能である。これに加えて、プロトコルを変更する（たとえば、ＣＡＮベースの制御ユニットをイーサネット（登録商標）に移植する）ときのソフトウェア保守を簡素化できる。
【００６６】
変更例
以上に説明した実施形態に対して、多くの変更がなされてもよいことがわかるだろう。
【００６７】
制御ユニットは、３つ以上のネットワークインターフェースモジュールを備えてもよい。ネットワークインターフェースモジュールのうちの２つ以上は、たとえば、ＣＡＮコントローラなど、同じ種類のものであってもよい。したがって、制御ユニットは、３つ以上の種類のバスに接続されてもよい。メッセージ・フォワーダは、３つ以上のネットワークインターフェースモジュールに接続されてもよい。したがって、制御ユニットは、同じ種類の３つ以上のバスに接続されてもよい。メッセージ・フォワーダは、３つ以上のネットワークインターフェースモジュールに接続されてもよい。したがって、メッセージ・フォワーダは、３つ以上のメッセージハンドラ間で、共通フォーマットのメッセージをスイッチングまたはルーティングしてもよい。
【図１】
2019506094.tif 000003
【図２】
2019506094.tif 000004
【図３】
2019506094.tif 000005
【図４】
2019506094.tif 000006
【図５】
2019506094.tif 000007
【図６】
2019506094.tif 000008
【図７】
2019506094.tif 000009
【図８】
2019506094.tif 000010
【図９】
2019506094.tif 000011
【国際調査報告】
2019506094.tif 000012
2019506094.tif 000013
2019506094.tif 000014
2019506094.tif 000015
2019506094.tif 000016