Patent Application
20070194920
1. Field Of The Invention
This invention is directed to a method for determining an alarm configuration in industrial alarm systems. In particular, the invention relates to a method of improving an existing alarm system through a process known as “Alarm Rationalization.” The conventional method of alarm rationalization is expensive and time-consuming. The present invention is directed to a novel Focused Alarm Rationalization method that is significantly less expensive and time-consuming than prior art Alarm Rationalization methods, but which yields equivalent performance results.
2. Description of the Prior Art
A Distributed Control System (DCS) is a process control system that uses a network to interconnect sensors, controllers, operator terminals and actuators. A DCS typically contains computers for control rather than individual control hardware.
Process sensors, switches, controllers, actuators, and other inputs and outputs connected to the DCS typically monitor and affect the magnitude and/or change in process variables, such as temperature, pressure, flow, level, volume, voltage, amperage, resistance, composition, pH, and similar physical or calculated characteristics. The term “tag” is used to refer to an element configured in the control system, and tags are identified uniquely in the DCS. A tag can be an individual reading from the process (such as a pressure value, a temperature value, a flow value, the position of a switch or other type of on-off element, and so forth), a logically derived element (such as presenting a reading from one sensor under some logically-derived conditions, and a reading from a different sensor under other conditions), a calculated result involving readings from one or more sensors, calculations involving information from systems totally external to the DCS (such as current pricing of a component of the process) or other similar and flexible constructs. A tag can be created as a combination of other tags. The tags in a DCS can range from very simple, to quite complex and flexible in their configuration.
In a DCS, alarms can be optionally assigned, via simple software settings, to most types of tags. These are known as “alarmable tags.” An example is a tag representing a temperature reading having a “High Value” alarm set at a particular number. A single tag can have multiple alarms of different types. A tag representing a single temperature reading might have, for example, not only a “High” value alarm but also a “High-High” value alarm, a “Low Value” alarm, a “Low-Low” alarm, a rate-of-change alarm, an alarm indicating the signal has moved outside of a known range, and several other types. Different types of tags can have many different types of alarms. Different alarms may be assigned different “alarm priority” as well, wherein the priority attribute is used to distinguish alarms in a way that is helpful to the DCS operator, such as by their relative importance. Alarm Priority in a DCS is ranked from the “highest” priority level through 2, 3, or more “lower” priority levels. A single process may have thousands of tags, and thus even more thousands of configured alarms.
Prior to the introduction of the DCS, industrial process controls were collections of individual sensors, actuators, controllers, and the like without much of the flexibility, communication, and alarm assignment characteristics of a DCS. In the pre-DCS era, the control room of a processing facility would typically have a section reserved for hard-wired alarms. Such alarms were generally wall-mounted boxes containing light bulbs arranged in a rectangular array, where individual bulbs would illuminate an engraved description of the alarm it represented. These alarm displays were expensive to design, install, and maintain, so the decision to “create an alarm” was made with care and deliberation. The advent of the DCS enabled the creation of alarms via simple software settings and constructs, without additional hardware or cost, which were then shown on a CRT-type display. The result was that most DCS systems have been implemented with very large numbers of configured alarms, and in times of process upset or even under normal circumstances, generate more alarm events than can be effectively handled by the operator. The alarm system then becomes a hindrance rather than an aid. The problem of overloaded alarm systems is well-known and has been cited in investigation reports of major process accidents. The solution of the problem involves many elements.
One common element for dealing with this situation is an alarm system review concentrating on the proper selection and configuration of alarms. This alarm review is known to those skilled in the DCS art by many names, and will be herein referred to as “Alarm Rationalization.” This is a structured methodology involving group discussion (usually of engineers and process operators) of the process sensors or software construct comprised by the DCS.
The basic concept and methodology for Alarm Rationalization is covered in published articles and guidelines, such as the Engineering Equipment and Material Users Association (EEMUA) Publication 191, titled “Alarm Systems—A Guide to Design, Management, and Procurement.”
Alarm Rationalization generally encompasses many elements including, but not limited to (a) the appropriateness of any alarms currently configured for that tag, (b) whether any alarms on that tag are duplicated by other alarms on other tags, (c) causes of the alarm, (d) verification of the alarm signal, (e) consequences if the alarm receives no response, (f) corrective actions to be taken, (g) time available to take corrective action, (h) process history of the sensed variable, and (i) the proper priority to be assigned to each of the alarms.
Prior art alarm systems have been modified to match what is called for in the rationalization; this is known as “implementing the rationalization.” The resulting alarm configuration is said to be “rationalized.” Many prior art systems that have not been through rationalization have 90% or more of the alarmable tags configured with alarms. A typical control system may comprise thousands of alarmable tags.
Prior art published works on Alarm Rationalization, such as the before-mentioned EEMUA Publication 191, refer to performing it on all tags with existing configured alarms, or on all tags where it is possible to configure alarms. This method is thorough, but very costly.
Alarm Rationalization is a group effort, usually involving three to six people if done according to best practices. Since a typical DCS may involve thousands of tags, the effort can be very time-consuming and costly. For a typical 4,000 tag system, it is quite normal to spend more than $100,000 in man-hour costs alone in performing the review. Since the people performing the review must be knowledgeable of the process under discussion, this effort takes away from their current job duties, incorporating a significant work disruption as well.
This high cost and the tedious nature of the work are large disincentives for this important safety review. But, because of the safety implications of the effort, any attempts to make it more efficient should be rigorously and cautiously evaluated.
Conventional Alarm Rationalization looks at every tag on a system that is capable of being configured with an alarm. However, historical system analysis has shown that even over long periods of time (6 months to a year or more), the facts are that approximately one quarter of the alarmable tags produce all of the alarms during the periods analyzed, and less than one fifth produce more than 10 individual alarm events during the various analysis periods (ranging over many months/years).
It is believed that the majority of the time spent in a conventional alarm rationalization discussion is inefficient, discussing tags that have not produced an alarm or otherwise contributed to the alarm problem of the system. Thus a properly safeguarded methodology of selecting, for purposes of alarm rationalization, only tags whose alarms are contributing to the alarm problem on the system would thereby bring about substantial time and cost savings in the rationalization process, and accomplish the needed performance improvement as well. This methodology is a fundamental part of the invention of Focused Alarm Rationalization.
The Focused Alarm Rationalization methodology described herein provides a high quality rationalization that is a significant cost and productivity improvement over the conventional method. Various embodiments of this Focused Alarm Rationalization methodology provide one or more of (a) alarm rationalization with significantly less effort than prior art methods and therefore reduce cost, and (b) no sacrifice in performance improvement of the post-rationalized alarm system compared to the conventional methodology.
Advances in computer technology and alarm analysis software have provided the ability to analyze many gigabytes of real-world alarm data, and to determine the actual functioning characteristics of many industrial alarm systems. Such advances are useful in practicing the present invention.
Focused Alarm Rationalization involves limiting the rationalization effort only to tags with alarms that are part of the alarm problem on the system. This involves specific prior analysis of the system to determine the list. Additionally, provisions are made to insure that the highest-priority alarms are properly addressed.
a is a block diagram of first and third preferred embodiments of the Focused Alarm Rationalization Process.
b is a block diagram of second and fourth preferred embodiments of the Focused Alarm Rationalization Process.
a is a block diagram of a fifth preferred embodiment the Focused Alarm Rationalization Process.
b is a block diagram of a sixth preferred embodiment the Focused Alarm Rationalization Process.
In one preferred embodiment, the invention is directed to a Three Step Focused Alarm Rationalization Methodology. The first step, Step 1a, is analyzing actual alarm event data from the system to be rationalized, as shown in block 10 of
The above pattern is repeated, for the alarms in the system in decreasing count.
There may be several hundred tags and alarms with very few events, or even only one event.
In a preferred embodiment, this list comprises the entire list of alarm events during the entire time period of the analysis. In a preferred embodiment, this is the beginning of the list to be subjected to Alarm Rationalization. This list will, based on historical analyses, typically be about 25-30% of the total alarmable tags on the system.
In another preferred embodiment the first step, Step 1b, is setting a minimum threshold of alarm count or rate activation, as shown in block 20 of
The second step, Step 2, comprises identifying the configured alarms that are set with the highest priority level allowed on the particular brand of control system involved, as shown in block 30 of
The third step, Step 3, comprises obtaining input from unit-knowledgeable engineers, operators, or technicians, as to whether any tags or alarms that are not currently configured as the highest priority, should be, as shown in block 40 of
In a preferred embodiment, this embodiment further comprises identifying any alarms specifically called out for in such studies, that should exist on the system, that were not found in either Step 1a or 1b (from alarm events), or Step 2 (from the alarm configuration on the system). In a preferred embodiment, this embodiment further comprises adding the identified alarms to the list of tags to be subjected to rationalization. This step is useful because the actual alarm configuration found on the system in Step 2 may not accurately reflect what has been specified to be on the system. This step is an important safeguard, but will likely not add to the tag count for alarm rationalization in a significant amount.
Thus, a first preferred embodiment of the invention comprises Steps 1a, 2, and 3, while a second preferred embodiment of the invention comprises Steps 1b, 2, and 3, as shown in
Two other preferred embodiments of the invention comprises the above Steps 1a or 1b, 2, and 3, as described above plus a fourth step, Step 4, which is performing Alarm Rationalization on the list accumulated performing Steps 1a or 1b, 2, and 3. These embodiments are shown in
A fifth preferred embodiment of the invention comprises the above Steps 1a, 2, 3 and 4, as described above plus a fifth step, Step 5a, which is performing a periodic reevaluation to check the alarms (tags) produced in the prior period, and rationalize any newly appearing ones that occurred that were not included in the list developed in Steps 1a, 2, and 3. This embodiment is shown in
In a preferred embodiment, short rationalization meetings can be used to handle the small number of “new” tags involved, without disrupting work schedules of the personnel involved. The amount of tags that will be discovered in this monthly check will be related to the duration of the analysis used in Step 1; the longer that duration, the smaller this amount will be. As these additional tags and alarms are rationalized and implemented on the system, the list of Rationalized Alarms should be updated to include them for the next cycle of review in this periodic program.
A sixth embodiment of the invention comprises the above Steps 1b, 2, 3 and 4, as described above plus a fifth step, Step 5b, which is performing a periodic reevaluation, as shown in block 70 of
In a preferred embodiment, short rationalization meetings can handle the relatively small number of “new” tags involved, without disrupting work schedules of the personnel involved. The amount of tags that will be discovered in this modified monthly check will also be related to the duration of the analysis used in Step 1b; the longer that duration, the smaller this amount will be. As these additional tags and alarms are rationalized and implemented on the system, the list of Rationalized Alarms should be updated to include them for the next cycle of review in this periodic program.
The foregoing disclosure and description of the inventions are illustrative and explanatory. Various changes in the illustrative method may be made without departing from the spirit of the invention.
This application claims priority from provisional application Ser. No. 60/775,116, filed Feb. 21, 2006.
| Number | Date | Country | |
|---|---|---|---|
| 60775116 | Feb 2006 | US |
