WO2016141007A1

WO2016141007A1 - Alarm management using hiding rules

Info

Publication number: WO2016141007A1
Application number: PCT/US2016/020345
Authority: WO
Inventors: Aldo Dagnino; Benjamin KLOEPPER; Marcel Dix; Martin Hollender; Mithun P. ACHARYA
Original assignee: Abb Technology Ag
Priority date: 2015-03-02
Filing date: 2016-03-02
Publication date: 2016-09-09

Abstract

One or more techniques and/or systems are provided for suggesting alarm hiding rules and/or alarm groupings. Operator alarms (e.g., a low pressure alarm, a high temperature alarm, etc.) may be stored into alarm baskets based upon alarm occurrence information. The alarm baskets may be defined based upon alarm occurrence overlap, operations (e.g., startup, shutdown, standard procedures, etc.), time slices, timeframes after operator actions (e.g., alarms occurring within 3 minutes after an operator turns off a valve), etc. Alarm hiding rule suggestions (e.g., a suggestion to hide an operator alarm (B) when an operator alarm (A) occurs because the operator alarm (B) usually occurs when the operator alarm (A) occurs) and/or alarm grouping suggestions may be created and provided based upon operator alarms sorted into the alarm buckets. Alarm hiding and grouping rules may be automatically suggested for implementation so that an operator is not inundate with unnecessary operator alarms.

Description

ALARM MANAGEMENT USING HIDING RULES

RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application

62/126,779, titled "ALARM MANAGEMENT" and filed on March 2, 2015, which is incorporated herein by reference.

BACKGROUND

[0002] Many industries, such as electric utilities, mining, water, industrial factories, etc., may employ a multitude of industrial devices (e.g., valves, temperature sensors, actuators, circuit breakers, transformers, processing equipment, etc.). Alarms may be used to alert an operator as to certain operating conditions of the industrial devices. For example, a temperature alarm may be triggered when a temperature exceeds one or more thresholds (e.g., a low threshold, a low-low threshold, a high threshold, a high-high threshold, etc.). The temperature alarm may be displayed to the operator so that the operator may take appropriate action. Alarm management may be based upon high level business key performance indicators in order to improve safety, efficiency, and/or effectiveness of production systems.

Unfortunately, management of alarms may take substantial amounts of manual human effort and time because thousands of alarms may be available. Without effective management of alarms, an operator may be overloaded with unnecessary alarm information (e.g., the operator may already expect the same 10 alarms to trigger during startup, and thus triggering such alarms may be unhelpful).

SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] Among other things, one or more systems and/or techniques for suggesting alarm hiding rules are provided herein. Operator alarms, within historical operator alarm data, may be sorted into alarm buckets based upon alarm occurrence information (e.g., start and end times of an alarm). An alarm bucket may be defined based upon various criteria (e.g., alarms having overlapping occurrences; alarms occurring during a time slice; alarms occurring during a timespan after an operator action; alarms occurring during startup, shutdown, or a standard procedure; etc.). An alarm co-occurrence relationship, between a first operator alarm and a second operator alarm within an alarm bucket, may be identified (e.g., the first operator alarm may occur with the second operator alarm above a co-occurrence threshold). An alarm hiding rule suggestion may be created for the first alarm. The alarm hiding rule suggestion may indicate that the first operator alarm is not to be displayed to an operator when the second operator alarm is displayed to the operator.

[0005] In an example, the alarm hiding rule suggestion may be provided to the operator. Responsive to receiving an alarm hiding rule creation command in response to the alarm hiding rule suggestion, an alarm hiding rule, corresponding to the alarm hiding rule suggestion, may be implemented for an alarm management service. In this way, alarms that occur together and/or during certain operations (e.g., startup, shutdown, standard procedures, after an operator action, etc.) may be hidden and/or grouped so that the operator is not inundated with unnecessary alarms that may be overwhelming and/or unhelpful.

[0006] To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages, and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the annexed drawings.

DESCRIPTION OF THE DRAWINGS

[0007] Fig. 1 is a flow diagram illustrating an exemplary method of suggesting an alarm hiding rule.

[0008] Fig. 2 is a component block diagram illustrating an exemplary system for suggesting an alarm hiding rule based upon alarm co-occurrence relationships. [0009] Fig. 3 is a component block diagram illustrating an exemplary system for suggesting an alarm hiding rule based upon operator alarms occurring during one or more operations.

[0010] Fig. 4A is a component block diagram illustrating an exemplary system for suggesting an alarm hiding rule based upon timeframes after operator actions.

[0011] Fig. 4B is a component block diagram illustrating an exemplary system for suggesting an alarm hiding rule based upon timeframes after operator actions, where operator alarms are resorted.

[0012] Fig. 5 is a component block diagram illustrating an exemplary system for suggesting an alarm grouping rule based upon time slices.

[0013] Fig. 6 is a component block diagram illustrating an exemplary system for suggesting an alarm hiding rule.

[0014] Fig. 7 is an illustration of an exemplary computing device-readable medium wherein processor-executable instructions configured to embody one or more of the provisions set forth herein may be comprised.

[0015] Fig. 8 illustrates an exemplary computing environment wherein one or more of the provisions set forth herein may be implemented.

DETAILED DESCRIPTION

[0016] The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are generally used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are illustrated in block diagram form in order to facilitate describing the claimed subject matter.

[0017] An embodiment of suggesting an alarm hiding rule is illustrated by an exemplary method 100 of Fig. 1. An alarm management service may be configured to provide alarms to an operator when certain conditions are met, such as when a pressure measurement exceeds a threshold value. Occurrence of alarms may be stored as historical operator alarm data (e.g., a time of activation, a time of return to a normal state, an alarm source such as an industrial device that created a signal triggering the alarm, a condition that triggered the alarm, and/or other information about an alarm). Because the operator may be provided with unnecessary alarms that may overwhelm the operator (e.g., 15 alarms may routinely trigger during system startup, and thus the 15 alarms may not provide the operator with new and useful information; a low pressure alarm may routinely occur when the operator switches a pump off, and thus the operator may already expect a low pressure event; a carbon monoxide level alarm may routinely occur with a nitrogen dioxide level alarm, and thus the operator may already expect a co-occurrence of both events; etc.), it may be advantageous for an alarm suggestion component to evaluate the historic operator alarm data in order to provide alarm hiding rule suggestions to the operator. In this way, alarms may be hidden and/or grouped so that the operator is not inundated with unnecessary alarms. Alarm hiding rules and groupings may be automatically identified and suggested without extensive manual evaluation and/or time because alarm hiding rule suggestions may be automatically created and provided to the operator for selection.

[0018] At 102, operator alarms, within the historic alarm data, may be sorted into alarm buckets based upon alarm occurrence information (e.g., start and end times of operator alarms). In an example of defining alarm buckets, a first operator alarm and a second operator alarm may be stored into an alarm bucket based upon the first operator alarm having a first alarm occurrence timespan corresponding to a second alarm occurrence timespan of the second operator alarm (e.g., the first operator alarm and the second operator alarm have overlapping occurrences). In this way, operator alarms that have overlapping occurrences may be sorted into the same alarm bucket.

[0019] In another example of defining alarm buckets, an alarm bucket may be defined based upon a timeframe corresponding to a startup operation, a shutdown operation, a standard procedure operation (e.g., the operator may routinely turn a valve off every hour for 1 minute), and/or other operations for which the operator may already know what events will occur and thus alarms for such events may be unnecessary to show the operator (e.g., the operator may know that a pipe may have low pressure when the valve is turned off for the 1 minute; the operator may know what events will occur during startup and shutdown; etc.). For example, a startup operation alarm bucket, a shutdown operation alarm bucket, a standard procedure operation alarm bucket, and/or other alarm buckets may be defined. An alarm model, such as a decision tree, may be used to label an operator alarm within the alarm bucket as occurring during at least one of normal operation (e.g., an unexpected operator alarm occurring during normal operation when an event triggering the alarm would not be expected by the operator, and thus the operator alarm should not be suggested for hiding), the startup operation, the shutdown operation, the standard procedure, or other types of operations used to define alarm buckets.

[0020] In another example of defining alarm buckets, an alarm bucket may be defined based upon a timeframe occurring after an operator action. For example, operator alarms occurring within 1 minute of an operator closing a valve may be sorted into a first alarm bucket, operator alarms occurring within 2 minutes of an operator opening a switch may be stored into a second alarm bucket, operator alarms occurring within 1 minute of an operator turning off a machine may be stored into a third alarm bucket, etc. In an example, the timeframe may be adjusted and operator alarms may be resorted into redefined alarm buckets corresponds to adjusted timeframes (e.g., a 1 minute timeframe for the first alarm bucket may be adjusted to a 3 minute timeframe based upon a number of operator alarms initially sorted into the first alarm bucket being below a threshold number).

[0021] In another example of defining alarm buckets, alarm buckets may be defined based upon time slices (e.g., time slices of the same temporal length such as 3 minute time slices; time slices of varying temporal lengths; etc.). For example, a first alarm bucket may be defined based upon a first time slice, such as a first 3 minutes. A second alarm bucket may be defined based upon a second time slice, such as a next 3 minutes. In this way, alarm buckets may be defined based upon time slices, and operator alarms having alarm occurrence information corresponding to such time slices may be sorted into corresponding alarm buckets. For example, the first operator alarm, having first alarm occurrence information indicating that the first operator alarm occurred during the first 3 minutes, may be sorted in the first alarm bucket. It may be appreciated that any number of time slices may be analyzed by various criteria (e.g., a time-window after an operator action, time-windows capturing operations modes such as start-up, shutdown, standard operations, etc., and/or other time windows may be simultaneously analyzed, such as by a decision tree). [0022] At 104, an alarm co-occurrence relationship between the first operator alarm and the second operator alarm may be identified based upon the first operator alarm and the second operator alarm being sorted into the same alarm bucket. For example, an association rule may be generated by frequent item set mining of the operator alarms for identifying the alarm co-occurrence relationship. In an example, the alarm co-occurrence relationship may be determined based upon the first operator alarm occurring with the second operator alarm above a co-occurrence threshold. At 106, an alarm hiding rule suggestion may be created for the first operator alarm based upon the alarm co-occurrence relationship. The alarm hiding rule suggestion may indicate that the first operator alarm is not to be displayed to an operator when the second operator alarm is displayed to the operator. In an example where the first operator alarm, the second operator alarm, and a third operator alarm are sorted into the alarm bucket, the alarm hiding rule suggestion may indicating that at least one of the first operator alarm, the second operator alarm, or the third operator alarm is not to be displayed when at least one of the first operator alarm, the second operator alarm, or the third operator alarm occurs.

[0023] In an example, frequent item set mining may be performed upon the alarm buckets to identify a set of co-occurring operator alarms. An alarm grouping suggestion may be created based upon the set of co-occurring operator alarms. For example, the alarm grouping suggestion may suggest the creation of an alarm grouping comprising the set of co-occurring operator alarms so that the operator merely receives a single alarm for the alarm group as opposed to being overwhelmed with individual alarms for the set of co-occurring operator alarms.

[0024] In an example, a fourth operator alarm may be sorted into an alarm bucket that was defined based upon a timeframe occurring after an operator action. A second alarm hiding rule suggestion, indicating that the fourth operator alarm is not to be displayed to the operator when the operator action occurs, may be created.

[0025] In this way, various alarm hiding rule suggestions and/or alarm grouping suggestions may be created. An alarm hiding rule suggestion and/or an alarm grouping suggestion may be provided to the operator. Responsive to the operator providing an alarm hiding rule creation command, an alarm hiding rule,

corresponding to the alarm hiding rule suggestion, and/or an alarm grouping, corresponding to the alarm grouping suggestion, may be implemented for an alarm management service. For example, the alarm hiding rule and/or the alarm grouping, after operator approval, may be used in an alarm system/distributed control system, such that merely alarm groups and alarms that are not hidden or grouped may be displayed on a display device to a process operator.

[0026] Fig. 2 illustrates an example of a system 200, comprising an alarm suggestion component 204, for suggesting an alarm hiding rule. In an example, the alarm suggestion component 204 may be hosted on a single computer or across a cluster of computers. The alarm suggestion component 204 may be configured to sort operator alarms, within historical operator alarm data 202, into alarm buckets. For example, the historical operator alarm data 202 may comprise a first occurrence 208 of an operator alarm (A) having a first start time 206 and a first end time 210, a second occurrence 214 of an operator alarm (B) having a second start time 212 and a second end time 216, a third occurrence of an operator alarm (C) having a third start time 218 and a third end time 222, and/or occurrences of other operator alarms such as an operator alarm (D), an operator alarm (E), an operator alarm (F), an operator alarm (G), and operator alarm (H), etc.

[0027] The alarm suggestion component 204 may sort the operator alarm (A), the operator alarm (B), and the operator alarm (C) into a first bucket 224 because the first occurrence 208 of the operator alarm (A), the second occurrence 214 of the operator alarm (B), and the third occurrence 220 of the operator alarm (C) overlap. The alarm suggestion component 204 may sort the operator alarm (D) and the operator alarm (E) into a second bucket 226 because occurrence of the operator alarm (D) overlaps occurrence of the operator alarm (E). The alarm suggestion component 204 may sort the operator alarm (F), the operator alarm (G), and the operator alarm (H) into a third bucket 228 because occurrence of the operator alarm (F), the operator alarm (G), and the operator alarm (H) overlap.

[0028] The alarm suggestion component 204 may create alarm hiding rule suggestions 230 based upon alarm co-occurrence relationships between operator alarms within the buckets. For example, a first alarm hiding rule suggestion 232 may suggest that the operator alarm (C) should be hidden based upon occurrence of the operator alarm (A) and/or the operator alarm (B). A second alarm hiding rule suggestion 234 may suggest that the operator alarm (E) should be hidden based upon occurrence of the operator alarm (D). A third alarm hiding rule suggestion 236 may suggest that the operator alarm (H) should be hidden based upon occurrence of the operator alarm (F) and/or the operator alarm (G). The alarm hiding rule suggestions 230 may be provided to an operator so that the operator may select alarm hiding rule suggestions to implement as alarm hiding rules.

[0029] Fig. 3 illustrates an example of a system 300, comprising an alarm suggestion component 304, for suggesting an alarm hiding rule. The alarm suggestion component 304 may be configured to sort operator alarms, within historical operator alarm data 302, into alarm buckets. For example, the historical operator alarm data 302 may comprise an operator alarm (A), an operator alarm (B), an operator alarm (C), an operator alarm (D), an operator alarm (E), an operator alarm (F), an operator alarm (G), an operator alarm (H), an operator alarm (I), an operator alarm (J), an operator alarm (K), an operator alarm (L), an operator alarm (M), an operator alarm (N), and/or other operator alarms.

[0030] The alarm suggestion component 304 may define one or more buckets based upon various operations that may occur. For example, the alarm suggestion component 304 may define a first bucket 308 for operator alarms that occur during a startup operation, a second bucket 310 for operator alarms that occur during a shutdown operation, a third bucket 312 for operator alarms that occur during a standard procedure operation, and/or a fourth bucket 314 for operator alarms that occur during normal operation. The alarm suggestion component 304 may sort the operator alarm (A), the operator alarm (B), and the operator alarm (C) into the first bucket 308 because such alarms may occur during the startup operation. The alarm suggestion component 304 may sort the operator alarm (D) and the operator alarm (E) into the second bucket 310 based upon such alarms occurring during the shutdown operation. The alarm suggestion component 304 may sort the operator alarm (F), the operator alarm (G), and the operator alarm (H) into the third bucket 312 based upon such alarms occurring during the standard procedure operation (e.g., a procedure that an operator routinely performs on a daily basis). The alarm suggestion component 304 may sort the operator alarm (I), the operator alarm (J), the operator alarm (K), the operator alarm (L), the operator alarm (M), and the operator alarm (N) into the fourth bucket 314 based upon such alarms occurring during normal operation.

[0031] In an example, the alarm suggestion component 304 may evaluate operator alarms within the alarm baskets to create an alarm model 306, such as a decision tree, used to label operator alarms as occurring during the startup operation, the shutdown operation, the standard procedure operation, or normal operation. The alarm suggestion component 304 may create alarm hiding rule suggestions 316 based upon the labels. For example, the alarm suggestion component 304 may create a first alarm hiding rule suggestion 318 that may suggest that the operator alarm (A), the operator alarm (B), and the operator alarm (C) should be hidden during the startup operation. A second alarm hiding rule suggestion 320 may suggest that the operator alarm (D) and the operator alarm (E) should be hidden during the shutdown operation. A third alarm hiding rule suggestion 322 may suggest that the operator alarm (F), the operator alarm (G), and the operator alarm (H) should be hidden during the standard procedure operation. The alarm hiding rule suggestions 230 may be provided to an operator so that the operator may select alarm hiding rule suggestions to implement as alarm hiding rules.

[0032] Figs. 4A-4B illustrate examples of a system 400, comprising an alarm suggestion component 404, for suggesting an alarm hiding rule. The alarm suggestion component 404 may be configured to sort operator alarms, within historical operator alarm data 402, into alarm buckets. The historical operator alarm data 402 may comprise an operator alarm (A), an operator alarm (B), an operator alarm (C), an operator alarm (D), an operator alarm (E), an operator alarm (F), an operator alarm (G), and/or other operator alarms. The alarm suggestion component 404 may define a first bucket 406 based upon a first timeframe occurring after an operator action (A), a second bucket 408 based upon a second timeframe occurring after an operator action (B), a third bucket 410 based upon a third timeframe occurring after an operator action (C), a fourth bucket 414 based upon a fourth timeframe occurring after an operator action (D), and/or other buckets, as illustrated in Fig. 4A.

[0033] The alarm suggestion component 404 may sort the operator alarm (F) and the operator alarm (G) into the first bucket 406 based upon such operator alarms occurring within the first timeframe. The alarm suggestion component 404 may sort the operator alarm (B) into the second bucket 408 based upon operator alarm (B) occurring within the second timeframe. The alarm suggestion component 404 may sort the operator alarm (A) and the operator alarm (C) into the third bucket 410 based upon such operator alarms occurring within the third timeframe. The alarm suggestion component 404 may sort the operator alarm (D), the operator alarm (E), and the operator alarm (H) into the fourth bucket 414 based upon such operator alarms occurring within the fourth timeframe.

[0034] The alarm suggestion component 404 may evaluate the buckets to create alarm hiding rule suggestions 415. For example, a first alarm hiding rule suggestion 416 may suggest that the operator alarm (F) and the operator alarm (G) should be hidden based upon occurrence of the operator action (A). A second alarm hiding rule suggestion 418 may suggest that the operator alarm (B) should be hidden based upon occurrence of the operator action (B). A third alarm hiding rule suggestion 420 may suggest that the operator alarm (A) and the operator alarm (C) should be hidden based upon occurrence of the operator action (C). A fourth alarm hiding rule suggestion 422 may suggest that the operator alarm (D), the operator alarm (E), and the operator alarm (H) should be hidden based upon occurrence of the operator action (D).

[0035] Fig. 4B illustrates the alarm suggestion component 404 adjusting the first timeframe, the second timeframe, the third timeframe, and the fourth timeframe to create an adjusted first timeframe for the first bucket 406 (e.g., a redefined first bucket), an adjusted second timeframe for the second bucket 408 (e.g., a redefined second bucket), an adjusted third timeframe for the third bucket 410 (e.g., a redefined third bucket), and an adjusted fourth timeframe for the fourth bucket 414 (e.g., a redefined fourth bucket).

[0036] The alarm suggestion component 404 may resort the operator alarms into the redefined buckets based upon the adjusted timeframes, as illustrated in Fig. 4B. For example, the alarm suggestion component 404 may sort the operator alarm (F), the operator alarm (G), and an operator alarm (I) into the first bucket 406 (e.g., the redefined first bucket) based upon such operator alarms occurring within the adjusted first timeframe. The alarm suggestion component 404 may sort the operator alarm (B) and an operator alarm (M) into the second bucket 408 (e.g., the redefined second bucket) based upon such operator alarms occurring within the adjusted second timeframe. The alarm suggestion component 404 may sort the operator alarm (A), the operator alarm (C), and an operator alarm (N) into the third bucket 410 (e.g., the redefined third bucket) based upon such operator alarms occurring within the adjusted third timeframe. The alarm suggestion component 404 may sort the operator alarm (D), the operator alarm (E), and the operator alarm (H) into the fourth bucket 414 (e.g., the redefined fourth bucket) based upon such operator alarms occurring within the adjusted fourth timeframe.

[0037] The alarm suggestion component 404 may evaluate the redefined buckets to create new alarm hiding rule suggestions 450. For example, a new first alarm hiding rule suggestion 452 may suggest that the operator alarm (F), the operator alarm (G), and the operator alarm (I) should be hidden based upon occurrence of the operator action (A). A new second alarm hiding rule suggestion 454 may suggest that the operator alarm (B) and the operator alarm (M) should be hidden based upon occurrence of the operator action (B). A new third alarm hiding rule suggestion 456 may suggest that the operator alarm (A), the operator alarm (C), and the operator alarm (N) should be hidden based upon occurrence of the operator action (C).

[0038] Fig. 5 illustrates an example of a system 500, comprising an alarm suggestion component 504, for suggesting an alarm hiding rule such as an alarm grouping suggestion. The alarm suggestion component 504 may be configured to sort operator alarms, within historical operator alarm data 502, into alarm buckets. For example, the historical operator alarm data 202 may comprise an operator alarm (A), an operator alarm (B), an operator alarm (C), an operator alarm (D), an operator alarm (E), an operator alarm (F), an operator alarm (G), an operator alarm (L), an operator alarm (M), an operator alarm (N), an operator alarm (O), and/or other operator alarms.

[0039] The alarm suggestion component 504 may define one or more buckets based upon time slices. For example, the alarm suggestion component 504 may define a first bucket 506 based upon a first time slice, a second bucket 508 based upon a second time slice, a third bucket 510 based upon a third time slice, a fourth bucket 512 based upon a fourth time slice, etc. The alarm suggestion component 504 may sort the operator alarm (B) and the operator alarm (C) into the first bucket 506 because such operator alarms occurred during the first time slice. The alarm suggestion component 504 may sort the operator alarm (A) into the second bucket 508 because the operator alarm (A) occurred during the second time slice. The alarm suggestion component 504 may sort the operator alarm (D), the operator alarm (E), the operator alarm (F), and the operator alarm (G) into the third bucket 510 because such operator alarms occurred during the third time slice. The alarm suggestion component 504 may sort the operator alarm (L), the operator alarm (M), the operator alarm (N), and the operator alarm (O) into the fourth bucket 512 because such operator alarms occurred during the fourth time slice.

[0040] The alarm suggestion component 504 may evaluate the buckets to create alarm grouping suggestions 514. For example, a first alarm grouping suggestion 516 may suggest to group operator alarm (B) and operator alarm (C) into a first alarm group. A second alarm grouping suggestion 518 may suggest to group operator alarm (D), operator alarm (E), operator alarm (F), and operator alarm (G) into a second alarm group. A third alarm grouping suggestion 520 may suggest to group operator alarm (L), operator alarm (M), operator alarm (N), and operator alarm (O) into a third alarm group. The alarm grouping suggestions 514 may be provided to an operator so that the operator may select alarm grouping suggestions to implement as alarm groups.

[0041] Fig. 6 illustrates an example of a system 600, comprising an alarm suggestion component 604, for suggesting alarm hiding rules and/or alarm groupings. The alarm suggestion component 604 may generate 606 buckets into which operator alarms may be stored (e.g., buckets defined based upon time slices, timeframes after operator actions, operator alarms having overlapping occurrence timespans, a shutdown operation, a startup operation, a standard procedure operation, normal operation, etc.). The alarm suggestion component 604 may sort the operator alarms into the buckets. The alarm suggestion component 604 may perform 608 frequent item set mining to identify alarm co-occurrence relationships. The alarm suggestion component 604 may transform 610 the alarm co-occurrence relationships into rules (e.g., if operator alarm (A) and operator alarm (B) occur, then operator alarm (C) generally occurs).

[0042] The alarm suggestion component 604 may extract 612 rule suggestions, such as alarm hiding rule suggestions and/or alarm grouping suggestions, from the rules. The alarm suggestion component 604 may display the rule suggestions to a user 616. The alarm suggestion component 604 may receive a selection 614 by the user 616 of rule suggestions to implement. The alarm suggestion component 604 may create hiding rules 626 and/or grouping rules 628 based upon the selection 614. An alarm management service 622 may evaluate incoming operator alarms 620 from a plant 618 (e.g., a factory). The alarm management service 622 may utilize a rule checker 630 to evaluate the alarms 620 against the hiding rules 626 and/or the grouping rules 628 in order to determine whether to show or hide particular operator alarms. Operator alarms that are to be shown to an operator 632 may be activated 624 by the alarm management service 622. The operator alarms 620 may be stored within the historic operator alarm data 602.

[0043] Still another embodiment involves a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An example embodiment of a computer-readable medium or a computer-readable device is illustrated in Fig. 7, wherein the implementation 700 comprises a computer-readable medium 708, such as a CD-R, DVD-R, flash drive, a platter of a hard disk drive, etc., on which is encoded computer-readable data 706. This computer-readable data 706, such as binary data comprising at least one of a zero or a one, in turn comprises a set of computer instructions 704 configured to operate according to one or more of the principles set forth herein. In some embodiments, the set of computer instructions 704 are configured to perform a method 702, such as at least some of the exemplary method 100 of Fig. 1, for example. In some embodiments, the set of computer instructions 704 are configured to implement a system, such as at least some of the exemplary system 200 of Fig. 2, at least some of the exemplary system 300 of Fig. 3, at least some of the exemplary system 400 of Figs. 4A-4B, at least some of the exemplary system 500 of Fig. 5, at least some of the exemplary system 600 of Fig. 6, for example. Many such computer-readable media are devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

[0044] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing at least some of the claims.

[0045] As used in this application, the terms "component," "module," "system", "interface", and/or the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

[0046] Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

[0047] Fig. 8 and the following discussion provide a brief, general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of Fig. 8 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Example computing devices include, but are not limited to, personal computers, server computers, handheld or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing

environments that include any of the above systems or devices, and the like.

[0048] Although not required, embodiments are described in the general context of "computer readable instructions" being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.

[0049] Fig. 8 illustrates an example of a system 800 comprising a computing device 812 configured to implement one or more embodiments provided herein. In one configuration, computing device 812 includes at least one processing unit 816 and memory 818. Depending on the exact configuration and type of computing device, memory 818 may be volatile (such as RAM, for example), non- volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in Fig. 8 by dashed line 814.

[0050] In other embodiments, device 812 may include additional features and/or functionality. For example, device 812 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in Fig. 8 by storage 820. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage 820. Storage 820 may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory 818 for execution by processing unit 816, for example.

[0051] The term "computer readable media" as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 818 and storage 820 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 812. Computer storage media does not, however, include propagated signals. Rather, computer storage media excludes propagated signals. Any such computer storage media may be part of device 812.

[0052] Device 812 may also include communication connection(s) 826 that allows device 812 to communicate with other devices. Communication connection(s) 826 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 812 to other computing devices. Communication connection(s) 826 may include a wired connection or a wireless connection. Communication connection(s) 826 may transmit and/or receive communication media.

[0053] The term "computer readable media" may include communication media. Communication media typically embodies computer readable instructions or other data in a "modulated data signal" such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

[0054] Device 812 may include input device(s) 824 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 822 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 812. Input device(s) 824 and output device(s) 822 may be connected to device 812 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 824 or output device(s) 822 for computing device 812.

[0055] Components of computing device 812 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 812 may be interconnected by a network. For example, memory 818 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.

[0056] Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 830 accessible via a network 828 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 812 may access computing device 830 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 812 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 812 and some at computing device 830. [0057] Various operations of embodiments are provided herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment provided herein. Also, it will be understood that not all operations are necessary in some embodiments.

[0058] Further, unless specified otherwise, "first," "second," and/or the like are not intended to imply a temporal aspect, a spatial aspect, an ordering, etc. Rather, such terms are merely used as identifiers, names, etc. for features, elements, items, etc. For example, a first object and a second object generally correspond to object A and object B or two different or two identical objects or the same object.

[0059] Moreover, "exemplary" is used herein to mean serving as an example, instance, illustration, etc., and not necessarily as advantageous. As used herein, "or" is intended to mean an inclusive "or" rather than an exclusive "or". In addition, "a" and "an" as used in this application are generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Also, at least one of A and B and/or the like generally means A or B and/or both A and B. Furthermore, to the extent that "includes", "having", "has", "with", and/or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising".

[0060] Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

Claims

What is claimed is:

1. A method for suggesting an alarm hiding rule, comprising:

sorting operator alarms, within historical operator alarm data, into alarm buckets based upon alarm occurrence information;

identifying an alarm co-occurrence relationship between a first operator alarm and a second operator alarm within an alarm bucket; and

creating an alarm hiding rule suggestion for the first operator alarm based upon the alarm co-occurrence relationship, the alarm hiding rule suggestion indicating that the first operator alarm is not to be displayed to an operator when the second operator alarm is displayed to the operator.

2. The method of claim 1, comprising:

providing the alarm hiding rule suggestion to the operator; and

responsive to receiving an alarm hiding rule creation command in response to the alarm hiding rule suggestion, implementing an alarm hiding rule, corresponding to the alarm hiding rule suggestion, for an alarm management service.

3. The method of claim 1, the sorting comprising:

sorting the first operator alarm and the second operator alarm into the alarm bucket based upon the first operator alarm having a first alarm occurrence timespan corresponding to a second alarm occurrence timespan of the second operator alarm.

4. The method of claim 1, the identifying comprising:

determining that the first operator alarm occurs with the second operator alarm above a co-occurrence threshold.

5. The method of claim 1, comprising:

identifying a second alarm co-occurrence relationship between the first operator alarm, the second operator alarm, and a third operator alarm within the alarm bucket; and creating a second alarm hiding rule suggestion for the first operator alarm based upon the second alarm co-occurrence relationship, the second alarm hiding rule suggestion indicating that the first operator alarm is not to be displayed to the operator when the second operator alarm and the third operator alarm are displayed to the operator.

6. The method of claim 1, the sorting comprising:

defining a first alarm bucket based upon a timeframe corresponding to at least one of a startup operation, a shutdown operation, or a standard procedure operation.

7. The method of claim 1, comprising:

evaluating operator alarms within the alarm buckets to create an alarm model used to label an operator alarm as occurring during at least one of normal operation, a startup operation, a shutdown operation, or a standard procedure operation.

8. The method of claim 7, the alarm model comprising a decision tree.

9. The method of claim 1, the sorting comprising:

defining a first alarm bucket based upon a first timeframe occurring after an operator action.

10. The method of claim 9, comprising:

responsive to sorting a third operator alarm into the first alarm bucket, creating a second alarm hiding rule suggestion for the third operator alarm, the second alarm hiding rule suggestion indicating that the third operator alarm is not to be displayed to an operator when the operator action occurs.

11. The method of claim 9, comprising:

adjusting the first timeframe to create an adjusted first timeframe;

redefining the first alarm bucket based upon the adjusted first timeframe to create a redefined alarm bucket; and

resorting operator alarms into the first alarm bucket.

12. The method of claim 1, the sorting comprising: defining the alarm bucket based upon a time slice;

defining a second alarm bucket based upon a second time slice;

sorting the first operator alarm into the alarm bucket based upon the first operator alarm having first alarm occurrence information corresponding to the first time slice;

sorting the second operator alarm into the alarm bucket based upon the second operator alarm having second alarm occurrence information corresponding to the first time slice; and

sorting a third operator alarm into the second alarm bucket based upon the third operator alarm having third alarm occurrence information corresponding to the second time slice.

13. The method of claim 12, the time slice having a temporal length

corresponding to a second temporal length of the second time slice.

14. The method of claim 12, comprising:

performing frequent item set mining upon the alarm buckets to identify a set of co-occurring operator alarms; and

creating an alarm grouping suggestion based upon the set of co-occurring operator alarms.

15. A system for suggesting an alarm hiding rule, comprising:

an alarm suggestion component configured to:

sort operator alarms, within historical operator alarm data, into alarm buckets based upon alarm occurrence information;

identify an alarm co-occurrence relationship between a first operator alarm and a second operator alarm within an alarm bucket;

create an alarm hiding rule suggestion for the first operator alarm based upon the alarm co-occurrence relationship, the alarm hiding rule suggestion indicating that the first operator alarm is not to be displayed to an operator when the second operator alarm is displayed to the operator;

provide the alarm hiding rule suggestion to the operator; and responsive to receiving an alarm hiding rule creation command in response to the alarm hiding rule suggestion, implement the alarm hiding rule for an alarm management service.

16. The system of claim 15, the alarm suggestion component configured to: sort the first operator alarm and the second operator alarm into the alarm bucket based upon the first operator alarm having a first alarm occurrence timespan corresponding to a second alarm occurrence timespan of the second operator alarm.

17. The system of claim 15, the alarm suggestion component configured to: evaluate operator alarms within the alarm buckets to create an alarm model used to label an operator alarm as occurring during at least one of normal operation, a startup operation, a shutdown operation, or a standard procedure operation.

18. The system of claim 15, the alarm suggestion component configured to: define a first alarm bucket based upon a first timeframe occurring after an operator action; and

19. The system of claim 15, the alarm suggestion component configured to: define a set of alarm buckets based upon a plurality of time slices;

sort the operator alarms into the set of alarm buckets;

perform frequent item set mining upon the set of alarm buckets to identify a set of co-occurring operator alarms; and

create an alarm grouping suggestion based upon the set of co-occurring operator alarms.

20. A computer readable medium comprising instructions which when executed perform a method for suggesting an alarm hiding rule, comprising:

sorting operator alarms, within historical operator alarm data, into a set of alarm buckets based upon alarm occurrence information;

performing frequent item set mining upon the set of alarm buckets to identify an alarm co-occurrence relationship between a first operator alarm and a second operator alarm within an alarm bucket; and