ISA18'2 Working Group 3 Basic Alarm Design Status Report

1
ISA-18.2Working Group 3 (Basic Alarm
Design)Status Report

• October 5th, 2009

2
Agenda

• Team
• Charter
• Progress to Date
• Issues
• Table of Contents

3
Working Group 3 Team

• Nicholas Sands
• Donald Dunn
• Todd Stauffer
• Patrick ODonnell
• Kim Van Camp
• Bridget Fitzpatrick
• John Hulman
• Bill Hollifield
• Joseph Alford
• John Bogdan

4
WG3 (Basic Alarm Design) Charter

• Working group 3 (WG3) is charged with the
  development of Technical Reports and Recommended
  Practices providing guidance on basic alarm
  design.
• WG3 focuses on the scope of ISA-18.2 clause 10
  and may include other clauses as needed (e.g.,
  operations and maintenance).
• Basic alarm design covers the selection of alarm
  attributes (e.g., types, deadbands, and delay
  times) and may be specific to each control
  system.

5
Progress to date

• Meetings (Wednesdays at 100 PM)
• 8/19, 9/2, 9/30
• Reviewed Charter
• Reviewed Annexes
• Reviewed Rejected Comments for those that are
  TR-worthy
• Established Framework / Table of Contents for
  Technical Report

6
Table of Contents Development Start with Clause
10

• 10.1 Purpose
• 10.2 Usage of Alarm States
•  10.2.1 Alarm State Triggering
•  10.2.2 Use of Alarm State Information
•  10.3 Alarm Types
•  10.4 Alarm Attributes
•  10.4.1 Alarm Setpoint
•  10.4.2 Alarm Deadband
•  10.4.2.1Alarm Deadband Requirements
•  10.4.2.2 Alarm Deadband Recommendations
•  10.4.3 Alarm On-Delay and Off-Delay
•  10..4.3.1 Alarm On-Delay and Off-Delay
  Requirements
•  10.4.3.2 Alarm On-Delay and Off-Delay
  Recommendations
•  10.5 Programmatic Changes to Alarm Attributes
•  10.6 Review Work Product
•  

New Material
7
Content Review

• Section 10. 1 Purpose (-gt Motivation or
  Importance)
• Importance of basic alarm design for minimizing
  nuisance alarms
• Reference metrics for how focus on basic alarm
  design has improved performance - ASM study
• Table of common alarm management problems and
  which ones can be addressed in Basic Design

8
Content Review (Contd)

• Section 10.2 Usage of Alarm States
• Add details / examples about alarm latching.When
  would you want to use it ? When would you not
  want to use it
• Re-alarming functionality
• Section 10.2.1 Alarm State Triggering
• General strategies for eliminating duplicate
  alarms (eg. from field device, from control
  system)
• Considerations for how to select alarm trigger
  source (HMI, controller, field), when there are
  options
• Section 10.2.2 Use of Alarm State Information
• Examples and considerations (pros and cons) for
  implementing interlocks separately from alarms
  (interlocking based on alarm state)
• Will Provide information to help users make the
  right choice for their application

9
Content Review (Contd)

• Section 10.3 Alarm Types
• Application / design information for each alarm
  type. What job role should respond to each
  oneExample Instrument Diagnostic alarm should
  be routed to the maintenance / instrumentation
  shop
• Discussion of which alarm types are prone to
  becoming nuisance alarms and recommendations for
  preventing them becoming nuisance alarms
• Add new alarm type - fieldbus alarms ?
• Some of these alarm types will be addressed in
  Advanced Alarming (first-out alarms, recipe
  driven alarms)

10
Content Review (Contd)

•  10.4.1 Alarm Setpoint
• N/A (Details to be provided in Rationalization
  TR)
•  10.4.2 Alarm Deadband
• Risk of misapplication of deadband (latching)
• Application Examples (how to interpret the
  default deadband charts in specific situations)
• Procedural examples (e.g. set low and increase by
  exception)
•  10.4.3 Alarm On-Delay and Off-Delay
• How to use statistical analysis of PV
  fluctuations to on/off delay
• Application examples
• Mention of alarm system metrics (time in alarm /
  between alarm) that should be generated to
  support review of settings
• Considerations for using both Deadband On/Off
  Delay
• Considerations when PV Filtering is in effect

11
Content Review (Contd)

•  10.5 Programmatic Changes to Alarm Attributes
• Common recommendations for access control
  security settings (crosses over into HMI Design
  no TR)

12
Content Review (Contd)

•  10.6 Review Work Product
• Verify that only those alarms called for in the
  Master Alarm Database have been implemented
• Procedures for automatic comparison of actual
  configuration vs MAD

13
Content Review (Contd)

• Alarm Message Composition
• Recommendations / Advice on use of abbreviations,
  usability, consistency
• Alarm Design for Specific Applications
• Relief Valves latch in alarm requires action
  (investigation / reset)
• Safety Showers
• Span of control / Routing of alarms
• Emphasize operators should only receive alarms
  for areas of process for which they are
  responsible
• Rout alarms from upstream unit to downstream
  (disturbance notification)

14
2 Issues for WG 3

• Where is the boundary between Basic and Advance
  Design
• One thought is that basic only deals with the
  setting of individual tag
• Treatment of Diagnostic Alarms
• System and Instruments

15
The cardinal rule of alarm management
An ALARM indicates a PROBLEM that requires an
operator RESPONSE.
An ALARM indicates a PROBLEM that requires an
operator RESPONSE.
An ALARM indicates a PROBLEM that requires an
operator RESPONSE.
An ALARM indicates a PROBLEM that requires an
operator RESPON