JP6102409B2 - イベント処理方法、イベント処理システム、およびイベント処理プログラム - Google Patents

Description

本明細書で議論される実施態様は、ストリームコンピューティングを用いるイベント処理に関する。

ビジネス上の意思決定の迅速化に対する要求の増加に伴い、ストリームコンピューティングが注目されている。ストリームコンピューティングは、様々なセンサやシステムから、次々と収集される大量のイベント（センシングによりデータが収集、あるいはシステムによりデータが生成されたこと、およびデータそのもの）をリアルタイムに処理する技術である。従来のデータ処理は、収集したイベントを一旦データベースに格納し、クエリを発行し、条件にあるデータの抽出・分析を行う。これに対し、ストリームコンピューティングは、あらかじめイベントを検出するロジックをクエリとして、ストリームエンジンに与えておき、イベントの到着時にクエリを実行し、イベントの抽出・分析を行う。そのため、アルゴリズム取引、工場設備の稼働状況監視、システム操作の不正行為検出などに利用されている。

一方、様々なセンサを搭載した携帯端末の普及と無線技術の発達により、移動体（移動を伴う人やモノ）の状態を把握できるようになり、移動体の状態変化に応じたサービスが注目されている。例えば、人の携帯端末から位置情報を収集し、人の居場所に応じて最適なコンテンツを配信したり、外来者にセンサを携行させ、許可されていないエリアへ立ち入っていないかを監視したりするサービス等が考えられる。それには、無線配信によりイベントを収集し、リアルタイムに処理する必要があり、ストリームコンピューティングのモバイル環境への適用が進みつつある。

通常、無線環境は不安定で、さまざまな環境要因により通信できなくなり、携帯端末は収集したイベントをストリームエンジンが稼働するサーバに送信できない場合がある。ストリームエンジンは連続的にイベントを処理するので、イベントが欠落すると、正しくイベントを処理できない可能性がある。例えば、人の移動軌跡が不完全なために、次の移動先の予測精度が低下することで、前もって適切なコンテンツを送信できなかったり、一定時間立ち入り禁止区域に入ったイベントを検出できず、不正立ち入り判定に失敗したりすることが考えられる。

このような問題を解決するために、端末がオフライン中は、端末側で収集したイベントを保持し、オンラインになった時点で、保持していたイベントをストリームエンジンに送信するという方法が考えられる（図２参照）。そうすることで、携帯端末が収集したすべてのイベントを、ストリームエンジンに順次処理させることが可能となる。

特開２０１０−１５４５１４号公報

しかし、ストリームエンジンは、イベントの発生時刻と到着時刻の差が少ないことを前提としており、ストリームエンジンにイベントが到着する時間が、発生時刻から大幅に遅れると、正しい処理ができないという問題がある。例えば、ストリームエンジンの典型的な処理として、タイマ処理とタイムウィンドウ処理がある。タイマ処理は、あるイベントが到着後、一定時間内に所定のイベントが到着しない、あるいは到着したことを検出する処理である。タイムウィンドウ処理は、ある一定期間内に到着したイベントをバッファリングして、共通の処理（例えば、平均値や最大値を求める）を行う処理である。これらの処理は、イベントのストリームエンジンへの到着時刻を基準に処理を行うため、イベントの発生時刻と到着時刻の差が大きいと、所定の時刻にタイマイベントを生成できなかったり、タイムウィンドウ処理の対象イベントが正しく認識されなかったりする場合がある。

したがって、生成時刻とシステムへの到着時刻の差が大きいイベントに対して、正しくストリーム処理を行うことが課題である。

本明細書で後述するイベント処理方法は、以下の処理をコンピュータによって実行される。まず、センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視する。次に、端末の通信不可能な時間の累積値を計算する。そして、ストリーム処理を行う際、システムクロックの時刻からその累積値を差し引いた補正時刻を計算する。最後に、端末が送信したイベントデータを補正時刻に基づいてストリーム処理して出力する。

本明細書で後述するイベント処理システムによれば、生成時刻とシステムへの到着時刻の差が大きいイベントに対して、正しくストリーム処理を行うことができる。

イベント処理システムの一実施例の構成図である。 端末がオフラインになることを想定した場合の、ストリームエンジンへのイベントの送信の仕方を説明するための図である。 イベント処理のタイムラインを説明するための図である。 第１の実施形態に係るイベント処理システムの構成図である。 標準的なコンピュータのハードウエア構成の一例を示すブロック図である。 端末状態管理テーブル例を説明するための図である。 セッション開始処理の処理内容を図解したフローチャートである。 端末接続状態監視処理の処理内容を図解したフローチャートである。 イベントストリーム再生処理の処理内容を図解したフローチャートである。 第２の実施形態に係るイベント処理システムの構成図である。

＜イベント処理システムの構成＞
図１は、本発明の原理を説明するためのイベント処理システムの構成図である。図１に示すように、イベント処理システム１０は、端末接続状態監視部１１と、クロック補正部１２と、イベントストリーム再生部１３と、ストリームエンジン１４と、システムクロック１５とを備える。

端末５０は、センサ５１を備える。センサ５１が収集したセンサデータを、端末５０はイベント処理システム１０にイベントデータとして送信する。

端末接続状態監視部１１は、各端末５０が通信可能（オンライン）か否（オフライン）かの接続状態を監視する。

クロック補正部１２は、端末５０毎にオフラインになった時刻と、オフライン時間の累積値を計算して管理し、イベントストリーム再生部１３やストリームエンジン１４に、端末５０がオンライン状態であり続けた場合の時刻（見かけ上の時刻）を提供する。

イベントストリーム再生部１３は、端末５０から送信されたイベントデータを、本来到着すべき時刻に、ストリームエンジン１４に入力する。

ストリームエンジン１４は、イベントをストリーム処理し、イベント利用サービス６０にイベントを出力する。

システムクロック１５は、イベント処理システム１０が動作する機器あるいはＯＳが提供する、常に一定の速度で動作するクロックで、実際の時刻を提供する。

このような構成により、イベント処理システム１０は、ストリームエンジン１４が参照するクロック補正部１２を制御し、イベントを送信する端末５０がオフラインの間はクロックが停止しているように、オンラインになって遅延して到着したイベントを、あたかも今到着したように、ストリームエンジン１４に認識させることができる。

また、オフライン中に送信されているイベントの間隔を実際よりも短く処理、すなわち見かけ上の時刻の進み方を速くすることにより、効率的にイベント処理を行ってもよい。

＜イベント処理システムの動作＞
続いて、イベント処理システム１０におけるイベント処理方法について説明する。イベント処理方法は、コンピュータによって実行される。

図２は，端末がオフラインになることを想定した場合の、ストリームエンジンへのイベントの送信の仕方を説明するための図である。通常の動作は、プログラムによって、以下の２種類の処理をコンピュータに実行させる。
（１）端末接続状態監視処理
（２）イベントストリーム再生処理

端末接続状態監視処理の動作は、以下の通りである。端末接続状態監視部１１が、端末５０の接続状態（オンラインまたはオフライン）を監視しており、接続状態が変化した場合に、端末の識別子と状態変化の内容を、クロック補正部１２に通知する。クロック補正部１２は、端末５０毎にオフラインになった時刻と、オフライン時間の累積値（以下、累積オフライン時間と呼ぶ場合がある）を計算して管理しており、端末５０がオンラインからオフラインに変化した場合は、オフラインに変化した時刻とシステムクロック１５との差分を算出し、それまでの累積オフライン時間に加算して、新しい累積オフライン時間とする。そうすることで、各端末が初期状態から現在までの、オフラインになっていた累積時間を把握できる。

イベントストリーム再生処理の動作は、以下の通りである。端末５０がイベント処理システム１０にイベントを送信する。この時点で、端末５０はオンライン状態であり、センサ５１によって収集したセンサデータが、リアルタイムで送信される場合もあれば、オフライン中に収集したイベントが送信される場合もある。各イベントは、センサデータの他に、センサデータを収集した時刻と端末５０の識別子を属性として持つ（端末５０のクロックは、イベント処理システム１０のシステムクロック１５と同期が取れたものとする）。端末５０がオフライン中に収集したイベントは、1個ずつ順番に送信される場合も、まとめて1回で送信される場合もあり得る。端末５０から送信されたイベントは、イベントストリーム再生部１３に渡される。イベントストリーム再生部１３は、各々のイベントに含まれるデータ収集時刻と端末５０の識別子を参照し、端末識別子をキーにして、クロック補正部１２から端末５０の見かけ上の時刻を取得する。クロック補正部１２は、システムクロック１５を参照し、端末識別子をキーにして、クロック補正部１２から端末５０の時刻を取得する。クロック補正部１２は、システムクロック１５を参照し、端末接続状態監視処理によって随時更新されている累積オフライン時間を差し引いた補正時刻を返却する。これは、イベントが本来到着するべき時刻を示している。イベントストリーム再生部１２は、各イベントを、その本来到着すべき時刻になった時点で、ストリームエンジン１４に入力する。ストリームエンジン１４がイベントを処理する間もクロックを参照するが、その際もクロック補正部１２経由で、端末５０毎のオフライン時間を考慮した補正値を利用する。また、端末５０がオフラインの場合は、本来返信されてくるはずのイベントも滞っているので、ストリームエンジン１４が参照する見かけ上の時刻は、常にオフラインになった時刻を返す。また、このとき、オフライン中に送信されているイベントの間隔を実際よりも短く処理することにより、効率的にイベント処理を行ってもよい。

図３は、この動作をタイムラインで示した図である。端末５０がオンラインの間に収集・送信されたイベント（時刻ｔ０およびｔ１に収集されたイベント）は、イベントストリーム再生部１３により、即座にストリームエンジン１４に渡され、処理される。時刻Ｔｏｆｆに、端末５０がオフラインになると、端末５０はイベントを収集するが（時刻ｔ２およびｔ３にイベントを収集）、イベント処理システム１０には送信できなくなる。すると、ストリームエンジン１４が参照するクロックはオフラインになった時刻を常に参照するようになり、タイマ処理やタイムウィンドウ処理も停止される。端末５０が時刻Ｔｏｎにオンラインに復帰すると、オフラインの間に収集した時刻ｔ２およびｔ３のイベントをイベント処理システム１０に送信する。しかし、イベントストリーム再生部１３は、すぐにストリームエンジン１４に渡さず、実際の時刻がｔ２＋（Ｔｏｎ−Ｔｏｆｆ）およびｔ３＋（Ｔｏｎ−Ｔｏｆｆ）になるまで待つ。Ｔｏｎ−Ｔｏｆｆは、端末５０がオフラインになっていた時間であり、実際の時刻からその時間を差し引いた補正時刻を、ストリームエンジン（４）が参照しながら、処理を行うことで、そのイベントが本来のｔ２およびｔ３の時刻に発生したものとして処理できるようになる。端末５０がオンラインに復帰した後に収集される、時刻ｔ４のイベントも同様に処理される。

イベント処理システム１０は、端末接続状態監視部１１が、端末５０の接続状況を監視しており、それをクロック補正部１２に通知する。クロック補正部１２は、端末５０がオフラインなのか、オンラインなのか、およびオフラインになっていた時間の累積値を計算して管理する。そして、他のモジュールが時刻を参照する際に、実際の時刻すなわちシステムクロックの時刻から累積オフライン時間を差し引いた補正時刻を返すことで、端末５０が常にオンライン状態で、イベントを送り続けたと仮定した場合の時刻を提供できるようにする。端末５０がオフラインの場合は、本来到着すべきイベントが滞っているので、時間が進まないように、オフラインになった時の見かけ上の時刻を返す。

このように動作することで、イベントを処理する際、イベントストリーム再生部１３が、クロック補正部１２を利用して、あたかも今イベントが到着したようにイベントをストリームエンジン１４に入力することができ、ストリームエンジン１４は現在のイベントを処理しているかのように動作することが可能となる。従って、イベントの発生時刻と到着時刻が大きく異なっていても、ストリームエンジン１４は正常に処理することが可能である。

＜第１の実施形態＞
図４は、第１の実施形態に係るイベント処理システムの構成図である。イベント処理システム２０は、無線通信により端末５０からイベントを収集する。図４において、図１で示した要素には類似の番号を付与してある。

図４に示すように、イベント処理システム２０は、イベント処理システム１０と同様に、端末接続状態監視部２１と、クロック補正部２２と、イベントストリーム再生部２３と、ストリームエンジン２４と、システムクロック２５とを備え、更に、セッション管理部２６と、イベント受信部２７とを備える。

端末接続状態監視部２１と、クロック補正部２２と、イベントストリーム再生部２３と、ストリームエンジン２４と、システムクロック２５は、イベント処理システム１０と同様に動作する。

セッション管理部２６は、セッション開始を要求した端末５０に対して、必要に応じて認証を行い、セッションを開始し、システムクロック２５から時刻を取得し、端末５０に返却する。更に、セッション管理部２６は、セッションを開始したことを、端末５０のＩＤとともに、端末接続状態監視部２１に通知する。

イベント受信部２７は、端末５０から送信されたイベントを解析し、内部形式に変換し、イベントストリーム再生部２３に渡す。

ここで、上記実施の形態によるイベント処理システムの動作、及びイベント処理をコンピュータに行わせるために共通に適用されるコンピュータの例について説明する。

図５は、標準的なコンピュータのハードウエア構成の一例を示すブロック図である。図５に示すように、コンピュータ７０は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）７１、メモリ７２、入力装置７３、出力装置７４、外部記憶装置７６、媒体駆動装置７７、ネットワーク接続装置７９等がバス７５を介して互いに接続されている。

ＣＰＵ７１は、コンピュータ７０全体の動作を制御する演算処理装置である。ＣＰＵ７１は、メモリ７２を利用してイベント処理プログラムを実行することにより、図４の端末接続状態監視部２１、クロック補正部２２、イベントストリーム再生部２３、ストリームエンジン２４、セッション管理部２６、イベント受信部２７として動作する。

メモリ７２は、例えばＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）等を含み、イベント処理プログラムとイベント処理に用いられるデータを格納する。メモリ７２は、イベント処理プログラムを予め記憶したり、イベント処理プログラムを実行する際に必要に応じて作業領域として使用したりするための記憶部である。メモリ７２は、例えば、端末５０毎にオフラインになった時刻と各々の累積オフライン時間を格納する記憶部としても用いることができる。

入力装置７３は、コンピュータの使用者により操作されると、その操作内容に対応付けられている使用者からの各種情報の入力を取得し、取得した入力情報をＣＰＵ７１に送信する装置であり、例えばキーボード装置、マウス装置などである。入力装置７３は、イベント処理プログラムを実行する際に、外部入力からの編集操作入力を受け付ける。

出力装置７４は、コンピュータ７０による処理結果を出力する装置であり、表示装置などが含まれる。表示装置とは、例えば、ディスプレイやプリンタ等であり、コンピュータのユーザへの問い合わせ、処理結果等の出力に用いられる。例えば表示装置は、ＣＰＵ７１により送付される表示データに応じてテキストや画像を表示する。出力装置７４は、イベント処理プログラムを実行する際にイベントを出力する。

外部記憶装置７６は、例えば、ハードディスクなどの記憶装置であり、ＣＰＵ７１により実行される各種制御プログラムや、取得したデータ等を記憶しておく装置である。記憶装置とは、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置等である。外部記憶装置７６は、端末５０毎にオフラインになった時刻と各々の累積オフライン時間を格納することもできる。この場合、端末５０毎にオフラインになった時刻と各々の累積オフライン時間は、外部記憶装置７６からメモリ７２に読み出されて、イベント処理に用いられる。さらに、イベント処理プログラムをコンピュータ７０の外部記憶装置７６に保存しておき、必要に応じて、それらをメモリ７２にロードして使用することもできる。

媒体駆動装置７７は、可搬記録媒体７８に書き込みおよび読み出しを行うための装置である。媒体駆動装置７７は、可搬記録媒体７８を駆動し、その記録内容にアクセスする。

ＣＰＵ７１は、可搬型記録媒体７８に記録されているイベント処理プログラムを、媒体駆動装置７７を介して読み出して実行することによって、イベント処理を行うようにすることもできる。可搬記録媒体７８は、例えばＣｏｍｐａｃｔ Ｄｉｓｃ（ＣＤ）−ＲＯＭ、Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ（ＤＶＤ）、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ（ＵＳＢ）メモリ等である。

ネットワーク接続装置７９は、有線または無線により外部との間で行われる各種データの授受の管理を行うインタフェース装置である。ネットワーク接続装置７９は、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ）、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ）等の任意のネットワーク（回線）を介して外部の装置を通信し、通信に伴うデータ変換を行う。また、必要に応じて、イベント処理プログラムを外部の装置から受け取り、それをコンピュータ７０のメモリ７２にロードして使用することもできる。

バス７５は、上記各装置等を互いに接続し、データのやり取りを行う通信経路である。この可搬記録媒体７８に上述のプログラムを格納しておき、必要に応じて、それをコンピュータ７０のメモリ７２にロードして使用することもできる。

上記それぞれの実施の形態によるイベント処理をコンピュータに実行させるイベント処理プログラムは、例えば外部記憶装置７６に記憶される。ＣＰＵ７１は、外部記憶装置７６からイベント処理プログラムを読み出し、イベント処理を行う。このとき、イベント処理をＣＰＵ７１に行わせるためのイベント処理プログラムは、予め外部記憶装置７６に記憶されている。そして、入力装置７３から所定の指示をＣＰＵ７１に与えて、このイベント処理プログラムを外部記憶装置７６から読み出させて実行させるようにする。また、このイベント処理プログラムは、可搬記録媒体７８に記憶するようにしてもよい。

次に、図５に図示したコンピュータ７０へのイベント処理プログラム及びデータのローディング例を説明する。
上述の実施形態において説明したイベント処理システム２０に相当する機能をコンピュータ７０に行わせるためには、イベント処理プログラムを、コンピュータ７０で読み取り可能な可搬記録媒体７８に予め記憶させておく。そして、その可搬記録媒体７８からイベント処理プログラムをコンピュータ７０に読み出させて、そのコンピュータ７０のメモリ７２や外部記憶装置７６に一旦格納させ、この格納されたイベント処理プログラムをそのコンピュータ７０の有するＣＰＵ７１に読み出させて実行させるように構成すればよい。

また、サーバが有するデータベースから、ネットワークを介して、イベント処理プログラムをコンピュータ７０にダウンロードすることとしてもよい。

＜システム全体の動作フェーズ＞
続いて、本実施形態におけるイベント処理方法について説明する。端末５０を含むシステム全体の典型的な動作フェーズは、以下の通りである。これらの処理をコンピュータに実行させる。
（１）端末５０がイベント送信のためにセッションを開始し、センシングを開始する。
（２）端末５０がオンラインになり、収集したセンサデータをイベントとして、イベント処理システム２０に送信する。
（３）端末５０がオフラインになり、端末５０内でイベントを蓄積する。
（４）端末５０がオンラインになり、オフライン中に蓄積したイベントをイベント処理システムに送信する。
（（３）から（４）を繰り返す。）
（５）端末がセンシングを終了し、イベント送信のためのセッションを終了する。

イベント処理システムの動作は、以下の４種類である。
セッション開始処理（動作フェーズ（１）に対応）：図６は、端末状態管理テーブルの例を示す。図７は、セッション開始処理の処理内容を図解したフローチャートである。
Ｓ１００において、端末５０は、イベント処理システム２０にイベントを送信する前に、セッション管理部２６に対してセッション開始を要求する。セッションは、イベントを送り続ける間、常に維持されるものであればよく、Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ（ＶＰＮ）やＨｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）等のセッションで構わない。

Ｓ１０２において、セッション管理部２６は、必要に応じて認証を行い、セッションを開始する。次に、Ｓ１０４において、セッション管理部２６は、システムクロック２５から時刻を取得し、端末５０に返却する。

Ｓ１０６において、端末５０は、端末５０のクロックを、取得した時刻に合わせる。更に、Ｓ１０８において、端末５０は、イベントの収集・送信を開始し、セッション終了まで継続する。

Ｓ１１０において、セッション管理部２６は、セッションを開始したことを、端末５０のＩＤとともに、端末接続状態監視部２１に通知する。これは逆に端末接続状態監視部２１が、セッション管理部２６に定期的に問い合わせるようにしても構わない。次に、Ｓ１１２において、端末接続状態監視部２１は、セッションの開始をクロック補正部２２に通知する。

クロック補正部２２は、端末５０毎にオフラインになった時のシステムクロック２５の時刻と、端末５０毎にオフラインになっていた時間の累積値を計算して管理しており、Ｓ１１４において、通知された端末５０のエントリを初期化する。続いて、Ｓ１１６において、端末接続状態監視部２１は、端末接続状態の監視を開始する。なお、セッション開始時は、オフライン時刻が空で、累積オフライン時間を０とする。

端末接続状態監視処理（動作フェーズ（３）および（４）に対応）：図８は、端末接続状態監視処理の処理内容を図解したフローチャートである。
Ｓ２００において、セッション管理部２６は、端末５０の接続状態を定期的に確認する。それはセッション管理部２６自身が管理するセッション情報を確認しても、端末５０からのパケットの有無や、ｐｉｎｇによる応答を確認しても構わない。セッション管理部２６は、その結果を端末ＩＤとともに端末接続状態監視部２１に通知し、Ｓ２０２に進む。

Ｓ２０２において、端末接続状態監視部２１は、端末５０の以前の接続状態から変化したか否かを確認する。すなわちオンラインだったのがオフラインに、あるいはオフラインだったのがオンラインに変化したかを判定する。そして、変化があった場合は、Ｓ２０４に進み、端末接続状態監視部２１は、その変化をクロック補正部２２に通知する。変化が無かった場合は、Ｓ２００に戻る。

Ｓ２０４に続いて、Ｓ２０６において、端末接続状態監視部２１は、端末５０の接続状態の変化が、オンラインからオフラインへの変化であるか否かを判定する。

Ｓ２０６の判定結果がＹＥＳの場合、すなわちオンラインからオフラインへの変化である場合、Ｓ２０８に進み、端末接続状態監視部２１は、端末状態管理テーブルのオフライン時刻に、システムクロックの時刻を記録し、Ｓ２００に戻る。

Ｓ２０６の判定結果がＮＯの場合、すなわち接続状態がオフラインからオンラインに変化した場合は、Ｓ２１０に進み、端末接続状態監視部２１は、システムクロック２５から現在時刻を取得する。次に、Ｓ２１２に進み、端末接続状態監視部２１は、システムクロック２５の現在時刻と、端末状態管理テーブルのオフライン時刻との差分を累積オフライン時間に加算する。そして、Ｓ２１４に進み、端末接続状態監視部２１は、オフライン時刻を空にする。その後、Ｓ２００に戻る。

イベントストリーム再生処理（動作フェーズ（２）および（４）に対応）：図９は、イベントストリーム再生処理の処理内容を図解したフローチャートである。まず、端末５０がセンサからデータを収集し、それをイベントとしてイベント受信部２７に送信する。端末５０は、イベントを１個ずつ送信する場合もあれば、複数をまとめて送信する場合もあり得る。端末がオンライン状態であればイベントを収集した時点で１個ずつ送信可能であるが、オフラインからオンラインに移行した直後であれば、オフライン中に収集したイベントをまとめて送信する方がイベントの遅延を小さくできるからである。

Ｓ３００において、イベント受信部２７は、端末５０から送信されたイベントを解析し、内部形式に変換し、イベントストリーム再生部２３に渡す。そして、Ｓ３０２において、イベントストリーム再生部２３は、渡されたイベントを、必要に応じて１個ずつに分解し、各イベントに対して、本来イベントが到着する時刻になった時点で、ストリームエンジン２４に入力する。ストリームエンジン２４は、クロック補正部２２に、端末５０の見かけ上の時刻を要求する。

次に、Ｓ３０４に進み、クロック補正部２２は、端末ＩＤをキーにして、累積オフライン時間を取得する。続いて、Ｓ３０６において、クロック補正部２２は、端末接続状態管理テーブルから、端末５０のオフライン時刻を取得する。そして、Ｓ３０８に進み、クロック補正部２２は、端末５０のオフライン時刻が存在するか否かを判定する。

Ｓ３０８の判定結果がＹＥＳの場合、すなわちその時刻が存在する場合、Ｓ３１２に進み、端末５０は現在オフライン状態なので、クロック補正部２２は、オフライン時刻から累積オフライン時間を差し引いた補正時刻をストリームエンジン２４に返却する。その後、Ｓ３１４に進む。

Ｓ３０８の判定結果がＮＯの場合、すなわちオフライン時刻が存在しない場合は、Ｓ３１０に進み、クロック補正部２２は、システムクロック２５から、現在時刻を取得し、累積オフライン時間を差し引いた補正時刻をストリームエンジン２４に返却する。その後、Ｓ３１４に進む。

Ｓ３１４において、クロック補正部２２は、上記のようにして取得した端末５０の見かけ上の時刻が、イベントの生成時刻より新しいか否かを判定する。Ｓ３１４の判定結果がＮＯの場合、Ｓ３１６に進み、クロック補正部２２は、イベントが本来処理されるべき時刻になっていないので、一定時間待機し、Ｓ３０４に戻り、同じ処理を繰り返す。なお、定常的にイベント到着の遅延時間を計測しておき、その時間を加味してもよい。それ以降の処理は、ストリームエンジン２４に与えられているクエリに依存するが、タイマ処理やタイムウィンドウ処理等のようにイベントの到着時刻に依存した処理は、時刻を参照する。その際の処理は、前述の時刻参照処理と同じである。

Ｓ３１４の判定結果がＹＥＳの場合、Ｓ３１８に進み、クロック補正部２２は、そのイベントをストリームエンジン２４に渡した後、Ｓ３２０に進み、繰返し処理を終了する。

その後、ストリームエンジン２４が実行するクエリに依存する処理を行う。Ｓ３２２において、ストリームエンジン２４がクエリを処理する。その処理の最中で、Ｓ３２４において、ストリームエンジン２４は、必要に応じて、時刻を取得する（上記の時刻取得処理を実行する）。その後、Ｓ３２６において、ストリームエンジン２４がイベントを出力する。
なお、上記において、繰返し処理は同期的に行う必要はなく、順次行うことができる。

セッション終了（動作フェーズ（５）に対応）：セッション管理部２６がセッションの終了処理を行う。この時点で、端末はオンライン状態なので、クロック補正部２２の端末接続状態管理テーブルのエントリを変更する必要がないので、端末接続状態監視部２１に対しては何もしない。端末接続状態管理テーブルのエントリを削除しないのは、ストリームエンジン２４が処理しているクエリにタイマ処理やタイムウィンドウ処理を含む場合、セッションが終了しても、クロック参照があり得るからである。

前述の動作では、端末が一旦オフラインになると、見かけ上の時刻を、実際の時刻より、端末がオフラインになっていた時間だけ遅らせるようにしている。そうすると、端末５０がオフライン・オンラインを繰り返すたびに、ストリームエンジン２４がイベントを処理する時刻が遅延し、リアルタイム性が低下する。それを防ぐために、見かけ上の時刻の進み方を早くし、通常よりも高速にイベントの処理を行うようにしてもよい。その場合、過去のイベント処理が終わり、現在時刻に追いついた時点で、見かけ上の時刻の進み方を元に戻す。

＜第２の実施形態＞
図１０は、第２の実施形態に係るイベント処理システムの構成図である。図１０に示すように、イベント処理システム３０は、端末接続状態監視部３１と、クロック補正部３２と、イベントストリーム再生部３３と、ストリームエンジン３４と、システムクロック３５と、セッション管理部３６と、イベント受信部３７とを備え、更に、ＶＭ管理部３８と、クロック取得部３９とを備える。

第１の実施形態においては、イベントストリーム再生部２３およびストリームエンジン２４が、端末５０の見かけ上の時刻を利用するためには、端末５０のＩＤが必要であり、専用のＡｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）を利用することを想定している。そのため、本実施形態においては、一般的なストリームエンジンに適用できるようにするために、クロックとして見かけ上の時刻を参照する機能を持つＶｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＶＭ、仮想マシン）を端末５０毎に用意し（すなわち、ｎ個のＶＭ１、ＶＭ２、…、ＶＭｎを用意し）、イベントストリーム再生部３３とストリームエンジン３４をその専用のＶＭで実行するようにしてもよい。

本実施形態において、第１の実施形態の構成と異なるのはＶＭ管理部３８とクロック取得部３９とを備えることである。
ＶＭ管理部３６は、端末５０毎にイベントを処理するＶＭを管理する。

クロック取得部３９は、ＶＭが処理する端末５０のＩＤを覚えておき、それを利用してクロック補正部３２から見かけ上の時刻を取得する。

セッション開始動作は、上述の動作に、セッション管理部３６がＶＭ管理部３８に対して、所定の端末５０のセッションが開始されることを通知する処理が加わる。ＶＭ管理部３８は、指定された端末ＩＤのＶＭが存在しているかを確認し、存在していなければ、イベントストリーム再生部３３、ストリームエンジン３４、およびクロック取得部３９を含むＶＭを作成し、端末ＩＤを設定したり、ストリームエンジンにクエリを登録したりする等の初期化を行う。

イベントストリーム再生処理の動作は、イベント受信部３７がイベントを受信すると、ＶＭ管理部３８に対して、イベントを処理するＶＭを問い合わせ、そのＶＭのイベントストリーム再生部３３にイベントを振り分ける。以降の処理は、前述の通りであるが、イベントストリーム再生部３３およびストリームエンジン３４にクエリを登録したりするなどの初期化を行う。

イベントストリーム再生処理の動作は、イベント受信部３７がイベントを受信すると、ＶＭ管理部３８に対して、イベントを処理するＶＭを問い合わせ、そのＶＭのイベントストリーム再生部３３およびストリームエンジン３４が見かけ上の時刻を取得する。そうすることで、既存のストリームエンジン製品を変更することなく、オフライン時のイベントを処理することが可能となる。

本実施形態によるイベント処理システムの動作、及びイベント処理をコンピュータに行わせるために共通に適用されるコンピュータの例は、図５に示したものと同様である。

ＣＰＵ７１は、メモリ７２を利用してイベント処理プログラムを実行することにより、図１０の端末接続状態監視部３１、クロック補正部３２、イベントストリーム再生部３３、ストリームエンジン３４、システムクロック３５、セッション管理部３６、イベント受信部３７、ＶＭ管理部３８、クロック取得部３９として動作する。

以上、説明したように、本実施形態によれば、無線端末からイベントを収集し、ストリーム処理する際に、ストリームエンジンが参照するクロックを制御することで、イベントがあたかも今到着したように認識させることができ、イベントの到着が大きく遅延する場合でも、正しく処理することが可能である。

なお、上記のように本発明の実施形態について説明したが、本発明は上述した実施形態に限定されるものではなく、他の様々な変更が可能である。

なお、以上までに説明した実施形態に関し、更に以下の付記を開示する。
（付記１）
コンピュータによって実行されるイベント処理方法であって、
センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視し、
前記端末の通信不可能な時間の累積値を計算し、
ストリーム処理を行う際、システムクロックの時刻から前記累積値を差し引いた補正時刻を計算し、
前記端末から送信されたイベントデータを前記補正時刻に基づいてストリーム処理して出力する、
ことを特徴とするイベント処理方法。
（付記２）
前記端末は複数であり、端末毎に異なる仮想マシンによって前記ストリーム処理を行うことを特徴とする付記１に記載のイベント処理方法。
（付記３）
前記イベント処理は、通信不可能な時間中に送信されているイベントの間隔を実際より短くして処理することを特徴とする付記１に記載のイベント処理方法。
（付記４）
センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視する端末接続状態監視部と、
前記端末の通信不可能な時間の累積値を計算し、ストリーム処理を行う際にシステムクロックの時刻から前記累積値を差し引いた補正時刻を計算するクロック補正部と、
前記端末から送信されたイベントデータをストリームエンジンに入力するイベントストリーム再生部と、
前記イベントデータを前記補正時刻に基づいてストリーム処理して出力するストリームエンジンと、
実際の時刻を提供するシステムクロックと、
を備えることを特徴とするイベント処理システム。
（付記５）
前記端末は複数であり、端末毎に異なる仮想マシンによって前記ストリーム処理を行うことを特徴とする付記４に記載のイベント処理システム。
（付記６）
前記イベント処理は、通信不可能な時間中に送信されているイベントの間隔を実際より短くして処理することを特徴とする付記４に記載のイベント処理システム。
（付記７）
センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視し、
前記端末の通信不可能な時間の累積値を計算し、
ストリーム処理を行う際、システムクロックの時刻から前記累積値を差し引いた補正時刻を計算し、
前記端末から送信されたイベントデータを前記補正時刻に基づいてストリーム処理して出力する、
処理をコンピュータに実行させるイベント処理プログラム。
（付記８）
前記端末は複数であり、端末毎に異なる仮想マシンによって前記ストリーム処理を行うことを特徴とする付記７に記載のイベント処理プログラム。
（付記９）
前記イベント処理は、通信不可能な時間中に送信されているイベントの間隔を実際より短くして処理することを特徴とする付記８に記載のイベント処理プログラム。

１０ イベント処理システム
１１ 端末接続状態監視部
１２ クロック補正部
１３ イベントストリーム再生部
１４ ストリームエンジン
１５ システムクロック
１６ セッション管理部
１７ イベント受信部
１８ ＶＭ管理部
１９ クロック取得部

Claims (5)

1. コンピュータによって実行されるイベント処理方法であって、
   センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視し、
   前記端末の通信不可能な時間の累積値を計算し、
   ストリーム処理を行う際、システムクロックの時刻から前記累積値を差し引いた補正時刻を計算し、
   前記端末から送信されたイベントデータを前記補正時刻に基づいてストリーム処理して出力する、
   ことを特徴とするイベント処理方法。
2. 前記端末は複数であり、端末毎に異なる仮想マシンによって前記ストリーム処理を行うことを特徴とする請求項１に記載のイベント処理方法。
3. 前記ストリーム処理は、通信不可能な時間中に前記センサが前記イベントデータを収集したイベントの間隔を実際より短くして処理することを特徴とする請求項１に記載のイベント処理方法。
4. センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視する端末接続状態監視部と、
   前記端末の通信不可能な時間の累積値を計算し、ストリーム処理を行う際、システムクロックの時刻から前記累積オフライン時間を差し引いた補正時刻を計算するクロック補正部と、
   前記端末から送信されたイベントデータをストリームエンジンに入力するイベントストリーム再生部と、
   前記イベントデータを前記補正時刻に基づいてストリーム処理して出力するストリームエンジンと、
   実際の時刻を提供するシステムクロックと、
   を備えることを特徴とするイベント処理システム。
5. センサが収集したデータをイベントデータとしてイベント処理システムに送信する端末の接続状態を監視し、
   前記端末の通信不可能な時間の累積値を計算し、
   ストリーム処理を行う際、システムクロックの時刻から前記累積値を差し引いた補正時刻を計算し、
   前記端末から送信されたイベントデータを前記補正時刻に基づいてストリーム処理して出力する、
   処理をコンピュータに実行させるイベント処理プログラム。