Patent Application
20060208872
The present invention generally relates to security systems, and relates in particular to an alarm management system.
Specifications of alarms and alarm handling mechanisms in surveillance systems tend to be different for each surveillance application. However, user requirements have tendency to keep changing. Therefore, it is difficult to predefine and develop a system to support all surveillance applications. Moreover, each surveillance system has its own format of alarms and actions that are not interoperable with other surveillance systems. In enterprise or wide area sensor network surveillance environments where surveillance systems from many vendors are installed, demands to uniformly and efficiently manage alarms and actions increase. Thus, there is a need for a way to ease dynamic alarm definition and development, and to uniformly and efficiently manage alarms and actions, especially in enterprise and wide area sensor network surveillance environments. The present invention fulfills this need.
In accordance with the present invention, an alarm management system includes an alarm receiver module receiving customized alarms from one or more of sensor devices and surveillance systems. A condition evaluation module performs an evaluation of one or more customized conditions for a customized alarm. An action handling module executes customized actions based on the evaluation.
Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein:
The following description of the preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses.
As summarized above, an alarm management system according to the present invention includes an alarm receiver module receiving customized alarms from one or more of sensor devices and surveillance systems. A condition evaluation module performs an evaluation of one or more customized conditions for a customized alarm. An action handling module executes customized actions based on the evaluation.
Various embodiments of the system can be realized. In some embodiments, the three aforementioned modules support simultaneous execution and reference to a shared state information including accumulated meta data. Examples of accumulated metadata include a history of events, effects of the events, dynamic configuration information of one or more devices generating the events, and selected portions of description meta data associated with the events. In some embodiments, external MPEG7 meta data can be employed as state information that an alarm rule can use to process incoming events more intelligently. In some embodiments, the system can allow both the developers and end users to create dynamically one or more of new shared state definitions, new rules, and new actions. In some embodiments, the shared states can be in one or more of the device, local memory, remote memory, and an external database. In some embodiments, the condition evaluation of a rule can be based not only on the state, but can also be based on dynamically generated time stamps and other data correlating the execution of rule and consequent firing of actions. This unique execution model is most effective in detecting multiple inter-correlated event patterns based on time, space, and other meta data (such as success or failure of execution, etc.) for high performance and reliable alarm processing. Features and functionalities of the aforementioned embodiments can be combined in various ways.
As further explained below, a rule based, intelligent alarm management system according to the present invention allows modification of format of an alarm, plus modification of alarm handling logic, without redevelopment of the system. For example, the alarm management system can be implemented using object oriented technology, dynamic class loading technology, and rule engine technology. Also, features, complex alarm management, alarm correlation, and alarm filtering can be realized. Further, the alarm management system of the present invention is easy to integrate with external systems if needs arise to access the external systems to handle alarms. In summary, the alarm handling approach of the present invention contributes to avoiding a new development cycle in order to modify an alarm management system of the present invention, significantly enhances capability of the alarm management system, and easily interacts with external systems.
Referring to
Turning now to
Turning now to
There are different kinds of databases and data structures in the alarm server: a relational database for message queue, XML files to store instances of rules and alarms, files to store implementation of customized subclasses. Databases/data structures include alarm queue DB, which provides asynchronous, first-in first-out, and persistent storage of alarms. Alarm queue database is a relational database to store alarms with meta data information about queue. Also, rule DB stores rules and implementations of customized predicates and actions. Rule DB stores instances of rules in XML files and class files for implementations of predicates and actions. Further, alarm definition DB maintains a list of alarm definitions, including instances of alarm definitions in XML files and class files for implementations of alarm definitions. Yet further, condition DB stores customized filtering conditions, including class files of customized alarms. Even further, alarm log DB saves all terminated alarms, including instances of alarms. Further still, in-memory active alarms DB is a data structure in memory that stores active alarms.
Turning now to
A rule class includes a condition class 114 and an action class 116. The condition class is a set of predicates. A predicate can be a function that returns true or false. A predicate can have the active_alarms class 110 and/or the alarm class 100 as parameters of the function. The action class 116 is a function with the active_alarms class 110 and/or the alarm class 100 as parameters. Examples of functions performed by the action class 116 are sending email, notification, and so on. In order to support extension of the system, the predicate class 114 and action class 116 can be customized via a subclass. A customized predicate class 114A can implement the evaluate( ) member function, and a customized action class 116A can implement the execute( ) member function.
Turning now to
If at least one condition is true, there are two cases. The first case is when there is no end condition for the alarm 208D. Lack of an end condition means that the alarm is transient and will not be in the active list. In this case, the actions associated with the condition are executed at 210 and the alarm immediately becomes completed at 212. The other case is when there is an end condition associated with the alarm as at 208C. In this case, the associated actions are executed at 210 and the alarm becomes active at 214. The status of an active or dormant alarm will eventually become completed at 212 upon an event as at 216A and 216B, but only if the end condition is true as at 218A and 218B. When an active alarm is terminated, any end actions associated therewith can be executed at 220.
Various events can terminate an active alarm. For example an alarm event occurs when a new alarm arrives and the end condition of the new alarm is met. Also, a timer event occurs when the end condition is specified as duration of time and the timer expires. Further, a counter event occurs when the end condition is specified as a limitation on a number of total active alarms and the number goes beyond the limitation. These types of events can similarly terminate a dormant alarm.
A specification of rules for the present invention is explored immediately below. A rule can be written as follows:
F1(P11, P12, . . . , P1n1)ˆF2(P21, P22, . . . , P2n2)ˆ . . . Fm(Pm1, Pm2, . . . , Pmnm)->Action1, Action2, . . . , Actionk
where: (a) Fi is a predefined or customized boolean function that returns true or false; (b) Pij is either: (i) a constant, usually from the alarm_definition class; (ii) an attribute of the current alarm or the current alarm itself, instantiated by a customized subclass of the alarm class (it could be an attribute, a group of attributes, or the class itself; however, since it is not easy to represent a group of attributes, it is preferably restricted to either an attribute or the class); or (iii) an iterator of alarms that is a reference to the list of either active alarms or previously qualified alarms from a previous predicate (it is assumed that this iterator is input and output; in other words predicate Fi takes the iterator, processes it, and returns a modified iterator that satisfies Fi, thus implementing binding); and (c) actioni is a predefined or customized function.
A few notes are worthwhile to mention: (a) the semantic is that if F1, F2, and Fm are true, then execute action1, action2, . . . , and actionk in order; (b) the order of predicates of a condition and actions is important; and (c) the number of arguments of a function is unlimited; three arguments, however, may be sufficient to define meaningful conditions, such as a constant, the current alarm, and an iterator.
A specification of conditions and actions for the present invention is explored immediately below. Conditions and actions are where an administrator or developer can define customized predicates and actions. The following key words and conventions are provided to help them to define conditions: (a) a constant is represented by double quote, such as “Door is Open”, or “1234”; ALARM is a key word to denote the current alarm, such that an attribute of the alarm can be by addition of a dot and the name of the attribute following the key word (e.g., ALARM.alarm_id); (b) FULL_ITERATOR is a key word to denote a reference to the list of the active alarms; (c) CURRENT_ITERATOR is a key word to denote a reference to the list of qualified alarms by the previous predicate; (d) CURRENT_ITERATOR is introduced to support of the concept of binding. For example, the semantic of the condition, A(FULL_ITERATOR) and B(FULL_ITERATOR) where A( ) and B( ) are Boolean functions, is to evaluate A( ) with the active alarms and returns true if there exists at least one qualified alarm. The same logic is applied to B( ). However, there are some cases where B( ) needs to be evaluated with the qualified alarms from A( ), instead of the active alarms. The condition, A(FULL_ITERATOR) and B(CURRENT_ITERATOR) can be used for this purpose.
An implementation of Boolean functions for the present invention is explored immediately below. The alarm management system can provide a set of predefined Boolean functions, such as equal( ), lessthan( ), greaterthan( ), and so on. Implementing a customized Boolean function requires the following steps: (a) define a Boolean function matching the name and arguments with the XML file in a .java file; note that the keyword, such as ALARM and FULL_ITERATOR, should not be used here because the customized alarm class replaces ALARM and the alarm_iterator class replaces FULL_ITERATOR and CURRENT_ITERATOR; (b) compile the .java to create a .class file; and (c) place the class file into the designated place.
An implementation of a rule engine for the present invention is explored immediately below. Given an alarm, the engine reads rules written in XML, applies the rules, and executes actions if conditions are met. Note that the engine does not know details of customized alarms and rules since the engine is implemented before the alarms and rules are defined.
Here is an algorithm for evaluating rules: (A) receive an alarm; (B) read all rules in XML from the system; (C) for each rule, get the condition and the predicates: (1) for each predicate, get a function name and description of arguments: (a) build the arguments in Java: (i) if it is a constant, assign it to the argument; (ii) if it is ALARM, assign the reference of the customized alarm to the argument; (iii) if it is FULL_ITERATOR, assign the reference of the iterator of the active alarms to the argument; (iv) If it is CURRENT_ITERATOR, assign the reference of the iterator of the argument of the latest Boolean function to the argument; (b) load the function dynamically; (c) execute the function with the arguments; (d) if the return value is false, stop and go to (C) for the next rule; if the return value is true and the predicate is the last one, build a list of actions; (e) if it is not the last condition, update the iterator argument from this function and go to (1) for the next predicate; (D) after the rules are evaluated, the engine sends a list of actions to the action handler.
Procedures for customization according to the present invention are explored immediately below. The following is the procedure to customize the system: (a) customize the alarm_definition class: (i) extend the alarm_definition class; (ii) compile the .java class and place it into a depository; (iii) create instances of the extended class; and (iv) store the instances; (b) customize the alarm_dynamic class: (i) extend the alarm_dynamic class; and (ii) compile the java class and place it into a depository; (c) customize the alarm_environment class: (i) extend the alarm_environment class; and (ii) compile the .java class and place it into a depository; (d) customize the alarm class: (i) extend the alarm class by including the customized alarm_definition, customized alarm_dynamic, and/or customized alarm_environment class; (ii) compile the java class and place it into a depository; (e) customize the action class: (i) extend the action class; (ii) implement the member function, execute( ); and (iii) compile the .java class and place it into a depository; (f) customize the predicate class: (i) extend the predicate class; (ii) implement the member function, evaluate( ); (iii) compile the .java class and place it into a depository; (g) store rules: (i) store rules in XML; and (h) alarm generator: (i) instantiate the customized alarm class; and (ii) send the instance of the customized alarm class to the alarm server.
As can be appreciated from the foregoing description, the alarm server according to the present invention provides several advantageous features. For example, it efficiently manages multiple surveillance systems. Also, it supports many formats of alarms. Further, it supports flexible conditions and actions. Yet further, it supports a flexible rule evaluation engine. Further still, it supports customization without reprogramming. Even further, it reduces the cost of development and customization. Even further still, it supports interoperability via web services. Finally, it easily integrates with external systems.
The description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. Such variations are not to be regarded as a departure from the spirit and scope of the invention.
