JP2006302256A

JP2006302256A - ディジタル監視システムのための規則ベースのインテリジェント・アラーム・マネジメント・システム

Info

Publication number: JP2006302256A
Application number: JP2006050708A
Authority: JP
Inventors: Mike Yu; ユマイク; Hitoshi Yashio; 仁八塩; Atsushi Kikukawa; 淳菊川; Namsoo Joo; ジョーナムスー
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Holdings Corp
Priority date: 2005-03-02
Filing date: 2006-02-27
Publication date: 2006-11-02
Anticipated expiration: 2026-02-27
Also published as: US7352279B2; US20060208872A1; JP4986478B2

Abstract

【課題】動的アラーム定義ならびに開発を容易にし、かつ一様かつ効率的にアラームならびにアクションをマネージする方法を提供する。
【解決手段】アラーム・マネジメント・システムは、センサ・デバイスおよび監視システムのうちの１ないし複数からカスタム化されたアラームを受信するアラーム受信機モジュールを含む。条件評価モジュールが、カスタム化されたアラームのための１ないし複数のカスタム化された条件の評価を行う。この評価を基礎として、アクション・ハンドリング・モジュールがカスタム化されたアクションを実行する。
【選択図】図１

Description

本発明は、概してセキュリティ・システムに関し、より詳細にはアラーム・マネジメント・システムに関する。

監視システムおけるアラームならびにアラーム・ハンドリング・メカニズムの仕様は、それぞれの監視アプリケーションごとに異なる傾向にある。しかしながら、ユーザの要求は、継続的に変化し続ける傾向を有する。したがって、すべての監視アプリケーションをサポートするシステムをあらかじめ定義し、開発することは困難である。さらにまた、それぞれの監視システムは、アラームならびにアクションについて独自のフォーマットを有しており、それらはほかの監視システムと共通利用できない。多くのベンダからの監視システムがインストールされるエンタープライズまたはワイド・エリア・センサ・ネットワーク監視環境においては、一様かつ効率的なアラームおよびアクションのマネージに対する需要が増加している。

したがって、動的アラーム定義ならびに開発を容易にし、かつ一様かつ効率的にアラームならびにアクションをマネージする方法が、特にエンタープライズまたはワイド・エリア・センサ・ネットワーク監視環境において必要とされている。本発明は、この要求に応える。

本発明によれば、アラーム・マネジメント・システムが、センサ・デバイスおよび監視システムのうちの１ないし複数からカスタム化されたアラームを受信するアラーム受信機モジュールを含む。条件評価モジュールが、カスタム化されたアラームのための１ないし複数のカスタム化された条件の評価を行う。この評価を基礎として、アクション・ハンドリング・モジュールがカスタム化されたアクションを実行する。

本発明の適用可能性の追加の分野については、以下に提供される詳細な説明から明らかになるであろう。ここで理解する必要があるが、これらの詳細な説明および特定の例は、本発明の好ましい実施態様を示してはいるが、例示のみを目的としており、本発明の範囲を限定することは意図されていない。

本発明は、以下の詳細な説明および添付の図面からより完全に理解されることになろう。

以下の好ましい実施態様の説明は、本質的に例示に過ぎず、いかなる形においても本発明、その応用、または利用を限定する意図はない。

前述した要約のとおり、本発明に従ったアラーム・マネジメント・システムは、センサ・デバイスおよび監視システムのうちの１ないし複数からカスタム化されたアラームを受信するアラーム受信機モジュールを含む。条件評価モジュールが、カスタム化されたアラームのための１ないし複数のカスタム化された条件の評価を行う。この評価を基礎として、アクション・ハンドリング・モジュールがカスタム化されたアクションを実行する。

システムの種々の実施態様を実現することができる。いくつかの実施態様においては、前述した３つのモジュールが同時の実行および、蓄積されたメタデータを含む共有状態情報に対する参照をサポートする。蓄積されたメタデータの例としては、事象の履歴、事象の効果、事象を生成する１ないし複数のデバイスの動的構成情報、および事象に関連付けされた記述メタデータの選択された部分が挙げられる。いくつかの実施態様においては、アラーム規則が、到来する事象をよりインテリジェントに処理するために使用することのできる状態情報として外部ＭＰＥＧ７メタデータを採用することができる。またいくつかの実施態様においては、システムは、開発者ならびにエンド・ユーザ両者による新しい共有状態定義、新しい規則、および新しいアクションのうちの１ないし複数の動的な作成を許容することができる。いくつかの実施態様においては、共有状態を、デバイス、ローカル・メモリ、リモート・メモリ、および外部データベースのうちの１ないし複数内のものとすることができる。いくつかの実施態様においては、規則の条件評価を、状態だけを基礎とするのではなく、動的に生成されたタイムスタンプならびにそのほかの、規則の実行と結果としてもたらされるアクションの起動を相関させるデータも基礎とすることができる。この独特の実行モデルは、高パフォーマンスおよび高信頼性のアラーム処理のための時間、空間、およびそのほかのメタデータ（実行の成功または失敗等）に基づく複数の相互に相関された事象パターンの検出においてもっとも効果的となる。以上述べた実施態様の特徴および機能は、種々の方法で組み合わせることが可能である。

さらに詳細を以下に説明するとおり、本発明に従った規則ベースのインテリジェント・アラーム・マネジメント・システムは、アラームのフォーマットの修正に加えてアラーム・ハンドリング・ロジックの修正を、システムの再開発を伴うことなく可能にする。たとえば、アラーム・マネジメント・システムは、オブジェクト指向テクノロジ、動的クラス・ローディング・テクノロジ、および規則エンジン・テクノロジを使用して実装することができる。また特徴、複合アラーム・マネジメント、アラーム相関、およびアラーム・フィルタリングを実現することが可能である。さらに、本発明のアラーム・マネジメント・システムは、外部システムにアクセスしてアラームを取り扱う必要が生じた場合には、外部システムとの統合も容易である。要約すれば、本発明のアラーム・ハンドリング・アプローチは、本発明のアラーム・マネジメント・システムの修正のための新しい開発サイクルの回避、アラーム・マネジメント・システムの能力の有意な強化、および外部システムとの容易なインタラクションに寄与する。

図１を参照すると、各監視システム１０Ａ〜１０Ｄは、独自のフォーマットのアラーム１２Ａ〜１２Ｄを有する。これらのアラーム１２Ａ〜１２Ｄは、システム間通信のための標準オープン・インターフェースであるウェブ・サービス１６を介してアラーム・サーバ１４に送られる。アラーム・サーバ１４は、カメラ・アラーム１２Ａ、ストレージ・アラーム１２Ｂ、トラッキング・アラーム１２Ｃ、およびアクセス・コントロール・アラーム１２Ｄを含む異なるフォーマットのアラーム１２Ａ〜１２Ｄをマネージする。また、ローカル・データベース１８も備え、バリデーションを目的として外部データベース２０と通信することもできる。デバイスの動的構成情報を、ランタイムでこの外部データベースから読み出すこともできる。前述した目的は、カスタム化インターフェース２４を有する規則エンジン／プラットフォーム機能２２によって実現することができる。

ここで図２を参照すると、クライアント３０用のクライアント・プラットフォーム機能２２Ａおよびサーバ３２用のサーバ・プラットフォーム機能２２Ｂは、基本アラーム３４Ａおよび３４Ｂ、条件３６、アクション３８、規則４０、データベースに対するインターフェース、およびクライアントとサーバの間のウェブ・サービス通信のマネジメントを実装する。また、ＳＤＫまたはＡＰＩを介してカスタム化インターフェース２４Ａおよび２４Ｂも提供され、プラットフォームの再プログラミングを伴わずにカスタム・アラーム４２Ａ１、４２Ａ２、４２Ｂ１、および４２Ｂ２、カスタム条件４４Ａおよび４４Ｂ、およびカスタム・アクション４６Ａおよび４６Ｂを実現することができる。カスタマは、独自のアラーム、条件、およびアクションを定義し、カスタム規則４８のインスタンスを作成することができる。その後、プラットフォームが残りのマネージを行うことができる。

次に図３を参照すると、このサーバによって構成されるアラーム・マネジメント・システム５０は、モジュールおよびデータベース／データ構造を含む。アラーム受信機モジュール５２は、センサ・デバイスもしくはそのほかの監視システムからアラームを受信し、それらを持続性アラーム・キューＤＢ５４に保存する。これらのアラームは、後に処理される。メッセージ・キュー・クラス５６は、アラーム・キューＤＢ５４にアクセスするＡＰＩを提供する。フィルタリング・ハンドラ５８は、キューＤＢ５４からアラームを吸い出し、そのアラームに対してフィルタリング条件を適用する。条件が満たされるときには、そのアラームが無視されてアラーム・ログＤＢ６０に保存される。満たされなければ、さらに処理するためにそれがアラーム状態マネジメント・モジュール６２に送られる。アラーム状態マネジメント・モジュール６２は、アラームのライフサイクルをマネージし、アクティブ・アラーム６６を追跡する。アクション・ハンドラ６４は、カスタム化されたアクションを動的にロードし、それらを実行する。いくつかのアクションでは、外部システムとの通信を必要とすることがある。規則エンジン６８は、規則を読み出し、それらを評価する。また、アクティブ・アラームを読み出してアラームと事象の履歴を相関させる。外部システムに条件の評価を要求することもできる。管理インターフェース７０は、管理者によるシステムのマネージを可能にする。これは、規則のインスタンス、アラーム定義、およびフィルタリング条件の検索、追加、削除、および更新を行う手段を提供する。開発インターフェース７２は、開発者によるこのシステムの拡張を可能にする。これは、アラーム、述部、およびアクションのカスタム化を行い、実装ファイルを保存するＳＤＫおよびＡＰＩを提供する。規則ＤＢ／アラーム定義ＤＢ／条件ＤＢアクセス・クラス７４は、規則ＤＢ７６、アラーム定義ＤＢ７８、およびフィルタリング条件ＤＢ８０にアクセスするＡＰＩを提供する。外部データベース８２は、デバイスの動的構成情報を提供する。規則エンジン６８は、アラームを取り扱うときにこの情報を使用する。

アラーム・サーバ内には、異なる種類のデータベースおよびデータ構造が存在する：すなわちメッセージ・キュー用のリレーショナル・データベース、規則のインスタンスならびにアラームをストアするＸＭＬファイル、カスタム化されたサブクラスの実装をストアするファイルである。データベース／データ構造は、アラーム・キューＤＢを含み、それがアラームの、非同期、ファースト‐イン・ファースト‐アウト、かつ持続性のストレージを提供する。アラーム・キュー・データベースは、キューに関するメタデータ情報とともにアラームをストアするリレーショナル・データベースである。また、規則ＤＢは、カスタム化された述部およびアクションの実装をストアする。規則ＤＢは、規則のインスタンスを、述部およびアクションの実装のためのＸＭＬファイルおよび．ｃｌａｓｓファイル内にストアしている。さらにアラーム定義ＤＢは、アラーム定義のリストを維持し、それにはアラーム定義の実装のためのＸＭＬファイルおよび．ｃｌａｓｓファイル内のアラーム定義のインスタンスが含まれる。さらにまた条件ＤＢは、カスタム化されたアラームの．ｃｌａｓｓファイルを含む、カスタム化されたフィルタリング条件をストアする。さらにまたアラーム・ログＤＢは、アラームのインスタンスを含めて、すべての終了済みアラームを保存する。またメモリ内アクティブ・アラームＤＢは、アクティブ・アラームをストアするメモリ内のデータ構造である。

次に図４を参照すると、ａｌａｒｍクラス１００は、ａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラス１０２、ａｌａｒｍ＿ｄｙｎａｍｉｃクラス１０４、およびａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラス１０６を含んでいる。ａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラス１０２は、一般にシステムの構成の間に管理者によって作成される静的アラーム定義のリストを含む。通常、それらが頻繁に変更されることはない。ａｌａｒｍ＿ｄｙｎａｍｉｃクラス１０４は、デバイスまたはサーバによって生成されるときにアラームの情報を取り込むべく定義される。これは、アラームのライフサイクルをマネージする。ａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラス１０６は、その生成時の環境の情報を含む。カスタマは、クラスのサブクラスとしてカスタム化されたクラスを定義することによってクラス１００Ａ、１０２Ａ、１０４Ａ、１０６Ａ、１１４Ａ、および１１６Ａをカスタム化することができる。ｅｎｄ＿ｒｕｌｅクラス１０８は、アラームのライフ・スパンおよびそのアラームの終了時に取られるアクションを取り決める。ａｃｔｉｖｅ＿ａｌａｒｍｓクラス１１０は、アラーム・サーバによって、現在のアラームの評価およびアラーム相関機能のサポートのために能動的に使用されるアラームのセットである。

ｒｕｌｅクラスは、ｃｏｎｄｉｔｉｏｎクラス１１４およびａｃｔｉｏｎクラス１１６を含む。ｃｏｎｄｉｔｉｏｎクラスは、述部のセットである。述部は、真または偽を返す関数とすることが可能である。述部は、関数のパラメータとしてａｃｔｉｖｅ＿ａｌａｒｍｓクラス１１０および／またはａｌａｒｍクラス１００を持つことができる。ａｃｔｉｏｎクラス１１６は、パラメータとしてａｃｔｉｖｅ＿ａｌａｒｍｓクラス１１０および／またはａｌａｒｍクラス１００を伴う関数である。ａｃｔｉｏｎクラス１１６によって実行される関数の例として、電子メール送信、通知等が挙げられる。システムの拡張をサポートするため、ｐｒｅｄｉｃａｔｅクラス１１４およびａｃｔｉｏｎクラス１１６を、サブクラスを通じてカスタム化することができる。カスタム化されたｐｒｅｄｉｃａｔｅクラス１１４Ａは、ｅｖａｌｕａｔｅ（）メンバ関数を実装することが可能であり、カスタム化されたａｃｔｉｏｎクラス１１６Ａは、ｅｘｅｃｕｔｅ（）メンバ関数を実装することができる。

ここで図５を参照するが、２００においてアラームがアラーム・マネジメント・システムに到来すると、システムは、そのアラームを用いてフィルタリング条件を実行し、不適当なアラームをふるい落とす（２０２）。フィルタリング条件が真であれば、そのアラームが無視され、２０４において状態が『アラーム起動なし』になる。真でなければアラームが次の処理状態に移動し、２０６において状態が『アラーム開始』になる。『アラーム開始』状態においては、２０８Ａ〜２０８Ｄにおいてこのアラームと規則の比較が行われる。合致する条件がない場合には２０４に進み、そのアラームは起動されない。終了条件に応じて２つのケースが存在する。２０８Ａに示されるように、終了条件がオフであり、合致する条件がない場合には、そのアラームは、アクティブ・アラーム・リストにストアされずに、直ちに２０４の終了状態（『アラーム起動なし』状態）に進む。それ以外の２０８Ｂに示されている場合には、２０９においてそのアラームが休眠リストにストアされ、到来アラームとの相関のための考慮がなされる。

少なくとも１つの条件が真である場合には２つのケースが存在する。最初のケースはそのアラームについてエンド条件が存在しない場合である（２０８Ｄ）。エンド条件がないということは、そのアラームが一過性であり、アクティブ・リスト内に入らないことを意味する。この場合、その条件に関連付けされるアクションが２１０において実行され、アラームが直ちに２１２において完了する。他方のケースは、２０８Ｃにおける場合のように、そのアラームに関連付けされるエンド条件が存在する。この場合においては関連付けされたアクションが２１０において実行され、２１４においてアラームがアクティブになる。アクティブもしくは休眠アラームの状態は、２１６Ａおよび２１６Ｂに示されるとおり事象に応答して最終的に２１２において完了となるが、２１８Ａおよび２１８Ｂに示されるとおり、エンド条件が真の場合に限られる。アクティブ・アラームが終了されるときには、それらに関連付けされた任意のエンド・アクションを２２０において実行することができる。

種々の事象がアクティブ・アラームを終了することができる。たとえば、新しいアラームが到来し、新しいアラームのエンド条件が満たされたとき、アラーム事象が発生する。また、エンド条件が持続時間として指定されており、タイマが満了すると、タイマ事象が発生する。さらにエンド条件が、合計のアクティブ・アラームの数についての限界として指定されており、その数が限界を超えるとカウンタ事象が発生する。これらのタイプの事象は、同様に休眠アラームを終了することもできる。

次に、本発明に関する規則の仕様を調べる。規則は、次のように記述することができる。
Ｆ１（Ｐ１１，Ｐ１２，．．．，Ｐ１ｎ１）＾Ｆ２（Ｐ２１，Ｐ２２，．．．，Ｐ２ｎ２）＾．．．Ｆｍ（Ｐｍ１，Ｐｍ２，．．．，Ｐｍｎｍ）‐＞Ａｃｔｉｏｎ１，Ａｃｔｉｏｎ２，．．．，Ａｃｔｉｏｎｋ
これにおいて：（ａ）Ｆｉは、あらかじめ決定済みもしくはカスタム化されたブール関数であり、真または偽を返す；（ｂ）Ｐｉｊは次のうちのいずれかである：（ｉ）通常はａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラスからもたらされる定数；（ｉｉ）ａｌａｒｍクラスのカスタム化されたサブクラスによってインスタンシエートされる現在のアラームの属性もしくは現在のアラーム自体（属性、属性のグループ、またはクラス自体とすることができる；しかしながら、属性のグループを表すことは容易ではないことから、好ましくは属性もしくはクラスのいずれかに制限される）；または（ｉｉｉ）アクティブ・アラームもしくは以前に以前の述部から適格となったアラームのリストに対する参照とするアラームの反復子（この反復子は、入力または出力されると仮定される；言い換えると述部Ｆｉは、反復子を取り、それを処理し、Ｆｉを満足する修正後の反復子を返し、したがってバインディングを実装する）；かつ（ｃ）ａｃｔｉｏｎｉは、あらかじめ定義されるかカスタム化された関数である。

ここでいくつかの点に注意することは有用である；（ａ）セマンティックは、Ｆ１，Ｆ２，およびＦｍが真であれば、ａｃｔｉｏｎ１，ａｃｔｉｏｎ２，．．．，およびａｃｔｉｏｎｋを順序どおりに実行するということである；（ｂ）条件の述部およびアクションの順序は、重要である；および（ｃ）関数の引数の数に制限はない；しかしながら、意味のある条件を定義する上で、たとえば定数、現在のアラーム、および反復子といった３つの引数があれば充分とすることができる。

次に、本発明に関する条件およびアクションの指定について調べる。条件およびアクションは、管理者もしくは開発者がカスタム化された述部およびアクションを定義できるところである。次に示すキーワードおよび規約を、管理者もしくは開発者が条件を定義する補助として提供する：（ａ）定数はダブル・クオートを用いて、“ドアが開いている”または“１２３４”等のように表現される；ＡＬＡＲＭは、現在のアラームを示すキーワードであり、アラームの属性は、ドットおよびその属性の名前をキーワードに続けることができる（たとえば、ＡＬＡＲＭ．ａｌａｒｍ＿ｉｄ）；（ｂ）ＦＵＬＬ＿ＩＴＥＲＡＴＯＲは、アクティブ・アラームのリストに対する参照を示すキーワードである；（ｃ）ＣＵＲＲＥＮＴ＿ＩＴＥＲＡＴＯＲは、以前の述部によって適格とされたアラームのリストに対する参照を示すキーワードである；（ｄ）ＣＵＲＲＥＮＴ＿ＩＴＥＲＡＴＯＲは、バインディングのコンセプトをサポートするために導入されている。たとえば、Ａ（）およびＢ（）をブール関数として、条件のセマンティック、Ａ（ＦＵＬＬ＿ＩＴＥＲＡＴＯＲ）およびＢ（ＦＵＬＬ＿ＩＴＥＲＡＴＯＲ）は、アクティブ・アラームを用いてＡ（）を評価し、少なくとも１つの適格アラームが存在するとき真を返す。同一のロジックがＢ（）にも適用される。しかしながら、場合によってはアクティブ・アラームに代えてＡ（）からの適格アラームを用いてＢ（）を評価する必要がある。その目的で条件Ａ（ＦＵＬＬ＿ＩＴＥＲＡＴＯＲ）およびＢ（ＣＵＲＲＥＮＴ＿ＩＴＥＲＡＴＯＲ）を使用することができる。

本発明のためのブール関数の実装を次に調べる。アラーム・マネジメント・システムは、ｅｑｕａｌ（）、ｌｅｓｓｔｈａｎ（）、ｇｒｅａｔｅｒｔｈａｎ（）等のあらかじめ定義済みブール関数のセットを提供することができる。カスタム化したブール関数の実装には次のステップが必要になる：（ａ）．ｊａｖａファイルのＸＭＬファイルを用いて名前および引数のマッチングを行うブール関数を定義する；ここで注意する必要があるが、カスタム化されたａｌａｒｍクラスがＡＬＡＲＭに置き換わり、ａｌａｒｍ＿ｉｔｅｒａｔｏｒクラスがＦＵＬＬ＿ＩＴＥＲＡＴＯＲおよびＣＵＲＲＥＮＴ＿ＩＴＥＲＡＴＯＲを置き換わることからＡＬＡＲＭおよびＦＵＬＬ＿ＩＴＥＲＡＴＯＲ等のキーワードは使用するべきでない；（ｂ）．ｊａｖａをコンパイルして．ｃｌａｓｓファイルを作成する；および（ｃ）．ｃｌａｓｓファイルを指定の場所に配置する。

本発明のための規則エンジンの実装について次に調べる。アラームが与えられると、エンジンがＸＭＬで記述された規則を読み出し、その規則を適用し、条件が合致するとアクションを実行する。ここで注意が必要であるがエンジンは、アラームおよび規則が定義される前に実装されることから、エンジンには、カスタム化されたアラームの詳細がわからない。

規則を評価するアルゴリズムは次のようになる：（Ａ）アラームを受け取る；（Ｂ）システムからＸＭＬのすべての規則を読み出す；（Ｃ）各規則について、条件および述部を獲得する：（１）各述部について、関数名および引数の記述を獲得する：（ａ）ジャバ（Ｊａｖａ）で引数を組み立てる：（ｉ）それが定数の場合には、それを引数に割り当てる；（ｉｉ）それがＡＬＡＲＭの場合には、カスタム化されたアラームの参照を引数に割り当てる；（ｉｉｉ）それがＦＵＬＬ＿ＩＴＥＲＡＴＯＲの場合には、アクティブ・アラームの反復子の参照を引数に割り当てる；（ｉｖ）それがＣＵＲＲＥＮＴ＿ＩＴＥＲＡＴＯＲの場合には、最後のブール関数の引数の反復子の参照を引数に割り当てる；（ｂ）関数を動的にロードする；（ｃ）引数を用いてその関数を実行する；（ｄ）戻り値が偽の場合には、停止して次の規則のために（Ｃ）へ進む；戻り値が真であり、述部が最後の１つであればアクションのリストを構築する；（ｅ）それが最後の条件でない場合には、この関数から反復子引数を更新し、次の述部のために（１）へ進む；（Ｄ）規則が評価された後、エンジンがアクションのリストをアクション・ハンドラに送る。

本発明に従ったカスタム化のためのプロシージャを次に調べる。以下は、システムをカスタム化するためのプロシージャである：（ａ）ａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラスをカスタム化する：（ｉ）ａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラスを拡張する；（ｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｉｉｉ）拡張されたクラスのインスタンスを作成する；および（ｉｖ）そのインスタンスをストアする；（ｂ）ａｌａｒｍ＿ｄｙｎａｍｉｃクラスをカスタム化する：（ｉ）ａｌａｒｍ＿ｄｙｎａｍｉｃクラスを拡張する；および（ｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｃ）ａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラスをカスタム化する：（ｉ）ａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラスを拡張する；および（ｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｄ）ａｌａｒｍクラスをカスタム化する：（ｉ）ａｌａｒｍクラスを、カスタム化されたａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎ、カスタム化されたａｌａｒｍ＿ｄｙｎａｍｉｃ、および／またはカスタム化されたａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラスを含めることによって拡張する；（ｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｅ）ａｃｔｉｏｎクラスをカスタム化する：（ｉ）ａｃｔｉｏｎクラスを拡張する；（ｉｉ）メンバ関数、ｅｘｅｃｕｔｅ（）を実装する；および（ｉｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｆ）ｐｒｅｄｉｃａｔｅクラスをカスタム化する：（ｉ）ｐｒｅｄｉｃａｔｅクラスを拡張する；（ｉｉ）メンバ関数、ｅｘｅｃｕｔｅ（）を実装する；（ｉｉｉ）．ｊａｖａクラスをコンパイルし、それをディポジトリ内に入れる；（ｇ）規則をストアする（ｉ）規則をＸＭＬでストアする；および（ｈ）アラーム・ジェネレータ：（ｉ）カスタム化されたａｌａｒｍクラスをインスタンシエートする；および（ｉｉ）カスタム化されたａｌａｒｍクラスのインスタンスをアラーム・サーバに送る。

以上の説明から認識できるとおり、本発明に従ったアラーム・サーバは、いくつかの有利な特徴を提供する。たとえば、これは、複数の監視システムを効率的にマネージする。また、多くのフォーマットのアラームをサポートする。さらに、柔軟な条件ならびにアクションをサポートする。さらにまた、柔軟な規則評価エンジンをサポートする。さらにまた、再プログラミングを伴うことのないカスタム化をサポートする。さらにまた、開発およびカスタム化のコストを削減する。さらにまた、ウェブ・サービスを介した共通利用をサポートする。最後に、これは、外部システムと容易に統合できる。

以上の本発明の説明は、本質的に例示に過ぎず、したがって本発明の要旨から逸脱しない変形は本発明の範囲内に含まれることが意図されている。その種の変形は、本発明の精神ならびに範囲から逸脱していると考えられるべきものではない。

本発明によるアラーム・サーバを例示したブロック図である。本発明によるアラーム・サーバのプラットフォーム機能およびカスタム化を例示したブロック図である。本発明によるアラーム・マネジメント・システムを例示したブロック図である。本発明によるアラーム・マネジメント・システムによって採用されるソフトウエア・オブジェクトのためのオブジェクト指向クラス構造を例示したブロック図である。本発明によるアラーム・マネジメント方法を例示したフローチャートである。

符号の説明

１０Ａ〜１０Ｄ監視システム
１２Ａ〜１２Ｄアラーム
１２Ａカメラ・アラーム
１２Ｂストレージ・アラーム
１２Ｃトラッキング・アラーム
１２Ｄアクセス・コントロール・アラーム
１４アラーム・サーバ
１６ウェブ・サービス
１８ローカル・データベース
２０外部データベース
２２規則エンジン／プラットフォーム機能
２２Ａクライアント・プラットフォーム機能
２２Ｂサーバ・プラットフォーム機能
２４カスタム化インターフェース
２４Ａ、２４Ｂカスタム化インターフェース
３０クライアント
３２サーバ
３４Ａ基本アラーム
３４Ｂ基本アラーム
３６条件
３８アクション
４０規則
４２Ａ１カスタム・アラーム
４４Ａ、４４Ｂカスタム条件
４６Ａおよび４６Ｂカスタム・アクション
４２Ａ１、４２Ａ２、４２Ｂ１、および４２Ｂ２カスタム・アラーム
４８カスタム規則
５０アラーム・マネジメント・システム
５２アラーム受信機モジュール
５４アラーム・キューＤＢ
５６メッセージ・キュー・クラス
５８フィルタリング・ハンドラ
６０アラーム・ログＤＢ
６２アラーム状態マネジメント・モジュール
６４アクション・ハンドラ
６６アクティブ・アラーム
６８規則エンジン
７０管理インターフェース
７２開発インターフェース
７４規則ＤＢ／アラーム定義ＤＢ／条件ＤＢアクセス・クラス
７６規則ＤＢ
７８アラーム定義ＤＢ
８０フィルタリング条件ＤＢ
８２外部データベース
１００ａｌａｒｍクラス
１００Ａ、１０２Ａ、１０４Ａ、１０６Ａ、１１４Ａ、および１１６Ａクラス
１０２ａｌａｒｍ＿ｄｅｆｉｎｉｔｉｏｎクラス
１０４ａｌａｒｍ＿ｄｙｎａｍｉｃクラス
１０６ａｌａｒｍ＿ｅｎｖｉｒｏｎｍｅｎｔクラス
１０８ｅｎｄ＿ｒｕｌｅクラス
１１０ａｃｔｉｖｅ＿ａｌａｒｍｓクラス
１１４ｃｏｎｄｉｔｉｏｎクラス；ｐｒｅｄｉｃａｔｅクラス
１１４Ａｐｒｅｄｉｃａｔｅクラス
１１６ａｃｔｉｏｎクラス
１１６Ａａｃｔｉｏｎクラス

Claims

センサ・デバイスおよび監視システムのうちの１ないし複数からカスタム化されたアラームを受信するアラーム受信機モジュールと、
カスタム化されたアラームのための１ないし複数のカスタム化された条件の評価を実行する条件評価モジュールと、
前記評価を基礎として、カスタム化されたアクションを実行するアクション・ハンドリング・モジュールと
を包含するアラーム・マネジメント・システム。
条件およびアラーム定義のインスタンスの検索、追加、削除、および更新を行うユーザ機能を提供するユーザ・インターフェースを包含する、請求項１に記載のシステム。
前記条件評価モジュールは、カスタム化された規則を評価することによってアラームを処理するための規則エンジンを含み、１ないし複数のカスタム化されたアクションが実行されるべきか否かをカスタム化された規則に関連付けされたカスタム化された条件を基礎として決定する、請求項１に記載のシステム。
前記条件評価モジュールは、カスタム化されたフィルタリング条件を評価してアラームが無視されるべきか否か、あるいは前記規則エンジンによって処理されるべきか否かを決定するフィルタリング条件ハンドラを含む、請求項３に記載のシステム。
前記規則エンジンは、外部システムに対して、規則によって指定される条件の評価を要求する、請求項３に記載のシステム。
アラーム、述部、およびアクションをカスタム化し、かつ実装ファイルを保存するＳＤＫおよびＡＰＩを提供することによって、開発者が前記アラーム・マネジメント・システムを拡張することを可能にする開発インターフェースを包含する、請求項１に記載のシステム。
アラームのライフサイクルをマネージし、アクティブ・アラームを追跡するアラーム状態マネジメント・モジュールを包含する、請求項１に記載のシステム。
外部データベースからデバイスの動的構成情報を読み出すシステムを包含する、請求項１に記載のシステム。
センサ・デバイスおよび監視システムのうちの１ないし複数からカスタム化されたアラームを受信すること、
１ないし複数のカスタム化された条件の評価を実行することによってカスタム化されたアラームを処理し、カスタム化されたアクションを実行する必要があるか否かを決定すること、
前記評価を基礎として、カスタム化されたアラームを実行すること
を包含する、アラーム・マネジメント方法。
条件およびアラーム定義のインスタンスの検索、追加、削除、および更新に使用することのできるユーザ・インターフェースを提供することを包含する、請求項９に記載の方法。
前記評価を実行することは、カスタム化された規則を評価し、カスタム化された規則に関連付けされた１ないし複数のカスタム化されたアクションが実行されるべきか否かを、カスタム化された規則に関連付けされたカスタム化された条件を基礎として決定することを包含する、請求項９に記載の方法。
前記評価を実行することは、カスタム化されたフィルタリング条件を評価してアラームが無視されるべきか否か、あるいは前記カスタム化された規則の評価を実行することによって処理されるべきか否かを決定することを含む、請求項９に記載の方法。
前記評価を実行することは、外部システムに要求を伝達して、規則によって指定される１ないし複数の条件を評価することを含む、請求項９に記載の方法。
前記評価を実行することは、それぞれの規則のための条件および１ないし複数の述部を獲得することを含む、請求項９に記載の方法。
前記評価を実行することは、それぞれの述部のための関数の名前および引数の記述を獲得することを含む、請求項１４に記載の方法。
前記評価を実行することは、
（ａ）前記引数を組み立てること、
（ｂ）前記関数をロードすること、
（ｃ）前記引数を用いて前記関数を実行し、それによって前記評価を実行すること
を含む、請求項１５に記載の方法。
前記引数を組み立てることは、
（ｉ）前記記述内の値を引数に割り当てること、
（ｉｉ）カスタム化されたアラームの参照を引数に割り当てること、
（ｉｉｉ）すべてのアクティブ・アラームのセットのデータ構造に対する参照を引数に割り当てること、
（ｉｖ）アクティブ・アラームのセットのデータ構造に対する参照を引数に割り当てることにして、前記参照は、別の識別可能な引数に対する割り当てのために選択されること、
のうちの１ないし複数を含む、請求項１６に記載の方法。
前記カスタム化されたアラームを実行することは、
（ａ）前記評価の結果を基礎としてアクションの集合を組み立てること、
（ｂ）前記アクションの集合を、前記アクションを実行するべく適合されたアクション・ハンドリング・モジュールに渡すこと、
を含む、請求項９に記載の方法。
アラーム、述部、およびアクションをカスタム化し、かつ実装ファイルを保存するＳＤＫおよびＡＰＩを提供することによって、開発者がアラーム・マネジメント・システムを拡張することを可能にする開発インターフェースを提供することを含む、請求項９に記載の方法。
アラームのライフサイクルをマネージすること、およびアクティブ・アラームを追跡することを包含する、請求項９に記載の方法。
前記評価を実行することは、事象の相関のためにアクティブ・アラームに対して要求を伝達することを含む、請求項９に記載の方法。
センサ・デバイスおよび監視システムのうちの１ないし複数からアラームを受信するアラーム受信機モジュールと、
規則に関連付けされた条件を基礎として１ないし複数のアクションが実行されるべきか否かを決定する、（ａ）各規則について条件および１ないし複数の述部を獲得すること、（ｂ）各述部について関数名および引数の記述を獲得すること、（ｃ）記述された引数を用いて関数を実行し、それによって前記規則を評価することを含む、アラームを処理するために規則を評価する規則エンジンと、
フィルタリング条件を評価してアラームが無視されるべきか否か、あるいは前記規則エンジンによって処理されるべきか否かを決定するフィルタリング条件ハンドラと、
前記規則エンジンによる評価の結果を基礎としてアクションを実行するアクション・ハンドリング・モジュールと
を包含するアラーム・マネジメント・システム。
条件およびアラーム定義のインスタンスの検索、追加、削除、および更新を行い、それによってカスタム化されたアラーム、カスタム化されたアラームの評価を基礎としてカスタム化されたアクションのシーケンスを条件付きで開始するためのカスタム化された規則、およびカスタム化されたアラームが前記カスタム化された規則によって評価されることを条件付きで防止するためのカスタム化されたフィルタリング条件を獲得するユーザ機能を提供するユーザ・インターフェースを包含する、請求項１に記載のアラーム・マネジメント・システム。