JP6116707B2 - アウトオブオーダーイベントを処理するための装置、方法及びコンピュータプログラム - Google Patents

Description

本発明の実施形態は、概して、データネットワークに関し、特に、アウトオブオーダーイベント、即ち、元々の時間的順序が狂って受信された後発イベントを処理するための装置及び方法に関する。

例えば、ワイヤレスセンサネットワークのようなセンサネットワークが広く利用されている。例えば、様々なテクノロジーのワイヤレスセンサネットワークは、例えば、人間及び／又は他の物体の位置探知を行うことのような位置探知の目的ために使用される。ここで、「位置探知」とは、地理的な場所即ち位置の検知即ち決定を意味する。一部の特殊化した位置探知又は位置追跡システムは、例えば、サッカー、アメリカンフットボール、ラグビー、テニス等のようなスポーツイベントにおいて、プレーヤ及びその他の物体（例えば、ボール）を位置探知するために使用される。

プレーヤ及び／又はボールの収集された地理的場所即ちポジショニングデータにより、スポーツイベント全体、例えば、サッカーの試合に関連する、又は、個々のチーム又はプレーヤに関連する統計的な情報を導き出す。このように導き出された統計的な情報は、様々な点で関心を引き得る。一方では、特定の統計及びその分析は、スタジアム及び／又は自宅のテレビの前の観客にとって特に関心のあるものである可能性があるため、様々な商業的関心がある。従って、特定の統計を提供することは、スポーツイベントにおいてより多くの関心を集める可能性がある。他方で、生のポジショニングデータから導き出された統計データは、トレーニングの目的で使用されてもよい。ここでは、相手及び／又は自チームの動きだけでなく、個別のプレーヤのパフォーマンス及び／又は健康状態も分析される。

上述の位置探知又は位置追跡システムは、様々なテクノロジーに基づくことが可能である。例えば、場所情報は、ワイヤレス無線信号及び／又は磁場の評価に基づいて決定される。このために、一般的にセンサとも称される送信機及び／又は受信機は、システムによって位置探知される対象の個々の物体（例えば、プレーヤ、ボール等）に配置される。関心の対象である地理的領域の周囲の所定の場所、例えば、サッカー場に、対応する受信装置及び／又は送信装置が取り付けられる。二、三個の考え得る技術的選択肢の例を挙げれば、信号強度、信号伝搬時間及び／又は信号位相の評価により、異なる時刻における個別のプレーヤ又は物体の地理的位置を示すセンサデータストリームを生じる。典型的には、地理的場所のデータサンプルは、ある物体が何時、どの地理的位置にあったかを示すタイムスタンプに関連付けられる。この組み合わせられた情報の運動学的データにより、例えば、ｘ座標、ｙ座標、及びｚ座標を含む場所データに加えて、同様の速度（速さ）、加速等が提供されてもよい。本明細書では、以下において、ローカライゼーションセンサシステムによって配信される場所及び運動学的データは、（生の）センサデータとも呼ばれる。

ワイヤレス追跡システムの特定の例では、人々又は物体は、小型の送信機を装備し、この送信機は、靴、ユニフォーム及びボールに埋め込まれることができ、その信号は、観察下にある領域の周囲に設置された多くのアンテナによって拾い上げられる。受信機ユニットは、収集された信号を処理し、それらの到達時間（ＴｏＡ）値を決定する。伝搬遅延の差異の計算に基づき、各送信機の位置が連続的に決定される。更に、ワイヤレス追跡システムと一体化したコンピュータネットワークは、特定のイベントを検出するために位置即ちセンサデータを分析する。２．４又は５ＧＨｚ帯で運用されるため、追跡システムは、全世界的に、ライセンスフリー（ライセンス不要）である。

位置探知又は位置追跡システムから出力された生のセンサデータストリームに基づき、所謂「イベント」が検出される。それにより、イベント又はイベントタイプは、ある時点における関心の瞬間的な発生と定義されることができ、固有のイベントＩＤによって定義される。一般に、イベントは、検知されることができる関連量の分布における変化と関連付けられる。イベントインスタンスは、明確な時点におけるイベントタイプの瞬間的な発生である。一つのイベントは、追跡システムのセンサデータ（運動学的データ）に直接的に基づいたプリミティブイベント、又は、代わりに以前に検出されたその他のイベントに基づくである合成イベントとする。即ち、合成イベントは、生のセンサデータに直接的に依存するのではなく、他のイベントに依存する。ボールゲームの用途では、イベントは、例えば、「プレーヤＸはボールに当たる」又は「プレーヤＸはボールを保持している」とする。より複雑なイベントは、例えば、「オフサイド」又は「ファウル」とする。

各イベントインスタンスは、発生、検出、及び到着タイムというタイムスタンプである三つのタイムスタンプを有する。全てのタイムスタンプは、同一の離散時間領域にある。発生タイムスタンプｔｓは、イベントが実際に発生した時間であり、検出タイムスタンプｄｔｓは、イベントがイベント検出器によって検出された時間であり、到着タイムスタンプａｔｓは、イベントが特定のイベント処理システム（ＥＰＳ）ノードによって受信された時間である。発生タイムスタンプ及び検出タイムスタンプは、任意の受信ノードにおけるイベントインスタンスに固定されるが、到着タイムスタンプは、ネットワーク内の異なるノードで変化し得る。

基本的なセンサデータストリームに基づくイベントの検出（複合イベント処理：ＣＥＰ）は、過去数年でデータベース及び分散型システムコミュニティにおける関心を高めている。ネットワーク監視、ｅビジネス、健康管理、財務分析、及びセキュリティ又は上述のスポーツイベント管理等の用途を含む、広範囲且つ今日増え続ける用途は、理想的には時系列の一連のイベントの形を取るデータストリームに対するクエリ（疑問）を処理する能力に依存する。イベント検出とは、人間の介入を必要としない生のセンサデータ及び／又はやイベントの完全に自動化された処理を意味し、多くの用途と同様に、膨大な量の供給されたセンサデータ及び／又はイベントは、もはや人間によって捕捉又は処理されることはできない。例えば、プレーヤ又はスポーツ物体、例えばボールの高速の変化が予期される場合、生のセンサ（位置探知又は位置追跡）データは、基本的な（ワイヤレス）センサネットワークによって十分に高速なデータ速度で決定されなければならない。加えて、追跡対象の多数のプレーヤ及び／又は物体（例えば、サッカーでは、２２人のプレーヤと一つのボール）がある場合、一秒毎の全体的な地理的場所及び運動学的データサンプルの量は、特にリアルタイムのイベント処理要件に対して、非常に多くなる可能性がある。

従って、生のセンサ及び／又はイベントデータストリームは、分析され、信号通信され、完全に自動化されたとしても、依然として多過ぎる情報がある可能性があり、その多過ぎる情報は、場合によっては全て全く関心のないものである可能性がある。今後、ますます多くのデバイスがセンサを備え、それらのデバイスが決定したセンサデータ（例えば、スマートフォンのようなワイヤレスデバイスによって決定された天気や温度データ）がインターネット等のパブリックネットワークに提供される可能性を備えるため、この問題は、更に悪化すると思われる。このため、関心のある特定のイベントに更に加工される対象となるセンサデータの量は、急激に増大すると思われる。

自動化されたイベント検出は、生のセンサデータをピース毎に集約し、且つ、より抽象的で相互依存的なイベントを決定しようとすることによって、上記の急激な増大に対する対策を提供することができるが、これは、生のセンサデータ自体よりもはるかに多くの情報を伝達する可能性がある。例えば、上述のサッカー関連の例に加えて、このように決定されたイベントは、「車Ｘが交差点Ｙに位置する」又は「Ｘ号線で交通渋滞」を含む可能性がある。

自動化されたイベント検出において生じる問題は、場合によっては大規模並列センサ及び／又はイベントデータストリームに対してイベント検出を行うために必要な演算能力であり、これは全て少なくともほぼリアルタイムでの処理要件下にある。この問題は、例えば、イーサネット（登録商標）を介して通信する、例えば、コンピュータネットワークの異なる（即ち、分散された）ネットワークノード上で動作するイベント検出器の並列化によって解決される可能性がある。これにより、イベント検出器は、ユーザのイベント仕様に従ってイベント又はセンサデータストリームから関心のある特定のイベントを自動的に抽出する。個別のイベント検出器は、データネットワークの異なるネットワークノード上に分散されている可能性があり、異なるイベント検出器は、異なるネットワークルート及びブランチを使用してネットワークを移動するイベント及び／又はセンサデータを使用して通信する。これにより、生のセンサデータ及び／又はイベントは、例えば、ＵＤＰ（ユーザデータグラムプロトコル）、ＴＣＰ（トランスミッションコントロールプロトコル）／ＩＰ（インターネットプロトコル）等のような一部のトランスポートプロトコルに従ってデータパケットで伝達される。しかしながら、この概念は、異なるネットワークノード間でアンバランスになりかねない計算負荷に対して、及びネットワーク内のイベントデータストリームの同期化に対して新たな問題を生じる。適切な対策がなければ、異なるネットワークノード間の計算負荷は、アンバランスになり、ネットワークにおける個別のセンサ及び／又はイベントデータストリームは、互いに時間同期されず、即ち、個別のイベントは、夫々の元の時間的順序から外れてイベント検出器に到達し、それによって、誤った検出結果になる可能性がある。

一例としてのサッカーのシナリオを想定すると、複数の並列な自動的に動作するイベント検出器が、プレーヤＡからプレーヤＢへのパスを検出するとする。「パス」イベントを検出するために、以下の先行するイベントシーケンスが求められる。即ち、
１．「プレーヤＡはボールを保持している」、
２．「プレーヤＡはボールを蹴る」、
３．「ボールはプレーヤＡを離れる」、
４．「ボールはプレーヤＢの近くに来る」、
５．「プレーヤＢはボールに当たる」

「プレーヤＸはボールを蹴る」というイベントに対するイベント検出は、「ボール付近のプレーヤＸ」というイベントシーケンス及びそのボールの検出された加速度ピークに基づく。「プレーヤＸはボールを蹴る」という前記イベントに対して自動化されたイベント検出器を設定するための以下の選択肢がある。

個別の所要イベントを順々に待つことができる。全ての所要イベントが正しい（時間的な）順序で確認されれば（ここでは、分かり易いように、あらゆる失敗基準は無視される）、パスを目撃した又は経験したと言うことができる。しかしながら、複雑な応用では、全ての所要イベントの検出は、イベント検出器の並列化により、必ずしも単一のネットワークノード又はＣＰＵ（中央演算処理装置）にて発生する訳ではない。このため、個別の所要イベントが正しい所要順序にてイベント検出器に到達するとは必ずしも保証されない。これは、例えば、ネットワークジッター、変動する及び／又はアンバランスなＣＰＵ負荷又は増大したネットワーク負荷による可能性がある。例えば、ｅ_ｋ・ａｔｓ＜ｅ_ｋ＋１・ａｔｓ、（１≦ｋ＜ｎ）であるイベントインスタンスｅ_１、ｅ_２、…、ｅ_ｎを含むイベントストリーム、即ち、イベントストリームにおけるイベントが昇順に到着時間別にソート（分類）される場合を考える。１≦ｉ＜ｊ≦ｎである任意のイベントｅ_ｉ及びｅ_ｊが、ｅ_ｉ・ｔｓ＞ｅ_ｊ・ｔｓというように存在すれば、イベントｅ_ｊは、順番が狂ったイベントと呼ばれる。

従って、イベントをバッファし、正しいイベントパターンを求めてこのバッファを検索する。しかしながら、どのバッファサイズを使用するべきだろうか。もしパスが最大五つの時間単位（例えば、秒）内に発生しなければならない場合、パスを検出するまで、又はアボートするまで第一の関連イベントの後に最大五つの時間単位の期間内のイベントを考慮しなければならない。しかしながら、最後の関連イベントが計算的にかなり複雑であることも考えられ、小さな更なるバッファを必要とする。しかしながら、この更なるバッファのサイズとは何か。そして、「パス」イベントを入力イベントとして必要とする合成イベント検出器に関連するバッファサイズとは何か。

Ｓ．Ｂａｂｕ、Ｕ．Ｓｒｉｖａｓｔａｖａ、及びＪ．ＷｉｓｄｏｍのＫ‐ｓｌａｃｋアルゴリズム（“Ｅｘｐｌｏｉｔｉｎｇ ｋ−ｃｏｎｓｔｒａｉｎｔｓ ｔｏ ｒｅｄｕｃｅ ｍｅｍｏｒｙ ｏｖｅｒｈｅａｄ ｉｎ ｃｏｎｔｉｎｕｏｕｓ ｑｕｅｒｉｅｓ ｏｒｖｅｒ ｄａｔａ ｓｔｒｅａｍｓ”、ＡＣＭ Ｔｒａｎｓ．Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ、２９巻５４５〜５８０頁、２００４年）は、イベント検出においてアウトオブオーダーイベントを扱うための周知の方法である。Ｋ−ｓｌａｃｋは、イベントｅ_ｉが最大でもＫ個の時間単位（Ｋは既知のアプリオリでなければならない）しか遅延されることができないことを確認するために長さＫのバッファを使用する。しかしながら、分散型システムでは、イベント信号発生遅延は、システム／ネットワーク構成全体、即ち、イベント検出器の分布、及びネットワーク負荷及びＣＰＵ負荷に依存する。最終的なシステム構成も負荷シナリオも、コンパイル時には予測されない可能性がある。

Ｍ．Ｌｉ、Ｍ．Ｌｉｕ、Ｌ．Ｄｉｎｇ、Ｅ．Ａ．Ｒｕｎｄｅｎｓｔｅｉｎｅｒ、及びＭ．Ｍａｎｉによるアプローチ（“Ｅｖｅｎｔ ｓｔｒｅａｍ ｐｒｏｃｅｓｓｉｎｇ ｗｉｔｈ ｏｕｔ−ｏｆ−ｏｒｄｅｒ ｄａｔａ ａｒｒｉｖａｌ”、ｉｎ Ｐｒｏｃ．２７ｔｈ Ｉｎｔｌ．Ｃｏｎｆ．Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ Ｗｏｒｋｓｈｏｐｓ、（ワシントンＤＣ）、６７〜７４頁、２００７年）は、少なくともｅ_ｉ・ｔｓ＋Ｋ≦ｃｌｋである限りイベントｅ_ｉをバッファする。分散型システムにはグローバルクロックがないため、各ノードは、ローカルクロックをそれまでで最大の発生タイムスタンプに設定することによってそのローカルクロックと同期する。

Ｋ‐ｓｌａｃｋアプローチを実施するオーダリング（順序付け）ユニットは、所与のＫを備えるスライディングウィンドウを入力ストリームに適用し、イベントのタイムスタンプに従ってイベントを遅延させ、順序付けられた出力ストリームのイベントを作成する。しかしながら、単一の固定されたアプリオリＫは、分散された階層状のイベント検出器には有効ではない。Ｋ−ｓｌａｃｋは、合成イベントを発生するためにＫ個の時間単位を取るので、同様にＫ個の単位のためにバッファし、合成イベントを待つより高い階層のイベント検出器は、前記イベントを見逃す。待機時間はイベント検出器の階層に沿って合計される。

Ｍ．Ｌｉｕ、Ｍ．Ｌｉ、Ｄ．Ｇｏｌｏｖｎｙａ、Ｅ．Ｒｕｎｄｅｎｓｔｅｉｎｅｒ、及びＫ．Ｃｌａｙｐｏｏｌ（“Ｓｅｑｕｅｎｃｅ ｐａｔｔｅｒｎ ｑｕｅｒｙ ｐｒｏｃｅｓｓｉｎｇ ｏｖｅｒ ｏｕｔ−ｏｆ−ｏｒｄｅｒ ｅｖｅｎｔ ｓｔｒｅａｍｓ”、ｉｎ Ｐｒｏｃ．２５ｔｈ Ｉｎｔｌ．Ｃｏｎｆ．Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ、（上海、中国）、７８４〜７９５頁、２００９年）は、イベント検出器毎に個別のＫを特定することによって上述のような問題を回避する。各Ｋ_ｎ（ｎは階層レベル）は、最大値（Ｋ_ｎ−１）よりも大きい値、即ち、全ての購読済みイベントの最大遅延よりも大きな値に設定されなければならない。それにより、購読済みイベントは、夫々のイベント検出器にとって関心のあるイベントである。階層レベルｎのイベント検出器は、より下層の階層レベルのイベントを購読し、それを入力として使用して、より上層の階層イベントを検出する。これは一見して良さそうに聞こえるが、全てのＫ_ｊに関して適切な値を選択することは困難であり、アプリケーション指定的及びトポロジー指定的であり、注意深く測定した後でしか行われない。保守的で過度に大きなＫ_ｊは、結果的に、高いメモリの需要がある大きなバッファ、及び階層的なＣＥＰに対する長時間の遅延（遅延が加算されるため）となる。大き過ぎるＫ_ｊは、回避されなければならない。理論的には、汎用的なシステムに関しては、レイテンシが、イベント検出器の分布及び具体的な基礎となるネットワークトポロジーに依存するため、最小／最良なＫ_ｊは、ランタイム測定によってしか発見されない。更に、最良のＫ_ｊ値は、検出器が移動すると実行時に変化する。

既に説明したように、イベントに基づくシステム（ＥＢＳ）は、様々な領域における監視、スポーツ、株取引、ＲＦＩＤシステム、及び不正検出等、多くの適用分野におけるデータストリームのほぼリアルタイムの反応分析に対する選択の方法として使用される。ＥＢＳは、高いデータ負荷をイベントに変え、それらのイベントが、エンドユーザの利用に適したレベルの粒度に達するまで、又は何らかのアクションを起動するために、それらのイベントをフィルタリングし、集約し、より高いレベルのイベントに変換する。性能要求が高く、イベント処理は、分散型の演算システムの幾つかの演算ノードに分配される必要があることが多い。多くの用途では、最小のイベント遅延によるイベント検出も求められる。例えば、分散型ＥＢＳは、自律的なカメラ制御システムを関心地点まで導くためにイベントを検出する。かかるシステムは、図１に概略的に示されている。

図１は、関心のある一つ以上の物体に取り付けられることができる無線送信機１１２を含む追跡システム１１０（例えば、ＲＴＬＳ）に結合されたＥＢＳ１００を示す。送信機１１２によって発せられ、生のセンサデータを伝送する無線信号は、アンテナ１１４によって受信され、分散型計算ネットワーク１２０に転送される。計算ネットワーク１２０の計算ノードは、追跡システム１１０によって配信されるセンサデータからプリミティブイベントを抽出する。これらのプリミティブイベントは、ＥＢＳ１００の一つ以上の計算ノード上で動作する一つ以上のイベント検出器１３０によって処理される。それにより、イベント検出器１３０は、イベント検出器の階層を形成することができ、最も低い階層レベルのイベント検出器１３０‐１、１３０−２は、センサデータ及び／又はそこから抽出されたプリミティブイベントを消費することができ、より高い階層レベルのイベント検出器１３０−３、１３０−４、１３０−５は、以前に検出されたより低いレベルのイベントに基づく合成イベントを消費する。関心のある特定のイベント（例えば、プレーヤはボールに当たる）がＥＢＳ１００によって検出されると、カメラ１４０は、関心のある検出されたイベントのビデオ映像を補足するように自動的に誘導される。これは、明らかに、低い検出レイテンシを必要とする。

高速のイベントストリームを処理するために、ＥＢＳ１００は、例えばイベント検出階層を構築するために出版‐購読型によってリンクされた幾つかのイベント検出器１３０−１乃至１３０−５に計算を分配する。これらのイベント検出器１３０は、計算ネットワーク１２０が含む利用可能なマシンに分散させる。イベント検出器１３０における異なるイベント伝搬遅延によって生じる誤った時間的順序を無視することにより、誤検出を生じる可能性がある。イベント検出器１３０自体は、一般に、イベント遅延がランタイム以前は未知のものであるため、低いレイテンシでイベントをリオーダリングすることができない。更に、動的に変化するアプリケーション指定遅延タイプ（例えば検出遅延のような）も存在する可能性があるため、利用可能な計算ノードへのイベント検出器へのアプリオリな最適な割り当てが存在しない。従って、分散型ＥＢＳでは、ミドルウェアは、典型的には、イベント検出器、それらの分布、及びそれらの購読済みのイベントに関するいかなるアプリオリ知識なしに、アウトオブオーダーイベントに対応する可能性がある。それにより、ミドルウェアは、一般的に、オペレーティングシステムから利用可能なイベント検出器を越えて（分散された）ソフトウェアアプリケーションにサービスを提供するソフトウェア層を示す。

バッファリングミドルウェアアプローチは、しばらくの間イベントを保留し、イベントをソートし、イベントを順番に検出器に放出する。主な問題点は、オーダリングバッファのサイズである。それが小さ過ぎると、検出に失敗する。それが大き過ぎると、時間を浪費し、高い検出レイテンシを招く。尚、待機時間は、検出階層に沿って加算される可能性がある。最良のバッファサイズは、未知であり、何らかの動的な予測不可能な行動に依存することもある。更に、アウトオブオーダーになることがないイベント又は問題なくアウトオブオーダーで処理されることができるイベントをバッファする必要がない。バッファリングミドルウェアは、信頼できるイベント検出の基礎とすることができるが、多くのイベントタイプにとってコストが掛かり過ぎ、待機時間によって束縛されるため、より高速なＣＰＵからの利益を受けることがない。

推測的ミドルウェアは、アウトオブオーダーイベント到着に対処する他の一つのアプローチであるが、生のデータストリームに推測的に作用する。これは、バッファリングがないため、より高速である。アウトオブオーダーイベントが受信される度に、誤って放出されたイベントは取り消されることができ、イベントストリームがリプレイされる。イベント取り消し及びストリームリプレイへの試みは、アウトオブオーダーイベントの数、及びイベント検出階層の深度と共に増加する。これは、メモリ管理への重要な課題であり、ＣＰＵを消耗する可能性があり、高い検出レイテンシ、更にはシステム障害を招く可能性がある。上述のバッファに基づくアプローチとは対照的に、より強力なＣＰＵが有用になるが、高い検出レイテンシのリスクは依然として残っている。

Ｂａｄｒｉｓｈ Ｃｈａｎｄｒａｍｏｕｌｉ、Ｊｏｎａｔｈａｎ Ｇｏｌｄｓｔｅｉｎ、及びＤａｖｉｄ Ｍａｉｅｒ（「Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｄｙｎａｍｉｃ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ ｏｖｅｒ Ｄｉｓｏｒｄｅｒｅｄ Ｓｔｒｅａｍｓ」、ＶＬＤＢ Ｅｎｄｏｗｍｅｎｔ、３巻、２２０〜２３１頁、シンガポール、２０１０年）は、パンクチュエーション（句読法）を用いることによるストリームリビジョンを可能にする。これらは、無効になったシーケンスを取り除く順番が狂ったイベントのための挿入アルゴリズムを与える。しかしながら、無効になったシーケンスを取り除くことは高分散型のシステムには可能ではない。無効化される必要があるイベントは、他のノード上で既に消費／処理されている可能性がある。Ｃｈａｎｄｒａｍｏｕｌｉ等は、シーケンス数によって又は浄化することによって推測を制限する。受信機は、前者を用いて、特定のイベントが安定した割合で発生するという稀なケースにおいて無秩序情報を推定する。後者は、パンクチュエーションに基づく環境にのみ有用であり、この環境は、パンクチュエーションをイベント検出器の最新のイベントタイムスタンプに設定することによってクエリウィンドウを制限するためにイベント定義を組み込まなければならない。しかしながら、この情報は、ミドルウェア技術が前記情報にアクセスすることができない時に汎用的なバッファリング拡張として使用されることができない。

Ｓ．Ｂａｂｕ、Ｕ．Ｓｒｉｖａｓｔａｖａ、及びＪ．ＷｉｓｄｏｍのＫ‐ｓｌａｃｋアルゴリズム（"Ｅｘｐｌｏｉｔｉｎｇ ｋ−ｃｏｎｓｔｒａｉｎｔｓ ｔｏ ｒｅｄｕｃｅ ｍｅｍｏｒｙ ｏｖｅｒｈｅａｄ ｉｎ ｃｏｎｔｉｎｕｏｕｓ ｑｕｅｒｉｅｓ ｏｒｖｅｒ ｄａｔａ ｓｔｒｅａｍｓ"、ＡＣＭ Ｔｒａｎｓ．Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ、２９巻５４５〜５８０頁、２００４年） Ｍ．Ｌｉ、Ｍ．Ｌｉｕ、Ｌ．Ｄｉｎｇ、Ｅ．Ａ．Ｒｕｎｄｅｎｓｔｅｉｎｅｒ、及びＭ．Ｍａｎｉによるアプローチ（"Ｅｖｅｎｔ ｓｔｒｅａｍ ｐｒｏｃｅｓｓｉｎｇ ｗｉｔｈ ｏｕｔ−ｏｆ−ｏｒｄｅｒ ｄａｔａ ａｒｒｉｖａｌ"、ｉｎ Ｐｒｏｃ．２７ｔｈ Ｉｎｔｌ．Ｃｏｎｆ．Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｓｙｓｔｅｍｓ Ｗｏｒｋｓｈｏｐｓ、（ワシントンＤＣ）、６７〜７４頁、２００７年） Ｍ．Ｌｉｕ、Ｍ．Ｌｉ、Ｄ．Ｇｏｌｏｖｎｙａ、Ｅ．Ｒｕｎｄｅｎｓｔｅｉｎｅｒ、及びＫ．Ｃｌａｙｐｏｏｌ（"Ｓｅｑｕｅｎｃｅ ｐａｔｔｅｒｎ ｑｕｅｒｙ ｐｒｏｃｅｓｓｉｎｇ ｏｖｅｒ ｏｕｔ−ｏｆ−ｏｒｄｅｒ ｅｖｅｎｔ ｓｔｒｅａｍｓ"、ｉｎ Ｐｒｏｃ．２５ｔｈ Ｉｎｔｌ．Ｃｏｎｆ．Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ、（上海、中国）、７８４〜７９５頁、２００９年） Ｂａｄｒｉｓｈ Ｃｈａｎｄｒａｍｏｕｌｉ、Ｊｏｎａｔｈａｎ Ｇｏｌｄｓｔｅｉｎ、及びＤａｖｉｄ Ｍａｉｅｒ（「Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｄｙｎａｍｉｃ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ ｏｖｅｒ Ｄｉｓｏｒｄｅｒｅｄ Ｓｔｒｅａｍｓ」、ＶＬＤＢ Ｅｎｄｏｗｍｅｎｔ、３巻、２２０〜２３１頁、シンガポール、２０１０年）

従って、アウトオブオーダーイベント到着に対処するための改善されたアプローチを提供することが望ましい。

バッファに基づくアプローチと推測的アプローチの両方の利点を組み合わせることが、実施形態の一つの知見である。従って、実施形態は、バッファリングＥＢＳに追加される新規の推測的処理に関連する。そのためには、
（１）ミドルウェアは、イベントセマンティクスとそれらの使用が両方とも高度にユーザ指定的且つアプリケーション指定的であるため、イベント検出器によってイベントセマンティクスもそれらの使用も利用することができない。
（２）推測にも拘らず、バッファリングミドルウェアは、イベント検出を信頼できるものに維持することができ、即ち、システム障害を防止するためにフォールスポジティブ又はフォールスネガティブ検出が回避される。従って、不正確な近似手法を使用するという選択肢又はオーバーロードされたシステムを生じるイベントを廃棄するという選択肢がない。

上記問題は、イベントの大部分をソートするため、しかしながら、スナップショットイベント検出器に、直ぐに放出されるそれらのイベントを推測的且つ早期に処理させるためにバッファリングを使用することによって解決されることが分かった。イベント検出器、即ち、それらの内部状態及び／又は出力は、リプレイが発生する時に回復される。推測の程度は、ＣＰＵアベイラビリティに合うように適合され、アイドル状態のＣＰＵ上での完全な推測からビジーなＣＰＵ上での単純なバッファリングに及ぶ。提案された技術は、内部イベントセマンティクスに関する知識無しに機能し、いかなる出版購読に基づくバッファリングミドルウェアに対して使用されることができ、クエリ言語又はイベント近似を使用しない。

第一の態様によれば、実施形態は、イベント検出器に関するアウトオブオーダーイベントストリームのイベントをオーダリングする方法を提供する。イベントストリームによって伝達されるイベントは、個別のイベント発生時間及びＫ個の時間単位の最大伝搬遅延までの個別のイベント伝搬遅延を、夫々、それに関連付けている。それにより、最大遅延Ｋは、イベントがその実際のイベント発生からイベント検出器へ移動するのにかかる最大遅延を示す。本方法は、イベントストリームから受信されたイベントを、オーダリングユニットとも呼ぶことができるイベントバッファに提供するステップを備える。更に、本方法は、（時間的に）順序付けられたイベントを得るために前記イベントバッファにおいて受信されたイベントを夫々の発生時間に従って（時間的に）オーダリングするステップを備える。また、本方法は、αが０＜α＜１である推測量を示すとするとｅ_ｉ・ｔｓ＋α^＊Ｋ≦ｃｌｋとなるように、イベント発生時間ｅ_ｉ・ｔｓを有する順序付けられたイベントｅ_ｉを、イベントバッファから、（最も早い）時刻ｃｌｋに前記（スナップショット）イベント検出器に推測的に転送するステップを備える。イベント検出器において、イベントは、少なくとも一つの推測的に転送されたイベントに基づいて検出される。また、検出されたイベントのイベント発生時間は、前記少なくとも一つの推測的に転送されたイベントに基づいて設定される。一部の実施形態では、前記イベント検出器は、前記少なくとも一つの転送されたイベントのイベント発生時間に応じて前記検出されたイベントのイベント発生時間を設定する。例えば、少なくとも第一及び第二の転送されたイベントに基づいて合成イベントが検出される。前記イベント検出器は、例えば、前記第一又は第二のイベントの前記発生時間のいずれが、前記合成イベントの発生時間をトリガするかに応じて、前記転送された第一又は第二のイベントのイベント発生時間に依存する又は対応する前記合成イベントのイベント発生時間を設定する。

更なる態様によれば、実施形態は、イベント検出器に関してアウトオブオーダーイベントを備えるイベントストリームのイベントをオーダリングする装置であって、前記イベントが、個別のイベント発生時間ｅ_ｉ・ｔｓ及びＫ個の時間単位の最大遅延までの個別のイベント伝搬遅延をそれに関連付けている装置も提供する。それにより、本装置は、受信されたイベントを前記イベントストリームからイベントバッファ（オーダリングユニット）に提供するように構成された入力を備える。本装置は、（時間的に）順序付けられたイベントを得るために前記バッファにおいて受信されたイベントを夫々の発生時間ｅ_ｉ・ｔｓに従ってオーダリングするように構成されたソーターエンティティを更に備える。また、本装置は、αが０＜α＜１である推測量を示すとするとｅ_ｉ・ｔｓ＋α^＊Ｋ≦ｃｌｋとなるように、イベント発生時間ｅ_ｉ・ｔｓを有する順序付けられたイベントｅ_ｉを、イベントバッファから、（最も早い）時刻ｃｌｋに前記（スナップショット）イベント検出器に推測的に転送するように構成された出力を備える。推測的に転送することは、最大遅延Ｋに対応するバッファリング時間が経過する前に前記バッファからイベントを転送又は送信することと理解される。本装置のイベント検出器は、少なくとも一つの推測的に転送されたイベントに基づいてイベントを検出するように構成される。また、イベント検出器は、前記少なくとも一つの推測的に転送されたイベントに基づいて前記検出されたイベントのイベント発生時間を設定するように構成される。一部の実施形態では、前記イベント検出器は、前記少なくとも一つの転送されたイベントのイベント発生時間に応じて前記検出されたイベントのイベント発生時間を設定する。例えば、前記イベント検出器は、少なくとも第一及び第二の転送されたイベントに基づいて合成イベントを検出するように、且つ、前記第一又は第二のイベントの発生時間のいずれが前記合成イベントの発生時間をトリガするかに応じて、前記転送された第一又は第二のイベントのイベント発生時間に依存する又は対応する前記合成イベントのイベント発生時間を設定するように構成される。

幾つかの実施形態は、本装置内に設置されたデジタル制御回路を備え、前記デジタル回路は、例えば、分散型計算ネットワークの一つ以上の計算ノードにおいて実施される。かかるデジタル制御回路網、例えば、デジタル信号プロセッサ（ＤＳＰ）、アプリケーション特定集積回路（ＡＳＩＣ）、又は汎用コンピュータは、それ相応にプログラムされる必要がある。しかし、更に他の実施形態は、コンピュータプログラムがコンピュータ又はデジタル信号プロセッサ上で実行される場合に、本方法の実施形態を実行するためのプログラムコードを有するコンピュータプログラムも提供する。

実施形態によれば、イベント検出器は、分散型計算システムのノード上で実行されているコンピュータプログラムのインスタンスとして理解される。イベント検出器は、前記コンピュータプログラムのプログラムコードと、その親アクティビティとを備える。前記分散型システムは、例えば、分散型コンピュータネットワーク又はマルチコアプロセッサである。コンピュータネットワークの場合、ネットワークノードであるノードは、例えば、イーサネット（登録商標）、又は一部のその他の形状のネットワーキングテクノロジーを介してその他のネットワークノードと通信するコンピュータデバイス又は処理ユニット、例えば、そのＣＰＵを備える。即ち、本発明の更なる態様によれば、少なくとも一つの（生の）センサデータストリームに更に基づくアウトオブオーダーの低レベルのイベントストリームに基づいてより高いレベルのイベントを決定する分散型計算システムも提供される。前記分散型計算システムは、コンピュータネットワークであるが、夫々がそれに関連させたイベント検出器を有する複数の分散型ノードと、アウトオブオーダーイベントストリームのイベントをオーダリングする装置の少なくとも一つの実施形態とを備える。

幾つかの実施形態では、前記分散型計算システム又はその装置は、所定の地理的領域内の物体を位置探知したり追跡したりする位置探知システムに結合され、前記位置探知システムは、前記少なくとも一つのセンサデータストリームを前記分散型計算システムに提供し、データを伝達する前記センサデータストリームは、前記位置探知された物体に関する地理的位置及び／又は運動学的なデータを示す。ＲＴＬＳ等の位置探知システムは、本明細書の導入部で既に記述されているワイヤレスセンサネットワークに基づく。

実施形態は、イベントを遅延及び／又は時間的に順序付けたりするが、少なくともその一部を推測的に処理するためにバッファリング技術を使用することを提案する。実施形態は、検出レイテンシが最小になるように利用可能なシステムリソースに合うようにランタイムにおける推測の程度を適応する。実施形態は、毎秒数千個のアウトオブオーダーセンサイベントによるリアルタイムロケーティングシステム（ＲＴＬＳ）からの合成データと実際のセンサデータの両方において先行技術のアプローチよりも優れている。

以下では、専ら一例として、且つ添付の図面を参照して、本発明の一部の実施形態が記述される。

図１は、一実施形態に係るイベントに基づくシステム（ＥＢＳ）に基づく自動的に制御されたカメラシステムを概略的に示す。 図２は、一実施形態に係る分散型の出版／購読ＥＢＳノード／システムを示す。 図３ａは、例示的なステートマシン及びアウトオブオーダーイベントストリームを示す。 図３ｂは、例示的なステートマシン及びアウトオブオーダーイベントストリームを示す。 図４は、イベント処理階層を例示的に示す。 図５は、一実施形態に記載のアウトオブオーダーイベントストリームのイベントを整理する方法のフローチャートを概略的に示す。 図６ａは、新たに到着したアウトオブオーダーイベントの挿入の実施形態を示す。 図６ｂは、新たに到着したアウトオブオーダーイベントの挿入の実施形態を示す。 図７は、推測量α＝１／３である一実施形態に係る推測的オーダリングを例示的に示す。 図８は、一実施形態に係るアウトオブオーダーイベントの挿入及び必要である可能性のあるポインタ再配置のための疑似コードを示す。 図９は、一実施形態に係るスナップショット回復及び推測量α＝１／３による推測的オーダリングユニットを示す。 図１０は、一実施形態に係るイベントの推測的放出のための疑似コードを示す。 図１１ａは、新たに到着するアウトオブオーダーイベントの受信時におけるイベント取り消しの実施形態を示す。 図１１ｂは、新たに到着するアウトオブオーダーイベントの受信時におけるイベント取り消しの実施形態を示す。 図１２は、推測量αの適応を示す。 図１３は、一実施形態に係る単純なバッファリング及び推測的バッファリングによるレイテンシの比較を示す。 図１４は、推測量αの適応による負荷挙動を示す。 図１５は、異なる値のαに関する様々な負荷シナリオを示す。

様々な例の実施形態は、一部の例の実施形態に示す添付の図面を参照して更に詳細に記述される。図面では、層及び／又は領域の厚みは、分かり易いように誇張されている場合がある。

従って、例の実施形態は、様々な機能的及び構造的変更及び別の形態が可能であるが、その実施形態は、図面において一例として示され、本書において詳細に記述される。しかしながら、当然のことながら、例の実施形態を、開示された特定の機能的及び構造的形態に限定する意図はなく、むしろ、例の実施形態は、本発明の範囲内に含まれる全ての機能的及び構造的変更、等価物、及び代替物を含むべきである。同様の数字は、図面の記述を通して同様又は類似の要素を指す。

当然のことながら、ある要素が、他の要素に「接続され」又は「連結され」という場合、その要素は、他の要素に直接的に接続又は連結されることができ、或いは、介在要素が存在してもよい。一方、ある部材が「直接的に接続され」又は「直接的に連結され」という場合、介在要素は存在しない。要素同士の関係を記述するために使用されるその他の用語は、同様に解釈されるべきである（例えば、「の間に」に対して「の間に直接的に」、「に隣接して」に対して「に直接的に隣接して」等）。

本書で用いられる専門用語は、単に特定の実施形態を記述することを目的とするものであり、例の実施形態を制限することを意図しない。本書で用いられるように、単数形の「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈が複数形は含まないことを明らかに示していない限りは、複数形も含むことを意図する。更に、当然のことながら、「を備える（ｃｏｍｐｒｉｓｅｓ）」、「を備える（ｃｏｍｐｒｉｓｉｎｇ）」、「を含む（ｉｎｃｌｕｄｅｓ）」及び／又は「を含む（ｉｎｃｌｕｄｉｎｇ）」という用語は、本書で使用される場合、記述された特徴、整数、ステップ、オペレーション、要素及び／又はコンポーネントの存在を特定するが、一つ以上の他の特徴、整数、ステップ、オペレーション、要素、コンポーネント及び／又はそのグループの存在又は追加を除外しない。

そうでないと定義されない限り、本書で用いられる全ての用語（技術的及び科学的用語を含む）は、例の実施形態が属する技術における通常の技術を有する者によって共通に理解される意味と同一又は類似の意味を有する。更に、当然のことながら、用語、例えば、一般的に用いられる辞書における定義される用語は、関連技術の文脈における意味と一致する意味を有するものと解釈されるべきであり、本書において明示的に定義されない限りは、理想化された意味又は過度に形式的な意味で解釈されることはない。

図２は、例示的ＥＢＳ２００を示し、例示的ＥＢＳ２００は、例えばセンサデータ２０２（例えば、ＲＦＩＤの読み出し）を収集することができるアンテナの形態としての数個のデータ分配装置（ＤＤＳ）１１４と、同一のイベント処理ミドルウェア２２０を実行することができるネットワーク内の数個のノード２１０−１、２１０−２とを備える。ミドルウェア２２０は、イベント検出器２１０毎にリオーダリングバッファ２２２を形成する。実施形態によれば、このリオーダリングバッファ２２２は、各々、推測ユニット２２４によって包まれる。リオーダリングバッファ２２２と推測ユニット２２４は、共に、推測イベントバッファ／オーダリングユニット２２６を各々形成し、推測イベントバッファ／オーダリングユニット２２６は、実施形態に係る、アウトオブオーダーイベントストリーム２０４のイベントをオーダリングするための装置と見なされることもできる。

図２から分かるように、ミドルウェア２２０は、（センサ）イベントソースの基礎となるネットワーク２３０によってアドバタイズされるイベント２０４を購読する。購読されたイベント２０４は、より高いレベルのイベントを検出／決定するための各関連するイベント検出器２１０−１、２１０−２によって使用される。ネットワーク２３０から基礎となる購読されたイベント２０４に基づいて正確に上記のようなより高いレベルのイベントを決定するために、ネットワーク２３０からのイベントは、各推測的オーダリングユニット２２６−１、２２６−２によって一時的にリオーダリングされなければならない。このために、ミドルウェア２２０は、処理遅延及びネットワーク遅延又は検出遅延等の全ての遅延タイプに対処することができ、関連するイベント検出器２１０−１、２１０−２が（Ｃ＋＋のようなネイティブなプログラミング言語又は何らかのイベント定義言語、即ちＥＤＬのいずれかにて）実行する複合的なイベントパターンを知っている必要はない。イベント検出器２１０−１、２１０−２は、より高いレベルのイベント検出器等の他のイベント検出器がどのマシンで作動しているかも、それらのランタイム構成も知っている必要はない。開始時、ミドルウェア２２０は、イベント遅延に関する知識を持たなくてもよいが、他のミドルウェアインスタンスにイベント出版及び購読（アドバタイズメント）を通知する。従って、ミドルウェア２２０は、汎用的でありカプセル化される。

実施形態の以下のより詳細な記述に関して、以下の専門用語が使用される。即ち、イベントタイプ、インスタンス、タイムスタンプである。
イベントタイプは、関心を引く発生即ち関心のある発生を定義し、固有のイベントタイプＩＤによって識別される。
イベントインスタンスは、ある時点におけるイベントタイプの瞬間的な発生である。イベントインスタンスは、例えば、プリミティブな（センサ）又は合成イベントとする。
一つのイベントは、三つのタイムスタンプを有する。即ち、発生時間、検出時間、及び到着時間である。全てのタイムスタンプは、我々の時間モデルに従って同一の離散時間ドメインに存在する。イベントは、その発生タイムスタンプｔｓにおいて、又は略して単にタイムスタンプにおいて、発生する。イベントは、その検出タイムスタンプｄｔｓにおいて検出される。到着タイムスタンプａｔｓでは、イベントは、特定のＥＢＳノードに受信されることができる。発生タイムスタンプ及び検出タイムスタンプは、任意の受信ノードにおいてイベント毎に固定されることができるが、到着タイムスタンプは、ネットワーク内の異なるノードで変化する。

イベントストリームｅ_１、．．．、ｅ_ｎを考える。事前定義されたタイプのＩＤのイベントは、イベント検出器に関連するローカルクロックを設定するために使用される。次に、ｅ_ｉ・ｔｓ≦ｅ_ｊ・ｔｓ≦ｅ_ｋ・ｔｓとなるようにｅ_ｉ・ｉｄ＝ｅ_ｋ・ｉｄ＝ＩＤ且つｅ_ｉ・ａｔｓ≦ｅ_ｊ・ａｔｓであるｅ_ｉ、ｅ_ｋが存在しなければ、即ち、ｅ_ｊ・ａｔｓが上記二つの連続するクロックアップデート間に当てはまらなければ、ｅ_ｊはアウトオブオーダーとみなされる。
イベント検出器の入力は、通常全イベントのサブセットである潜在的には無限のイベントストリームとする。イベントストリームは、その特定のイベント検出器に関して少なくとも関心のあるイベントタイプを保持することができ、幾つかの無関係なイベントも含む可能性がある。

以下の例を考える。即ち、あるプレーヤがボールを蹴るということを検出するためには、ボールはプレーヤ（Ａ）の近くにあるというイベントを待ち、次に、ボールは蹴られるというイベント、即ち、加速のピーク（Ｃ）を待つ。前記二つのイベントの間には、ボールはプレーヤ（Ｂではない）から離れるというイベントは存在しなくてもよいが、それは、その場合、ボールはグラウンドに落下したばかりであるからである。より形式的には、イベントＡ（近く）を受信し、続いてイベントＣ（加速ピーク）を受信し、その間にイベントＢ（近くない）を受信しなければ、イベントＤを生じる。この文脈において、図３ａは、イベントＤに関する有限状態オートマトン３００を描いている。簡単にするために、プレーヤ識別のための送信機ＩＤの区別は省いている。

図３ｂには例示的イベントストリーム２０４が描かれている。ストリーム３００におけるイベント（Ａ、Ｂ、Ｃ、Ｅ）はアウトオブオーダーであり、イベントの単純な処理は、Ａ４／Ｃ５からイベントＤを発生させるようにはイベント検出器を導かず、Ａ２／Ｃ１からＤを検出する。ここでは、記号Ａ４は、イベントＡが発生時間ｔｓ＝４を有することを表す簡易化した記号である。同様に、Ｃ５は、イベントＣが発生時間ｔｓ＝５を有することを表す省略形である。

正しいイベント検出を行うために、ＥＢＳ２００のバッファリングミドルウェア２２０は、イベント入力ストリーム２０４とイベント検出器２１０との間にＫ−ｓｌａｃｋに基づいて、動的に生成されたオーダリングユニットをマウントする。それにより、Ｋ−ｓｌａｃｋは、イベントｅ_ｉは、最大でＫ個の時間単位だけ遅延する可能性があると推測する。従って、特定のイベント検出器２１０に関して、潜在的なアウトオブオーダーイベントを有するストリームを取り、ソートされたイベントストリームを生成するオーダリングユニットは、Ｋを、全購読済みイベントの時間単位における最大の遅延とする必要があり、イベントオーダリングのためにＫサイズのバッファを必要とする。従って、イベントストリームからローカルクロックｃｌｋを抽出し、アウトオブオーダーイベント処理を回避するために必要な分だけ遅いイベントと早いイベントの両方を遅らせる。

この文脈において、図４は、高いレベルの「ゴール前で阻まれたシュート」イベント４７２を検出するための例示的イベント処理階層４００を示す。見て分かるように、レベル７の「ゴール前で阻まれたシュート」イベント４７２は、複数のより低いレベルのイベント４１２乃至４６２に基づいている。それにより、各より低いレベルのイベント４１２乃至４６２は、それに関連付けられた専用のイベント検出器を有する。このイベント処理階層４００における各イベント検出器は、独自の動的にパラメータ化されたオーダリングユニットを有することができ、低いレイテンシによってイベントを検出するように構成される。例えば、「プレーヤはボールに当たる」というイベント検出器（レベル５）は、図３ｂのパターンと類似のパターンを実行する。そのオーダリングユニットは、検出器に対して正しく並べられたイベント入力を保証するために最大で一秒のレイテンシを導入する。これにより、少なくとも一秒だけ「ゴールにシュート」というイベント（レベル６）の検出が遅れ、「ゴール前で阻まれたシュート」イベント４７２は、更に遅延される。

階層４００を通して全イベント検出器４１２乃至４７２に対して最小のＫ値が使用されても、結果として生じる結合、即ち蓄積レイテンシは、不必要に高くなる可能性があり、推測的処理がより良い選択肢となる可能性がある。

図３ｂの例が最小のＫ_Ｄ＝３を必要とすると仮定する。これにより、イベントＤは三つの時間単位の遅延でしか検出されることができないので、少なくとも三つの時間単位だけ上位の処理階層におけるいずれかのイベントの検出が遅延する。しかしながら、タイプＢのイベントが稀であると仮定する。その場合、イベントＢの発生を除外するまでイベントＤの検出を遅延するのではなく、イベントＢが実際に発生するという稀なケースにおいてＤの誤検出を取り消す方が有益である可能性がある。従って、図３ｂに描かれたイベントストリームに関して、ｃｌｋが８に設定される（Ｋ_Ｄ＝３のため）前にＡ４／Ｃ５からイベントＤを検出する。後でイベントＤの検出を取り消すべきイベントＢがあれば、Ｄを取り消す。従って、イベントＤを検出するために使用されるイベント検出器は、より低いレイテンシでより高いレベルのイベント検出器を起動するために使用されることができる事前のイベントを生成する。従って、実施形態の一つの重要な思想は、両技術を組み合わせること、及びイベントの一部を早期に処理するために推測ユニット２２４にＫ−ｓｌａｃｋバッファ２２２を包むことである。

追加された推測により、アウトオブオーダーイベントが全くなければ検出レイテンシを改善することができ、それは、イベント検出器が放出するものは、更に上方の検出器階層から取り消される必要がないからである。しかしながら、イベントストリームにおいてアウトオブオーダーイベントが多いほど、検出器ステートを保存するためにより多くのメモリが必要とされる可能性があり、且つ、取り消しを行うためにより多くのＣＰＵ時間が必要とされる可能性があるので、検出階層は深くなり、取り消し作業はより複雑になる可能性がある。従って、単純な推測アプローチでは、誤推測の影響をパージするコストは、その有益な効果を容易に上回る可能性があり、純粋な非推測的バッファリングに掛かるコストよりもレイテンシを容易に増大する可能性がある。従って、実施形態は、ＣＰＵ及びメモリが全力で使用される一方で、消耗されることなく使用されるように、推測量を制限することを目的とする。システムパラメータは、ランタイムにて推定されることができ、推測的オーダリングユニット２２６は、現在のシステム及びイベント負荷に連続的に適合される。

図５は、本発明の一実施形態に係るアウトオブオーダーイベントストリーム２０４をオーダリングする方法５００を示す。

イベントストリーム２０４が備えるイベントは、各々、それに個別のイベント発生時間ｅ_ｉ・ｔｓを関連付け、個別のイベント伝搬は、最大でＫ個の時間単位の伝搬遅延まで遅延する。方法５００は、着信したイベントストリーム２０４から受信したイベントを推測的バッファリングユニット２２６に提供するステップ５０２を備える。更に、方法５００は、図３ｂに関して記述されるように順序付けられたイベントを得るために各発生時間に従って順番に推測的イベントバッファリングユニット２２６において受信したイベントを（一時的に）オーダリングするステップを備える。更なるステップ５０６では、イベント発生時間ｅ_ｉ・ｔｓを有する順序付けられたイベントｅ_ｉは、αが０＜α＜１である推測量を表す場合ｅ_ｉ・ｔｓ＋α^＊Ｋ≦ｃｌｋであるように最も早い時刻ｃｌｋにて推論的イベントバッファ（オーダリングユニット）２２６からその関連するイベント検出器２１０に推測的に転送される。イベント検出器２１０では、少なくとも一つの推測的に転送されたより低いレベルのイベントに基づいて、より高いレベルのイベントが検出される。また、検出されたより高いレベルのイベントのイベント発生時間は、前記少なくとも一つの順序付けられた、推測的に転送されたより低いレベルのイベントに基づいて設定される。例えば、イベント検出器２１０では、バッファリングユニット２２６からイベント検出器２１０に転送される第一のイベントＡ及び第二のイベントＢに基づいて、合成イベントＣが検出される。イベント検出器２１０は、転送された第一のイベントＡ及び／又は転送された第二のイベントＢのイベント発生時間に応じて、例えば、第一又は第二のイベントＡ、Ｂの発生時間のいずれが合成イベントＣの発生時間をトリガするかに応じて、合成イベントＣのイベント発生時間を設定する。従って、イベント検出器２１０は、その入力イベントＡ、Ｂに応じて合成イベントＣの発生時間（タイムスタンプ）を設定又はリセットする。例えば、イベント検出器２１０は、時刻Ｔ２に検出された合成イベントに、合成イベントに寄与するより古いイベントのタイムスタンプＴ１（Ｔ１＜Ｔ２）を提供する。これは、例えばサッカーにおける「オフサイド」のように、より複雑な合成イベントに関連する。これにより、方法５００が実行された後、イベント検出器２１０への推測的イベントバッファリングユニット２２６の出力にて推測的に順序付けられたイベントストリームを生じる。本実施形態の文脈では、推測的に転送するとは、イベントが、従来必要とされたＫ個の時間単位だけ遅延される前にそのイベントを転送することを意味する。

実施形態に係る推測的なイベント処理技術は、従来のＫ−ｓｌａｃｋバッファリングアプローチを拡張する。この技術は、入力イベント２０４の大部分を時間的順序に並べることができるが、完全に正確な時間的順序に必要とされるように入力イベント２０４をバッファしない。Ｋ個の時間単位毎にイベントｅ_ｉをバッファする代わりに、実施形態は、新たな推測量αを有する、以下の式１である限り、ｅ_ｉのみをバッファする。

それにより、推測量αは、推測コンポーネントを調整するために使用される。αが大きいほど、早期に放出されるイベントが少なくなる。即ち、α＝１又はαが１に近ければ、実施形態は、推測することなくＫ−ｓｌａｃｋに向かって基本的に収束する。推測量αに対するより小さな値が推測を作動する。即ち、αが０又は０に近ければ、不等式（１）は、基本的にほとんどの場合に（ローカルクロックｃｌｋを推測的オーダリングユニット２２６に設定するために異なるイベントタイプが使用される場合に発生する可能性のある負の遅延を有するイベントは除く）適用可能であるため、全く又はほとんどバッファリング／オーダリングがない。一般に、０＜α＜１。しかしながら、幾つかの実施形態では、０．１≦α≦０．９。

例えば、Ｋ＝５且つα＝１を有する従来のイベントオーダリングユニットは、ｃｌｋが少なくとも２５になる前ではなくｃｌｋ＝２２で受信されるｔｓ＝２０を有するイベントを放出する。その時初めてｅ_ｉ・ｔｓ＋Ｋ＝２０＋５≦２５＝ｃｌｋとなる。純粋なバッファリングミドルウェアは、単にイベントを放出するだけではなく、バッファからイベントをパージする。Ｋ＝５であるがα＝０．６の例では、推測的バッファ２２６は、ｃｌｋ＝２３（２０＋０．６^＊５＝２３）で既にｔｓ＝２０のイベントを早期に、即ち、より早く放出する。推測量αがα≦０．４である場合、放出はｃｌｋ＝２２で即座に起こる。実施形態によれば、時刻ｃｌｋにて推測的イベントバッファ２２６からイベント検出器２１０に推測的に転送されるイベント発生時間ｅ_ｉ・ｔｓを有するイベントｅ_ｉは、ｃｌｋが常に同一のイベントタイプに基づいて設定されれば、ｅ_ｉ・ｔｓ＋Ｋ＞ｃｌｋを満たす。

更なる推測、即ち、０＜α＜１では、イベントは、イベント検出器２１０に推測的に放出されることができるが、イベントは、後のイベントリプレイに必要である可能性があるため、瞬時にはバッファからパージ即ち削除されなくなる。幾つかの実施形態によれば、ｅ_ｉ・ｔｓ＋Ｋ≦ｃｌｋを満たすイベント発生時間ｅ_ｉ・ｔｓを有するイベントｅ_ｉは、少なくともクロック信号ｃｌｋが常に同一のイベントタイプについて導出されれば、前記時刻ｃｌｋにてイベントバッファから削除される。従って、実施形態によれば、推測的イベントバッファ２２６は、推測的に放出済みの推測的バッファ２２６に最新のイベント又はエレメントへの参照と見なすことができる放出済みのポインタ（ＡＥＰ）によって強化されることができる。即ち、イベントを推測的に転送するステップ５０６は、イベントバッファ２２６に最新の推測的に転送されたイベントにポインタ（ＡＥＰ）をキープすることを備える。

入力ストリーム２０４から新たに到着したイベントｅ_ｉは、その発生タイムスタンプｅ_ｉ・ｔｓに従って、推測的イベントバッファ２２６に挿入される。例えば、図６ａ及び図６ｂでは、遅れて到着したイベントＡ３（ｔｓ＝３のＡ）は、既にバッファされたイベントＡ２（ｔｓ＝２のＡ）とＢ４（ｔｓ＝４のＢ）との間に挿入される。バッファのヘッドから、放出済みのポインタ（ＡＥＰ）へのイベントＡ０、Ｃ１、及びＡ２（斜線で示す）は、関連するイベント検出器へ既に転送されている。α、ｃｌｋ、Ｋ及びＡＥＰに応じて、二つの考え得る状況は、
ｅ_ｉ・ｔｓ＞ｅ_ＡＥＰ・ｔｓ：最新の到着イベントｅ_ｉのタイムスタンプがＡＥＰのタイムスタンプ（図６ａの例ではＡ２）よりも大きければ、誤推測は発生しておらず、従ってどのイベントも取り消される又はリプレイされる必要がない。図６ａでは、イベントＡ０乃至Ａ２は、早期に又は推測的に放出されており、イベントＡ３は、イベント検出器に既に転送されている出力イベントストリームにおいて欠落していない。
ｅ_ｉ・ｔｓ≦ｅ_ＡＥＰ・ｔｓ：新たに到着したイベント（ここではＡ３）のタイムスタンプが既に放出されているポインタ（ＡＥＰ）（図６ｂの例ではＢ４）のタイムスタンプよりも小さい場合、後に記述される概念によって、誤って放出されたイベントが取り消される。放出済みのポインタ（ＡＥＰ）は、新たに到着したイベントｅ_ｉに設定されることができ、バッファのヘッドから新しい放出済みのポインタ（ＡＥＰ）がリプレイ、即ち、関連するイベント検出器へそのイベントが再送信される。図６ｂの例では、イベントＢ４は、アウトオブオーダーイベントＡ３が、Ｂ４がリプレイされる前に早期に放出されることができるように取り消される。

推測的バッファ２２６におけるローカルクロック信号ｃｌｋが、例えば、特定のイベントタイプに基づいて更新される度に、推測的バッファ２２６は、不等式（１）を満たす全てのイベントを放出する。イベントは、従来の非推測的Ｋ−ｓｌａｓｋバッファもそれらのイベントをパージ即ち削除する場合、つまり、ｅ_ｉ・ｔｓ＋Ｋ≦ｃｌｋを満たすイベント発生時間ｅ_ｉ・ｔｓ有するイベントｅ_ｉが、時刻ｃｌｋにイベントバッファ２２６から削除されることができる場合にのみパージされる。

図７は、図３ａからのイベント検出器２１０のための推測的バッファ２２６が、推測量α＝１／３且つ初期Ｋ＝０によってどのように作用するかを例示的に示す。推測的バッファ２２６の方向（ｏｒｉｅｎｔａｔｉｏｎ）はここでは縦であり、即ち、そのヘッドが上部にある。一例として、タイプＡのイベントは、内部クロックｃｌｋ_Ａを設定するために使用されることができ、Ｋは、動的Ｋ−ｓｌａｃｋ（図７の太字の値を参照）によって調整される。破線で示すイベントは、各時刻にバッファ２２６からパージされる。早期に又は推測的に放出されたイベントは、斜線付きのボックスによって示す。放出済みのポインタ（ＡＥＰ）は、図７にははっきりとは描かれていないが、最新の斜線付きのイベントを示す。取り消しは、図７の下部における出力ストリーム７２０を示す負のイベント及び矢印によって示す。出力ストリーム７２０においてリプレイされたイベントは、下線で表現される。

未ソートの入力イベントストリーム２０４の始めは、イベント遅延の測定がないので、イベントＡ０及びＡ２は、ステップ７０１及び７０２において推測的に放出される。イベントＣ１がステップ即ち時刻７０３にてバッファの入力で受信されると、イベントＡ２が以前に誤って放出されたことが認識される。従って、誤って推測的に転送されたイベントＡ２は、正確に順序付けられたサブストリームを置換することによって取り消される（ステップ７０３の−Ａ２を参照）、即ち、イベントＣ１と、Ａ２が再び放出される。即ち、推測的バッファ２２６から関連するイベント検出器２１０へ取り消しメッセージを転送することは、新たに受信されたイベントＣ１と、以前に推測的に転送されたイベントＡ２とをイベント検出器２１０に転送することを備える。

ステップ７０４では、最大のイベント遅延Ｋは、イベントＡ３がバッファの入力に到着すると直ぐに２に設定される。Ａ３は、ｅ_ｉ・ｔｓ＋α^＊Ｋ＝３＋１／３^＊２＝３．６７＞３＝ｃｌｋであるため未だ放出されていない。ステップ７０４では、イベントＣ１は、Ｋ＝２が、ｔｓ＜３−Ｋ＝１を有するアウトオブオーダーイベントは存在することができないと告げているため、パージされる。ステップ７０５では、新たに到着したイベントＢ４がバッファに挿入される。ステップ７０６にて到着するイベントＡ６により、更なるローカルｃｌｋアップデートがあり、現在バッファされているイベントが評価される。次に、イベントＡ３（３．６７≦６＝ｃｌｋ_Ａ）及びイベントＢ４（４．６７≦６＝ｃｌｋ_Ａ）が放出され、推測的バッファ２２６は、ｅ_ｉ・ｔｓ＋Ｋ≦ｃｌｋを満たす各イベント、即ち、（純粋なＫ−ｓｌａｃｋのルールによって）現在確実なイベントＡ２、Ａ３及びＢ４を削除することによってパージされる。ローカルクロックｃｌｋは、ステップ７０７においてイベントＣ５を受信した時にアップデートされないが、Ｃ５がｅ_ｉ・ｔｓ＋α^＊Ｋ＝５＋１／３^＊２＝５．６７≦６＝ｃｌｋを満たすのでＣ５を早期に放出することができ、イベントＡ６は以前に処理されていないので、リプレイする必要がない。イベントＢ８及びＣ７は、両方とも、ステップ７１０におけるイベントＡ１１の受信までキューに入れられる。次に、Ａ６、Ｃ７、を処理し、Ｃ５をパージする。イベントＡ１２の受信により、イベントＢ１０は、ｅ_ｉ・ｔｓ＋α^＊Ｋ＝１０＋１／３^＊６＝１２≦１２＝ｃｌｋが満たされるため、早期に放出される。ステップ７１３では、新たに受信したイベントＣ９は、放出済みのポインタ（ＡＥＰ）（Ｂ１０を指す）の前に挿入され、このようにして誤推測が検出される。従って、放出済みの（ＡＥＰ）は再配置され、イベントＣ９及びＢ１０を転送又はリプレイすることによって、前記イベント検出器及び／又は前記イベント検出器に対して下流に配置されたより高いレベルのイベント検出器のためにイベント取り消しプロシージャを開始するために、関連するイベント検出器には、取り消しメッセージ（−Ｂ１０を参照）が転送される。

図８に表現されるアルゴリズム１は、アウトオブオーダーイベントの挿入と、必要となる可能性のあるＡＥＰ再配置のための例示的な疑似コードを示し、一方、図１０の例示的アルゴリズム２は、推測的放出、即ち、イベントのリプレイのための疑似コードを与える。両アルゴリズムの詳細は、以下で更に記述される。

推測が早過ぎた場合、推測的オーダリングユニット２２６は、放出済みのポインタ（ＡＥＰ）を再配置し、イベントストリームをリプレイする。即ち、新たに受信されたイベントのイベント発生時間が最新の推測的に転送されたイベントのイベント発生時間よりも小さければ、方法５００は、前記イベント検出器及び／又は前記イベント検出器２１０の下流に配置されたより高いレベルのイベント検出器のためのイベント取り消しプロシージャを開始するためにバッファ２２６からイベント検出器２１０へ取り消しメッセージを転送するステップを更に備える。しかしながら、推測的オーダリングユニット２２６は、以下に更により詳細に記述される取り消し方法によって誤ったイベントを修正するが、放出されたイベントを処理するイベント検出器は、これらの誤った早期に放出されたイベントによって、未だ誤った状態である。従って、リプレイのために、イベント検出器２１０の内部変数は、イベント検出器２１０が第一の誤った早期のイベントを処理する前の状態に戻される。言い換えれば、取り消しメッセージを転送することにより、イベント検出器２１０の推測的な内部状態を、イベント検出器が最新の推測的に転送されたイベントを処理する前の状態に戻す即ち回復することになる。

このような状態回復は、三つの理由により困難である可能性がある。まず、オーダリングミドルウェア２２０は、アウトオブオーダーイベントストリームを透過的に取り扱い、イベント検出器２１０は、オーダリングユニット２２６が存在することすら知らない。第二に、イベント検出器２１０は、推測的オーダリングユニット２２６があることを知っていて、イベント検出器２１０がその状態を戻すために取り消しイベントを処理するとしても、イベント検出器２１０は、推測量α及び最大イベント遅延Ｋの手がかりがないため、イベント検出器２１０が幾つの状態を維持する必要があるかの手がかりがない。第三に、多くの場合、限定的な推測が有益である主な理由である取り消しカスケードは、中断され、より早く解決される。これは、オーダリングミドルウェアの中からのみ可能である。

実施形態は、ミドルウェア２２０にイベント検出器の状態のバックアップと回復の両方をトリガさせることを目的とする。要求に応じて、イベント検出器２１０は、後にこのスナップショットに戻る必要がある全てのデータを提供することができる。一つの思想は、早期のイベントｅ_ｉが推測的バッファ２２６から放出されようとする度にイベント検出器２１０にその内部状態のスナップショットを求めること、及び、このスナップショットをｅ_ｓ・ｔｓ＝ｅ_ｉ・ｔｓの異常なイベントｅ_ｓとしてオーダリングバッファ２２６に、早期に放出されたイベントｅ_ｉの前に直接に挿入することである。その時、スナップショット状態ｅ_ｓは、早期のイベントｅ_ｉが早期に又は推測的に放出される前に適切な位置にあるイベント検出器の状態を示す。従って、イベント検出器２１０の推測的状態に戻ることは、最新の推測的に転送されたイベントに応じて推測的イベントバッファ２２６に以前に提供されているイベント検出器２１０の保存されたスナップショット状態に基づく。それにより、イベント検出器２１０のスナップショット状態は、最新の推測的に転送されたイベントｅ_ｉと同一の発生時間を有する異常なイベントｅ_ｓとしてイベントバッファ２２６に挿入される。

推測的バッファ２２６から関連するイベント検出器２１０へイベントがリプレイされる度に、検出器２１０は、イベント検出器２１０の以前の内部状態をカプセル化するこのような異常なイベントｅ_ｓを受信すると直ぐに、前記以前の状態に戻る。幾つかの実施形態によれば、第一のバッファされたスナップショットイベント、即ち、最上位のイベントのみがリプレイにおいて放出され、残りのスナップショットはスキップされる。リプレイ中に、イベント検出器もスナップショットが求められ、オーダリングバッファ２２６における既存のスナップショットは、新しいもので置換される。スナップショットイベントｅ_ｓは、以前に記述したように、任意のその他のイベントのように推測的バッファ２２６からパージされる。

図９は、更なるスナップショット処理による図７のオーダリングユニットを示す。各放出された斜線付きのイベントの上部には、バッファにおける特殊なスナップショットイベントがある（ｓで示す）。遅れて到着したイベントＣ１に対するステップ９０３のリプレイ状況を考える。イベントＡ２が推測的に放出されている時、ステップ９０２にて取得されているスナップショットイベントＳ_２は、未だバッファにある。リプレイのため、このスナップショットイベントＳ_２は、最初に放出され、ステップ９０３にてイベントＣ１及びＡ２が続く。プロシージャは、アウトオブオーダーイベントＣ９がステップ９１３にて到着する時と同様である。

同一のイベント検出器２１０の二つの後続のスナップショットが異ならなければ、実施形態は、前のスナップショットへの参照を単に保存する。それでも、推測は、余分なストレージが必要である。必要な空間は、推測の程度と共に大きくなり、イベント検出器の状態空間の複雑さによって異なる。

図８及び図１０のアルゴリズム１及び２は、推定がどのように機能するかを示す。オーダリングユニット２２６に渡って繰り返され、イベント処理（アルゴリズム２）のためにイベント検出器によって使用されるワーカースレッドが使用される。かかるワーカースレッドは処理イベントでビジーであるが、新たなイベントが受信され、アルゴリズム１は受信を受けて呼び出される。このイベントはアウトオブオーダーであるために、アルゴリズム１は、オーダリングユニットのバッファのロックを取得する、即ち、イベント検出器処理を停止し、（アウトオブオーダー）イベントをその正確な位置に挿入し、イベント検出器を再初期化し、必要に応じてＡＥＰを再配置する。それが終了すると、アルゴリズム１は、ワーカースレッドが続行するようにトリガする。ワーカースレッドは、ｃｌｋアップデートによってもトリガされ、また、バッファから古くなったイベントをパージするために使用される。従って、アルゴリズム１は、新たなイベントの受信を受けて呼び出される。そのタスクは、該当する場合は、Ｋをアップデートすること、バッファのロックをグリーディに取得すること、アウトオブオーダーイベントをその正確な位置に挿入すること、イベント検出器を再初期化すること、及び放出済みのポインタ（ＡＥＰ）を再配置することである。それが終了すると、アルゴリズム１は、記述したようにアルゴリズム２を実行するワーカースレッドをトリガする。ワーカースレッドは、イベント挿入とｃｌｋアップデートの両方によってトリガされる。また、ワーカースレッドは、Ｋ−ｓｌａｃｋ制約によってバッファをパージする。

推測的に放出されたイベントストリーム（出力ストリーム）において幾つかのイベントが欠落していれば、実施形態は、購読イベント検出器２１０のスナップショット状態を回復し、イベントストリームをリプレイする。オープンのままであるものは、このイベント検出器２１０自体が、早期の不完全な出力イベントストリームに基づいてより高いレベルのイベントを既に生成していることである。これらの生成されたイベントは、より高い階層のレベルにおける検出器によって購読されたイベントストリームから取り消される／除去される。これにより、取り消しカスケードが重くなるので、実施形態は、推測の程度を制限することを目的とする。

図３ａの例のイベント検出器及び図１１ａに示す推測的バッファを考える。関連するイベント検出器は、発生タイムスタンプｔｓ＝４のアウトオブオーダーの入力イベントＢがバッファの入力に到着した時、斜線付きイベントＡ３乃至Ｂ８を既に推測的に処理しており、入力イベントＡ３／Ｃ５に基づく出力イベントＤ_ｉ３と、入力イベントＡ６／Ｃ７に基づく出力イベントＤ_ｉ＋１６を既に生成している。この例に関して、イベント検出器は、生成した出力イベントＤに番号を付すと仮定し、例えば、Ｄ_ｉ３は、ｃｌｋ＝３にて生成されたｉ番目のイベントを示す。従って、購読するイベント検出器自体は、Ｄ_ｉ３を誤って生成している。従って、イベント検出器の状態を回復してＣ５乃至Ｂ８をリプレイするだけでなく、より高いレベルのイベント検出器、即ち、イベントＤを購読したイベント検出器のストリームから出力イベントＤ_ｉ３を取り消す即ち除去する。更に、出力イベントＤ_ｉ＋１６は、二つの理由でも誤っている。まず、イベント検出器は、図示しないある内部状態変数により、入力イベントＢ４が存在する場合はＤ_ｉ＋１６状態に達していない。第二に、Ｄ_ｉ＋１６の代わりに、イベント検出器は、ｉが最新の放出されたイベントＤの連続番号を示すＤ_ｉ６を生成すべきだった。従って、イベントストリームをリプレイすることができることに加え、ミドルウェア２２０は、早期に放出されたイベントに基づいて生成されているイベントを無効にできる状態にもある。実施形態によれば、誤って生成されているイベントを識別する取り消しイベント又はメッセージを送信することによって、より高いレベルのイベント検出器Ｈにおいて正しい状態が保存されるので、Ｈのオーダリングユニットは、それを固定し、イベントストリームをリプレイする。以下に、検出階層に渡るイベント取り消しに対処するための二つの技術、即ち、完全な取り消し及びオンデマンドの取り消しを示す。

完全な取り消しの一つの思想は、放出済みのポインタ（ＡＥＰ）が再配置されると、誤って生成されている全てのイベントを瞬時に取り消すことである。この目的で、イベント検出器の推測的オーダリングバッファ２２６は、早期に放出されたイベント及び関連するイベント検出器２１０のスナップショット状態を保存するだけでなく、概念的には、早期に放出されたイベント、即ち、上記例ではＤ_ｉ３及びＤ_ｉ＋１６からイベント検出器２１０が生成したイベントのリストを保持する。従って、方法５００は、少なくとも一つの推測的に転送されたイベントに基づいてイベント検出器２１０が生成している少なくとも一つのイベントのリストを維持することを備える。

アウトオブオーダーイベントが推測的バッファ２２６に挿入又は入力されると、まず、誤って生成されている全てのイベントを収集し、各イベントの（概念的な）取り消しメッセージを各購読するより高いレベルのイベント検出器Ｈのオーダリングユニットに送信する。このオーダリングユニットがこのような取り消しメッセージを受信すると、このオーダリングユニットは、このイベントを、そのバッファからパージし、それ自体の取り消し及びリプレイを行う。従って、取り消しメッセージ又は取り消しイベントは、アウトオブオーダーイベントが行うのと同一のリプレイ及びスナップショット回復を必要とする。例えば、図１１ａでは、新たに到着したイベントＢ４は、Ａ３とＣ５との間に挿入される。瞬時に、関連するイベント検出器に、適切なスナップショットを回復し、リプレイを開始するように告げるために−Ｄ_ｉ３及び−Ｄ_ｉ＋１６の取り消しメッセージが送信される。

一つ一つの誤って生成されたイベントＤの取り消しは機能するが、同一の効果を達成するより効率的な方法がある。一つの思想は、前にイベント検出器によって行われたように、推測的オーダリングユニット２２６がイベント検出器の状態に添付するイベントカウンタｉを利用することである。数個の取り消しメッセージ（この例では−Ｄ_ｉ３及び−Ｄ_ｉ＋１６）を送信する代わりに、上位のレベルの検出器にイベントカウンタＤ：ｉ−１を送信すれば十分である。このイベント検出器は、次に、より大きなカウンタを有するバッファからの全てのＤイベントをパージする。イベントカウンタは、より高いレベルの検出器に送信される必要がある取り消しイベントの数を減少するのに役立つだけではない。検出器状態を格納する又は検出器状態にあるカウンタにより、生成したイベントにリストをキープする必要がなくなる（上記例では、Ｃ５‐‐＞Ｄ_ｉ３及びＣ７‐‐＞Ｄ_ｉ＋１６のリストが必要ない）。

完全な取り消しの一つの利点は、より高いレベルのイベント検出器のオーダリングユニットが、それらのバッファからの取り消されたイベントをパージし、それらのイベントストリームを直ちにリプレイすることである。イベント検出器の状態が変化したり、及び／又は早期に生成されたイベントが異なったりする場合、完全な取り消しは可能な限り効率的に機能する。

生成したイベントの完全な取り消し及びそのパージにより、イベント検出器は、再度それらの検出作業を実行しなければならない。これは、ＣＰＵサイクルを消費する。しかしながら、パージされたイベントを再度正確に生成するステートレス検出器を考える。これらの検出器に関して、取り消し作業の大部分が浪費されることは明らかである。上述の完全な取り消しの効率は、イベント検出器の内部構造及びその生成したイベントに強く依存する。それは、不必要なＣＰＵのオーバーヘッドを生じ、従って、達成可能な推測の程度を不必要に破壊する。

上述のオンデマンドの取り消しの一つの思想は、ＡＥＰ再配置を受けて直ちに取り消しイベントを送信しないことである。代わりに、イベントストリームがリプレイされ、スナップショット状態が変化したり、及び／又は検出器出力イベントがリプレイ時に再度生成されなかったりする場合のみ、イベントが取り消される。更に詳細には、リプレイ時にイベントが放出される度に、以下の二つのプロパティが適用できるか否かが検証される。

（１）スナップショットが等しい。イベントストリームがリプレイされ、スナップショットが異ならない場合、リプレイ処理は中断される。リプレイにおいて次に来る早期のイベントは同一のスナップショットを生じ、従って同一のイベントを生成するので、スナップショットと以前に生成された早期のイベントは両方とも有効なままである。即ち、取り消しは、新たに受信されたイベントの処理を受けて、保存されたスナップショット状態が、イベント検出器の新しい内部状態と等しいか否かを検証し、検証が肯定であれば、より高いレベルの検出器に関してイベントリプレイ処理を中断することを備える。

（２）生成したイベントが等しい。リプレイ時に再度生成されたイベント、即ち、イベントタイプ及びカウンタは、アップデートとしてマークされ、より高いレベルのイベント検出器Ｈのオーダリングユニットは、以前に生成された早期のイベントが最近生成された早期のイベントと等しいか否か検証できる。等しければ、Ｈのオーダリングユニットは、新たなイベントを再挿入せず、ＡＥＰを再配置せず、従って、不必要な取り消しカスケードをトリガしない。言い換えれば、取り消し処理は、更に、取り消しメッセージの処理を受けてイベント検出器によって生成された出力イベントが、最新の推測的に転送されたイベントに応じて生成されている以前に生成された出力イベントと等しいか否かを検証することを備えることができ、検証が肯定であれば、より高いレベルのイベント検出器に関するイベントリプレイ処理を中断することを更に備える。

図１１ｂは、上記例に関するオンデマンドのイベント取り消しを例示的に示す。新たに到着したイベントＢ４がバッファに挿入されると、関連するイベント検出器は、スナップショット_Ｓ４＝_Ｓ５を使用するためにリセットされ、再生されたイベントに作用する。関連するイベント検出器は、次に、推測的にＢ４を処理した後（図１１ｂには図示されない）ある状態_Ｓ５’に達する。_Ｓ５’＝_Ｓ５（＝_Ｓ４）、即ち、関連するイベント検出器の状態が遅れて到着したイベントＢ４の影響を受けなければ、全ての後続のスナップショット及び早期に生成されたイベントが変化しないままなので、リプレイ及び取り消しが中断される。

しかしながら、関連したイベント検出器の状態が影響を及ぼされる場合、イベントストリームは、リプレイされ、イベントが生成されるか否か、即ち、アップデートフラグは、それがより高いレベルのイベント検出器Ｈのオーダリングユニットに送信される前に設定される。次に、Ｈのオーダリングユニットは、更新されたイベントを同等か否かについてチェックし、同等ならば、そのイベントは、破棄される。

イベント検出器がステートレスであれば、又はリプレイを生じるイベントが出力の多くを変化しなければ、オンデマンド取り消しは、イベント検出器階層に渡って完全な取り消しによって導入される取り消し作業が大幅に減少する。

実施形態によれば、推測は、イベント検出レイテンシを低下するために更なるシステムリソースを必要とする。残りの問題は、推測の程度を制御する減衰又は推測係数αの設定方法である。推定量αの理想的な値は、結果的に、最良のレイテンシとなるが、利用可能なシステムリソースを消耗すること、ひいてはシステム障害も回避する。幾つかの実施形態は、この目標を達成するランタイムα適応を提案する。ランタイム測定が利用不可能な場合、又は臨界状況、例えば、ある閾値よりも高いＣＰＵ負荷が発生した場合、システム障害を防止するために、αはその初期値、例えばα_０＝１に（再）設定されるので安全である。他の初期値は、例えば、α_０＝０．９９又はα_０＝０．９もある。更に、α適応は、αが単一の推測的オーダリングユニット２２６（及びその関連するイベント検出器２１０）のリプレイ及び取り消しに影響するだけなので、局所的な効果のみを有する。上位レベルのイベント検出器の推測的バッファは、イベントを挿入したり、及び／又は取り消したりするだけであるが、一般的にその推測係数αに依存するリプレイを開始しないため、その他の検出器を起動するマシン上にＣＰＵ負荷は、大きく影響されない。

実施形態の一つの思想は、輻輳制御メカニズムに類似のα適応の制御ループを使用することである。前記輻輳制御は、データ速度、即ち、各時間単位において、多くの認知されるべきパケットを保持する輻輳ウィンドウサイズを二倍にすることによってスループットを最大化しようとする。データ速度がリンクに対して高くなり過ぎる時、データパケットは、パケットがネットワークにおいて失われるのでタイムアウトされ、データ速度、即ち、ウィンドウサイズが１に減少される。最大のウィンドウサイズがセーブされ、新たな反復を開始する。ウィンドウサイズは、以前の反復のウィンドウサイズの半分になるまで再度二倍にされる。その後、ウィンドウサイズは、再度パケットが失われ、次の反復をやり直すまでインクリメントされる。

この思想を採用するため、推測係数αは、輻輳ウィンドウサイズ、及び負荷指標としてのＣＰＵワークロードと同様に使用される。ＣＰＵ負荷が評価される度に、αの値は調整される。ＣＰＵ負荷を正確に測定するため、ミドルウェア２２０は、イベント検出器がイベント処理に必要な時間、即ちｔ_ｂｕｓｙを繰り返し（例えば、各時間間隔ｔ_ｓｐａｎ後）合計し、ミドルウェアワーカースレッドの各々がアイドル状態にある時間の合計、即ちｔ_ｉｄｌｅに関する。得られるビジー係数ｂ_ｃは、以下の［式］（２）に従って決定される。

例えば、蓄積されたアイドル状態時間ｔ_ｉｄｌｅ＝０．１秒及び蓄積されたビジー時間ｔ_ｂｕｓｙ＝０．８９秒により、結果として生じるビジー係数ｂ_ｃ＝１−（０．１ｓ／０．８９ｓ）＝０．８８８。これは、利用可能なリソースの８８．８％が使用されること、及びシステムリソースの約１２％が未だ利用可能である（その他の処理がＥＢＳに干渉しないと仮定する）ことを意味する。ビジー係数は、αの値が減少するのとともに増加する。αを調整するために、間隔［ｂ_ｌ；ｂ_ｕ］は、ｂ_ｃに関して下位（ｂ_ｌ）及び上位のターゲット値（ｂ_ｕ）に対して特定される。一部の実施形態によれば、ビジー係数ｂ_ｃがｂ_ｌを下回る場合、ＣＰＵ時間が利用可能であり、推測量αが減少する。ビジー係数がｂ_ｕを上回れば、ＣＰＵ時間は限界であり、αは増加又はその初期値α_０に設定される。即ち、推測量αは、推測量αが、計算ノードの負荷の減少と共に減少し、計算ノードの負荷の増加と共に増加するように、方法５００を実行する少なくとも一つの計算ノードの負荷に基づいて調整される。推測量αは、その値が（１−＿α_ｂｅｓｔ）／２よりも小さく設定される間近になるまで、再度減少される。その時から、ターゲット間隔に緩やかに近づけるためにαは素早くは減少しなくなる。即ち、初期値から開始すると、推測量αは、所定の閾値に達するために第一の速さで減少する。前記閾値に達した後、推測量αは、負荷のターゲット間隔に達するまで、第一の速さよりも低速の第二の速さで更に減少する。

例えば、間隔［ｂ_ｌ＝０．８；ｂ_ｕ＝０．９］は、実施形態において十分に良好に機能する。しかしながら、ビジー係数ｂ_ｃは、αの選択によって影響を受けるだけではない。バースト状況において、或いはイベント検出器がその状態空間のレアエリア又はスローエリアに達する時、ｔ_ｂｕｓｙはピークである。このような場合、ランタイムα適応は、推測量αをその初期値α_０にリセットすることによって、ひいてはイベント検出器により多くの計算リソースを提供することによって適切に反応する。

実施形態の評価に関して、ドイツのニュルンベルクにおけるメインサッカースタジアムに設置されたリアルタイムロケーティングシステム（ＲＴＬＳ）からの位置データストリームが分析されている。このＲＴＬＳは、ボールに関しては毎秒２．０００サンプリング点において、プレーヤ及びレフェリーに関しては毎秒２００個のサンプリング点において同時間に１４４個の送信機を追跡する。各プレーヤは、４個の送信機を各四肢に１個ずつ備えている。センサデータは、ミリメータ単位の絶対位置、速度、加速度、及び任意の位置に関する位置の品質（ＱｏＬ）を備える。サッカーは、これらのサンプリングレートを必要とする。ボールに関する毎秒２．０００個のサンプリング点及び最大１５０ｋｍ／ｈの速度により、二つの連続する位置は、２ｃｍよりも離れている。パス、ダブルパス、又はゴールへのシュート等のサッカーのイベントは、一秒の何分の一かの範囲で発生する。イベント検出器の階層が、人間の観察者、例えばリポータ、又は関心のあるイベントにスムーズに追従すべきカメラシステムが、システムのライブの出力と瞬時に連動するように促すことができるように、低レイテンシが必要とされる（例えば図１を参照）。実施形態に従ってスタジアムからの位置データストリームにイベント処理システム及びアルゴリズムを適用することから結果が提示される。使用された計算プラットフォームは、数個の６４ビットＬｉｎｕｘ（登録商標）マシンを含み、各々が、１Ｇｂｉｔの完全な交換網上で通信する２．８０ＧＨｚ及び６４ＧＢのメインメモリに二個のＩｎｔｅｌ Ｘｅｏｎ Ｅ５５６０クアッドコアＣＰＵを装備する。テストに関して、二つのアマチュアリーグのフットボールクラブ間のテストゲームが開催されている。送信機から受信される位置ストリームは、実施形態に係るＥＢＳによって処理されている。

図１２は、時間（曲線１２０２を参照）に対するビジー係数ｂ_ｃを示し、且つ時間（曲線１２０２を参照）に対する（１−α）を示す図を示す。見て分かるように、ＥＢＳは、改善し得る負荷領域（ｂ_ｃ?０．６）におけるビジー係数を生じる初期の推定量α＝１から開始される。αを１から約０．１５に減少することにより、ビジー係数ｂ_ｃが約１５秒で臨界状況に達するまで（ｂ_ｃ?０．９）、ビジー係数ｂ_ｃは効率的な負荷エリアに置かれる。この臨界負荷状況により、αはα_０＝１にリセットされることになり、それにより、ビジー係数ｂ_ｃを約０．９から０．６へ減少する。再度、α値は、１から約０．１５へ減少され、それにより、ビジー係数ｂ_ｃがその効率的な領域に再度到達するまで、負荷状況を連続的に改善する。

ベンチマークを得るために、分散型計算クラスタにおいて位置ストリームデータをリプレイした。イベント処理ミドルウェアの実施形態、即ち、推測的処理、パブ／サブマネージメント等の方法は、Ｃ＋＋コードの約９，０００本のラインを取る。その上部に、１００を超過するイベント検出器は、１，５００個を上回る異なるイベントタイプを検出するために使用されるＣ＋＋コードの１５，０００本を上回るラインによって実行されている。イベント検出階層は、１５レベルあり、サッカーの試合からのイベントストリームのスニペットがリプレイされる。テストイベントストリームの継続時間は１００秒であり、８７５，０００個の位置イベントと、イベント検出器によって生成される２５，０００個のより高いレベルのイベントとを備える（早期のイベント又は取り消しイベントは含まない）。データストリームは、幾つかのバースト状況も包含する。処理済みデータストリームの平均的なデータ速度は、２．２７メガバイト／秒である。

バッファリングミドルウェアのレイテンシを低減するために推測が追加される。それを評価するために、記録されたテストマッチからの位置データストリームを使用し、「パス」イベント検出器から入力イベント遅延を分析する。この検出器は、六つの異なるイベントタイプを購読し、（失敗した）パスイベントを検出する。位置及びイベントデータストリームを二回リプレイするが、図１３を参照。

純粋な動的Ｋ−ｓｌａｃｋバッファリング（α＝１、参照番号１３０２）は、オーダリングの間違いを受けてＫをアップデートし、最終的にはストリームリプレイの最後で５２６ｍｓの検出レイテンシとなる。１００秒に対するその平均的なレイテンシは、５０４ｍｓであった。対照的に、動的α適応の実施形態は、はるかに小さい検出レイテンシに達する（参照番号１３０４）。初めは、αはα_０＝１から開始し、第一の調整の後、約３００ｍｓのレイテンシを生じる。リプレイ時、レイテンシは、α適応アルゴリズムがシステム負荷を測定するにつれて低減される。αは、検出レイテンシが６４ｍｓの時、その最小値に到達する。２８（及び４８及び７８も）秒後、イベントストリームがバーストし、ビジー係数とひいてはαの両方が増加し、検出レイテンシの増加につながる。その後、αは、レイテンシがその最小値に近づくように再度低減される。動的推測の実証済みの実施形態の平均的なレイテンシは１０５ｍｓであった。

これらの結果は、推測的バッファリング技術の実施形態が、ランタイムにおけるイベントの検出レイテンシを大きく減少することを示す。全１００秒を通して、ＣＰＵ負荷は許容範囲であり、臨界状況において、α適応によってシステム障害が回避されている。従って、カメラの動き及び焦点は、純粋なバッファリング技術よりもはるかに早く、即ち、ある特定の例において５００ｍｓを上回る代わりに１００ｍｓ未満でトリガされる。このテストでは、平均レイテンシは、純粋なバッファリングが生じるレイテンシの五分の一よりも大きい４００ｍｓよりももっと低減されている。その他のイベント検出器のレイテンシは同様に挙動する。

以前のテストでは、最小の検出レイテンシに達するために動的α適合を備える実施形態を使用した。しかしながら、高いシステム負荷によってαが増加している稀な点が存在している。α適応のパフォーマンスを詳細に説明するために、イベントストリームの最初の３５秒を処理することの結果に注目する。図１４を参照。

テストに関して、ビジー係数目標間隔をｂ_ｃ＝［０．８；０．９］に設定しており、α（線１４０２）は、α_０＝１から開始する。αは、ｔ_ｓｐａｎ＝三秒毎に半分になり、その結果、ビジー係数ｂ_ｃ（線１４０４）は増加する。九秒後、ｂ_ｃは、ｂ_ｌ＝８０％とｂ_ｕ＝９０％との間のその目標間隔になり、αは、調整されなくなり、α＝０．１２５に留まる。従って、実施形態では、０．１＜α＜１である。

それから、ビジー係数ｂ_ｃとＣＰＵ負荷は両方とも８０％と９０％との間で変動する。更に１４秒後（ランタイムの２３秒後）、ｂ_ｃは、０．９２に達し（その時のＣＰＵ負荷１４０６は９１％だった）、αは、その初期値α_０に直ちに設定される。その結果、ｂ_ｃ１４０４とＣＰＵ負荷１４０６は両方とも瞬時に減少する。時間２４から開始すると、αは、時間２７まで再度半分になる。次に、αは、（１．０−０．１２５）／２＝０．４３（二等分線）よりも低く設定されつつあり、今から、ｔ_ｓｐａｎ毎に０．０５だけ減少される。ｂ_ｃ１４０４とＣＰＵ負荷１４０６は両方とも、８０％と９０％との間のそれらの目標間隔に再度増加する。

これらの結果は、α適応アルゴリズムによる実施形態が、利用可能なＣＰＵ電力を効率的に使用するためにαを減少するだけでなく、システムが、例えば、バースト状況にあるように、過負荷に近くなればαを瞬時に増加する（例えばαを１に適応させる）ことを示す。従って、推測的バッファは、システム障害を回避し、負荷バーストを素早く吸収することができる。更に、ｂ_ｃとＣＰＵ負荷は同様に挙動する。従って、ｂ_ｃは、ミドルウェアによってＣＰＵ消費を推定するために十分に良好な指標である。

リソース消費を測定するため、サッカーの試合からのイベントストリームスニペットは、４回リプレイされている。図１５は、結果的に生じるＣＰＵ負荷を示す。純粋なＫ−ｓｌａｃｋバッファリング（α＝１）、静的α＝０．５を有する半分の推測的バッファリング（線１５０４）、動的α適応（線１５０６）、及び完全な推測的処理（α＝０、線１５０８）に関してＣＰＵ負荷１５０２を記録した。純粋なバッファリング１５０２は、全１００秒に渡って４５％を下回る遅延ＣＰＵ負荷を示す。これは、イベントが、十分に長い時間バッファされ、イベント検出器は、取り消しイベントを受け取ることも、スナップショットを求められることも回復することもないからである。対照的に、完全な推測１５０８は、全１００秒に渡って９０％を超える高いＣＰＵ消費を生じる。ベンチマークでは、ＣＰＵ消費は、数回１００％に達し、イベントバッファが増加するにつれ、アウトオブオーダーイベントが処理され、イベント検出器は、無効状態に陥っており、後になって、バッファもオーバーランする。入力イベントストリームは、高過ぎであり、未だ処理される必要があるイベントの個数は着実に増加する。静的α＝０．５ははるかに良好なパフォーマンスに達する（参照番号１５０４を参照）。ＣＰＵ負荷は、純粋なバッファリングアプローチ１５０２の場合よりも高いが、完全な推測バッファ１５０８の場合ほど臨界的ではなく、イベント検出器の検出レイテンシを低減するために使用される。動的推測１５０６（即ち、変動するα）の実施形態によって最高の結果が得られる。ＣＰＵ負荷は、臨界になることはないが、ストリームリプレイの全１００秒に渡って効率的に使用される。従って、推測の程度を適応的に増加することによって、検出レイテンシを低減するために、利用可能なリソースが効率的に使用される。実施形態は、システム障害を回避するために推測の程度も低下させ、ひいては推測を任意の状況にいつも最適に適応させる。

二つの取り消し技術の評価に関して、サッカーの試合から実際のイベントストリームをリプレイし、早期に生成され、試合中、即ち、９０分間に取り消されるイベントの個数を記録する。

プレーヤはボールに当たるということを検出するために使用されるイベント検出器からの取り消されたイベントの個数を記録し、イベントストリームを二回リプレイし、両方の取り消し技術の間で切り替える。また、動的α適応を使用する。完全な取り消しは、ボールに当たるという５，６２３個のイベントを取り消すが、オンデマンドの取り消しは、７３５個のイベントしか取り消さない。合計で、完全な取り消しの導入された取り消しカスケードは、検出器階層に渡って計１１７，６００個のイベントを取り消したが、オンデマンドの取り消しは、１２，３００個のイベントしか取り消さなかった。

更に、オンデマンドの取り消しに関しては、スナップショットと早期に生成されたイベントを比較することによって計算時間は増加するが、完全な取り消しの平均α値（０．５６）は、オンデマンドの取り消しの平均α値（０．４９）よりも１３％高く、これは、オンデマンドの取り消しが、所定の検出器に関してより良好なパフォーマンスを得ることを意味する。

しかしながら、完全な取り消しが使用される場合により良好に実行する稀なイベント検出器もある。例えば、パスを検出するために使用される検出器は、受信するほぼ全てのイベントに対してその状態を変化させる。次に、オンデマンドの取り消しは、スナップショットと生成したイベントを比較するのに不必要に時間が掛かる。この時間は、完全な取り消しの取り消しカスケードの処理に使用されることができたはずである。この検出器に関しては、いずれにせよ、取り消し作業のほとんどが行われなければならない。

ここで、完全な取り消しは、８１９個のイベントを取り消すが、オンデマンドの取り消しは、７９２個のイベントを取り消す。この僅かな改善は、取り消し中断に使用される導入されたＣＰＵの消費を補償しない。

三つの異なる動作モード間ではメモリ消費も異なる。純粋なバッファリングα＝１では、イベントのみをバッファし、スナップショットはバッファしなくてよい。バッファの平均メモリ消費は、２５秒のイベントストリーム処理に対して１，４２０キロバイトだけだった。半分の推測α＝０．５及び動的推測的処理（変数α）は、両方とも、イベントを早期に放出する時、イベント検出器のスナップショットを保存する必要もある。イベント検出器の状態は、平均サイズが１５２バイトだった。半分の推測的処理の平均バッファサイズは、７，２２０キロバイトであり、動的推測的処理バッファの平均サイズは、１３，３５０キロバイトだった。

実施形態は、アウトオブオーダーイベントの優位性の下であっても高データ速度センサストリームの信頼できる低レイテンシの分散型イベント処理を達成する。イベント遅延が測定され、ミドルウェアは、それ自体ランタイムに適応し、必要なだけイベントを延期し、アプリケーション特定のイベント検出器に対して受信するイベントストリームを順番に並べる。イベント遅延のアプリオリな知識は必要とされない。実施形態は、例えば、サッカーでの利用においてＲＴＬＳ上で良好に機能する。レイテンシ低減に関するパフォーマンスは、ｃｌｋ信号の導出によって制限される。クロックアップデートが稀である場合、イベントの検出レイテンシは増加する。

記述及び図面は、単に本発明の原理を示す。従って、当然のことながら、当業者は、本書に明示的に記述又は図示されないが、本発明の原理を具体化し、その精神及び範囲内に含まれる様々な配置を考案することができる。更に、本書に挙げられた全ての例は、主に、明らかに、読者が本発明の原理及び本発明者が当該技術の進展に寄与する概念を理解することを促す教育上の目的に過ぎず、且つ、このように具体的に挙げられた例及び条件に制限されないものと解釈されるものとする。更に、本発明の原理、態様、及び実施形態を上げる本書の全ての記述は、その具体例と共に、その均等物を包含するものとする。

「…するための手段」（特定の機能を実行する）と表現される機能的ブロックは、夫々、特定の機能を実行するように適合され、構成され、又は動作可能である回路網を備える機能的ブロックとして理解されなければならない。従って、「何かのための手段」は、「何かを行うように適合され、構成され、又は動作可能な手段」と理解される。従って、特定の機能を実行するように適応させた手段は、このような手段が、必ず前記機能を（所与の時刻に）実行していることを示唆しない。

図面に示す様々な要素の機能は、任意の機能的ブロックも含め、専用のハードウェア、例えば、プロセッサ、及び適切なソフトウェアに関連してソフトウェアを実行することができるハードウェアの使用によって提供される。プロセッサによって提供される場合、単一の専用のプロセッサによって、単一の共有プロセッサによって、又は複数の個別のプロセッサであって、それらの一部は共有されてもよいプロセッサによって機能が提供される。更に、「プロセッサ」又は「コントローラ」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアのみを指すものと解釈されるべきではなく、デジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、アプリケーション指定集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを格納するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、及び不揮発性ストレージを、無制限に、黙示的に含む。その他のハードウェア、従来のもの及び／又はカスタマイズされたものも含まれる。

当業者には当然のことながら、本書の任意のブロック図は、本発明の原理を具体化する例示的な回路網の概念図を表す。同様に、当然のことながら、任意のフローチャート、フロー図、状態遷移図、疑似コード等は、コンピュータ可読媒体において実質的に表され、コンピュータ又はプロセッサによって実行される様々な処理を表し、このようなコンピュータ又はプロセッサが明示的に図示されているか否かに拘らない。

更に、以下の請求項は、本書によって、詳細な記述に援用され、各請求項は、別々の実施形態として独立する。各請求項は別々の実施形態として独立するが―従属請求項は、特許請求の範囲において、一つ以上の他の請求項との特定の組み合わせを示すが―その他の実施形態は、その他の各従属請求項の主題との従属請求項の組み合わせを含むことに留意するべきである。このような組み合わせは、特定の組み合わせを意図していないと述べない限り、本書に提案されている。更に、ある請求項が、任意のその他の独立請求項に直接的に従属していなくても、その独立請求項に対してその請求項の特徴も含むことが意図されている。

更に、本明細書又は請求項に開示された方法は、これらの方法の夫々のステップの各々を実行するための手段を有するデバイスによって実施されてもよいことに留意するべきである。

更に、当然のことながら、本明細書又は請求の範囲に開示された複数のステップ又は機能の開示は、特定の順番の範囲内にあると解釈されてはならない。従って、複数のステップ又は機能の開示は、このようなステップ又は機能が技術的な理由で入れ替え可能でない限りは、これらを特定の順番に限定しない。

更に、一部の実施形態では、単一のステップは、複数のサブステップを含んでもよいし、複数のサブステップに分解されてもよい。かかるサブステップは、明示的に排除しない限りは、この単一のステップの開示の一部として含まれる。

Claims (15)

1. イベント検出器（２１０）に関するアウトオブオーダーイベントを備えるイベントストリーム（２０４）のイベントをオーダリングする方法（５００）であって、前記イベントが、個別のイベント発生時間（ｅｉ・ｔｓ）及びＫ個の時間単位の最大遅延までの個別のイベント伝搬遅延を前記イベントに関連付けており、前記方法は、
   前記イベントストリームから受信されたイベントをイベントバッファ（２２２、２２６）に提供すること（５０２）と、
   順序付けられたイベントを得るために前記イベントバッファ（２２２、２２６）において受信されたイベントを夫々の発生時間に従ってオーダリングすること（５０４）と、
   αが０＜α＜１である推測量を示すとするとｅｉ・ｔｓ＋α＊Ｋ≦ｃｌｋとなるように、イベント発生時間ｅｉ・ｔｓを有する順序付けられたイベント（ｅｉ）を、前記イベントバッファ(２２２、２２６)から、最も早い時刻ｃｌｋに前記イベント検出器（２１０）に推測的に転送すること（５０６）と、
   前記イベント検出器（２１０）において、イベントを検出し、少なくとも一つの推測的に転送されたイベントに基づいて、前記検出されたイベントのイベント発生時間を設定することを備え、
   前記推測量αは、推測コンポーネントを調整するために使用されているものであり、
   前記推測的に転送することは、最大遅延Ｋに対応するバッファリング時間が経過する前に前記イベントバッファ（２２２、２２６）からイベントを転送又は送信することである方法（５００）。
2. 前記推測量αは、前記方法を実行する計算ノードの負荷に基づいて、前記計算ノードの負荷が減少するのと共にαが減少し且つ前記計算ノードの負荷が増加するのと共にαが増加するように調整される請求項１に記載の方法（５００）。
3. 順序付けられたイベントを推測的に転送すること（５０６）は、前記イベントバッファ（２２２、２２６）において最新の推測的に転送されたイベントへのポインタ（ＡＥＰ）を維持することを備える請求項１及び２のいずれか一項に記載の方法（５００）。
4. 新たに受信されたイベントの前記イベント発生時間が最新の推測的に転送されたイベントの前記イベント発生時間よりも小さい場合、前記イベント検出器及び／又は前記イベント検出器（２１０）に対して下流に配置されたより高いレベルのイベント検出器に関してイベント取り消しプロシージャを開始するために前記イベント検出器（２１０）へ取り消しメッセージを転送することを備える請求項１乃至３のいずれか一項に記載の方法（５００）。
5. 前記取り消しメッセージを転送することは、前記イベント検出器（２１０）へ、前記新たに受信されたイベントを転送し、前記最新の推測的に転送されたイベントを再び転送することを備える請求項４に記載の方法（５００）。
6. 前記取り消しメッセージを転送することは、前記イベント検出器（２１０）の推測的な内部状態を、前記イベント検出器（２１０）が前記最新の推測的に転送されたイベントを処理する前の状態に戻すことを引き起こす請求項４又は５に記載の方法（５００）。
7. 前記イベント検出器（２１０）の前記推測的な内部状態を戻すことは、前記最新の推測的に転送されたイベントに応じて前記イベントバッファ（２２２、２２６）に以前に提供されている前記イベント検出器（２１０）の保存されたスナップショット状態に基づく請求項６に記載の方法（５００）。
8. 前記イベント検出器（２１０）の前記スナップショット状態は、前記最新の推測的に転送されたイベントと同一の発生時間を有する例外的なイベント（ｅｓ）として前記イベントバッファ（２２２、２２６）に挿入される請求項７に記載の方法（５００）。
9. 前記取り消しメッセージを転送することは、前記保存されたスナップショット状態、前記新たに受信されたイベント、及び前記以前に推測的に転送されたイベントを前記イベント検出器に転送することを備える請求項７に記載の方法（５００）。
10. 前記取り消しメッセージを転送することは、
    前記新たに受信されたイベントを処理すると前記保存されたスナップショット状態が前記イベント検出器（２１０）の新たな内部状態と等しいか否かを検証すること、及び
    前記検証が肯定であれば、より高いレベルのイベント検出器のためのイベントリプレイ処理を中断することを更に備える請求項９に記載の方法（５００）。
11. 前記取り消しメッセージを転送することは、
    前記取り消しメッセージを処理することを受けて前記イベント検出器によって生成された出力イベントが、前記最新の推測的に転送されたイベントに応じて生成されている以前に生成された出力イベントと等しいか否かを検証すること、及び
    前記検証が肯定であれば、より高いレベルのイベント検出器に関してイベントリプレイ処理を中断することを更に備える請求項９又は１０に記載の方法（５００）。
12. ｅｉ・ｔｓ＋Ｋ≦ｃｌｋを満たすイベント発生時間ｅｉ・ｔｓを有するイベントｅｉが、時刻ｃｌｋにて前記イベントバッファ（２２２、２２６）から削除される請求項１乃至１１のいずれか一項に記載の方法（５００）。
13. イベントは、地理的位置特定システムのセンサデータに直接的に基づくプリミティブイベント、又は複数のプリミティブ又は合成イベントに基づく合成イベントである請求項１乃至１２のいずれか一項に記載の方法（５００）。
14. コンピュータプログラムがコンピュータ又はプロセッサ上で実行される時に前記請求項１乃至１３のいずれかに記載の前記方法（５００）を実行するためのプログラムコードを有する前記コンピュータプログラム。
15. イベント検出器（２１０）に関してアウトオブオーダーイベントを含むイベントストリーム（２０４）のイベントをオーダリングする装置（２２６）であって、前記イベントが、個別のイベント発生時間及びＫ個の時間単位の最大遅延までの個別のイベント伝搬遅延を前記イベントに関連付けており、前記装置（２２６）は、
    前記イベントストリーム（２０４）から受信されたイベントをイベントバッファ（２２２）に提供するように構成された入力、
    順序付けられたイベントを得るために前記イベントバッファ（２２２）において受信されたイベントを夫々の発生時間に従ってオーダリングするように構成されたソーター、
    αが０＜α＜１である推測量を示すとするとｅｉ・ｔｓ＋α＊Ｋ≦ｃｌｋとなるように、イベント発生時間ｅｉ・ｔｓを有する順序付けられたイベントｅｉを、前記イベントバッファ（２２２）から、最も早い時刻ｃｌｋに前記イベント検出器（２１０）に推測的に転送するように構成された出力、及び
    イベントを検出し、少なくとも一つの推測的に転送されたイベントに基づいて、前記検出されたイベントのイベント発生時間を設定するように構成された前記イベント検出器（２１０）を備え、
    前記推測量αは、推測コンポーネントを調整するために使用されているものであり、
    前記推測的に転送することは、最大遅延Ｋに対応するバッファリング時間が経過する前に前記イベントバッファ（２２２、２２６）からイベントを転送又は送信することである装置（２２６）。

Images