(57)【要約】【課題】イベント条件判定の効率化を実現することを可能とする。【解決手段】イベント条件データベース１５は、センサＩＤ及び状態ＩＤを含む要素条件を保持する要素条件テーブルを有する。状態判定データベース１１は、現在の状態ＩＤを保持する状態管理テーブルと、現在の状態の判定に関連するセンサＩＤを保持する関連センサテーブルと、現在の状態ＩＤ及びセンサデータに対応付けて状態ＩＤを保持する状態判定テーブルとを含む。センサデータ収集部１２は、センサデータ及びセンサＩＤを受信する。状態判定部１３は、センサＩＤが関連センサテーブルに保持されている場合、センサデータ及び現在の状態ＩＤに対応付けて状態判定テーブルに保持されている状態ＩＤを取得する。イベント判定部１８は、センサＩＤ及び取得された状態ＩＤを含む要素条件及びセンサデータに応じて当該要素条件を含むイベント条件を満たしているかを判定する。【選択図】      図１
2009294763.tif 000002
【特許請求の範囲】
【請求項１】
イベント条件に含まれる複数の要素条件であって、当該要素条件に関わるセンサＩＤ及び状態ＩＤを含む要素条件を予め保持する要素条件テーブルと、
予め管理されている現在の状態を表す現在の状態ＩＤを保持する状態管理テーブルと、
前記現在の状態の判定に関連するセンサＩＤを予め保持する関連センサテーブルと、
前記状態管理テーブルに保持されている現在の状態ＩＤ及び外部から受信されるセンサデータに対応付けて、当該センサデータに応じて当該現在の状態から遷移する状態を表す状態ＩＤを予め保持する状態判定テーブルと、
外部からのセンサデータ及びセンサＩＤを受信する受信手段と、
前記受信されたセンサＩＤが前記関連センサテーブルに保持されているかを判定する第１の判定手段と、
前記受信されたセンサＩＤが前記関連センサテーブルに保持されていると判定された場合に、前記受信されたセンサデータ及び前記状態管理テーブルに保持されている現在の状態ＩＤに対応付けて前記状態判定テーブルに保持されている状態ＩＤを取得する取得手段と、
前記要素条件テーブルに保持されている要素条件のうち、前記受信されたセンサＩＤ及び前記取得された状態ＩＤを含む要素条件を前記受信されたセンサデータが満たしているかを判定することで、当該要素条件を含むイベント条件を満たしているかを判定する第２の判定手段と
を具備することを特徴とする制御指示条件判定装置。
【請求項２】
イベント条件に含まれる複数の要素条件であって、当該要素条件に関わるセンサＩＤ及び状態ＩＤを含む要素条件を予め保持する要素条件テーブルと、予め管理されている現在の状態を表す現在の状態ＩＤを保持する状態管理テーブルと、前記現在の状態の判定に関連するセンサＩＤを予め保持する関連センサテーブルと、前記状態管理テーブルに保持されている現在の状態ＩＤ及び外部から受信されるセンサデータに対応付けて、当該センサデータに応じて前記現在の状態から遷移する状態を表す状態ＩＤを予め保持する状態判定テーブルとを備える制御指示条件判定装置が実行する制御指示条件判定方法であって、
外部からのセンサデータ及びセンサＩＤを受信するステップと、
前記受信されたセンサＩＤが前記関連センサテーブルに保持されているかを判定するステップと、
前記受信されたセンサＩＤが前記関連センサテーブルに保持されていると判定された場合に、前記受信されたセンサデータ及び前記状態管理テーブルに保持されている現在の状態ＩＤに対応付けて前記状態判定テーブルに保持されている状態ＩＤを取得するステップと、
前記要素条件テーブルに保持されている要素条件のうち、前記受信されたセンサＩＤ及び前記取得された状態ＩＤを含む要素条件を前記受信されたセンサデータが満たしているかを判定することで、当該要素条件を含むイベント条件を満たしているかを判定するステップと
を具備することを特徴とする制御指示条件判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、制御指示の判定を行う際の、条件判定を効率よく行うことができる制御指示条件判定装置及び制御指示条件判定方法に関する。
【背景技術】
【０００２】
従来、例えば各種センサからのセンサ情報（センサデータ）及びイベント条件（制御指示条件）に基づき、当該イベント条件の判定を行うイベント判定装置（制御指示条件判定装置）が存在する。イベント条件は、要素条件（Ｉｆ−Ｔｈｅｎルールなどの判定条件）の組合せによって表現される。このような従来のイベント判定装置は、イベント条件の判定を行うに際し、イベント条件の要素条件毎に逐次判定を行っている。
【０００３】
このように、従来のイベント判定装置においてはイベント条件の要素条件毎に逐次判定が行われるため、当該要素条件数やセンサ情報量が膨大な場合には、イベント条件判定に時間がかかる場合がある。
これに対して、例えば効率よくイベント条件判定を行う技術（以下、先行技術と表記）が開示されている。この先行技術によれば、センサ情報を発信するセンサへセンサＩＤを付与し、当該センサからセンサ情報とセンサＩＤを合わせて発信することで、センサ情報の取得時に、このセンサＩＤに関連するイベント条件の絞込みが行われる。これにより、センサ情報が取得された際に、当該取得されたセンサ情報に関連するイベント条件のみを取得判定することが可能となる。従って、先行技術においては、例えば条件数やセンサ情報量が膨大な場合であっても、イベント条件判定の効率化が図られている。
【０００４】
【特許文献１】特開２００６−２５９９２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところが、上記した先行技術は、例えばセンシング周期が異なるセンサが存在する場合、当該センシング周期が長いセンサが関与するイベント条件判定を実施する頻度を下げる方式である。従って、各要素条件の判定発生の頻度が満遍なく発生する場合（センサＩＤを持つセンサからのセンサ情報の発信が偏り無く実施されている場合）には、その効果は低減する。
【０００６】
この発明は上記事情に着目してなされたもので、その目的とするところは、イベント条件判定の効率化を実現することができる制御指示条件判定装置及び制御指示条件判定方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するためにこの発明は、イベント条件に含まれる複数の要素条件であって、当該要素条件に関わるセンサＩＤ及び状態ＩＤを含む要素条件を予め保持する要素条件テーブルと、予め管理されている現在の状態を表す現在の状態ＩＤを保持する状態管理テーブルと、前記現在の状態の判定に関連するセンサＩＤを予め保持する関連センサテーブルと、前記状態管理テーブルに保持されている現在の状態ＩＤ及び外部から受信されるセンサデータに対応付けて、当該センサデータに応じて当該現在の状態から遷移する状態を表す状態ＩＤを予め保持する状態判定テーブルと、外部からのセンサデータ及びセンサＩＤを受信する受信手段と、前記受信されたセンサＩＤが前記関連センサテーブルに保持されているかを判定する第１の判定手段と、前記受信されたセンサＩＤが前記関連センサテーブルに保持されていると判定された場合に、前記受信されたセンサデータ及び前記状態管理テーブルに保持されている現在の状態ＩＤに対応付けて前記状態判定テーブルに保持されている状態ＩＤを取得する取得手段と、前記要素条件テーブルに保持されている要素条件のうち、前記受信されたセンサＩＤ及び前記取得された状態ＩＤを含む要素条件を前記受信されたセンサデータが満たしているかを判定することで、当該要素条件を含むイベント条件を満たしているかを判定する第２の判定手段とを具備する情報処理装置、である。
【発明の効果】
【０００８】
要するにこの発明によれば、イベント条件判定の効率化を実現することができる。
【発明を実施するための最良の形態】
【０００９】
以下、図面を参照してこの発明に係わる実施形態を説明する。
図１は、本実施形態に係る制御指示条件判定装置の機能構成を示すブロック図である。図１に示すように、制御指示条件判定装置１は、センサデータ送信装置２及びイベント受信装置３と例えばネットワークを介して接続されている。
【００１０】
図１に示す制御時指示条件判定装置１は、状態判定データベース１１、センサデータ収集部１２、状態判定部１３、イベント条件判定同期部１４、イベント条件データベース（ＤＢ）１５、イベント条件登録通知部１６、イベントキャッシュ部１７、イベント判定部１８及びイベント通知部１９を含む。
【００１１】
状態判定データベース１１は、関連センサテーブル、状態管理テーブル及び状態判定テーブルを含む。
ここで、図２は、状態判定データベース１１に含まれる関連センサテーブルのデータ構造の一例を示す。図２に示すように、関連センサテーブルには、センサＩＤが予め保持される。このセンサＩＤは、予め管理されているシステム（制御指示条件判定装置１）全体の現在の状態の判定（状態判定）に関連するセンサＩＤである。
【００１２】
図２に示す例では、関連センサテーブルには、センサＩＤとして「センサＡ」及び「センサＢ」が保持されている。
図３は、状態判定データベース１１に含まれる状態管理テーブルのデータ構造の一例を示す。図３に示すように、状態管理テーブルには、システム全体の現在の状態を表す現在の状態ＩＤが１つ管理（保持）されている。
【００１３】
図３に示す例では、状態管理テーブルには、システム全体の現在の状態を表す状態ＩＤとして「状態Ａ」が保持されている。
図４は、状態判定データベース１１に含まれる状態判定テーブルのデータ構造の一例を示す。図４に示すように、状態判定テーブルには、現在の状態ＩＤ及び例えば外部から受信されるセンサデータに対応付けて、状態ＩＤが予め保持される。この状態ＩＤは、例えばセンサデータに応じて現在の状態から遷移する状態を表す。
【００１４】
図４に示す例では、例えば現在の状態ＩＤ「状態Ａ」及びセンサデータ「Ａｃｔｉｏｎ１」に対応付けて状態ＩＤ「状態Ａ」が保持されている。このＡｃｔｉｏｎ１は、例えばセンサデータの値を示す。図４に示すＡｃｔｉｏｎ２及び３についても同様である。
【００１５】
センサデータ収集部１２は、制御指示条件判定装置１の外部からのセンサデータ及びセンサＩＤを受信する。具体的には、センサデータ収集部１２は、センサデータ送信装置２から非同期に送られてくるセンサデータ及びセンサＩＤを受信する。
センサデータ収集部１２は、受信されたセンサＩＤが状態判定データベース１１に含まれる関連センサテーブルに保持されているか否かを判定する。
【００１６】
センサデータ収集部１２は、受信されたセンサＩＤが関連センサテーブルに保持されている場合、受信されたセンサデータ及びセンサＩＤにセンサ同期ＩＤを付与し、これらを組として記録管理する。このセンサ同期ＩＤについては、後述する。
センサデータ収集部１２は、記録管理されているセンサデータ、センサＩＤ及びセンサ同期ＩＤの組を状態判定部１３に対して送信する。また、センサデータ収集部１２は、記録管理されているセンサデータ、センサＩＤ及びセンサ同期ＩＤの組をイベント条件判定同期部１４に送信する。
【００１７】
センサデータ収集部１２は、センサデータ、センサＩＤ及びセンサ同期ＩＤの組が状態判定部１３及びイベント条件判定同期部１４に送信されると、当該センサデータ収集部１２において記録管理されていたセンサデータ、センサＩＤ及びセンサ同期ＩＤの組を消去する。
【００１８】
センサデータ収集部１２は、受信されたセンサＩＤが関連センサテーブルに保持されていない場合、受信されたセンサデータ及びセンサＩＤを組として記録管理する。センサデータ収集部１２は、記録管理されているセンサデータ及びセンサＩＤの組をイベント条件同期判定部１４に送信する。センサデータ収集部１２は、センサデータ及びセンサＩＤの組がイベント条件判定同期部１４に送信されると、当該センサデータ収集部１２において記録管理されていたセンサデータ及びセンサＩＤの組を消去する。
【００１９】
状態判定部１３は、状態判定データベース１１に含まれる状態管理テーブルに保持されている現在の状態ＩＤを取得する。状態判定部１３は、センサデータ収集部１２によって送信されたセンサデータ及び取得された現在の状態ＩＤに該当する状態ＩＤを、状態判定データベース１１に含まれる状態判定テーブルから取得する。
【００２０】
状態判定部１３は、センサデータ収集部１２によって送信されたセンサ同期ＩＤ及び取得された状態ＩＤの組をイベント条件同期判定部１４に対して送信する。また、状態判定部１３は、取得された状態ＩＤを状態判定データベース１１に対して送信する。状態判定データベース１１では、状態判定部１３によって送信された状態ＩＤが当該状態判定データベース１１に含まれる状態管理テーブルに上書きされる。これにより、状態判定部１３によって送信された状態ＩＤが、システム全体の現在の状態を表す状態ＩＤとして記録管理される。
【００２１】
イベント条件判定同期部１４は、センサデータ収集部１２によって送信されたセンサデータ、センサＩＤ及びセンサ同期ＩＤの組と、状態判定部１３によって送信されたセンサ同期ＩＤ及び状態ＩＤの組とにおいて、センサ同期ＩＤが合致する組を用いて、センサデータ、センサＩＤ及び状態ＩＤの組として記録管理する。
【００２２】
また、イベント条件判定同期部１４は、センサデータ収集部１３によって送信されたセンサデータ及びセンサＩＤの組と、状態判定データベース１１に含まれる状態管理テーブルに保持されている現在の状態ＩＤとを用いて、センサデータ、センサＩＤ及び状態ＩＤの組として記録管理する。
【００２３】
イベント条件判定同期部１４は、記録管理されているセンサデータ、センサＩＤ及び状態ＩＤの組をイベント判定部１８に対して送信する。
イベント条件データベース１５は、図５に示すように、イベントテーブル２１、イベント条件テーブル２２、要素条件テーブル２３及びセンサテーブル２４を有する。なお、
これらの各テーブル２１〜２４に保持される情報は、予め登録されている。
【００２４】
イベントテーブル２１には、イベントＩＤ２１−１及びイベント名２１−２が保持される。イベントテーブル２１は、イベントＩＤ２１−１を介してイベント条件テーブル２２と関連付けられている。
イベント条件テーブル２２には、イベント条件ＩＤ２２−１、イベントテーブル２１のイベントＩＤ２１−１と関連付けられたイベントＩＤ２２−２、要素条件テーブル２３の要素条件ＩＤ２３−１と関連付けられた要素条件ＩＤ２２−３及び論理演算し２２−４が保持される。
【００２５】
要素条件テーブル２３には、状態ＩＤ２３−１、イベント条件テーブル２２の要素条件ＩＤ２２−３に関連付けられた要素条件ＩＤ２３−２、センサテーブル２４のセンサＩＤに関連付けられたセンサＩＤ２３−３、比較演算子２３−３及び比較値２３−４が保持される。要素条件テーブル２３によって規定される要素条件は、互いに異なるものである。
【００２６】
センサテーブル２４には、要素条件テーブル２３のセンサＩＤ２３−３に関連付けられたセンサＩＤ２４−１、センサ名２４−２、データ型２４−３及び単位２４−４が保持される。
イベント条件登録通知部１６は、例えばイベント条件の追加や変更があった場合に当該イベントＩＤをイベントキャッシュ部１７に通知する。
【００２７】
イベントキャッシュ部１７は、イベント条件登録通知部１６から通知されたイベントＩＤに関するイベント条件をイベント条件データベース１５から取得する。イベントキャッシュ部１７は、取得されたイベント条件毎のリストを作成して格納する。
このリストのレコードには、例えば図６に示すように、要素条件ＩＤ、結合条件（ＡＮＤ、ＯＲの論理演算子）、初期値ＦＡＬＳＥの判定結果及び初期値零の条件成立数が含まれる。
【００２８】
イベント判定部１８は、イベント条件判定同期部１４によって送信されたセンサデータ、センサＩＤ及び状態ＩＤ（の組）を受信する。
イベント判定部１８は、受信されたセンサＩＤ及び状態ＩＤに関わる要素条件を、イベント条件データベース１５を参照することにより取得する。イベント判定部１８は、取得された要素条件が満たされるか否かをセンサデータと比較することにより判定する。イベント判定部１８は、判定結果をイベントキャッシュ部１７のリストの判定結果及び条件成立数に記録する。
【００２９】
これにより、複数のイベント条件があり、イベント条件間で要素条件の重複がある場合でも、同一の要素条件に対し、一度のセンサデータとの比較のみとすることができる。図６（ａ）は、記録前のイベントキャッシュ部１７のリストの例を示す図であり、図６（ｂ）は、記録後のイベントキャッシュ部１７のリストの例を示す図である。
【００３０】
次に、イベント判定部１８は、受信されたセンサＩＤ及び状態ＩＤを含む（要素条件を含む）イベント条件に対して、そのイベント条件が満たされるか否かを判定する。イベント判定部１８は、イベントキャッシュ部１７のイベント条件のリストの先頭レコードから順に判定結果をサーチし、成立した場合にのみイベント通知部１９にイベントＩＤを通知する。
【００３１】
ただし、ＯＲ論理演算子のみで結合されたイベント条件では、成立した要素条件が見つかった時点で当該イベント条件が成立したと判断してサーチを打ち切る。また、ＡＮＤ論理演算子のみで結合されたイベント条件では、不成立した要素条件が見つかった時点で当該イベント条件が不成立したと判定し、サーチを打ち切る。
【００３２】
また、判定結果のサーチの際に、当該レコードの結合条件がＯＲ演算子かつ成立条件数がその前方にあるレコードよりも大きい場合、そのレコードを前方に移動させることにより、成立頻度が高い順にソートする。
ＯＲ論理演算子のみで結合されたイベント条件は、一つの要素条件が成立した時点で当該イベント条件の正否判定を行えることから、成立頻度が高い順にリストをソートすることによって、条件判定回数を少なくすることができる。
【００３３】
図７（ａ）は、移動前のレコードのリストを示す図である。図７（ｂ）は、移動後のレコードのリストを示す図である。図７においては、要素条件ＩＤ：２のみが成立した場合について示している。
また、そのレコードの結合条件がＡＮＤ演算子かつ成立条件数がその前方にあるレコードより小さい場合、そのレコードを前方に移動させることにより、成立頻度が低いレコード順にリストをソートする。
【００３４】
ＡＮＤ論理演算子のみで結合されたイベント条件は、一つの要素条件が不成立した時点で当該イベント条件の正否判定を行えることから、成立頻度が低い順にリストをソートすることによって、条件判定回数を少なくすることができる。
図８（ａ）は、移動前のレコードのリストを示す図である。図８（ｂ）は、移動後のレコードのリストを示す図である。図８においては、要素条件ＩＤ：１のみが成立した場合について示している。
【００３５】
なお、イベント判定部１８は、受信されたセンサＩＤ及び状態ＩＤ以外の要素条件については、イベントキャッシュ部１７に格納されたセンサＩＤ及び状態ＩＤ以外の要素条件のレコードの直前の判定結果を適用する。このような処理を行うことにより、イベント条件に関わるセンサ情報（センサデータ）の全てが揃わなくても収集したセンサ情報から逐次イベント判定（イベント条件判定）を行うことが可能となる。
【００３６】
イベント通知部１９は、イベント判定部１８から受けたイベントＩＤに対応するイベント名を、イベント条件データベース１１（のイベントテーブル２１）を検索することにより取得し、例えばネットワークを介してイベント受信装置３に通知（送信）する。
【００３７】
次に、図９及び図１０のフローチャートを参照して、本実施形態に係る制御指示条件判定装置１の処理手順について説明する。
まず、センサデータ収集部１２は、センサデータ送信装置２から非同期に送信されるセンサデータ及びセンサＩＤを受信する（ステップＳ１）。
【００３８】
次に、センサデータ収集部１２は、状態判定データベース１１を参照して、受信されたセンサＩＤが当該状態判定データベース１１に含まれる関連センサテーブルに保持されているか否かを判定する。つまり、センサデータ収集部１２は、受信されたセンサＩＤがシステム全体の状態判定に関連するセンサＩＤとして関連センサテーブルに登録済みであるか否かを判定する（ステップＳ２）。
【００３９】
受信されたセンサＩＤが関連センサテーブルに登録済みであると判定された場合（ステップＳ２のＹＥＳ）、センサデータ収集部１２は、受信されたセンサデータ及びセンサＩＤに前述したセンサ同期ＩＤを付与し、これらを組として記録管理する（ステップＳ３）。このセンサ同期ＩＤは、例えば状態ＩＤの切り替えを実施する場合に、当該状態ＩＤの切り替え後にイベント条件判定処理が実施されるように、当該状態ＩＤの切り替えとイベント条件判定処理の実施タイミングの同期を図るために用いられる。
【００４０】
センサデータ収集部１２は、当該センサデータ収集部１２において記録管理されているセンサデータ、センサＩＤ及びセンサ同期ＩＤの組を、状態判定部１３及びイベント条件判定同期部１４に対して送信する（ステップＳ４）。以下、ここで送信されたセンサデータ、センサＩＤ及びセンサ同期ＩＤの組を第１の組情報と表記する。
【００４１】
ステップＳ４の処理が実行されると、センサデータ収集部１２は、当該センサデータ収集部１２において記録管理されているセンサデータ、センサＩＤ及びセンサ同期ＩＤの組（第１の組情報）を消去する（ステップＳ５）。
状態判定部１３は、センサデータ収集部１２によって送信された第１の組情報（センサデータ、センサＩＤ及びセンサ同期ＩＤの組）を受信（取得）する。また、状態判定部１３は、状態判定データベース１１に含まれる状態管理テーブルに保持されている現在の状態ＩＤを取得する。
【００４２】
状態判定部１３は、取得されたセンサデータ及び現在の状態ＩＤに該当する状態ＩＤを、状態判定データベース１１に含まれる状態判定テーブルから取得する（ステップＳ６）。この状態ＩＤは、例えば取得されたセンサデータに応じて現在の状態から遷移する状態を表す。
【００４３】
状態判定部１３は、受信されたセンサ同期ＩＤ及び取得された状態ＩＤの組をイベント条件同期判定部１４に対して送信する（ステップＳ７）。以下、ここで送信されたセンサ同期ＩＤ及び状態ＩＤの組を、第２の組情報と表記する。
状態判定部１３は、取得された状態ＩＤを状態判定データベース１１に対して送信する。これにより、状態判定部１３によって取得された状態ＩＤは、状態判定データベース１１にて記録管理される（ステップＳ８）。この状態ＩＤは、状態判定データベース１１に含まれる状態管理テーブルに、システム全体の現在の状態を表す状態ＩＤとして保持される。つまり、状態ＩＤは、状態管理テーブルに上書きされる。
【００４４】
一方、上記したステップＳ２において、受信されたセンサＩＤが関連センサテーブルに登録済みでないと判定された場合（ステップＳ２のＮＯ）、センサデータ収集部１２は、受信されたセンサデータ及びセンサＩＤの組を記録管理する（ステップＳ９）。
センサデータ収集部１２は、当該センサデータ収集部１２において記録管理されているセンサデータ及びセンサＩＤの組をイベント条件判定同期部１４に対して送信する（ステップＳ１０）。以下、ここで送信されたセンサデータ及びセンサＩＤの組を第３の組情報と表記する。
【００４５】
ステップＳ１０の処理が実行されると、センサデータ収集部１２は、当該センサデータ収集部１２において記録管理されているセンサデータ及びセンサＩＤの組（第３の組）を消去する。
次に、イベント条件判定同期部１４は、センサデータ収集部１２によって送信された組情報を受信する。
【００４６】
イベント条件判定同期部１４は、受信された組情報にセンサ同期ＩＤが含まれるか否かを判定する（ステップＳ１１）。つまり、受信された組情報が上記したステップＳ４において送信されたもの（つまり、第１の組情報）である場合には、イベント条件判定同期部１４は、受信された組情報にセンサ同期ＩＤが含まれると判定する。一方、受信された組情報が上記ステップＳ１０において送信されたもの（つまり、第３の組情報）である場合には、イベント条件判定同期部１４は、受信された組情報にセンサ同期ＩＤが含まれないと判定する。
【００４７】
ここで、受信された組情報にセンサ同期ＩＤが含まれると判定された場合を想定する（ステップＳ１１のＹＥＳ）。この場合、受信された組情報は、センサデータ、センサＩＤ及びセンサ同期ＩＤの組（第１の組情報）である。また、この場合には、イベント条件判定同期部１４では、上記したステップＳ７において送信されたセンサ同期ＩＤ及び状態ＩＤの組（第２の組情報）が受信される。
【００４８】
イベント条件判定同期部１４は、受信された第１及び第２の組情報において、センサ同期ＩＤが合致する組を用いて、センサデータ、センサＩＤ及び状態ＩＤの組を記録管理する（ステップＳ１２）。
イベント条件判定同期部１４は、当該イベント条件判定同期部１４において記録管理されているセンサデータ、センサＩＤ及び状態ＩＤの組をイベント判定部１８に対して送信する（ステップＳ１３）。
【００４９】
イベント判定部１８は、イベント条件判定同期部１４によって送信されたセンサデータ、センサＩＤ及び状態ＩＤ（の組）に基づいて、イベント条件が成立するか否かの判定処理（イベント条件判定処理）を実行する（ステップＳ１４）。イベント判定部１８は、イベント条件判定同期部１４によって送信されたセンサＩＤ及び状態ＩＤを含む要素条件を当該送信されたセンサデータが満たしているかを判定することで、当該要素条件を含むイベント条件を満たしているかを判定する。なお、このイベント判定部１８による判定処理の詳細については後述する。
【００５０】
イベント判定部１８は、イベント条件が成立した場合に、イベント通知部１９に対してイベントＩＤを通知する。
イベント通知部１９は、イベント判定部１８から受けたイベントＩＤに対応するイベント名を状態判定データベース１１に含まれるイベントテーブル２１から取得し、例えばネットワークを介してイベント受信装置４に送信（通知）する（ステップＳ１５）。
【００５１】
一方、受信された組情報にセンサ同期ＩＤが含まれないと判定された場合を想定する（ステップＳ１１のＮＯ）。この場合、受信された組情報は、センサデータ及びセンサＩＤの組（第３の組情報）である。
イベント条件判定同期部１４は、状態判定データベース１１に含まれる状態管理テーブルに保持されているシステム全体の現在の状態を表す状態ＩＤを取得する（ステップＳ１６）。
【００５２】
イベント条件判定同期部１４は、受信されたセンサデータ、センサＩＤ（第３の組情報）及び取得された状態ＩＤの組を記録管理する（ステップＳ１７）。
ステップＳ１７の処理が実行されると、上記したステップＳ１３乃至ステップＳ１５の処理が実行される。
【００５３】
次に、図１１乃至図１４のフローチャートを参照して、図１に示すイベント判定部１８による判定処理の処理手順について説明する。
まず、イベント判定部１８は、イベント条件判定同期部１４によって送信されたセンサデータ、センサＩＤ及び状態ＩＤを受信する（ステップＳ２１）。
【００５４】
次に、イベント判定部１８は、受信されたセンサＩＤ及び状態ＩＤに関わる要素条件を、イベント条件データベース１５を参照することにより取得する（ステップＳ２２）。つまり、イベント判定部１８は、イベント条件データベース１５の要素条件テーブル２３において規定（保持）されている要素条件のうち、受信されたセンサＩＤ及び状態ＩＤを含む要素条件を取得する。
【００５５】
イベント判定部１８は、取得された要素条件が満たされるか否かをセンサデータと比較することにより判定し、その結果をイベントキャッシュ部１７のリストの判定結果に記録し（ステップＳ２３）、要素条件が成立している場合には条件成立数を更新する（ステップＳ２４及びステップＳ２５）。
【００５６】
その後、イベント判定部１８は、上記したステップＳ２１において受信されたセンサＩＤ及び状態ＩＤに関わるイベント条件の全リストをイベントキャッシュ部１７から取得し（ステップＳ２６）、全リストの判定が終了したか否かの判断を行う（ステップＳ２７）。
【００５７】
ステップＳ８において、全リストの判定が終了したと判断された場合には、処理が終了される。
一方、ステップＳ８において、全リストの判定が終了していないと判断された場合には、イベントキャッシュ部１７のリストからレコードの判定結果を取得し（ステップＳ２８）、当該取得した判定結果を真（ｔｒｕｅ）か否かの判断が行われる（ステップＳ２９）。
【００５８】
ステップＳ１０において、判定結果を真であると判断された場合には、リストがＯＲ論理演算子のみで結合されているか否かの判断が行われ（ステップＳ３０）、ＯＲ論理演算子のみで結合されていると判断された場合には、成立条件数が前方のレコードよりも大きいか否かの判断が行われる（ステップＳ３１）。
【００５９】
ステップＳ３１において、成立条件数が前方のレコードよりも大きいと判断された場合には、当該レコードを前方に移動し（ステップＳ３５）、当該レコードのイベントＩＤを通知し（ステップＳ３６）、上記したステップＳ８の処理に戻る。
一方、ステップＳ２９において、判定結果が真ではないと判断された場合には、リストがＡＮＤ論理演算子のみで結合されているか否かの判断が行われる（ステップＳ３２）。ステップＳ３２において、リストがＡＮＤ論理演算子のみで結合されていると判断された場合には、成立条件数が前方のレコードよりも小さいか否かの判断が行われる（ステップＳ３３）。
【００６０】
ステップＳ３３において、成立条件数が前方のレコードよりも小さいと判断された場合には、当該レコードを前方に移動し（ステップＳ３４）、上記したステップＳ８の処理に戻る。
ステップＳ３０においてリストがＯＲ論理演算子のみで結合されていないと判断された場合、及びステップＳ３２においてリストがＡＮＤ論理演算子のみで結合されていないと判断された場合には、全レコードの判定が終了したか否かの判断が行われる（ステップＳ３７）。
【００６１】
ステップＳ３７において、全レコードの判定が終了したと判断された場合には、リストの条件が成立したか否かの判断が行われる（ステップＳ３８）。
ステップＳ３８において、リストの条件が成立したと判断された場合には、ステップＳ３６の処理に移り、成立していないと判断された場合には、ステップＳ８の処理に戻る。
【００６２】
なお、イベント条件に関わるセンサ情報（センサデータ）の一部が不足する場合不足センサ情報に関する要素条件の判定結果を用いて当該イベント条件の判定を行ってもよい。すなわち、イベント条件判定同期部１４によって送信されたセンサＩＤ及び状態ＩＤ以外の要素条件については、当該レコードの判定結果が適用される。これにより、イベント条件に関わるセンサ情報の全てが揃わなくとも、収集したセンサ情報から逐次イベント条件判定を行うことができる。
【００６３】
上記したように本実施形態においては、状態判定による状態ＩＤの切り替え管理を行いつつ、状態ＩＤを活用したイベント条件判定を実施することを可能とする。本実施形態においては、システム全体で現在の状態ＩＤを管理することで、システムが行うべき挙動を想定し、例えばシステム設定者のようなユーザが事前のイベント条件の絞込み内容を設定しておくことが可能となる。したがって、本実施形態においては、センサデータに応じてイベント条件判定の対象となる状態ＩＤを切り替える設定を行うことが可能となり、イベント条件判定の対象を絞り込むことができる。これにより、本実施形態においては、イベント条件判定の効率化を図ることができる。
【００６４】
また、本実施形態においては、センサ同期ＩＤを用いることによって、状態ＩＤの切り替えが実施される場合に、取得されたセンサデータを活用した状態ＩＤの切り替え後にイベント条件判定が実施されるように、状態ＩＤの切り替えとイベント条件判定の実施タイミングの同期を図ることができる。
【００６５】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６６】
また、実施形態に記載した手法は、計算機（コンピュータに実行させることができるプログラム（ソフトウェア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録場痛いに格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウェア手段（実行プログラムのみならずテーブルやデータ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また、場合により設定プログラムによりソフトウェア手段を構築し、このソフトウェア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスクや半導体メモリ等の記憶媒体を含むものである。  
【図面の簡単な説明】
【００６７】
【図１】本発明の実施形態に係る制御指示条件判定装置の機能構成を示すブロック図。
【図２】図１に示す状態判定データベース１１に含まれる関連センサテーブルのデータ構造の一例を示す図。
【図３】図１に示す状態判定データベース１１に含まれる状態判定テーブルのデータ構造の一例を示す図。
【図４】図１に示す状態判定データベース１１に含まれる状態管理テーブルのデータ構造の一例を示す図。
【図５】図１に示すイベント条件データベース１５のデータ構造の一例を示す図。
【図６】イベントキャッシュ部１７のリストの一例を示す図。
【図７】イベントキャッシュ部１７のリストの変更を説明するための図。
【図８】イベントキャッシュ部１７のリストの変更を説明するための図。
【図９】本実施形態に係る制御指示条件判定装置１の処理手順を示すフローチャート。
【図１０】本実施形態に係る制御指示条件判定装置１の処理手順を示すフローチャート。
【図１１】図１に示すイベント判定部１８による判定処理の処理手順を示すフローチャート。
【図１２】図１に示すイベント判定部１８による判定処理の処理手順を示すフローチャート。
【図１３】図１に示すイベント判定部１８による判定処理の処理手順を示すフローチャート。
【図１４】図１に示すイベント判定部１８による判定処理の処理手順を示すフローチャート。
【符号の説明】
【００６８】
１…制御指示条件判定装置、２…センサデータ送信装置、３…イベント受信装置、１１…状態判定データベース、１２…センサデータ収集部、１３…状態判定部、１４…イベント条件判定同期部、１５…イベント条件データベース、１６…イベント条件登録通知部、１７…イベントキャッシュ部、１８…イベント判定部、１９…イベント通知部、２１…イベントテーブル、２２…イベント条件テーブル、２３…要素条件テーブル、２４…センサテーブル。
【図１】
2009294763.tif 000003
【図２】
2009294763.tif 000004
【図３】
2009294763.tif 000005
【図４】
2009294763.tif 000006
【図５】
2009294763.tif 000007
【図６】
2009294763.tif 000008
【図７】
2009294763.tif 000009
【図８】
2009294763.tif 000010
【図９】
2009294763.tif 000011
【図１０】
2009294763.tif 000012
【図１１】
2009294763.tif 000013
【図１２】
2009294763.tif 000014
【図１３】
2009294763.tif 000015
【図１４】
2009294763.tif 000016