A user-friendly multi-rule alarm logic method

Abstract

This invention discloses a user-friendly multi-rule alarm logic method. This invention takes abnormal events as system input and outputs alarms by executing pre-defined rules, achieving highly flexible and precise alarm customization. Rules can be added, removed, or changed without restriction, enabling the security alarm system to fully meet the user's customization needs. It effectively solves the problem that existing security alarm systems lack a systematic alarm logic processing system and are difficult to customize alarms flexibly and precisely.

Description

Technical Field

[0001] This invention relates to the field of intelligent security alarm technology, and in particular to a user-friendly multi-rule alarm logic method. Background Technology

[0002] Intelligent security alarm systems are widely used in important locations such as factories, mines, schools, and airports. They typically incorporate multiple sensors, such as vibration, current, and temperature sensors, as well as cameras, to detect abnormal events in the monitored area and generate appropriate alarms.

[0003] Traditional alarms are generally based on thresholds, such as temperature, vibration, or duration. An alarm is generated when a threshold is exceeded, or an event triggers the alarm, such as a camera detecting a target. Some alarm rule systems can further process alarms, such as merging and filtering related alarms, and suppressing frequent alarms. While these alarm rule systems further optimize alarms and reduce duplicate and redundant alarms, they still lack a complete logical system, making it difficult to flexibly and precisely customize alarms according to needs, and difficult to change rules. For example, it is difficult to implement the following fine-grained customization functions:

[0004] 1. There are different strict levels during the day and at night.

[0005] 2. There are different levels of strictness on weekdays and holidays.

[0006] 3. Different alarm rules apply to different defense zones and at different times.

[0007] 4. Define custom alarm logic conditions, such as generating an alarm when the system temperature is high (or the load power is low or the system has been idle for a long time).

[0008] 5. Customize the alarm timing. For example, if the cable current rises first and then the temperature rises, it is a normal phenomenon under high load. If the cable temperature rises first and then the current rises, it is an abnormal situation.

[0009] 6. Allows contradictory rules, ensuring a unique and definite result in all situations. This allows for the addition, removal, and modification of rules without needing to check for rule conflicts.

[0010] 7. A user-friendly interface allows you to set the above rules without using a programming language. Summary of the Invention

[0011] In view of this, the present invention provides a user-friendly multi-rule alarm logic method. This method allows users to conveniently and unrestrictedly customize the logical conditions and timing conditions for triggering alarms; it allows the formulation of multiple alarm rules, with different rules for different zones and different times; it allows the addition, deletion, and modification of alarm rules; and it has a user-friendly interface, eliminating the need to use programming languages ​​to set these rules.

[0012] A user-friendly multi-rule alarm logic method includes the following steps:

[0013] S1, Initialize the alarm set event collection

[0014] S2, Users create multiple rules to form a rule set. After initialization is complete, the system enters a waiting state, waiting to be triggered to wake up;

[0015] Each rule's rule information includes a sequence number (id), a governing predicate (F), an alarm predicate (G), alarm setting information (A), and a hold time (holdtime). The governing predicate (F) is used to detect whether the current time (R) is active and whether the abnormal event is within the jurisdiction of rule (R). The alarm predicate (G) is used to detect whether the current event triggers an alarm. The rules R are arranged in a queue data structure. When a new rule is added, its ID is incremented by 1 and then added to the queue from the head. The queue is sorted in descending order of the rule ID. During iteration... Newer rules are accessed first, and those with higher priority are executed first.

[0016] S3, if abnormal event E i,x Trigger, where i represents the event type and x represents the defense zone, then first trigger the abnormal event E. i,x The event information is updated to the event set ε, and then the rule set is traversed sequentially. If R is currently active and the abnormal event E i,x If an alarm is required within the scope of rule R, then alarm A is generated and the alarm information is updated to the alarm set. In the middle. As long as E i,x Within the scope of rule R, the process terminates regardless of whether an alarm is triggered.

[0017] S4, if the timer is triggered, iterate through the rule set sequentially. Iterate through the types of R alarm settings. A subset of ε is traversed according to the type of events it governs, and timeout information is checked and cleaned up.

[0018] Preferably, all different types of alarms in the system are numbered with integers, totaling M types. Alarm Set The alarms are divided into M subsets based on their type. Save different types of alarms separately. This represents a set of alarms of type i, whose elements are recorded alarm messages. Each alarm message includes zone x, start time, and update time.

[0019] All different abnormal event types in the system are numbered by integers, totaling N types. The event set ε is divided into N subsets according to event type, ε = ε1∪ε2∪…∪ε N Store different types of events separately. ε i Let i ∈ {1, 2, ..., N} represent a set of events of type i, whose elements are recorded event information. The event information for each event includes the zone x, the start timestamp starttime, and the update timestamp updatetime.

[0020] In step S3, the abnormal event E i,x The specific steps for updating the event set ε are as follows:

[0021] Determine the set ε i If record E exists in zone x, update the timestamp of E to the current time; otherwise, record the abnormal event E. i,x Add to event collection ε i middle.

[0022] Preferably, in step S3, the rule set is traversed. If R is currently active and the abnormal event E i,x If an alarm is required within the scope of rule R, then an alarm is generated and the alarm information is updated to the alarm set. The specific steps are as follows:

[0023] Iterate through the rule set starting from the head of the queue. First, we check the jurisdiction predicate F(i,x,t) of R. The input terms of the jurisdiction predicate F(i,x,t) represent the event type as i, located in zone x, and the current time as t. If F(i,x,t) is true, it means that R is active at the current time and event E is active. i,x Within the scope of rule R, continue to examine its alarm predicates. Otherwise: proceed to the next rule;

[0024] If F(i,x,t) is true: Alert predicate If the condition is true and the alarm setting information A of R is not empty, then alarm A is generated and the alarm information is updated to the alarm set. If the condition is met, then the process ends; otherwise, the process ends.

[0025] Preferably, the jurisdiction predicate F(i,x,t) consists of four elements: the first element {n1,n2,...} represents the set of event types; the second element {x1,...} represents the set of defense zones; the third element {day,...} represents the set of dates; and the fourth element {timeslot,...} represents the set of time slots within a 24-hour day. F(i,x,t) is true when all input parameters belong to the corresponding items in F. If the input i = 0, it means that event types do not need to be detected, and only the last three items are detected.

[0026] Preferably, the alarm predicate It is obtained by combining multiple triggers, and the result is calculated from left to right by connecting the multiple triggers through operators.

[0027] Preferably, each trigger is composed of multiple basic predicates, which include the following: (1) there is an event or alarm of type {n1,n2,..}; (2) there is no event or alarm of type {n1,n2,..}; (3) the zone is equal to x; (4) the update time is less than t seconds from the current time; (5) the start time is greater than t seconds from the current time; (6) the start time of event n1 is earlier than the start time of event n2; (7) the start time of event n2 is less than t seconds from the update time of event n1.

[0028] Preferably, the operator includes one or more of AND, OR, parentheses, and NOT, with NOT having higher precedence than AND and OR.

[0029] Preferably, the alarm setting information A includes alarm type, alarm level, and alarm base type, whereby the alarm base type is used to convert and merge alarms into a more general type.

[0030] In step S4, the rule set is traversed sequentially. Iterate through the types of R alarm settings. The specific steps for detecting and cleaning up timeout information are as follows: (The text then goes on to describe the process of traversing subsets of ε based on their managed event types.)

[0031] First, iterate through the alarm set. Mark A as 0; Traverse the event set E∈ε: mark E as 0. Elements marked as 0 indicate that they have not been visited or detected by any rule R.

[0032] Then iterate through the rule set in sequence. The execution of each rule is as follows:

[0033] Preferably, according to rule R, output alarm type i≠0, and iterate through all... If A is marked as 1, it indicates that it has already been detected by a higher-priority R and will not be processed further. If A is marked as 0, then F(0,x,t) is used for detection, where x is the zone of A, t is the current time, and the first item of F is 0, indicating that no detection type is needed. If F(0,x,t) is true: if the time difference between the last update time of A and the current time exceeds the retention time set by R, then A is removed; otherwise, A is marked as 1. If the output alarm information of R is empty, it is skipped, and the next rule is executed.

[0034] Preferably, according to the event type i governed by rule R, all E∈ε are traversed. i If E is marked as 1, it indicates that it has already been detected by a higher-priority R and will not be processed further. If E is marked as 0, then F(0,x,t) is used for detection, where x is the zone of E, t is the current time, and the first item of F is 0 to indicate that no detection type is needed. If F(0,x,t) is true: if the time difference between E's last update time and the current time exceeds the retention time set by R, then E is removed; otherwise, E is marked as 1. The event types governed by R are set by the first item {n1,n2,...} of the predicate F. If multiple event types are governed, then for each type ε... i The above processing is performed on all i∈{n1,n2,..}.

[0035] The beneficial effects of this invention are:

[0036] 1. This invention uses abnormal events as input to the system and outputs alarms by executing pre-defined rules, achieving highly flexible and precise alarm customization. Rules can be added, removed, or changed without restriction, enabling the security alarm system to fully meet the user's customized needs. It effectively solves the problem that existing security alarm systems lack a systematic alarm logic processing system and are difficult to customize alarms flexibly and precisely.

[0037] 2. This invention features flexible alarm triggering conditions, allowing users to finely customize the logical and timing conditions for triggering alarms. By setting a multi-rule mechanism, it can achieve separate alarm rules for different defense zones and different times, as well as local rules covering the overall rules. Furthermore, rules can contradict each other, and there will be a unique and definite result during execution. Users can arbitrarily add, remove, or change rules without considering rule conflicts. The algorithm logic is clear, lightweight, and concise, making it suitable for embedded systems and edge computing.

[0038] 3. The security alarm system of the present invention has a user-friendly interface, and users can implement the above functions without using a programming language. It can easily and unrestrictedly customize the logical conditions and timing conditions for triggering alarms, and can formulate complex alarm rules to achieve highly flexible alarm customization. Attached Figure Description

[0039] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is the system structure and flowchart of the security alarm system of the present invention.

[0041] Figure 2 This is the rule set of the present invention. Alarm Collection A schematic diagram of the data structure of the event set ε.

[0042] Figure 3 This is a schematic diagram of the content structure of rule R of this invention.

[0043] Figure 4 This is a user interface diagram for setting up multi-rule alarm logic.

[0044] Figure 5 This is a schematic diagram of the user interface for displaying and setting the governing predicate F.

[0045] Figure 6 This is a schematic diagram of the user interface for displaying and setting the alarm condition predicate G.

[0046] Figure 7 This is a schematic diagram of the user interface for displaying and setting alarm information A and its hold time. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the invention is described below with reference to specific embodiments shown in the accompanying drawings. However, it should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0048] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0049] To better understand the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings.

[0050] This invention provides a user-friendly multi-rule alarm logic method, which has the following advantages:

[0051] 1. Flexible alarm triggering conditions: Users can finely customize the logical and timing conditions for triggering alarms.

[0052] 2. A multi-rule mechanism enables different alarm rules to be set for different defense zones and at different times, and also allows local rules to cover overall rules;

[0053] 3. Rules can contradict each other, and there will be a unique and definite result when they are executed. Users can add, remove, or change rules at will without having to consider rule conflicts;

[0054] 4. A user-friendly interface allows users to implement the above functions without using a programming language.

[0055] The user-friendly multi-rule alarm logic method presented in this invention achieves highly flexible and precise alarm customization, allowing for unrestricted addition, deletion, and modification of rules. This enables the security alarm system to fully meet the user's customization needs and effectively solves the problems of existing security alarm systems lacking a systematic alarm logic processing system and being unable to flexibly and precisely customize alarms.

[0056] Figure 1 The diagram shows the system structure and flowchart of a security alarm system. This method is shown as 003 in the structure and flowchart of the security alarm system. It takes abnormal events as input to this method and outputs alarms by executing the pre-defined rules.

[0057] Other modules related to this method include: the security alarm system connects to multiple sensors, such as temperature, current, and cameras, i.e., 001; the internal signal processing and recognition algorithm module 002 reads the data detected by the sensors and executes the corresponding recognition algorithm to detect abnormal events; the multi-rule alarm logic algorithm module 003 obtains various status information and recognition algorithm results, processes the received abnormal event information, and outputs alarm information; and the alarm information is sent to the database 004 for permanent storage.

[0058] Figure 2 The diagram shown is a data structure diagram of the present invention, including a set of 005 rules. 006 Alarm Collection 007 event set ε.

[0059] The rule set is created by the user; 005 is the set of all rules, denoted as... gather The element in the code is a "rule" denoted by R, as shown in 008. The information of each rule includes the sequence number id, the governing predicate F, the alarm predicate G, the alarm setting information A, and the holdtime.

[0060] gather Member information is stored using a queue data structure, and during traversal... Access is performed sequentially from the head to the tail of the queue. As shown in 005, the head element of the queue is the rule with id=11. Rule ids are automatically assigned by the system and incremented by 1 when a new rule is created. Newly added rules are enqueued from the head. When a rule is modified, its id cannot be changed. When a rule is deleted, the order of rules before and after the deleted rule remains unchanged. Therefore, the queue is sorted in descending order of rule id, with newer rules having higher priority and being executed first. Figure 4 The image shows the set of rules for setting 005. User interface.

[0061] Figure 006 shows the alarm set consisting of all active alarms, denoted as . Different types of alarms are numbered with integers, for example, Type 1: Mechanical Construction; Type 2: Personnel Intrusion; Type 3: Cable Leakage, etc., totaling M types. (Set) The alarms are divided into M subsets based on their type. Save different types of alarms separately. This represents a set of alarms of type i, whose elements are recorded alarm information. As shown in 009, each alarm message includes zone x, start time, and update time, and UTC (Universal Time Coordinated) time can be used as the timestamp.

[0062] The abnormal events referred to are events that have occurred but have not yet generated alarms. This invention does not involve algorithms for how abnormal events are generated. Figure 007 shows the event set formed by all abnormal events, denoted as ε. Different types of abnormal events in the system are numbered with integers, for example, type 1: temperature too high; type 2: camera detects a person; type 3: excessive vibration, etc., totaling N types. The set ε is divided into N subsets according to event type, ε = ε1 ∪ ε2 ∪ ... ∪ ε N Store different types of events separately. ε i Let i ∈ {1, 2, ..., N} represent a set of events of type i, whose elements are recorded event information. As shown in 010, the event information of each event includes the defense zone x, the start timestamp (start time), and the update timestamp (update time).

[0063] Figure 3 The diagram shown is a schematic diagram of the content structure of rule R of the present invention, which includes 011 range predicate F, 012 alarm predicate G, 013 output alarm information A and 014 hold time.

[0064] Figure 011 shows the structural composition of the governing predicate F. Figure 5 The image shows the user interface for setting the predicate F. The predicate F(i,x,t) is used to detect whether the current time R is active and whether event E... i,x Whether an event falls within the scope of rule R is determined by the parameters representing event type i, location x, and current time t. The predicate F(i,x,t) consists of four elements, each a set: the first element {n1,n2,...} represents the event type set; the second element {x1,...} represents the zone set; the third element {day,...} represents the date set; and the fourth element {timeslot,...} represents the time slot set within each 24-hour day. F(i,x,t) is true when all input parameters belong to the corresponding item in F. If i = 0, it indicates that the event type is not checked.

[0065]

[0066]

[0067] Figure 012 shows the composition of the alarm predicate G. Figure 6 The image shows the user interface for setting predicate G. The alarm predicate... Used to detect whether the current status is alarm-free; the parameter indicates the alarm set to be detected at the x-position of the zone. And the event set ε. G is obtained by combining multiple triggers G1, G2..., which are connected by the connectives AND, OR, and bracket operators, and evaluated from left to right. Triggers can also set their own NOT operator (NOT has higher precedence than AND and OR). Triggers and the logical relationships between multiple triggers are... Figure 6 Configure the settings as shown in the interface.

[0068] Alarm predicate One possible expression is as follows, where the number of triggers and operators can be set arbitrarily:

[0069]

[0070] Each trigger is composed of multiple basic predicates, as shown in 015 and 016. g1 and g2 represent basic predicates or basic conditions. Basic conditions include three categories, which are obtained through... Figure 6 Configure the interface:

[0071] a) Detection event set ε

[0072] b) Detection and alarm collection

[0073] c) Event Sequence

[0074] Specifically, this mainly includes:

[0075] 1) There are events or alarms of type {n1, n2, ...}

[0076] 2) No events or alarms of type {n1, n2, ...} exist.

[0077] 3) The defense zone equals x

[0078] 4) The update time is less than t seconds from the current time.

[0079] 5) The start time is greater than t seconds from the current time.

[0080] 6) The start time of event n1 is earlier than the start time of event n2.

[0081] 7) The start time of event n2 is less than t seconds from the update time of event n1.

[0082] The trigger Gi is true when all basic conditions are true, that is:

[0083]

[0084] Figure 013 shows the alarm setting information A in the rule, including alarm type, alarm level, and alarm base type. It indicates that if the alarm predicate G of this rule is true, then this alarm information A will be output. The alarm base type is used to convert and merge alarms into more general types. For example, alarms "personnel intrusion" and "vehicle intrusion" can be set to merge into the base type "perimeter intrusion". If the base type is empty, no type conversion and merging will be performed.

[0085] If alarm setting information A is empty, it means no alarm is triggered; this rule effectively masks alarms. Alarms of the same type within the same zone will be automatically merged and updated, and the output alarm level will be the highest among these merged alarms. If an alarm base type is set, for example, under the settings above, if "personnel intrusion" occurs and "perimeter intrusion" exists in the same zone, then "personnel intrusion" will be automatically converted and merged into "perimeter intrusion".

[0086] 014 shows the holdtime in the rule, including tE and tA, which represent the time during which event information and alarm information are held. If the last update time of the information is more than this value from the current time, it will be removed from the alarm set. Remove the information from the event set ε. Figure 7 The image shows the user interface for setting alarm settings information A (013) and hold time (014).

[0087] The user interface for setting rules is described in detail below with reference to the attached diagram.

[0088] Figure 4The image shows the set of rules for setting 005. The user interface allows users to easily customize alarm rules. The user settings interface is mainly divided into left and right sides. The left side displays the rule list, and the right side displays the specific details of each rule. Item 017 shows a single rule created by the user. From left to right, it includes a serial number, a summary, and a delete button. The serial number is the rule's ID, sorted from smallest to largest in the list. The summary displays the rule's scope, predicate type, and protection zone for easy user identification. The delete button is used to delete the rule. Item 018 shows the rule list, which can display multiple rules. Item 019 shows a scroll bar; if there are too many rules to display entirely in the list, it can be used to view the remaining rules. Item 020 shows a button for adding rules. Newly added rules are located at the bottom of item 018. If a rule is deleted, the display order of the rules before and after the deleted item remains unchanged. Therefore, the rules in the interface list have increasing priority from top to bottom, with the last rule in the list having the highest priority. Note that in the 018 interface, the rule list is numbered sequentially from top to bottom to conform to user habits. However, in the internal queue of the algorithm, the rules are still sorted in descending order by their IDs, as described above.

[0089] After selecting a rule in the list, its details are displayed and set on the right. 021 shows the rule's scope tab, used to display and set the governing predicate F. 022 shows the alarm triggering condition tab, used to display and set the alarm condition predicate G. 023 shows the alarm information tab, used to set (output) the alarm content A and the holdtime. 024 shows the detailed settings for each tab; the above three tabs have their own settings interfaces.

[0090] Figure 5 The interface shown displays and sets the jurisdiction predicate F, allowing you to set the time, event type, and defense zone for the jurisdiction. 025 is a drop-down menu for setting the effective date, such as every day, holidays, or weekdays. 026 sets the effective time period, using a 24-hour clock, for example, a left-closed, right-open interval [7:00, 18:00). 027 is a delete button to delete an existing object. 028 is an add button to add an object. 029 shows a drop-down menu for setting events, allowing you to set event types, such as detected personnel, high temperature, or high current. These event types are saved with their integer numbers i∈{1,2,..N}. You can reset existing events by clicking the arrow on the right side of the drop-down menu. 030 shows the defense zone settings, allowing you to set a range of defense zones, such as the left-closed, right-open interval [1,5) in the diagram, or a single defense zone. Multiple objects can be added for time periods, events, and defense zones via 028, and existing objects can be deleted via 027. The 019 scroll bar is used to view the remaining settings when there are too many settings to display completely.

[0091] Figure 6 The interface shown is for displaying and setting alarm condition predicate G, used to display and set alarm conditions. The functions of elements such as add, delete, and scrollbar are the same as described above and will not be repeated. 031 is used to add triggers or combinations, where a combination is a group of triggers, equivalent to the parentheses operator, and the result in the combination is evaluated first. The result of a combination is equivalent to a single trigger. 032 shows the trigger list, displaying multiple set triggers and trigger combinations. Triggers are connected by AND and OR connectors and evaluated from top to bottom and left to right. Triggers themselves can be set with a NOT operator, which takes precedence. 033 shows the triggers; the left side displays a summary, including the NOT operator and its number, while the right side displays the connectors between the trigger and subsequent triggers. Clicking the left summary section of 033 displays the basic condition list (039), and clicking the right connector section displays the logic settings (036).

[0092] 036 is used to set the logic for triggers and combinations. The radio button 037 on the left sets the NOT operator prefix for the trigger, the middle button represents the trigger itself, and the drop-down menu 038 on the right sets the connect statement between this trigger and the next trigger. If it is the last trigger, the connect statement on its right is ignored. Clicking the collapse arrow in the upper left corner of 036 will hide it.

[0093] 034 is a collapsed combination, displaying a summary on the left and subsequent connectives on the right. Similar to the triggers described above, clicking the summary section on the left of 034 displays the expanded combination list of 035, and clicking the connectives section on the right displays the logic settings of 036. 035 is an expanded combination, also a list of triggers; the results of the combined trigger list are calculated first. Clicking the collapse arrow in its upper left corner collapses 035 to display 034. Elements in lists 032, 035, and 039 can be freely deleted and added using the delete and add buttons. Deleting an element maintains the relative positions of the elements before and after it; adding an element places it at the end of the list.

[0094] 039 is a list of basic conditions, displaying multiple set basic conditions. 040 is a single basic condition. Clicking 040 will display 041, showing and setting the details of the basic condition. 042 The following menu is used to set the basic conditions for three templates: detection events, detection alarms, and event sequences. Each has its own settings interface.

[0095] Interface 043 is the settings interface for event detection. The dropdown menu 044 sets the detection conditions to either "event exists" or "event does not exist." Interface 038 sets the logical relationships between multiple events in the event list as AND or OR. For example, it can be set as "Event exists: High temperature OR High current," or "Event does not exist: High vibration AND no personnel detected." The dropdown menu 029 sets the event type; multiple event types can be added using the add button. Interfaces 045 and 046 are used to set the event detection time, i.e., only events within this time range are detected. Dropdown menu 045 sets the time point T, i.e., the start time or most recent update time of the event; dropdown 046 sets the number of seconds that must not exceed from time point T to the current time. Interface 047 sets the event detection range, i.e., only events within a certain range near zone x are detected, where x is the zone where the event triggering the algorithm occurred.

[0096] 048 is the settings interface for alarm detection. 049 is a drop-down menu for setting alarm types. The other parts of the interface in 048 have the same functions as the corresponding parts in 043.

[0097] Interface 050 is the settings interface for event timing. It's used to define the relationship between two time points T1 and T2, with T2 > T1. Interfaces 029 and 045 are used to set these two time points T1 and T2 respectively. 029 sets the event type, and 045 sets the time point to either the start time or the update time. Interfaces 051 and 046 set the timing relationship, specifying that T2 - T1 is greater than or equal to, or less than or equal to, a certain number of seconds. Interface 047 is used to set the range for event detection.

[0098] Figure 7 The image shows the interface for displaying and setting alarm information A and its hold time. Alarm content, base alarm type, and hold time are set respectively. 049 and 053 set the type and level of the output alarm. The 049 dropdown menu sets the alarm type; "None" indicates no alarm, a way to mask alarms. The 053 dropdown menu sets the alarm level, with level one being the most severe. 054 sets the base alarm type; "None" indicates no base type conversion. If a base type is set, and a base type alarm exists in the same zone, this alarm type will be converted to the base type alarm. 046 sets the hold time for tE and tA.

[0099] These settings interfaces enable all the functions mentioned above. With a multi-rule logic mechanism, users can easily and conveniently implement finely customized logic and timing conditions for triggering alarms without using programming languages.

[0100] The following combines the above set of rules. Alarm Collection The data structure of the event set ε is described in detail, along with the execution process of the present invention.

[0101] After the system starts and completes initialization, rule execution is primarily triggered in two ways: event-triggered and timer-triggered. Event-triggered execution occurs when the identification algorithm detects an abnormal event and generates event information E. i,x Execution is triggered periodically. In this method, the timer's trigger period is 1 second. The algorithm of this invention is shown in the table below, and the logical details of all steps described in this invention are based on this table:

[0102]

[0103]

[0104] Specifically, the user-friendly multi-rule alarm logic method provided by this invention includes the following steps:

[0105] S1, Initialization, set the alarm set The event set ε is set to empty.

[0106] S2, Users create multiple rules to form a rule set. After initialization is complete, the system enters a waiting state, waiting to be triggered to wake up. If it is woken up by a timer, the timer processing procedure is executed; if it is woken up by an event, the event processing procedure is executed. This process is repeated until the system exits.

[0107] S3, if an abnormal event is triggered, the specific steps to be executed are as follows:

[0108] First, handle the abnormal event E. i,x Update to event set ε: Check set ε i If record E exists in zone x, update the timestamp of E to the current time; otherwise, record the abnormal event E. i,x Add to event collection ε i middle.

[0109] Then, start traversing the rule set from the head of the queue. First, we check the jurisdiction predicate F(i,x,t) of R. The input terms of the jurisdiction predicate F(i,x,t) represent the event type as i, located in zone x, and the current time as t. If F(i,x,t) is true, it means that R is active at the current time and event E is active. i,x Within the scope of rule R, continue to examine its alarm predicates. Otherwise: proceed to the next rule;

[0110] If F(i,x,t) is true: if the alert predicate is true... If the condition is true and the alarm setting information A of R is not empty, then alarm A is generated and the alarm information is updated to the alarm set. If the condition is met, then the process ends; otherwise, the process ends.

[0111] The above event triggers a processing procedure. If F is true, the process ends regardless of whether an alarm is generated. That is, at most one rule R will be executed during the processing of an exception event. The rule queue is sorted in descending order by ID. New rules are visited first during the traversal, so new rules will overwrite old rules within the jurisdiction.

[0112] S4, if the timer is triggered, iterate through the rule set sequentially. Iterate through the types of R alarm settings. A subset of ε is traversed according to the type of events it governs, and timeout information is checked and cleaned up.

[0113] The formulas related to the timer triggering process are as follows:

[0114] This indicates the type of alarm A output by R.

[0115] EventType(R) = {n1,n2,..}, where {n1,n2,..}∈F represents the event type governed by R.

[0116] HoldTimeA(R) = tA represents the alarm hold time related to R, where the alarm type is as described above.

[0117] HoldTimeE(R) = tE represents the event hold time related to R, where the event type is {n1, n2, ...} as described above.

[0118] Label(A) means to retrieve the label of A, and the same applies to event E.

[0119] Idle(A) = t - update time, update time ∈ A, where t is the current time and represents the time difference between the last update time of A and the current time, i.e., the idle time of A. The same applies to event E.

[0120] Based on the above formula, the specific steps of S4 are as follows:

[0121] First, iterate through the alarm set. Label(A) ← 0; Traverse the event set E ∈ ε: Label(E) ← 0. Elements marked as 0 indicate that they have not been accessed or detected by any rule R.

[0122] Then iterate through the rule set in sequence. The execution of each rule is as follows:

[0123] Calculate i = AlarmType(R) to obtain the output alarm type. If i ≠ 0: iterate through all... If Label(A) = 1, it indicates that it has already been detected by a higher priority R and will not be processed again. If Label(A) = 0, then continue to use F(0,x,t) for detection, where x is the zone of A, t is the current time, and the first item of F is 0 to indicate that no detection type is needed. If F(0,x,t) is true: if Idle(A) > HoldTimeA(R), then A is removed; otherwise, Label(A) is incremented by 1. If i = 0, then skip this rule R and continue to the next rule.

[0124] Calculate {n1,n2,..} = EventType(R), and iterate through i ∈ {n1,n2,..}: iterate through all E ∈ ε. i If Label(E) = 1, it indicates that it has already been detected by the higher priority R and will not be processed again. If Label(E) = 0, then continue to use F(0,x,t) for detection, where x is the zone of E, t is the current time, and the first item of F is 0 to indicate that no detection type is needed. If F(0,x,t) is true: if Idle(E) > HoldTimeE(R), then remove E; otherwise: mark Label(E) ← 1.

[0125] During the timer triggering process described above, the first rule R accessed will mark the related A and E as 1. The marked elements will not be processed by subsequent rules. Within the jurisdiction, the new rule will take precedence and override the old rule.

[0126] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A user-friendly multi-rule alarm logic method, characterized in that, Specifically, the following steps are included: S1, Initialize the alarm set event collection S2, where users create multiple rules to form a rule set: After initialization is complete, the system enters a waiting state, waiting to be triggered to wake up; Each rule R includes a sequence number (id), a governing predicate (F), an alarm predicate (G), alarm settings (A), and a hold time (holdtime). The governing predicate (F) is used to detect whether the current time R is active and whether the abnormal event is within the jurisdiction of the rule R. The alarm predicate (G) is used to detect whether the current state triggers an alarm. The rules R are arranged in a queue data structure. When a new rule is added, its ID is incremented by 1 and then it is enqueued from the head of the queue. During traversal... Newer rules are accessed first, and those with higher priority are executed first. S3, if abnormal event E i,x Trigger, where i represents the event type and x represents the defense zone, then first trigger the abnormal event E. i,x The event information is updated to the event set ε, and then the rule set is traversed sequentially. If R is currently active and the abnormal event E i,x If an alarm is required within the scope of rule R, then alarm A is generated and the alarm information is updated to the alarm set. middle; As long as E i,x Within the scope of rule R, the process terminates regardless of whether an alarm is triggered. S4, if the timer is triggered, iterate through the rule set sequentially. Iterate through the types of R alarm settings. A subset of ε is traversed according to the type of events it governs, and timeout information is checked and cleaned up.

2. The user-friendly multi-rule alarm logic method according to claim 1, characterized in that, All different types of alarms in the alarm system are numbered with integers, totaling M types. Alarm Collection The alarms are divided into M subsets based on their type. Save different types of alarms separately. This represents a set of alarms of type i, whose elements are recorded alarm information. Each alarm information includes zone x, start time, and update time.

3. The user-friendly multi-rule alarm logic method according to claim 1, characterized in that, Different types of abnormal events in the system are numbered with integers, totaling N types. The event set ε is divided into N subsets according to event type, where ε = ε1∪ε2∪…∪ε N Store different types of events separately, ε i ,i∈{1,2,..N} represents a set of events of type i, whose elements are recorded event information. The event information of each event includes the defense zone x, the start time, and the update time. In step S3, the abnormal event E i,x Where i represents the event type and x represents the defense zone, the specific steps for updating the event set ε are as follows: Determine the set ε i If record E exists in zone x, then update the timestamp of E to the current time. Otherwise, the abnormal event E will be... i,x Add to event collection ε i middle.

4. The user-friendly multi-rule alarm logic method according to claim 1, characterized in that, Step S3 involves traversing the rule set. If R is currently active and the abnormal event E i,x If an alarm is required within the scope of rule R, then alarm A is generated and the alarm information is updated to the alarm set. The specific steps are as follows: Iterate through the rule set starting from the head of the queue. First, we check the jurisdiction predicate F(i,x,t) of R. The input terms of the jurisdiction predicate F(i,x,t) represent the event type as i, located in zone x, and the current time as t. If F(i,x,t) is true, it means that R is active at the current time and event E is active. i,x Within the scope of rule R, continue to examine its alarm predicates. Otherwise: proceed to the next rule; If F(i,x,t) is true: if the alert predicate is true... If the condition is true and the alarm setting information A of R is not empty, then alarm A is generated and the alarm information is updated to the alarm set. Then the process ends; Otherwise: End the process.

5. The user-friendly multi-rule alarm logic method according to claim 4, characterized in that, The jurisdiction predicate F(i,x,t) consists of four elements: the first element {n1,n2,...} represents the set of event types; the second element {x1,...} represents the set of defense zones; the third element {day,...} represents the set of dates; and the fourth element {timeslot,...} represents the set of time slots within a 24-hour day. F(i,x,t) is true when all input parameters belong to the corresponding terms of F. If the input i=0, it means that the event type does not need to be detected, and only the last three items are detected.

6. The user-friendly multi-rule alarm logic method according to claim 4, characterized in that, The alarm predicate The result is obtained by combining multiple triggers, and the multiple triggers are connected by operators and calculated from left to right.

7. The user-friendly multi-rule alarm logic method according to claim 6, characterized in that, Each trigger is composed of multiple basic predicates, which include: the existence of an event or alarm of type {n1,n2,...}, the absence of an event or alarm of type {n1,n2,...}, the zone equals, the update time is less than t seconds from the current time, the start time is greater than t seconds from the current time, the start time of event n1 is earlier than the start time of event n2, and the start time of event n2 is less than t seconds from the update time of event n1.

8. The user-friendly multi-rule alarm logic method according to claim 6, characterized in that, The operators include one or more of AND, OR, parentheses, and NOT, with NOT having higher precedence than AND and OR.

9. The user-friendly multi-rule alarm logic method according to claim 1, characterized in that, The alarm setting information A includes alarm type, alarm level, and alarm base type. The alarm base type is used to convert and merge alarms into a more general type.

10. The user-friendly multi-rule alarm logic method according to claim 1, characterized in that, In step S4, the rule set is traversed sequentially. Iterate through the types of R alarm settings. The specific steps for detecting and cleaning up timeout information are as follows: (The text then goes on to describe the process of traversing subsets of ε based on their managed event types.) First, iterate through the alarm set. Mark A as 0; Traverse the event set E∈ε: Mark E as 0, the element marked as 0 indicates that it has not been visited or detected by any rule R; Then iterate through the rule set in sequence. The execution of each rule is as follows: If the alarm type output by R is not empty, i.e., the output alarm type i ≠ 0: iterate through all alarms. If A is marked as 1, it indicates that it has already been detected by a high-priority R and will not be processed again; if A is marked as 0, then F(0,x,t) is used for detection, where x is the zone of A, t is the current time, and the first item of F is 0, indicating that no detection type is needed. If F(0,x,t) is true: if the time difference between the last update time of A and the current time exceeds the retention time set by R, then A will be removed; otherwise, A will be marked as 1. If the output alarm information of R is empty, then skip to the next rule. According to rule R governing event type i, traverse all E∈ε i If E is marked as 1, it indicates that it has already been detected by a higher priority R and will not be processed further; if E is marked as 0, then F(0,x,t) is used for detection, where x is the zone of E, t is the current time, and the first item of F is 0, indicating that no detection type is needed. If F(0,x,t) is true: if the time difference between the last update time of E and the current time exceeds the retention time set by R, then E is removed; otherwise, E is marked as 1. The event types governed by R are set by the first item {n1,n2,...} of the predicate F; if multiple types of events are governed, then for each type ε i The above processing is performed on all i∈{n1,n2,..}.

Images