(57)【要約】本発明は、通信システムの加入者ノード、通信システム及び通信システム内でメッセージを伝送する方法に関する。メッセージは、通信システムの第１加入者ノードから通信システムのデータパスを介して通信システムの第２加入者ノードへと伝送される。第１加入者ノードのアプリケーションプログラムは送信されるメッセージをメッセージメモリに格納し、メッセージメモリから送信されるメッセージがアプリケーションプログラムの送信コマンドに応じて通信コントローラにより読み出されデータパスを介して伝送される。特に送信タスクの取消しの際にホストＣＰＵの利用度及び効率を改善できるので、送信される又は送信されたメッセージについての送信イベントがメッセージメモリとは機能的に区別される少なくとも１つの送信イベントメモリに格納され、アプリケーションプログラムがイベントメモリに格納された情報に常時アクセス可能であることが提案される。【選択図】図１
2011520368.tif 000002
【特許請求の範囲】
【請求項１】
データバス（２）を含む通信システム（１）の加入者ノード（３）であって、前記データバス（２）には前記加入者ノード（３）と、少なくとも１つのさらなる別の加入者ノード（３）とが接続されており、前記加入者ノード（３）は、前記データバス（２）を介してメッセージ（７）を送信し及び／又は前記データバス（２）からメッセージ（７）を受信するための通信コントローラ（４）と、送信又は受信されるメッセージ（７）を一時的に格納するためのメッセージメモリ（１１、１２）とを有する、前記加入者ノード（３）において、
前記加入者ノード（３）は、前記メッセージメモリ（１１、１２）とは機能的に区別される少なくとも１つの送信イベントメモリ（１３）を有し、前記送信イベントメモリ（１３）には、少なくとも１つの送信される又は送信されたメッセージ（７）についての送信イベントが格納されていることを特徴とする、加入者ノード（３）。
【請求項２】
前記送信イベントは、
−メッセージ（７）が成功裏に送信された、
−送信タスクの取消しにも関わらず、メッセージ（７）が成功裏に送信された、
−送信タスクの取消し、送信プロセスが未だに開始していない、
−送信タスクの取消し、アービトレーションが失われた後で送信プロセスが終了した、及び、
−送信タスクの取消し、エラーの後で送信プロセスが終了した、
というイベントのうちの少なくとも１つを含むことを特徴とする、請求項１に記載の加入者ノード（３）。
【請求項３】
前記送信イベントメモリ（１３）には、少なくとも１つの送信される又は送信されたメッセージ（７）の識別子が格納されていることを特徴とする、請求項１又は２に記載の加入者ノード（３）。
【請求項４】
−前記少なくとも１つの送信される又は送信されたメッセージ（７）のデータ長コード、
−前記イベントが起きたことを示す時間標識、
−前記送信タスクが出された前記メッセージメモリ（１１、１２）のアドレス、及び、
−比較的大きなデータ量が、同一の前記識別子を有する複数のメッセージ（７）で順次送信される場合に、データパケットを識別するシーケンスカウンタ、
という情報のうちの１つ又は複数が、前記送信イベントメモリ（１３）に格納されていることを特徴とする、請求項１〜３のいずれか１項に記載の加入者ノード（３）。
【請求項５】
前記送信イベントメモリ（１３）は複数のメモリ素子を含み、各メモリ素子に、送信される又は送信されたメッセージ（７）に対する情報が格納されていることを特徴とする、請求項１〜４のいずれか１項に記載の加入者ノード（３）。
【請求項６】
前記送信イベントメモリ（１３）は、随意にアクセスされるメモリを含むことを特徴とする、請求項１〜５のいずれか１項に記載の加入者ノード（３）。
【請求項７】
前記送信イベントメモリ（１３）は、メッセージメモリ（１１、１２）の一部として構成されることを特徴とする、請求項１〜６のいずれか１項に記載の加入者ノード（３）。
【請求項８】
前記送信イベントメモリ（１３）の大きさは、設定ビットにより設定可能であることを特徴とする、請求項７に記載の加入者ノード（３）。
【請求項９】
データバス（２）と、データ伝送のために前記データバス（２）に接続された複数の加入者ノード（３）を含む通信システム（１）であって、前記加入者ノード（３）はそれぞれ、前記データバス（２）を介してメッセージ（７）を送信し及び／又は前記データバス（２）からメッセージ（７）を受信するための通信コントローラ（４）と、送信又は受信されるメッセージ（７）を一時的に格納するためのメッセージメモリ（１１、１２）と、を有する、前記通信システム（１）において、
少なくとも１つの前記加入者ノード（３）は、前記メッセージメモリ（１１、１２）とは機能的に区別される少なくとも１つの送信イベントメモリ（１３）を有し、前記送信イベントメモリ（１３）には、少なくとも１つの送信される又は送信されたメッセージ（７）についての送信イベントが格納されていることを特徴とする、通信システム（１）。
【請求項１０】
通信システム（１）の第１加入者ノード（３）から、前記通信システム（１）のデータバス（２）を介して、前記通信システム（１）の第２加入者ノード（３）へとメッセージ（７）を伝送する方法であって、前記第１加入者ノード（３）のアプリケーションプログラム（５）は、送信される前記メッセージ（７）をメッセージメモリ（１１、１２）に複写し、前記メッセージメモリ（１１、１２）から、前記送信されるメッセージ（７）が、前記アプリケーションプログラム（５）の送信コマンドに応じて、通信コントローラ（４）により読み出され、前記データバス（２）を介して伝送される、前記方法において、
送信される又は送信されたメッセージ（７）についての送信イベントが、前記メッセージメモリ（１１、１２）とは機能的に区別される少なくとも１つの送信イベントメモリ（１３）に格納され、前記アプリケーションプログラム（５）は前記送信イベントメモリ（１３）に格納された前記送信イベントに常時アクセス可能であることを特徴とする、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムの加入者ノードに関する。通信システムは、加入者ノードと、少なくとも１つのさらなる別の加入者ノードとが接続されたデータバスを含む。加入者ノードは、データバスを介してメッセージを送信し及び／又はデータバスからメッセージを受信するための通信コントローラと、送信又は受信されるメッセージを一時的に格納するためのメッセージメモリとを有する。さらに、本発明は、データバスと、データ伝送のために当該データバスに接続された複数の加入者ノードとに関する。加入者ノードはそれぞれ、データバスを介してメッセージを送信し及び／又はデータバスからメッセージを受信するための通信コントローラと、送信又は受信されるメッセージを一時的に格納するためのメッセージメモリとを有する。最後に、本発明は、通信システムの第１加入者ノードから、通信システムのデータバスを介して、通信システムの第２加入者ノードへとメッセージを伝送する方法に関する。本方法では、第１加入者ノードのアプリケーションプログラムは、送信されるメッセージをメッセージメモリに格納し、当該メッセージメモリから、送信されるメッセージが、アプリケーションプログラムの送信コマンドに応じて、通信コントローラにより読み出され、データバスを介して伝送される。
【背景技術】
【０００２】
上記の形態の公知の通信システムの例は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）通信システムである。ここでは、車両内のワイヤリングハーネスの長さを短縮し、これにより場所と重量を削減するために、１９８３年に車両内での制御装置のネットワーク構築のためにボッシュ社（Ｂｏｓｃｈ）により開発され、１９８６年に（ＳＡＥ  Ｐａｐｅｒ  ８６０３９１、Iｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｇｒｅｓｓ  ａｎｄ  Ｅｘｐｏｓｉｔｉｏｎ、Ｄｅｔｒｏｉｔ、Ｍｉｃｈｉｇａｎ、Ｆｅｂ．２４−２８，１９８６参照）インテル社（Ｉｎｔｅｌ）と共同で導入された非同期型直列バスシステムが関わっている。ただし、ＣＡＮバスの利用は、自動車分野に限定されない。ＣＡＮバスはその間、例えば、建築統制技術や工作機械分野に進出した。ＣＡＮにおいて、データ伝送は、伝送されるユーザデータ（本来のメッセージ）の他に、先頭部の設定データ（ヘッダ部）及びフレームの最後尾の検査ビット（ＣＲＣ部）も有するデータフレームで行なわれる。上記の形態の公知の通信システムの他の例は、ＦｌｅｘＲａｙバス、ＭＯＳＴ（Ｍｅｄｉａ  Ｏｒｉｅｎｔｅｄ  Ｓｙｓｔｅｍｓ  Ｔｒａｎｓｐｏｒｔ）バス、又は、任意のフィールドバス、例えば、ＬＩＮ（Ｌｏｃａｌ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  Ｎｅｔｗｏｒｋ）バスである。
【０００３】
ＣＡＮ及び他のプロトコルにおいては、第１加入者ノードのアプリケーションプログラムが、送信されるメッセージをメッセージメモリに複写し、当該メッセージメモリから、アプリケーションプログラムの送信コマンドに応じて、送信されるメッセージが通信コンとローラにより読み出されデータバスを介して伝送されることで、メッセージが第１加入者ノードと第２加入者ノードとの間で伝送される。その際、送信タスクの結果と、場合によっては起こりうる送信タスクの取消しについて、アプリケーションプログラムに報知する必要性が生じることが多い。これは、例えば、送信タスクの実行中に、より緊急のさらなる別の送信タスクが入る場合が該当する。このような場合に、関連する送信タスクが取り消されるが、場合によっては既に開始されている送信プロセス（スタート・オブ・フレーム（ＳＯＦ：Ｓｔａｒｔ  Ｏｆ  Ｆｒａｍｅ）ビットが既に送信されている）は中断されずに、アービトレーションが失われるまで、エラーが発生するまで、又はメッセージが成功裏に送信されるまで続行する。ＣＡＮや他のプロトコルにおいてデータは直列伝送されるため、場合によっては、データフレームの最後尾に達するまで、比較的長く掛かる可能性がある。この時間の間、加入者ノードの演算ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）は、データフレームの最後尾が到着するのを待つ必要があるため、実際には封鎖される（ｂｌｏｃｋｉｅｒｅｎ）。このことはさらに、より緊急のさらなる別の送信タスクの実行時における許容されない遅延へと繋がりうる。
【０００４】
第１の送信タスクのデータフレームの最後尾に達した後に初めて、ＣＰＵは、緊急の送信タスクに取り掛かることができる。さらに、加入者ノードのアプリケーションプログラムは、緊急の送信タスクの送信されるメッセージを、メッセージメモリに複写し、当該メッセージメモリから、送信されるメッセージが、アプリケーションプログラムの送信コマンドに応じて、通信コントローラにより読み出され、データバスを介して伝送される。緊急の送信タスクを処理した後に、アプリケーションプログラムは、中断した伝送を再びまた続行する。この目的のために、アプリケーションプログラムに、緊急タスクの前に処理された送信タスクの状態についての情報が提供される必要がある。アプリケーションプログラムは、送信タスクの結果と、場合によっては起こりうる送信タスクの取消しとについて報知される機会を有するべきであろう。
【０００５】
したがって、公知の加入者ノードの場合、その内容が送信されるメッセージメモリは、状態ビットと繋がれている。状態ビットでは、送信タスクの成功のみ示されることが多い。イベントによっては、特に送信タスクの取消し（Ｔｘ−Ｃａｎｃｅｌｌａｔｉｏｎ）の場合には、状態ビットによって示されない可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記の背景技術に基づき、本発明の根底には、送信タスクについての情報が管理され、当該情報がアプリケーションプログラムにとってアクセス可能となるように、加入者ノードを形成し発展させるという課題がある。
【課題を解決するための手段】
【０００７】
本課題を解決するために、冒頭に挙げた形態の加入者ノードに基づき、加入者ノードが、メッセージメモリとは機能的に区別される少なくとも１つの送信イベントメモリを有し、当該送信イベントメモリには、少なくとも１つの送信される又は送信されたメッセージが格納されることが提案される。
【０００８】
本発明によれば、送信タスクについての情報も、その内容が送信されるメッセージメモリに格納されるのではなく、送信イベントメモリの構成要素としての特別なリストに格納される。このことは、アプリケーションプログラムが、様々なメッセージメモリから情報を集める必要がなく、情報が、固定の場所で、好適に時間的に整理されて呼び出し可能であり、メッセージメモリが、送信タスクの取消しの後で、当該取り消しの結果を待つことなく直ちに利用可能となり、引き続き利用されるという利点を有する。特に、加入者ノードのＣＰＵは、送信タスクの取消し後にすぐに次の送信タスクの実行に取り掛かり、例えば、メッセージをメッセージメモリに格納する。当然のことながら、ＣＰＵは、取消しの後に、任意の他のアクションのためにも利用可能である。本発明により、連続する送信タスクの実行もまた、送信タスクの取消しの際に加速され、ＣＰＵの効率が改善されうる。さらに、本発明は、送信タスクの状態についての状態フラグが、メッセージメモリに繋がれてないという利点を有する。
【０００９】
本発明の好適な発展形態によれば、送信イベントが、
−メッセージが成功裏に送信された、
−送信タスクの取消しにも関わらず、メッセージが成功裏に送信された、
−送信タスクの取消し、送信プロセスが未だに開始していない、
−送信タスクの取消し、アービトレーションが失われた後で送信プロセスが終了した、及び、
−送信タスクの取消し、エラーの後で送信プロセスが終了した、
というイベントのうちの少なくとも１つを含むことが提案される。
【００１０】
送信イベントメモリに格納された送信イベントによって、加入者ノードのアプリケーションプログラムはまた、いつでも、先行する送信タスクの厳密な状態又は出力を呼び出すことができる。データ伝送が成功したかについてのみならず、追加的に、どの状況において伝送が（送信タスクが取り消されることなく、又は、送信タスクの取消しにも関わらず）成功したのかについての情報も、さらに、送信タスクが取り消されたのか、どの状況において送信タスクが取り消されたのか（（例えば、データバスが使用中であったために）送信プロセスが未だに開始していない、アービトレーションが失われた後に送信プロセスが終了した、又は、エラーの後で送信プロセスが終了した）についての情報も呼び出されうる。この追加的な情報は、アプリケーションプログラムが、送信タスクが取り消されたデータ伝送を続行する際に適切な対策を取ること、例えば、新しい送信タスクを与えることを可能とする。
【００１１】
本発明の好適な実施形態によれば、送信イベントメモリには、少なくとも１つの送信される又は送信されたメッセージの識別子が格納されていることが提案される。識別子は好適に、メッセージ又は送信タスクの一意の識別を可能とする。少なくとも１つの送信される又は送信されたメッセージについての送信イベントに加えて送信イベントメモリに格納された識別子によって、様々な送信タスクに関する複数の送信イベントがイベントメモリに格納されている場合に、特定のメッセージ又は特定の送信タスクに対する、送信イベントの一意の対応付け自体が可能である。これにより、イベントメモリのメモリ容量の範囲内で、特定のメッセージ又は特定の送信タスクについての送信イベントが、いつでも読み出し可能となる。イベントメモリの容量が大きくなるほど、より多くの送信イベントが、関連する情報と共に格納されうる。
【００１２】
当然のことながら、送信イベントや識別子の他に、さらなる別の情報も送信イベントメモリに格納されうる。したがって、例えば、
−少なくとも１つの送信される又は送信されたメッセージのデータ長コード、
−イベントが起きたことを示す時間標識、
−送信タスクが出されたメッセージメモリのアドレス、及び、
−比較的大きなデータ量が、同じ識別子の複数のメッセージで順次送信される場合に、データパケットを識別するシーケンスカウンタ、
という情報のうちの１つ又は複数が、送信イベントメモリに格納されていることが提案される。
【００１３】
追加的な情報により、アプリケーションプログラムによる、格納された送信イベントの管理が軽減されうる。時間標識は、特定のアプリケーションプログラムのために重要でありうる。加入者ノードが複数の送信メッセージメモリ（いわゆる、送信バッファ）を有する場合に、送信タスクが出されたメッセージメモリのアドレスによって、どの送信バッファが新しい送信タスクのために空いているかを確認することができる。例えば、ラインの末端で、又は、工場にある間に、制御装置として構成された通信システムの加入者ノードが初めて新たにプログラミングされ、又は、新しいソフトウェアバージョンによりプログラミングされる場合に、シーケンスカウンタは、例えばソフトウェアのダウンロードの際に重要でありうる。その際、ソフトウェアは、複数の、例えば８バイトのデータパケットに分割され、当該データパケットは同じ識別子を有する。シーケンスカウンタは、送信イベントがどのデータパケットに関してイベントメモリに格納されたのか、又は、どのデータパケットが成功裏に伝達されているのかを示す。
【００１４】
有利に、送信イベントメモリは、ＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）メモリとして組織化されている。好適に、送信イベントメモリは、複数のメモリ素子を含み、各メモリ素子には、送信される又は送信されたメッセージに対する情報が格納されている。実際には、イベントメモリの容量は一般に、幾つかのメモリ素子によって満たされる。アプリケーションプログラムがほとんど読み出さないために、送信イベントメモリの容量を超える恐れがある場合には、警告信号が出力されうる。実際にメモリの容量を超えた場合には、エラー信号が出力されうる。代替的又は追加的に、送信イベントメモリの容量を超えた場合には、最初に格納されたエントリが破棄されることが構想されうる。
【００１５】
有利に、送信イベントメモリは、随意にアクセスされるメモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）を含む。さらに、他の方法での実現、例えばフリップフロップを用いた実現も構想可能であるが、この実現は、比較的大きなシリコン面積を必要とし、したがって、比較的高いコストの原因にもなる。送信イベントメモリがメッセージメモリの一部として構成される本発明の構成は、特に有利である。メッセージメモリと、送信イベントメモリとが機能的に区別されるにも関わらず、双方は、ハードウェアに関して、同一のメモリ素子内であるが、異なるメモリ領域内に構成されうる。有利に、送信イベントメモリの大きさ、特に、イベントメモリのメモリ素子の数は、ソフトウェアに関して、例えば設定ビットによって、自由に設定可能である。このようにして、イベントメモリの大きさは、簡単な方法で、個別の要請に対して柔軟に調整されうる。
【００１６】
本発明の課題のさらなる解決策として、冒頭に挙げた形態の通信システムに基づき、少なくとも１つの加入者ノードが、メッセージメモリとは機能的に区別される少なくとも１つの送信イベントメモリを有し、送信イベントメモリには、少なくとも１つの送信される又は送信されたメッセージについての送信イベントが格納されている。好適な発展によれば、本発明にかかる通信システムの少なくとも１つの加入者ノードはさらに、請求項２〜８のうちの１つ又は複数に記載の特徴を有する。
【００１７】
最後に、本発明のさらなる別の解決案として、冒頭で挙げた形態によるメッセージ伝送方法に基づいて、送信される又は送信されたメッセージについての送信イベントが、メッセージメモリとは機能的に区別される送信イベントメモリに格納され、アプリケーションプログラムがいつでも、イベントメモリに格納された情報にアクセス可能であることが提案される。
【図面の簡単な説明】
【００１８】
以下では、本発明の好適な実施形態が図面を用いて詳細に解説される。
【図１】本発明にかかる通信ネットワークの例である。
【図２】図１の通信ネットワークの本発明にかかる加入者ノードの例である。
【図３】図１の通信ネットワークを介したメッセージ伝達のための本発明にかかる方法のフローチャートである。
【発明を実施するための形態】
【００１９】
図１には、本発明にかかる通信システム全体が符号１により示されている。ネットワーク１は、単線により象徴的に示されるデータバス２を含む。当然のことながら、データバス２は、１つ、２つ、又は複数の有線バスとして構成されうる。データバス２の物理層は、１つ又は複数の銅線、１つ又は複数のガラス繊維線、又は、光通信（例えば、赤外線）、又は無線通信を含みうる。データバス２には、複数の加入者ノード３が接続されており、そのうちの３つが図１に例示されている。各ノード３は、通信モジュール４（いわゆる、通信コントローラ。Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｒ：ＣＣ）を介して、データバス２に接続されている。さらに、ノード３は、ホストアプリケーション５（いわゆる、アプリケーションプログラム。Ａｐｐｌｉｋａｔｉｏｎｓｐｒｏｇｒａｍｍ：ＡＰ）を有する。
【００２０】
データバス２を介して、メッセージ７が、直列通信プロトコル（例えば、ＣＡＮ、ＦｌｅｘＲａｙ、ＬＩＮ、ＭＯＳＴ等）にしたがって伝送されうる。通信モジュール４は、データバス２を介してメッセージ７を送受信する役割を果たす。メッセージ７はそれぞれ、識別子（いわゆる、Ｉｄｅｎｔｉｆｉｅｒ）と、さらなる別の設定ビットと、を有するヘッダ８を有する。メッセージ７は、ヘッダ８の他に、ユーザデータ部９（いわゆる、ペイロード）と、いわゆるトレーラ１０とを有する。識別子は、メッセージ７の一意の識別を可能とする。ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）において、識別子は例えば、メッセージ７の発信元の確認を可能としメッセージ７の内容９を明らかにする一種の送信アドレスである。
【００２１】
論理的に、アプリケーションプログラム５と通信コントローラ４との間には、発信され又は到着するメッセージ７のための一時メモリとしての送信バッファ１１（Ｔｘ）及び受信バッファ１２（Ｒｘ）が配置されている。物理的には、メッセージメモリ１１、１２は、通信コントローラ４と一体に構成された構成要素であり、又は、通信コントローラ４と別体で構成されうる。メッセージメモリ１１、１２は、好適に、ＦＩＦＯの形態により構成される。メッセージメモリ１１、１２は、例えば、随意にアクセスされるメモリ（いわゆる、ＲＡＭ）として構成される。
【００２２】
加入者３のうちの１つのアプリケーションプログラム５が、データバス２を介して他の加入者３宛てにメッセージ７を送信したい場合に、最初に、送信されるメッセージ７又はその内容９を送信バッファ１１に格納する（図２の矢印２０）。アプリケーションプログラム５の送信コマンドに応じて、通信コントローラ４は、メッセージ７又はその内容９を送信バッファ１１から読み出し（図２の矢印２１）、通信システム１内でメッセージ７が伝送される通信プロトコルに応じて、メッセージ７又はその内容９を正しい形式にし（例えば、ヘッダ８及びトレーラ１０の追加）、データバス２を介してメッセージ７を伝達する（図２の矢印２２）。メッセージ７はデータバス２を介して直列伝送されるので、比較的長く掛かる可能性がある。本発明は、送信タスクが実行される間の任意の時点において、当該送信タスクが、例えば、特に緊急の他の送信タスクを先に実行すべきであるために、再び取り消される場合に関する（いわゆる、送信キャンセル）。送信タスクは、送信バッファ１１へのメッセージ７又はその内容９の格納で始まり、メッセージが成功裏に送信されたか否かという通信コントローラ４からのフィードバックの受信で終了する。
【００２３】
このような場合に、また他の場合にも、アプリケーションプログラム５は、送信タスクの結果、及び、場合によっては起こりうる送信タスクの取消しについて報知される必要がある。したがって、従来技術においては、送信バッファ１１は、送信タスクが成功裏に処理されたか否かについての情報を伝達しうる状態ビットと繋がれている。さらなる別のイベントについての情報は、特に送信タスクの取消しの際には、状態ビットからは得られない。ＣＡＮにおいては、送信タスクの取消しの際には、場合によっては既に開始されている送信プロセス（すなわち、スタート・オブ・フレーム（ＳＯＦ：Ｓｔａｒｔ  Ｏｆ  Ｆｒａｍｅ）が既に送信されている）は中断されずに、アービトレーションが失われるまで、エラーが発生するまで、又は、メッセージが成功裏に送信されるまで続行する。アプリケーションプログラム５は、送信タスクの取消し後にどのイベントが最後に起きたのかについて、状態ビットから情報を得られない。さらに、アプリケーションプログラム５は、送信タスクのイベントを待つ必要があり、この時間の間ある程度遮断されている。この点において、本願は改善案を提供しうる。
【００２４】
本発明によれば、各加入者ノード３内にはそれぞれ、メッセージメモリ１１、１２とは機能的に区別される送信イベントメモリ１３（Ｔｘ  Ｓｔａｔ）が設けられており、この送信イベントメモリ１３には、少なくとも１つの送信される又は送信されたメッセージ７についての送信イベント又は状態が格納されている。当然のことながら、通信ネットワーク１の全ての加入者ノード３に、送信イベントメモリ１３が設けられる必要はない。イベントメモリ１３は、好適に、随意にアクセルされるメモリ（ＲＡＭ）として構成され、ＦＩＦＯの形態により組織化されている。当然のことながら、イベントメモリ１３は、読み出し専用メモリ（例えば、フラッシュメモリ、ＲＯＭ、ＥＥＰＲＯＭ）としても構成されうる。イベントメモリ１３は、通信コントローラ４と一体に構成された構成要素として、又は、通信コントローラ４とは別体で、構成されうる。さらに、送信イベントメモリ１３は、メッセージメモリ１１、１２とは別体で、又は、メッセージメモリ１１、１２の一部として構成されうる。イベントメモリ１３がメッセージメモリ１１、１２の一部である場合、イベントメモリ１３の大きさは、ソフトウェアに関して、例えば設定ビットによって、個別の要請に応じて柔軟に定めることができる。
【００２５】
送信タスクの状態についての情報もまた、もはや、その内容が送信されるメッセージメモリ１１に格納されるではなく、特別な送信イベントリストに格納される。この送信イベントリストは、有利に、送信イベント又は取消しイベントごとのエントリを含む。本発明により、送信タスクの状態についての情報を通信モジュール４内で管理し、イベントメモリ１３に格納することが可能である（図２の矢印２３）。アプリケーションプログラム５は、イベントメモリ１３に格納された情報を、時間的に柔軟に読み出すことができる（図２の矢印２４）。送信タスクについての情報が、いまや、送信バッファ１１から完全に離されていることは、特に有利である。さらなる利点は、アプリケーションプログラム５がもはや、送信タスクについての状態情報を、様々なメッセージメモリ１１から集める必要がなく、情報が（送信イベントメモリ１３内の送信イベントリスト内の）固定の場所で、好適に時間的に整理されて呼び出し可能である点にある。送信タスクの取消し後に、メッセージメモリ１１はすぐに、送信タスク又は取消しの結果を待つ必要もなく、再び利用可能である。アプリケーションプログラム５は、後の時点において、イベントメモリ１３に格納された情報を読み出すことが可能であり、即時に（例えば、割り込みごとに）対応する必要はない。アプリケーションプログラム５がほとんど読み出さないために、イベントメモリ１３の容量を超える恐れがある場合には、最初のステップで警告信号が出力され、当該警告信号は、情報の少なくとも一部の、加速された読み出し、又はより頻度が高い読み出しのための対応する対応策と連携させることができる。実際にメモリ１３の容量を超える場合には、エラー信号が出力されうる。この場合に、現在の送信タスクの情報のために場所を作るために、送信イベントメモリ１３内の最古のエントリがその都度破棄されうる。
【００２６】
最も簡単な場合に、イベントメモリ１３は、送信タスクの、時系列に並べられたイベント（メッセージ７が送信された、送信タスクの取消しが行なわれた）を含む。以下に、イベントメモリ１３に格納可能なさらなる別のイベントの例を幾つか記載する。
１）メッセージ７が成功裏に送信された、
２）送信タスクの取消しにも関わらず、メッセージ７が成功裏に送信された、
３）送信タスクが取り消され、送信プロセスが開始されない、
４）送信タスクが取り消され、送信プロセスが、アービトレーションが失われた後に終了された、及び、
５）送信タスクが取り消され、送信プロセスがエラーの後に終了された。
【００２７】
送信される又は送信されたメッセージ７についての送信イベントに加えて、送信イベントメモリ１３には、さらなる別の情報も格納されうる。メモリ１３のメモリ素子の情報内容については、様々な拡張段階が存在する。好適に、メモリ１３には、メッセージ７の識別子（例えば、ＣＡＮ識別子）も格納される。識別子は、特定のメッセージに対する格納された情報の一意の識別及び対応付けを可能とするので、メッセージは、必ずしも発生順にメモリ１３に格納される必要はない。以下の追加的な情報、すなわち、
１）少なくとも１つの送信される又は送信されたメッセージ７のユーザデータ部９の長さを示すデータ長コード、
２）メモリ１３に格納されているイベントが何時起きたのかを示す時間標識、
３）送信タスクが出されたメッセージメモリ１１のアドレス、及び、
４）高次の送信プロトコルによって、比較的大きなデータ量が、同じ識別子の複数のメッセージ７で順次送信される場合に、データパケットを識別するシーケンスカウンタ、
のうちの１つ又は複数を送信イベントメモリ１３に記録することも構想可能である。
【００２８】
追加的な情報により、アプリケーションプログラム５による、格納された送信イベントの管理が軽減されうる。時間標識は、特定のアプリケーションプログラム５のために重要でありうる。加入者ノード３が複数の送信バッファ１１を有する場合に、送信タスクが出されたメッセージメモリ１１のアドレスによって、どの送信バッファ１１が新しい送信タスクのために空いているのかを確認することができる。例えば、ラインの末端で、又は、工場にある間に、制御装置として構成された、通信ネットワーク１の加入者ノード３が初めて新たにプログラミングされ、又は、新しいソフトウェアバージョンによりプログラミングされる場合に、シーケンスカウンタは、例えばソフトウェアのダウンロードの際に重要でありうる。その際、ソフトウェアは、複数の、例えば８バイトのデータパケットに分割され、当該データパケットはすべて同じ識別子を有する。シーケンスカウンタは、送信イベントがどのデータパケットに関してイベントメモリ１３に格納されたのか、又は、どのデータバケットが成功裏に伝達されているのかを示す。シーケンスカウンタは、アプリケーションプログラム５によって、送信タスクの付与の際に、メッセージメモリ１１に登録されている。
【００２９】
以下では、本発明にかかる方法が、図３に示されるフローチャートを用いて詳細に解説される。本方法は、機能ブロック３０で開始する。機能ブロック３１において、アプリケーションプログラム５は、伝送されるデータを送信バッファ１１へと伝達する。アプリケーションプログラム５は、機能ブロック３２で、送信コマンドを送信する。送信コマンドに応じて、通信コントローラ４が、機能ブロック３３において、送信バッファ１１からデータを読み出す。続いて、コントローラ４は、機能ブロック３４で、データ９を、利用される通信プロトコルに対応するメッセージに入れ、データを対応する形式にする。その後、機能ブロック３５で、メッセージ７が、データバス２を介して直列伝送される。メッセージ伝送は、ＳＯＦビットの送信で開始する。
【００３０】
送信タスクが実行される間の任意の時点において（機能ブロック３１〜３５）、送信タスクの取消しが必要となるイベント、例えば、現在の送信タスクのメッセージよりも緊急で重要な他のメッセージを、可能な限りすぐに送信するという要望が生じうる。このようなイベントの発生は、図３では、機能ブロック３６によって図示されている。示される例において、イベント３６は、直列メッセージ伝送の間に発生する。アプリケーションプログラム５は、現在の送信タスクを取り消す。
【００３１】
機能ブロック３７において、アプリケーションプログラム５は、送信タスクの取消し後にすぐに、新しいデータ、すなわち、より緊急で又はより重要なメッセージ７のデータを再び送信バッファ１１に格納することか可能である。アプリケーションプログラム５は、第１のメッセージ７の伝送の終了、又は、第１の送信タスクのイベントを待つ必要はない。これにより、ホストＣＰＵの利用度及び効率が改善されうる。第１の送信タスクの状態は、第１のメッセージの伝送の終了後の後の時点に、通信コントローラ４によって送信イベントメモリ１３に格納される。このことは、第１のメッセージの伝送の後の任意の時点に実行可能であり、図３では、機能ブロック３８により図示されている。
【００３２】
機能ブロック３９において、アプリケーションプログラム５は、さらなる別のメッセージの伝達のための送信コマンドを送信する。送信コマンドに応じて、通信コントローラ４は、機能ブロック４０で、送信バッファ１１から新しいデータを読み出す。続いて、コントローラ４は、機能ブロック４１で、データ９を、利用される通信プロトコルに対応した第２のメッセージ７に入れ、データを対応する形式にする。その後、機能ブロック４２で、第２のメッセージ７が、データバス２を介して直列伝送される。メッセージ伝送は、ＳＯＦビットの送信で開始する。第２の送信タスクの状態は、通信コントローラ４により、第２のメッセージの伝送後の、任意の後の時点において、送信イベントメモリ１３に格納される。このことは、図３に機能ブロック４３により図示されている。
【００３３】
第１のメッセージ７の伝送の終了後の任意の時点において、アプリケーションプログラムは、第１の送信タスクのイベントを、送信イベントメモリ１３から読み出す。このことは、示される例では、機能ブロック４４において、第１の送信タスクの取り消しを引き起こした第２のメッセージの伝送の終了後に行なわれる。第１の送信タスクの、読み出されたイベントにしたがって、アプリケーションプログラム５は、機能ブロック４５で、第１のメッセージ７の新たな伝送を促し（メッセージが成功裏に送信されていない）、又は、第１のメッセージ７の新たな伝送を促さない（メッセージが成功裏に送信されている）。その後、本方法は、機能ブロック４６で終了する。
【００３４】
本発明の重要な観点は、ホストＣＰＵの利用度が改善され、送信タスクの取消し後に、最短の時間内に新メッセージの伝送が開始されうること、個別の送信タスクに対するより詳細な情報が提供されること、イベントメモリへの送信タスクについての情報の格納と、当該情報の読み出しとが時間的に切り離されており、そのことによって、ホストＣＰＵの封鎖が起こらないことにある。
【図１】
2011520368.tif 000003
【図２】
2011520368.tif 000004
【図３】
2011520368.tif 000005
【国際調査報告】
2011520368.tif 000006
2011520368.tif 000007
2011520368.tif 000008
2011520368.tif 000009