Strategies For Alarming
Alarming is typically done by many different systems within the plant. Certain types of alarms are better serviced by certain systems based a few criteria. In general, the question is "Which alarms should be serviced by the control system and which alarms should be in the information system?" To set up an Alarm event, refer to Alarm Event.
Reasons Why Control System Should Alarm
-
Need for extremely fast data
-
Need for real-time action
-
Most convenient operator interface
Reasons Why Information System Should Alarm
-
Not all the data is available to control system
-
Dependency of alarm on manual entry
-
Based on values that can be recalculated non real-time
-
Awareness of product and product specification
-
Awareness of schedule and order characteristics
Why Alarm in Plant Applications?
-
Documents alarm conditions for historical analysis
-
Capture alarms reasons, actions
-
Expose exception based operating procedures
-
Use alarms in quality control and disposition
The general process for configuring Alarms in Plant Applications is as follows:
-
Choose variables that should have alarms.
-
Define Cause Reason and Action Trees.
-
Configure product specifications for each product where alarms are appropriate.
-
Group variables related by process, or by a specific problem.
-
Define documentation for each group and for each variable to be used when alarm condition is detected.
-
Define Alarm Rules under "Alarms" in the Template Library. A Rule should be created for each group of variables.
-
Attach variables to the Rule, define Limits which should trigger alarms, and attach appropriate documentation to the Rule and individual variables.
-
Build Alarm View displays.
-
Configure security and attach to Alarm View displays to control who can acknowledge alarms and change reasons.
See Also