JP5607823B2 - メッセージの処理方法 - Google Patents

Description

本発明は、メッセージを処理する方法及び構成に関する。

例えばＬＡＮのようなケーブルで接続されたネットワーク内でデータパケットを伝送するために、特に、所謂イーサネット技術が利用される。イーサネットは、データ処理のための複数の構成を備えることが可能なデータ処理のためのネットワークである。その際に使用される制御モジュール又はイーサネットコントローラは、通常、データパケットを介して様々な情報を受信し、処理装置のソフトウェアドライバへと転送するよう構成される。ソフトウェアドライバは、メッセージを評価して、イーサネットコントローラの受信メモリから他の内部メモリへと複写するよう構成される。この行程は多くの演算を必要とし、不必要に長い処理時間をもたらす。

これに対して、例えばＣＡＮ又はＦｌｅｘＲａｙのような通常使用されるフィールドバスシステムのための、メッセージメモリを有する通信コントローラが車両内で利用される。このメッセージメモリ内の各メモリ位置は、例えばエンジン回転数又は車両速度のような車両の駆動パラメータを特に含みうる特別なメッセージの処理のために役立つ。その際に、メッセージの事前解析と、既にハードウェア内での自動格納とが行われる。ソフトウェアは、必要な場合には常に、最後に受信されたデータにアクセスすることが可能である。その際に、古いメッセージが現在のメッセージによって上書きされる。

このような背景から、独立請求項に記載の特徴を備えた方法及び構成が提示される。本発明の更なる別の実施形態は、従属請求項及び明細書の記載から明らかとなろう。

本発明の枠組みにおいて設けられるイーサネットコントローラ、即ち、イーサネット技術によりデータパケットが伝送されるネットワークの制御装置又は制御モジュールは、メッセージメモリを備える。従って、このイーサネットコントローラは、典型的に、メッセージ設定が固定の閉じたネットワーク内での利用に適している。

イーサネット制御装置とも呼ばれるイーサネットコントローラは、データパケットとしてのメッセージを受信し、当該メッセージを、予めメッセージメモリ内で定められた特定の属性について検査する。特定の又は関連する属性が、受信されたメッセージに該当する場合には、この受信されたメッセージは、メッセージメモリ内の対応する箇所に格納される。その際に、特定の内容を有するメッセージのために、当該メッセージのための特定の箇所又はメモリ位置であって、当該メッセージのために予約され当該メッセージが格納される上記メモリ位置を設けることが可能である。メモリ位置に対するメッセージの割り当ては、特に、どの少なくとも１つの駆動パラメータをメッセージが含むのかに依存する。対応して、少なくとも１つの特定の駆動パラメータのために予約されたメモリ位置には、当該少なくとも１つの駆動パラメータを有するメッセージのみが格納される。

通常使用されるソフトウェアは、常に、もっぱら最後に受信されたメッセージに対してアクセスすることが可能である。その際に、現在のメッセージが、古いメッセージを自動的に上書きする。駆動パラメータとして、例えば車両速度が考慮されうる。

本発明の実施形態において、メッセージは少なくとも１つの駆動パラメータを有し、この少なくとも１つの駆動パラメータによって、当該メッセージの少なくとも１つの属性が設定される。通常では、車両の駆動パラメータは特定の値を有する。駆動パラメータの値は、通常では車両の駆動中に変化する。

本発明の更なる別の構成において、少なくとも１つの駆動パラメータを介してその少なくとも１つの属性が定められる第１のメッセージは、当該少なくとも１つの駆動パラメータの第１の値を有する。第１のメッセージの場合と同一の少なくとも１つの駆動パラメータを介してその少なくとも１つの属性が定められる第２のメッセージは、当該少なくとも１つの駆動パラメータの第２の値を有する。更新工程の際に、より古い第１のメッセージが、より新しい第２のメッセージによって置換されることが構想される。従って、メッセージメモリ内で、少なくとも１つの駆動パラメータの値の変更が行われる。

ソフトウェア側の制御装置によってメッセージが送信されることが構想される場合には、メッセージは、メッセージメモリ内の適切な箇所に対してアドレス指定され、送信が開始される。

この開始は、通常、通信コントローラの送信レジスタ内の対応する書込み工程によって行われる。発展形態において、各修正後に直ぐに、従って、例えばメッセージの更新の後直ぐにも、当該メッセージの送信が開始されうる。この機能は間接的に、互いに通信する２つ以上の通信コントローラ上でのメッセージのミラーリングに匹敵する。

プロセッサが、第１のメッセージから第２のメッセージが生じるように、メッセージ、即ちメッセージの内容を変更する場合に、この第２のメッセージは自動的に送信され、メモリメッセージ内の他の全てのメモリ位置が対応して更新されうる。メッセージメモリ内での整合性を保障するために、通信コントローラは通常入出力バッファを有し、この入出力バッファを用いてメッセージが要求され、通信コントローラにより提供される。しかしながら、イーサネットコントローラのメッセージメモリを、直接的にプロセッサのアドレス空間に設置することも構想可能であり、従って直接的なアクセスが可能となる。従って、メモリオーバーレイ（メモリマッピング）が実行されうる。

イーサネットコントローラ自身がメッセージを評価し対応して格納するため、本方法によって、ソフトウェアの著しい負荷軽減が達成される。従来技術の方法では、ソフトウェアは、このメッセージを最初にプロトコルスタックにおいて評価し、従って、ＯＳＩモデルの複数層を評価し、最終的に対応する箇所にメッセージを複写する必要がある。従って、本発明に係る方法の一実施形態では、メッセージの滞留時間又は遅延時間が短縮されうる。さらに、イーサネットコントローラの中央演算ユニット（ＣＰＵ）は負荷が軽減され、他のタスクのために利用されうる。

本発明に係る構成は、提示される方法の全ステップを実行するよう構成される。その際に、本方法の個々のステップは、本構成の個々の構成要素によっても実行されうる。さらに、本構成の機能又は本構成の個々の構成要素の機能は、本方法のステップとして実施されうる。さらに、本方法のステップが、本構成の少なくとも１つの構成要素の機能又は構成全体の機能として実現されうる。

本発明の更なる別の利点及び実施形態は、明細書の記載及び添付の図面から明らかとなろう。

先に挙げた特徴、及び、以下で解説された特徴は、各示される組み合わせのみならず他の組み合わせにおいても、又は、単独でも、本方法の枠組みを逸脱することなく、利用されうる。

従来技術で公知のイーサネットコントローラの概略図を示す。 所謂ＴＣＰ／ＩＰスタックのブロック図を概略的に示す。 通常車両で使用される従来技術で公知の通信コントローラの一例を概略的に示す。 本発明に係るイーサネットコントローラの一実施形態で使用されうようなメッセージメモリの概略図を示す。 イーサネットフレームの一例を概略的に示す。 ＩＰＶ４フレーム、従って、例えばインタネットプロトコルバージョン４で使用されるようなデータパケットのフレームの構造を概略的に示す。 ＩＰＶ６フレーム、又は、例えばインタネットプロトコルバージョン６で使用されるようなデータパケットのフレームの構造を概略的に示す。 ＴＣＰフレームの一例を概略的に示す。 ＵＤＰフレームの一例を概略的に示す。 本発明に係る構成の一実施形態の概略図を示す。

本発明は、実施形態を用いて図面に概略的に示され、以下では、図を参照して詳細に記載される。

図面は、互いに関連して包括的に記載され、同一の符号は同一の構成要素を示す。

図１に概略的に示される従来のイーサネットコントローラ２は、ホストインタフェース４と、データバンクプロバイダへのインタフェースと、８ｋＢのユーザフラッシュ６又はデジタルメモリチップと、メッセージを送信する２ｋＢのＴｘバッファ８又はバッファメモリと、メッセージを受信する４ｋＢのＲｘＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ、先入れ先出し）バッファと、ここでは２ＭＨｚの周波数により駆動されるクロック１２と、媒体アドレスへのアクセスを制御するイーサネットＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、メディアアクセスコントロール）１４と、制御表示１６（ＬＥＤ制御）と、物理層１８（イーサネットＰＨＹ）と、を含む。

イーサネットコントローラ２のインタフェース４は、並列のバス接続を介して、データプロバイダ（ホスト）のマイクロコントローラ２２（ＭＣＵ）と接続される。図１はさらに、チップ２６（ＲＪ−４５）を有するモジュール２４と、ＬＩＮＫ ＬＥＤ及びＡＣＴ ＬＥＤのための導線３２、３３を介して制御表示１６と接続されたＡＣＴ ＬＥＤとして構成された発光ダイオード２８及びＬｉｎｋ ＬＥＤとして構成された発光ダイオード３０と、を示している。さらに、物理層１８が、送信経路３４を介してモジュール２４にメッセージを送信し、受信経路３６を介してモジュール２４からメッセージを受信することが構想される。

図２は、ＴＣＰ／ＩＰスタック（Ｓｔａｃｋ）、及び、伝送制御プロトコル（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／インタネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のためのスタックメモリ３８のブロック図を概略的に示す。このスタックメモリ３８は、アプリケーション４２を有するユーザ領域４０と、コア４４と、ネットワークアダプタ４８を含むハードウェア４６と、を含む。

コア４４は、ＴＣＰ／ＵＤＰネットワークプロトコル５０（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍｍ Ｐｒｏｔｏｃｏｌ、ユーザデータグラムプロトコル）と、インタネットプロトコルバージョン４（ＩＣＭＰｖ４ ＩＧＭＰ）に従ってインタネットメッセージを制御するモジュール５２と、インタネットプロトコルバージョン４（ＩＰｖ４）を含むモジュール５４と、インタネットプロトコルバージョン６（ＩＰｖ６）を含むモジュール５６と、インタネットプロトコルバージョン６（ＩＣＭＰｖ６）に従ってインタネットメッセージを制御するモジュール５８と、を有する。さらに、コア４４は、更なる別のネットワークプロトコル（ＡＲＰ：Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ、アドレス解決プロトコル）のためのモジュール６０と、伝達層（リンクレイヤ）を備えるモジュール６２と、デバイスドライバ（Ｄｅｖｉｃｅ Ｄｒｉｖｅｒ）のためのモジュール６４と、を備える。

メッセージの受信後、当該メッセージは、ホストＭＣＵ２２（図１）によって処理される。このために、メッセージは、イーサネットドライバと、スタックメモリ３８（ＴＣＰ／ＩＰスタック）（図２）を通過する。その後にようやく、アプリケーション４２は、データを処理することが可能である。

図３は、従来技術として例えば車両のネットワーク（ＣＡＮ：Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）内で使用される通信コントローラ６６の概略図を示す。この通信コントローラ６６は、ドライバ６８（Ｂｕｓ−ＣＬＫ）と、ここではＲＡＭとして構成されるメッセージメモリ７０と、３２個のメッセージのためのバッファと、１３６ｘ３２ビットのメモリ位置と、を含む。

ドライバ６８は、アドレス７４を受信しデータ７６及び制御命令７８を他の装置と交換するよう構成されたインタフェース７２を備える。さらに、ドライバ６８は、第１の決定モジュール８０（ＩＦ ＣＯＮ ＲＥＧ１）と、第２の決定モジュール８２（ＩＦ ＣＯＮ ＲＥＧ２）と、を備える。更に、ドライバ６８は、レジスタ８４と、メッセージを処理するモジュール８６と、メッセージメモリ７０を制御する制御ユニット８８と、を有する。コア９０（ＣＡＮ−ＣＯＲＥ）は、送信経路９２（ＣＡＮ−ＴＸ）を介してＣＡＮバスへとメッセージを送信し、受信経路９４（ＣＡＮ−ＲＸ）を介してＣＡＮバスからメッセージを受信するよう構成される。

ここで示される車両内で使用可能な、メッセージメモリ７０を備える通信コントローラ６６は、メッセージの送受信に必要な情報と、メッセージメモリ７０によりメッセージの対応するユーザデータを格納する領域と、を有する。ＣＡＮコントローラの場合は、この情報は、例えば、送信方向、メッセージ識別子、及びメッセージマスクを含む。ＦｌｅｘＲａｙの場合は更に、時間的位置についての情報が通信スケジュールに格納される。

イーサネット技術に従ったデータパケットの伝送の際には、伝送は、第２のＯＳＩ層（イーサネット）を介して出て、第３の層（ＩＰｖ４／ＩＰｖ６）及び第４の層（ＴＣＰ／ＵＤＰ）も利用可能であるため、構造レベルに従って、場合によっては明らかにより多くの情報が必要である。

図４は、本発明の可能な実施形態で使用されるようなイーサネットコントローラの構成要素として使用されるメッセージメモリ９６の一実施形態を概略的に示す。メッセージメモリ９６は、データパケットのヘッダデータ（ヘッダ）のための第１の領域９８と、利用されていない第２の領域１００と、データパケットのユーザデータのための第３の領域１０２と、を含む。その際に、第１の領域９８は、第１のメッセージのヘッダデータのためのメモリ位置１０４と、第２のメッセージのヘッダデータのための第２のメモリ位置１０６と、ｎ番目のメッセージのヘッダデータのためのｎ番目のメモリ位置１０８と、を含む。第３の領域は、第１のメッセージのユーザデータのための第１のメモリ位置１１０と、データパケットのユーザデータのための第２のメモリ位置１１２と、ｎ番目のメッセージのユーザデータのためのｎ番目のメモリ位置１１４と、を含む。その際に、メッセージ処理についての情報、及び、メッセージのユーザデータが、ここで示されるように別々の範囲９８、１０２内に存在するのか、又は、１つのブロックに一緒に格納されるのかは重要なことではない。メッセージのヘッダデータの大きさが、ユーザデータの大きさと明らかに異なる場合には、通常ではメッセージメモリ９６の分離が行われる。このことは、通常ではイーサネットの場合に該当する。これに対してＣＡＮの場合は、ユーザデータは常に、特に処理情報を含む対応するヘッダデータの直後に続く。

図５は、イーサネットパケット１１６の一例を概略的に示しており、このイーサネットパケット１１６は、７バイト長のプリアンブルと、１バイト長のフレームデリミタ（ＳＦＤ：Ｓｔａｃｋ Ｆｒａｍｅ Ｄｅｌｉｍｉｔｅｒ、スタックフレームデリミタ）１２０と、を備える。イーサネットフレーム１２２は、それぞれが６バイト長を有する宛先ＭＡＣアドレス１２４及び発信元ＭＡＣアドレス１２６を含む。ＶＬＡＮタグ１２８は、その際にＶＬＡＮは仮想ＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）の略称であるが、ＴＰＩＤ１３０及びＴＣＩ１３２を含めて、４バイト長を有する。さらに、イーサネットフレーム１２２は、タイプフィールド１３４と、０〜１５００バイト長のデータ１３６と、を含む。さらに、イーサネットフレーム１２２は、ＲＡＤフィラーフィールド１３８と、ＣＲＣチェックサム１４０と、を含む。

イーサネット技術によるデータ伝送の際、最も簡単な場合には、ＯＳＩレイヤの第２層（イーサネット）についての情報のみ必要である。図５のイーサネットフレーム１２２からは、メッセージメモリ内の送信及び受信のための上記メッセージ情報が導出されうる。

図６は、ＩＰｖ４ヘッダデータ範囲として構成されたヘッダデータ範囲１４２、従って、インタネットプロトコルバージョン４（ＩＰｖ４）においてメッセージのための送信されるデータパケット（フレーム）の導入部として利用されるような、ヘッダの一例を概略的に示している。

３２ビット幅のこのヘッダデータ範囲１４２は、ヘッダデータ範囲１４２のバージョンについての４ビット幅の表示１４４と、データパケットの長さについての４ビット幅の情報１４６であって、この長さ１４６はＩＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ（ＩＰヘッダ長）を略してＩＨＬと称される上記情報と、サービスタイプ（ＴＯＳ：Ｔｙｐｅ Ｏｆ Ｓｅｒｖｉｃｅ）についての８ビット幅の情報１４８と、データパケットの全長についての１６ビット幅の情報１５０とを含む。

さらに、ヘッダデータ範囲１４２は、１６ビット幅の識別子１５２と、３ビット幅の制御スイッチ（フラグ）１５４と、フラグメント化（フラグメントオフセット、Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ）についての１３ビット幅の情報１５６と、を含む。さらに、ここでは、データパケットの寿命（生存時間、ＴＴＬ：Ｔｉｍｅ ｔｏ Ｌｉｖｅ）についての８ビット幅の情報１５８と、本発明の実施形態の枠組みにおいて利用されるインタネットプロトコルについての８ビット幅の情報１６０と、１６ビット幅のチェックサム１６２と、が設けられる。バージョン４のインタネットプロトコル１６０に従った、ここで提示されるヘッダデータ範囲１４２は、それぞれが３２ビット幅を有する発信元アドレスについての情報１６４及び宛先アドレスについての情報１６６及び、場合によっては、更なるオプションについての少なくとも１つの情報１６８も含む。

インタネットプロトコルバージョン６（ＩＰｖ６）のメッセージのためのデータパケット（フレーム）のヘッダデータ範囲１７０が、図７に概略的に示されている。ＩＰｖ６ヘッダデータ範囲として構成されるこのヘッダデータ範囲１７０又はヘッダは、バージョンについての４ビット幅の情報１７２と、優先度設定（トラフィッククラス、Ｔｒａｆｆｉｃ Ｃｌａｓｓ）についての８ビット幅の情報１７４と、フロー値（フローラベル、Ｆｌｏｗ Ｌａｂｅｌ）についての２０ビット幅の情報１７６と、ＩＰｖ６データパケットとして構成されたデータパケットの内容の長さについての１６ビット幅の情報１７８と、後続のヘッダデータ範囲の識別のための８ビット幅の情報１８０と、割り当てられたデータパケットを、ルータを介して元に戻すことが許される中間ステップ（ホップリミット、Ｈｏｐ Ｌｉｍｉｔ）の最大数についての８ビット幅の情報１８２と、を含む。さらに、示されるヘッダデータ範囲１７０は、それぞれが１２８ビット幅を有する発信元アドレス１８５と宛先アドレス１８６とを含む。

ＯＳＩレイヤの第３層のＩＰプロトコルのために、ヘッダデータ範囲１４２についての図６で示されるバージョンと、ヘッダデータ範囲１７０についての図７で示されるバージョンと、が利用される。ここから、メッセージの送受信のための、示された情報が導出されうる。

図８は、ＴＣＰプロトコルで利用されるようなフレーム１８８の概略図を示している。フレーム１８８は、ＴＣＰヘッダデータ範囲１９０（ＴＣＰヘッダ）と、伝送されるデータのための範囲１９５と、を含む。

ヘッダデータ範囲１９０は、発信元ポートについての情報１９２と、宛先ポートについての情報１９４と、シーケンス番号についての情報１９６と、受信確認についての情報１９８と、を含む。さらに、ヘッダデータ範囲１９０は、データ間隔（データオフセット、Ｄａｔａ ｏｆｆｓｅｔ）２００と、予約された範囲２０２と、複数の制御変数２０４と、ウインドウ２０６と、チェックサム２０８と、緊急表示２１０と、複数の３２ビットワードを有する更なる別のオプションについての情報２１２と、を含む。

図９に概略的に示される、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、ユーザデータグラムプロトコル）のために利用されるようなＵＤＰフレーム（ＵＤＰ−Ｆｒａｍｅ）は、ＵＤＰデータパケット２１６と、発信元ポートについての情報２１８と、宛先ポートについての情報２２０と、長さについての情報２２２と、チェックサムについての情報２２４と、データ２２６と、を含む。

従って、ＴＣＰフレーム１８８（図８）及びＵＤＰフレーム２１４（図９）は、例えば発信元ポート１９２、２１８、宛先ポート１９４、２１８、又は長さ２２２についての各示される情報を含む。ここでは、ＴＣＰ情報の処理の際に、例えばメッセージカウンタの現在のプロトコル状態が考慮されることに注意されたい。ＵＤＰプロトコルはステートレスであり、本発明に係る方法の一実施形態において低い複雑性に基づいても処理される。

図１０に概略的に示されるメッセージ２３０、２３２を処理するための本発明に係る構成２２８の一実施形態は、複数のメモリ位置２３８を含むメッセージメモリ２３６を備えたイーサネットコントローラ２３４、従ってデータパケットとしてイーサネット技術により伝送されるメッセージのための制御装置を有する。イーサネットコントローラ２３４は、少なくとも１つの属性の存在について、受信されたメッセージ２３０、２３２を検査し、少なくとも１つの属性がメッセージ２３０、２３２に該当する場合には、受信されたメッセージ２３０、２３２を、メッセージ２３０、２３２のために予約されたメッセージメモリ２３６のメモリ位置２３８、２４０、２４２、２４４に格納する。

さらに、構成２２８は、送信レジスタ２４８を備える通信コントローラ２４６を備え、この通信コントローラ２４６は、送信レジスタ２４８内での書込み工程の実行後にメッセージ２３０、２３２を送信するよう構成される。

ここで記載される本発明に係る構成２２８の実施形態は、車両内のネットワーク内に配置され、車両の少なくとも１つの駆動パラメータの値を少なくとも１つの属性として有するメッセージ２３０、２３２を伝達するように構成される。従って、メッセージ２３０、２３２の少なくとも１つの属性は、少なくとも１つのパラメータを介して定められる。

図１０を用いて示される駆動状況において、第１のメッセージ２３０が、既にメッセージメモリ２３６のメモリフィールド２４０内に存在することが構想される。この第１のメッセージ２３０は、少なくとも１つの駆動パラメータの第１の値を含む。さらに車両の駆動中には、少なくとも１つの駆動パラメータの値が変更される。しかしながら、値の変化が起きることによって、少なくとも１つの駆動パラメータ及びメッセージ２３０、２３２の少なくとも１つの属性も変更されない。通信コントローラ２４６により伝達される第２のメッセージ２３２は、少なくとも１つの駆動パラメータの、更新された第２の値を含む。第２のメッセージ２３２がイーサネットコントローラ２３４に到達し次第、第２のメッセージ２３２は、既に第１のメッセージ２３０が存在するメモリ位置２４０に格納され、これによりさらに、第１メッセージ２３０が第２のメッセージ２３２によって上書きされる。これにより、メッセージメモリ２３６内で、少なくとも１つの駆動パラメータの値の更新が行われる。

Claims (9)

1. メッセージメモリ（９６、２３６）を有する少なくとも１つのイーサネットコントローラ（２３４）を用いて車両内のメッセージ（２３０、２３２）を処理する方法であって、受信されたメッセージ（２３０、２３２）は、前記少なくとも１つのイーサネットコントローラ（２３４）によって、少なくとも１つの属性の存在について検査され、前記受信されたメッセージ（２３０、２３２）は、前記少なくとも１つの属性が前記メッセージ（２３０、２３２）に該当する場合には前記メッセージメモリ（９６、２３６）に格納され、
   前記受信されたメッセージ（２３０、２３２）は、前記車両の少なくとも１つの駆動パラメータの値を含み、前記属性は、前記車両の前記少なくとも１つの駆動パラメータにより定められ、
   前記メッセージ（２３０、２３２）は、該当する前記属性に応じて、当該メッセージのために予約された、前記メッセージメモリ（９６、２３６）のメモリ位置に格納される、方法。
2. 前記少なくとも１つのイーサネットコントローラ（２３４）の前記メッセージメモリ（９６、２３６）の内容は、メッセージ（２３０、２３２）が変更された場合に更新される、請求項１に記載の方法。
3. 前記少なくとも１つの属性を有する第１のメッセージ（２３０、２３２）は、前記メッセージメモリ（９６、２３６）のメモリ位置（１０４、１０６、１０８、１１０、１１２、１１４、２３８、２４０、２４２、２４４）に格納され、前記第１のメッセージ（２３０、２３２）は、当該第１のメッセージ（２３０、２３２）が有するのと同一の少なくとも１つの属性を有する第２のメッセージ（２３０、２３２）の受信の際には、前記第２のメッセージ（２３０、２３２）によって上書きされる、請求項１〜２のいずれか１項に記載の方法。
4. メッセージ（２３０、２３２）は、少なくとも１つの通信コントローラ（２４６）によって送信される、請求項１〜３のいずれか１項に記載の方法。
5. 前記メッセージ（２３０、２３２）は、ネットワーク内でインタネットプロトコルを介して送信される、請求項１〜４のいずれか１項に記載の方法。
6. メッセージメモリ（９６、２３６）を備えたイーサネットコントローラ（２３４）を有する、車両内のメッセージを処理するための構成であって、前記少なくとも１つのイーサネットコントローラ（２３４）は、少なくとも１つの属性の存在について受信されたメッセージ（２３０、２３２）を検査し、前記少なくとも１つの属性が前記メッセージ（２３０、２３２）に該当する場合には、前記受信されたメッセージ（２３０、２３２）を前記メッセージメモリ（９６、２３６）に格納するよう構成され、
   前記受信されたメッセージ（２３０、２３２）は、前記車両の少なくとも１つの駆動パラメータの値を含み、前記属性は、前記車両の前記少なくとも１つの駆動パラメータにより定められ、
   前記イーサネットコントローラ（２３４）は、前記メッセージ（２３０、２３２）を、該当する前記属性に応じて、当該メッセージのために予約された、前記メッセージメモリ（９６、２３６）のメモリ位置に格納するよう構成される、構成。
7. 前記メッセージメモリ（９６、２３６）は、複数のメモリ位置（１０４、１０６、１０８、１１０、１１２、１１４、２３８、２４０、２４２、２４４）を有し、各メモリ位置（１０４、１０６、１０８、１１０、１１２、１１４、２３８、２４０、２４２、２４４）は、前記少なくとも１つの属性を満たすメッセージ（２３０、２３２）のために予約される、請求項６に記載の構成。
8. 前記構成は、送信レジスタ（２４８）を備えた通信コントローラ（２４６）を有し、前記通信コントローラ（２４６）は、前記送信レジスタ（２４８）による書込み工程の実行後にメッセージ（２３０、２３２）を送信するよう構成される、請求項６又は７に記載の構成。
9. 前記構成は、車両内に配置され、前記車両内に配置されたネットワークのメッセージを交換するよう構成される、請求項６〜８のいずれか１項に記載の構成。

Images