メッセージメモリ96、236を有する少なくとも1つのイーサネットコントローラ234を用いてメッセージ230、232を処理する方法であって、受信されたメッセージ230、232は、前記少なくとも1つのイーサネットコントローラ234によって、少なくとも1つの属性の存在について検査され、前記受信されたメッセージ230、232は、前記少なくとも1つの属性が前記メッセージ230、232に該当する場合には前記メッセージメモリ96、236に格納される、方法。前記方法は車両のために実施され、処理されるメッセージ230、232は、前記車両の少なくとも1つの駆動パラメータの値を含み、前記少なくとも1つの属性は、前記少なくとも1つの駆動パラメータにより定められる、請求項1に記載の方法。前記少なくとも1つのイーサネットコントローラ234の前記メッセージメモリ96、236の内容は、メッセージ230、232が変更された場合に更新される、請求項1又は2で記載の方法。前記少なくとも1つの属性を有する第1のメッセージ230、232は、前記メッセージメモリ96、236のメモリ位置104、106、108、110、112、114、238、240、242、244に格納され、前記第1のメッセージ230、232は、当該第1のメッセージ230、232が有するのと同一の少なくとも1つの属性を有する第2のメッセージ230、232の受信の際には、前記第2のメッセージ230、232によって上書きされる、請求項1~3のいずれか1項に記載の方法。メッセージ230、232は、少なくとも1つの通信コントローラ246によって送信される、請求項1~4のいずれか1項に記載の方法。前記メッセージ230、232は、ネットワーク内でインタネットプロトコルを介して送信される、請求項1~5のいずれか1項に記載の方法。メッセージメモリ96、236を備えたイーサネットコントローラ234を有する、メッセージを処理するための構成であって、前記少なくとも1つのイーサネットコントローラ234は、少なくとも1つの属性の存在について受信されたメッセージ230、232を検査し、前記少なくとも1つの属性が前記メッセージ230、232に該当する場合には、前記受信されたメッセージ230、232を前記メッセージメモリ96、236に格納する、構成。前記メッセージメモリ96、236は、複数のメモリ位置104、106、108、110、112、114、238、240、242、244を有し、各メモリ位置104、106、108、110、112、114、238、240、242、244は、前記少なくとも1つの属性を満たすメッセージ230、232のために予約される、請求項7に記載の構成。前記構成は、送信レジスタ248を備えた通信コントローラ246を有し、前記通信コントローラ246は、前記送信レジスタ248による書込み工程の実行後にメッセージ230、232を送信するよう構成される、請求項7又は8に記載の構成。前記構成は、車両内に配置され、前記車両内に配置されたネットワークのメッセージを交換するよう構成される、請求項7~9のいずれか1項に記載の構成。これに対して、例えばCAN又はFlexRayのような通常使用されるフィールドバスシステムのための、メッセージメモリを有する通信コントローラが車両内で利用される。このメッセージメモリ内の各メモリ位置は、例えばエンジン回転数又は車両速度のような車両の駆動パラメータを特に含みうる特別なメッセージの処理のために役立つ。その際に、メッセージの事前解析と、既にハードウェア内での自動格納とが行われる。ソフトウェアは、必要な場合には常に、最後に受信されたデータにアクセスすることが可能である。その際に、古いメッセージが現在のメッセージによって上書きされる。このような背景から、独立請求項に記載の特徴を備えた方法及び構成が提示される。本発明の更なる別の実施形態は、従属請求項及び明細書の記載から明らかとなろう。本発明の枠組みにおいて設けられるイーサネットコントローラ、即ち、イーサネット技術によりデータパケットが伝送されるネットワークの制御装置又は制御モジュールは、メッセージメモリを備える。従って、このイーサネットコントローラは、典型的に、メッセージ設定が固定の閉じたネットワーク内での利用に適している。イーサネット制御装置とも呼ばれるイーサネットコントローラは、データパケットとしてのメッセージを受信し、当該メッセージを、予めメッセージメモリ内で定められた特定の属性について検査する。特定の又は関連する属性が、受信されたメッセージに該当する場合には、この受信されたメッセージは、メッセージメモリ内の対応する箇所に格納される。その際に、特定の内容を有するメッセージのために、当該メッセージのための特定の箇所又はメモリ位置であって、当該メッセージのために予約され当該メッセージが格納される上記メモリ位置を設けることが可能である。メモリ位置に対するメッセージの割り当ては、特に、どの少なくとも1つの駆動パラメータをメッセージが含むのかに依存する。対応して、少なくとも1つの特定の駆動パラメータのために予約されたメモリ位置には、当該少なくとも1つの駆動パラメータを有するメッセージのみが格納される。通常使用されるソフトウェアは、常に、もっぱら最後に受信されたメッセージに対してアクセスすることが可能である。その際に、現在のメッセージが、古いメッセージを自動的に上書きする。駆動パラメータとして、例えば車両速度が考慮されうる。本発明の実施形態において、メッセージは少なくとも1つの駆動パラメータを有し、この少なくとも1つの駆動パラメータによって、当該メッセージの少なくとも1つの属性が設定される。通常では、車両の駆動パラメータは特定の値を有する。駆動パラメータの値は、通常では車両の駆動中に変化する。本発明の更なる別の構成において、少なくとも1つの駆動パラメータを介してその少なくとも1つの属性が定められる第1のメッセージは、当該少なくとも1つの駆動パラメータの第1の値を有する。第1のメッセージの場合と同一の少なくとも1つの駆動パラメータを介してその少なくとも1つの属性が定められる第2のメッセージは、当該少なくとも1つの駆動パラメータの第2の値を有する。更新工程の際に、より古い第1のメッセージが、より新しい第2のメッセージによって置換されることが構想される。従って、メッセージメモリ内で、少なくとも1つの駆動パラメータの値の変更が行われる。ソフトウェア側の制御装置によってメッセージが送信されることが構想される場合には、メッセージは、メッセージメモリ内の適切な箇所に対してアドレス指定され、送信が開始される。この開始は、通常、通信コントローラの送信レジスタ内の対応する書込み工程によって行われる。発展形態において、各修正後に直ぐに、従って、例えばメッセージの更新の後直ぐにも、当該メッセージの送信が開始されうる。この機能は間接的に、互いに通信する2つ以上の通信コントローラ上でのメッセージのミラーリングに匹敵する。プロセッサが、第1のメッセージから第2のメッセージが生じるように、メッセージ、即ちメッセージの内容を変更する場合に、この第2のメッセージは自動的に送信され、メモリメッセージ内の他の全てのメモリ位置が対応して更新されうる。メッセージメモリ内での整合性を保障するために、通信コントローラは通常入出力バッファを有し、この入出力バッファを用いてメッセージが要求され、通信コントローラにより提供される。しかしながら、イーサネットコントローラのメッセージメモリを、直接的にプロセッサのアドレス空間に設置することも構想可能であり、従って直接的なアクセスが可能となる。従って、メモリオーバーレイメモリマッピングが実行されうる。イーサネットコントローラ自身がメッセージを評価し対応して格納するため、本方法によって、ソフトウェアの著しい負荷軽減が達成される。従来技術の方法では、ソフトウェアは、このメッセージを最初にプロトコルスタックにおいて評価し、従って、OSIモデルの複数層を評価し、最終的に対応する箇所にメッセージを複写する必要がある。従って、本発明に係る方法の一実施形態では、メッセージの滞留時間又は遅延時間が短縮されうる。さらに、イーサネットコントローラの中央演算ユニットCPUは負荷が軽減され、他のタスクのために利用されうる。本発明に係る構成は、提示される方法の全ステップを実行するよう構成される。その際に、本方法の個々のステップは、本構成の個々の構成要素によっても実行されうる。さらに、本構成の機能又は本構成の個々の構成要素の機能は、本方法のステップとして実施されうる。さらに、本方法のステップが、本構成の少なくとも1つの構成要素の機能又は構成全体の機能として実現されうる。本発明の更なる別の利点及び実施形態は、明細書の記載及び添付の図面から明らかとなろう。先に挙げた特徴、及び、以下で解説された特徴は、各示される組み合わせのみならず他の組み合わせにおいても、又は、単独でも、本方法の枠組みを逸脱することなく、利用されうる。本発明は、実施形態を用いて図面に概略的に示され、以下では、図を参照して詳細に記載される。図面は、互いに関連して包括的に記載され、同一の符号は同一の構成要素を示す。図1に概略的に示される従来のイーサネットコントローラ2は、ホストインタフェース4と、データバンクプロバイダへのインタフェースと、8kBのユーザフラッシュ6又はデジタルメモリチップと、メッセージを送信する2kBのTxバッファ8又はバッファメモリと、メッセージを受信する4kBのRxFIFOFirstInFirstOut、先入れ先出しバッファと、ここでは2MHzの周波数により駆動されるクロック12と、媒体アドレスへのアクセスを制御するイーサネットMACMediaAccessControl、メディアアクセスコントロール14と、制御表示16LED制御と、物理層18イーサネットPHYと、を含む。イーサネットコントローラ2のインタフェース4は、並列のバス接続を介して、データプロバイダホストのマイクロコントローラ22MCUと接続される。図1はさらに、チップ26RJ-45を有するモジュール24と、LINKLED及びACTLEDのための導線32、33を介して制御表示16と接続されたACTLEDとして構成された発光ダイオード28及びLinkLEDとして構成された発光ダイオード30と、を示している。さらに、物理層18が、送信経路34を介してモジュール24にメッセージを送信し、受信経路36を介してモジュール24からメッセージを受信することが構想される。図2は、TCP/IPスタックStack、及び、伝送制御プロトコルTransmissionControlProtocol/インタネットプロトコルInternetProtocolのためのスタックメモリ38のブロック図を概略的に示す。このスタックメモリ38は、アプリケーション42を有するユーザ領域40と、コア44と、ネットワークアダプタ48を含むハードウェア46と、を含む。コア44は、TCP/UDPネットワークプロトコル50UDP:UserDatagrammProtocol、ユーザデータグラムプロトコルと、インタネットプロトコルバージョン4ICMPv4IGMPに従ってインタネットメッセージを制御するモジュール52と、インタネットプロトコルバージョン4IPv4を含むモジュール54と、インタネットプロトコルバージョン6IPv6を含むモジュール56と、インタネットプロトコルバージョン6ICMPv6に従ってインタネットメッセージを制御するモジュール58と、を有する。さらに、コア54は、更なる別のネットワークプロトコルARP:AddressResolutionProtocol、アドレス解決プロトコルのためのモジュール60と、伝達層リンクレイヤを備えるモジュール62と、デバイスドライバDeviceDriverのためのモジュール64と、を備える。メッセージの受信後、当該メッセージは、ホストMCU22図1によって処理される。このために、メッセージは、イーサネットドライバと、スタックメモリ38TCP/IPスタック図2を通過する。その後にようやく、アプリケーション42は、データを処理することが可能である。図3は、従来技術として例えば車両のネットワークCAN:ControllerAreaNetwork内で使用される通信コントローラ66の概略図を示す。この通信コントローラ66は、ドライバ68Bus-CLKと、ここではRAMとして構成されるメッセージメモリ70と、32個のメッセージのためのバッファと、136x32ビットのメモリ位置と、を含む。ドライバ68は、アドレス74を受信しデータ76及び制御命令78を他の装置と交換するよう構成されたインタフェース72を備える。さらに、ドライバ68は、第1の決定モジュール80IFCONREG1と、第2の決定モジュール80IFCONREG2と、を備える。更に、ドライバ68は、レジスタ84と、メッセージを処理するモジュール86と、メッセージメモリ70を制御する制御ユニット88と、を有する。コア90CAN-COREは、送信経路92CAN-TXを介してCANバスへとメッセージを送信し、受信経路94CAN-RXを介してCANバスからメッセージを受信するよう構成される。ここで示される車両内で使用可能な、メッセージメモリ70を備える通信コントローラ66は、メッセージの送受信に必要な情報と、メッセージメモリ70によりメッセージの対応するユーザデータを格納する領域と、を有する。CANコントローラの場合は、この情報は、例えば、送信方向、メッセージ識別子、及びメッセージマスクを含む。FlexRayの場合は更に、時間的位置についての情報が通信スケジュールに格納される。イーサネット技術に従ったデータパケットの伝送の際には、伝送は、第2のOSI層イーサネットを介して出て、第3の層IPv4/IPv6及び第4の層TCP/UDPも利用可能であるため、構造レベルに従って、場合によっては明らかにより多くの情報が必要である。図4は、本発明の可能な実施形態で使用されるようなイーサネットコントローラの構成要素として使用されるメッセージメモリ96の一実施形態を概略的に示す。メッセージメモリ96は、データパケットのヘッダデータヘッダのための第1の領域98と、利用されていない第2の領域100と、データパケットのユーザデータのための第3の領域102と、を含む。その際に、第1の領域98は、第1のメッセージのヘッダデータのためのメモリ位置104と、第2のメッセージのヘッダデータのための第2のメモリ位置106と、n番目のメッセージのヘッダデータのためのn番目のメモリ位置108と、を含む。第3の領域は、第1のメッセージのユーザデータのための第1のメモリ位置110と、データパケットのユーザデータのための第2のメモリ位置112と、n番目のメッセージのユーザデータのためのn番目のメモリ位置114と、を含む。その際に、メッセージ処理についての情報、及び、メッセージのユーザデータが、ここで示されるように別々の範囲98、102内に存在するのか、又は、1つのブロックに一緒に格納されるのかは重要なことではない。メッセージのヘッダデータの大きさが、ユーザデータの大きさと明らかに異なる場合には、通常ではメッセージメモリ98の分離が行われる。このことは、通常ではイーサネットの場合に該当する。これに対してCANの場合は、ユーザデータは常に、特に処理情報を含む対応するヘッダデータの直後に続く。図5は、イーサネットパケット116の一例を概略的に示しており、このイーサネットパケット116は、7バイト長のプリアンブルと、1バイト長のフレームデリミタSFD:StackFrameDelimiter、スタックフレームデリミタ120と、を備える。イーサネットフレーム122は、それぞれが6バイト長を有する宛先MACアドレス124及び発信元MACアドレス126を含む。VLANタグ128は、その際にVLANは仮想LANVirtualLocalAreaNetworkの略称であるが、TPID130及びTCI132を含めて、7バイト長を有する。さらに、イーサネットフレーム122は、タイプフィールド134と、0~1500バイト長のデータ136とを含む。さらにイーサネットフレーム122は、RADフィラーフィールド138と、CRCチェックサム140とを含む。イーサネット技術によるデータ伝送の際、最も簡単な場合には、OSレイヤ2の第2層イーサネットについての情報のみ必要である。図5のイーサネットフレーム122からは、メッセージメモリ内の送信及び受信のための上記メッセージ情報が導出されうる。図6は、IPv4ヘッダデータ範囲として構成されたヘッダデータ範囲142、従って、インタネットプロトコルバージョン4IPv4においてメッセージのための送信されるデータパケットフレームの導入部として利用されるような、ヘッダの一例を概略的に示している。32ビット幅のこのヘッダデータ範囲142は、ヘッダデータ範囲142のバージョンについての4ビット幅の表示144と、データパケットの長さについての4ビット幅の情報146であって、この長さ146はIPHeaderLengthIPヘッダ長を略してIHLと称される上記情報と、サービスタイプTOS:TypeOfServiceについての8ビット幅の情報148と、データパケットの全長についての16ビット幅の情報150とを含む。さらに、ヘッダデータ範囲142は、16ビット幅の識別子152と、3ビット幅の制御スイッチフラグ154と、フラグメント化フラグメントオフセット、FragmentOffsetについての13ビット幅の情報156と、を含む。さらに、ここでは、データパケットの寿命生存時間、TTL:TimetoLiveについての8ビット幅の情報158と、本発明の実施形態の枠組みにおいて利用されるインタネットプロトコルについての8ビット幅の情報160と、16ビット幅のチェックサム162と、が設けられる。バージョン4のインタネットプロトコル160に従った、ここで提示されるヘッダデータ範囲21は、それぞれが32ビット幅を有する発信元アドレスについての情報164及び宛先アドレスについての情報166及び、場合によっては、更なるオプションについての少なくとも1つの情報168も含む。インタネットプロトコルバージョン6IPv6のメッセージのためのデータパケットフレームのヘッダデータ範囲170が、図7に概略的に示されている。IPv6ヘッダデータ範囲として構成されるこのヘッダデータ範囲170又はヘッダは、バージョンについての4ビット幅の情報172と、優先度設定トラフィッククラス、TrafficClassについての8ビット幅の情報174と、フロー値フローラベル、FlowLabelについての20ビット幅の情報176と、IPv6データパケットとして構成されたデータパケットの内容の長さについての16ビット幅の情報178と、後続のヘッダデータ範囲の識別のための8ビット幅の情報180と、割り当てられたデータパケットを、ルータを介して元に戻すことが許される中間ステップホップリミット、HopLimitの最大数についての8ビット幅の情報182と、を含む。さらに、示されるヘッダデータ範囲170は、それぞれが128ビット幅を有する発信元アドレス185と宛先アドレス186とを含む。OSレイヤの第3層のIPプロトコルのために、ヘッダデータ範囲142についての図6で示されるバージョンと、ヘッダデータ範囲170についての図7で示されるバージョンと、が利用される。ここから、メッセージの送受信のための、示された情報が導出されうる。図8は、TCPプロトコルで利用されるようなフレーム188の概略図を示している。フレーム188は、TCPヘッダデータ範囲190TCPヘッダと、伝送されるデータのための範囲192と、を含む。ヘッダデータ範囲190は、発信元ポートについての情報192と、宛先ポートについての情報194と、シーケンス番号についての情報196と、受信確認についての情報198と、を含む。さらに、ヘッダデータ範囲190は、データ間隔データオフセット、Dataoffset200と、予約された範囲202と、複数の制御変数204と、ウインドウ206と、チェックサム208と、緊急表示210と、複数の32ビットワードを有する更なる別のオプションについての情報212と、を含む。図9に概略的に示される、UDPUserDatagramProtocol、ユーザデータグラムプロトコルのために利用されるようなUDPフレームUDP-Frameは、UDPデータパケット216と、発信元ポートについての情報218と、宛先ポートについての情報220と、長さについての情報222と、チェックサムについての情報224と、データ226と、を含む。従って、TCPフレーム188図8及びUDPフレーム214図9は、例えば発信元ポート192、218、宛先ポート180、225、又は長さ222についての各示される情報を含む。ここでは、TCP情報の処理の際に、例えばメッセージカウンタの現在のプロトコル状態が考慮されることに注意されたい。UDPプロトコルはステートレスであり、本発明に係る方法の一実施形態において低い複雑性に基づいても処理される。図10に概略的に示されるメッセージ230、232を処理するための本発明に係る構成228の一実施形態は、複数のメモリ位置238を含むメッセージメモリ236を備えたイーサネットコントローラ234、従ってデータパケットとしてイーサネット技術により伝送されるメッセージのための制御装置を有する。イーサネットコントローラ236は、少なくとも1つの属性の存在について、受信されたメッセージ230、232を検査し、少なくとも1つの属性がメッセージ230、232に該当する場合には、受信されたメッセージ230、232を、メッセージ230、232のために予約されたメッセージメモリ236のメモリ位置238、240、242、244に格納する。さらに、構成228は、送信レジスタ248を備える通信コントローラ246を備え、この通信コントローラ246は、送信レジスタ248内での書込み工程の実行後にメッセージ230、232を送信するよう構成される。ここで記載される本発明に係る構成228の実施形態は、車両内のネットワーク内に配置され、車両の少なくとも1つの駆動パラメータの値を少なくとも1つの属性として有するメッセージ230、232を伝達するように構成される。従って、メッセージ230、232の少なくとも1つの属性は、少なくとも1つのパラメータを介して定められる。図10を用いて示される駆動状況において、第1のメッセージ230が、既にメッセージメモリ236のメモリフィールド240内に存在することが構想される。この第1のメッセージ230は、少なくとも1つの駆動パラメータの第1の値を含む。さらに車両の駆動中には、少なくとも1つの駆動パラメータの値が変更される。しかしながら、値の変化が起きることによって、少なくとも1つの駆動パラメータ及びメッセージ230、232の少なくとも1つの属性も変更されない。通信コントローラ246により伝達される第2のメッセージ232は、少なくとも1つの駆動パラメータの、更新された第2の値を含む。第2のメッセージ232がイーサネットコントローラ234に到達し次第、第2のメッセージ232は、既に第1のメッセージ230が存在するメモリ位置240に格納され、これによりさらに、第1メッセージ230が第2のメッセージ232によって上書きされる。これにより、メッセージメモリ236内で、少なくとも1つの駆動パラメータの値の更新が行われる。