18
Previous Issue: 30 September 2003 Next Planned Update: 1 October 2008 Revised paragraphs are indicated in the right margin Page 1 of 18 Engineering Report SAER-5895 30 September 2003 Alarm Management Guidelines for Process Automation Systems Document Responsibility: Process & Control Systems Dept. Saudi Aramco DeskTop Standards Table of Contents 1 Objective........................................................ 2 2 Introduction.................................................... 2 3 Definitions...................................................... 2 4 Alarm Design................................................. 5 5 Management of Change............................... 12 6 Alarm System Performance Analysis and Monitoring at Operating Facilities......... 12 7 Application of Design Guidelines................. 14 8 Advanced Alarm Applications...................... 17

SAER-5895

Embed Size (px)

Citation preview

Page 1: SAER-5895

Previous Issue: 30 September 2003 Next Planned Update: 1 October 2008 Revised paragraphs are indicated in the right margin Page 1 of 18

Engineering Report

SAER-5895 30 September 2003 Alarm Management Guidelines for Process Automation Systems Document Responsibility: Process & Control Systems Dept.

Saudi Aramco DeskTop Standards Table of Contents 1 Objective........................................................ 2 2 Introduction.................................................... 2 3 Definitions...................................................... 2 4 Alarm Design................................................. 5 5 Management of Change............................... 12 6 Alarm System Performance Analysis and Monitoring at Operating Facilities......... 12 7 Application of Design Guidelines................. 14 8 Advanced Alarm Applications...................... 17

Page 2: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 2 of 18

1 Objective

This document provides guidelines for the implementation of alarm management within Saudi Aramco facilities to improve safety, reliability, and profitability. It will serve as a guide in the design and management of alarms for process automation systems.

2 Introduction

Process and system alarms are essential to monitor plant conditions and attract the attention of the process plant operator to significant changes that require timely assessment or action. A well configured alarm system helps the operator to correct potentially dangerous situations before the Emergency Shutdown System (ESD) is forced to intervene, thus improving plant availability and safety. Conversely, alarms should also inform of shutdown system failures, or of other unsafe situations, that require operator intervention. An effective alarm system also helps the operator to identify deviations from desired operating conditions that could lead to financial loss, as well as to better understand complex process conditions such as during unit upset.

To accomplish the above objectives, each and every alarm point in the system must:

a. Require an operator action.

b. Provide sufficient time for operator action.

c. Be designed based on a consistent and documented approach.

The Engineering Equipment and Material User Association (EEMUA) publication no. 191: 1999, "Alarms Systems – A Guide to Design, Management, and Procurement", has been used extensively to develop this guideline.

There are two main contexts in which the alarm system guidelines will be applied: 1) during new facility design, and 2) for assessment / improvement of existing facilities. When applied at initial design, the design of alarms shall be part of the process design and shall be part of detailed reviews such as HAZOP.

3 Definitions

3.1 Abbreviations

MRT: Maximum Response Time

PV: Process Variable

3.2 Definitions:

Alarm Priority. Alarm priorities are used to define the relative importance of an event. Throughout this document, it is assumed that the control system has five (5) alarm priorities: NoAlarm/Journal/Low/High/Emergency.

Page 3: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 3 of 18

• NoAlarm: No alarm is configured.

• Journal: The alarm is recorded and time-stamped in the control system archive, but no visual or audible alarm is generated to alert the operator.

• Emergency/High/Low: These alarms are raised to the operator console and generate an audible alarm. The alarms are also recorded and time-stamped in the control system archive.

Alarm State:. The following alarm states are possible.

• Acknowledged: The operator has acknowledged his awareness of the alarm by push button or mouse click.

• Cleared: The alarm has been removed from the alarm summary list of standing alarms. Normally, this occurs because the alarm was acknowledged and the abnormal conditions causing the alarm to be raised have returned to normal.

• Inhibited: The raising of the alarm is prevented even when the abnormal conditions exist. This is an engineering function normally used on a temporary basis during a time when the alarm will give an inaccurate indication.

• Raised: Control system has recognized that the conditions for the alarm have been met; it has taken the logical action configured for this condition (with regard to audible tone, printing, display, and journal).

• Shelved: The raising of the alarm is prevented (except that it is still journaled) even when the abnormal conditions exist. This is an operator function normally used on a temporary basis during a time when the alarm has become a nuisance.

• Standing: The alarm has been raised and is not yet cleared.

Bad I/O Alarm. A system alarm that indicates an inaccurate or unavailable input or output signal.

Absolute Alarm (HH, H, L, LL): A process alarm that an analog signal exceeds a pre-defined abnormal value (the alarm set point). Most control systems have the following absolute alarms:

• High-High (HH)

• High (H)

• Low (L)

Page 4: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 4 of 18

• Low-Low (LL)

Change-of-State Alarm: A process alarm notification that equipment has changed its operation from one state to the other. For example, a pump changes from "On" state to "Off" state, and vice versa.

Command-Disagree Alarm: A process alarm of an unexpected equipment state compared to its actual state. For example, an MOV status is different than its command state (after a suitable time delay).

Deviation Alarm: A notification that the difference between the setpoint and the actual PV exceeds a certain limit.

HAZOP: A systematic, detailed hazards analysis technique applied to processes to identify and qualify deviations from design or normal operation which have the potential to place the process plant, environment or personnel at risk. The HAZOP study is a normal part of new facility design. The analysis shall follow the guidelines of SAER-5437, Saudi Aramco HAZOP Engineering Report.

Off-Normal Alarm: A notification that equipment is not in its normal state. For example, if the normal state of an MOV is open, then Off-Normal alarm would occur when the MOV is not in its normal, open state.

Plant-State Alarm: An alarm optimization technique used to change the configuration of one or more alarm points in real-time, depending on the operating states of the equipment.

Process Alarm:. A notification that a changed condition has been detected in the operating facility; either a process condition (e.g., a flow) or a process state (e.g., a pump stopped). How the notification is reported depends upon the priority of the process alarm. Listed below are some commonly used process alarm mechanisms.

Rate-of-Change Alarm:. A notification that the rate-of-change of an analog PV exceeds a pre-defined abnormal value (alarm set point).

System Alarm:. Alarm which occurs as a result of a DCS hardware or software fault.

4 Alarm Design

The alarm system design will determine if an alarm is required. If an alarm is required, then

• What is the priority setting?

Page 5: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 5 of 18

• What is the alarm setpoint and other configuration settings?

• Is it appropriate to modify the alarm settings based on the operating state of the equipment?

• How are alarms visually and audibly presented to the operator?

The following sections provide a design methodology and design criteria to ensure consistency for Saudi Aramco facilities. These design procedures apply to both new and existing alarm systems. The redesign of existing alarm systems is commonly known as "alarm rationalization".

4.1 Is an Alarm Required

The questions below are used to determine conditions when a process alarm is necessary to be raised to the operator (Emergency, High, or Low priority).

• Does the event represent an abnormal condition?

• Does the abnormal situation require operator action?

• Is there adequate time for an operator action?

• Is this the appropriate place to indicate to the operator the event has occurred?

Those events that do not meet the above criteria should be either Journal priority (stored in history) or NoAlarm (not configured). One guiding principle is this: if there is no abnormal condition, then no alarm shall be raised. For example, if a pair of 100% pumps are provided, it is a normal condition for one of the pumps to be on and one off. The offline pump should not have a standing alarm.

Conversely, there are some pumps that have no running spare. When "running" is always the normal condition and "stopped" is always the abnormal condition, an alarm triggered by transition to stopped may be needed (subject to the remaining criteria).

If an alarm is required, analysis must be conducted to determine the appropriate alarm priority.

4.2 Alarm Priorities

Alarm priority is a means to convey the urgency of a specific process condition to the operator and drives the operator's responses during upsets when many alarms occur simultaneously. To properly focus the operator's responses, a logical and consistent method of assigning priorities is required.

Page 6: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 6 of 18

Two important factors will be considered when determining the priority of an alarm:

• Severity of Consequences

• Maximum Response Time

There are three levels of alarm priority for the alarm system that are raised to the operator. These levels should be consistent throughout the site. Fire detection system is excluded from this categorization because it is an independent system. EEMUA recommends the following alarm priority distribution as a guideline:

Alarm Priority Percentage of Total Alrms

Emergency 5%

High 15%

Low 80%

A way to assign priorities via the use of matrices is shown in the following sections.

4.2.1 Areas of Impact and Severity of Consequences

The selection of an alarm priority depends heavily on the consequences of the abnormal condition if the operator fails to take corrective actions in a timely fashion. For each alarm, the potential consequences without any operator actions must be identified.

A risk matrix is to be defined for each individual plant site. A risk matrix will be used to define the Severity of Consequence criteria. An example risk matrix is shown below.

Page 7: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 7 of 18

Table 1 – Example Risk Matrix

Severity of Consequence

Impact Minor Major Severe

Personnel None Lost time injury Life Threatening Public or Environment

Minimal exposure. No impact. Does not cross fence line. Contained release. Little, if any, clean up. Source eliminated.

Exposed to hazards that may cause injury. Hospitalizations and medical first aid possible. Damage Claims.

Exposed to life-threatening hazard. Disruption of basic services. Impact involving the community. Catastrophic property damage. Uncontained release of hazardous materials with major environmental impact and 3rd party impact.

Plant/Equipment Equipment damages that result in negligible unit downtime.

Results in unit downtime up to 15 days, some to severe equipment damage.

Results in loss of entire unit or critical equipment for more than 15 days

Costs/Production Event costing <10M$ Event costing 10M$-1MM$ Event costing >1MM$

For each impact, the consequence (if any) of an operator failure to take action will be determined. The worst case impact determines the consequence of minor, major, or severe. For example, if a single event would result in a minor loss of production but would also cause severe equipment damage, then the consequence should be classified as "severe".

4.2.2 Maximum Response Time

Maximum Response Time (MRT) is the time that the operator has to take action to prevent or mitigate undesired consequences caused by an abnormal condition. The shorter the time to respond, the higher the priority of the alarm, assuming equal consequences can result. MRT must include the action of outside personnel following direction from the console operator.

MRT categories shall be defined for each individual plant site. MRT will be defined for each alarm. An example MRT table is shown below:

Page 8: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 8 of 18

Table 2 – Example MRT categories

Maximum Response Time Categories

> 30 minutes

10 to 30 minutes

3 to 10 minutes

< 3 minutes

4.2.3 Alarm Priority Matrix

Combining the severity of consequence and the MRT provides a systematic approach for setting alarm priorities. An alarm priority matrix shall be defined for each plant site. Each alarm priority is determined through the use of this matrix. An example alarm priority matrix is shown below:

Table 3 – Example Alarm Priority Matrix

Maximum Severity of Consequence Response Time Minor Major Severe

> 30 Minutes No Alarm No Alarm No Alarm

10 to 30 minutes No Alarm Low High

3 to 10 minutes Low High High

< 3 minutes High Emergency Emergency

As an example, if an event was determined to have a major consequence and the operator has 15 minutes to respond to take corrective action, the alarm priority would be set to Low using the above example matrix. Note that for this example, an event with an MRT greater than 30 minutes does not warrant configuration of an alarm.

The alarm priority matrix provides a mechanism to ensure consistency in the setting of priorities. The reason for an alarm priority setting different from the alarm priority matrix shall be documented.

It is recommended that every Emergency priority alarm have a pre-alarm set to High priority. However, if there is inadequate time for the operator to take effective action in response to the pre-alarm, it should not be configured.

Page 9: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 9 of 18

4.3 Alarm Settings

Alarm settings include alarm setpoints and alarm filter configuration settings. These settings should be selected to provide adequate response time to plant operations and to minimize nuisance alarms.

At design time, alarm setpoints are determined by the process design engineer. Care must be taken to ensure that operations have adequate time to take action to correct the abnormal situation. After sufficient process experience has been gained, the setting may be adjusted to reduce the occurrence of nuisance alarms.

To minimize chattering alarms, which activate repeatedly over a short period of time, appropriate alarm dead bands and digital delay times are recommended. The recommended design settings are shown below. Adjustments to these values may be made after sufficient operating experience has been obtained.

Table 4 – Recommended Alarm Dead band and Digital Delay Times

Signal Type Delay Time (Digital) Dead Band (Analog)

Flow 2 sec 5%

Level 2 sec 5%

Pressure 1 sec 2%

Temperature 0 sec 1%

4.4 Alarm Documentation

For ease of access and maintainability, the alarm system documentation should be maintained through a uniform electronic database system across the entire site.

At a minimum, the following items shall be documented for each alarm, either during initial alarm design or during rationalization.

• Potential consequences if the operator does not respond to the alarm

• Maximum time available for the operator to respond and mitigate identified consequences

• The reasons for over-riding any priority recommendations

The following additional items may be included at the Operating Organization discretion.

• Operator response or corrective actions for the alarm

• Causes of the alarm

Page 10: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 10 of 18

For new projects, alarm system documentation shall be provided for review as part of the process automation system detailed design.

4.5 Alarm Display and Annunciation

The alarm message shall clearly identify the condition that has occurred. It shall be consistent in format throughout the plant and use consistent abbreviations from a site dictionary.

The DCS operator interface system shall be designed to minimize the number of keystrokes required to identify, verify, and assess an alarm. The guideline for this shall be one keystroke to access the appropriate operating schematic for Emergency alarms, and two keystrokes for High alarms.

Distinct audible tones should be provided for each alarm priority. However, alternatives, such as a distinct audible tone for each console, should be considered where multiple consoles are in close proximity.

The alarm indication color should be based on priority and be consistent throughout displays on all consoles. Alarm display conventions shall be established to provide consistency. An example of alarm display conventions follows:

Table 5 – Example Alarm Display Conventions

Priority Unacknowledged Acknowledged

Emergency Red – blinking Red – solid

High Orange – blinking Orange – solid

Low Yellow – blinking Yellow - solid

The alarm status shall be indicated on objects (e.g., valves, measurements) drawn on process graphics and control faceplates.

Alarm behavior on the Alarm Summary page should be based upon the priority of each individual alarm. The desired functionality is that the color and visual pattern of an alarm on the Alarm Summary immediately indicates the priority of each individual alarm. Standing alarms (those still in alarm condition) are normally displayed with most recent alarms at the top; but should be sortable by priority to see highest priority grouped at top (needed during upsets).

4.6 Alarm Rationalization

Alarm rationalization is the redesign of alarms in an operating facility. It is recommended when the measured performance of an existing alarm system does not meet the requirements stated in Section 6 of this report. During alarm

Page 11: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 11 of 18

rationalization, all DCS points shall be reviewed in accordance to the design procedures of Section 4.

The rationalization team normally includes full time participation of:

• Two senior operators with experience in the area being rationalized

• Alarm Management specialist to facilitate the process and to document results.

Other individuals with knowledge of the process unit, its operation, its advanced control schemes, unit hazards and critical equipment will be needed periodically.

Documents required for a thorough rationalization normally includes:

• Unit P&ID's

• Operating Instructions

• DCS configuration data

• Results from HAZOP or PHA reviews and

• ESD point lists, ESD trip setpoints, and ESD logic diagrams

Access to the archived PI point database via Process Book trends is very useful to select alarm setpoints that avoid nuisance alarms.

Since the number of alarms to be rationalized is very large, alarm rationalization software is recommended for efficient use of manpower. The software should display all DCS alarm configuration details and allow for rapid documentation of results.

4.7 Manual Alarm Shelving Function

Alarms may need to be suppressed for temporary periods, especially when inoperable and awaiting repair. Such instances must be controlled to ensure proper re-activation, either manually initiated or upon detection of some process parameter change. An alarm shelving function is recommended to suppress such alarms in a way that protects the integrity of the alarm system. Shelving differs from alarm inhibition in 2 ways: 1) inhibition is "permanent"; there is no reminder to un-inhibit, 2) inhibition is done as an engineering function.

The alarm shelving function shall have the following features:

• Suppress alarm raising to operator (both audible and visible) while still being journaled (effectively switching priority to "Journal")

• The shelving action should be journaled

Page 12: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 12 of 18

• The operator must be able to observe which alarms are shelved

• The operator must document the reason for shelving and set expected time of return to normal

• Provide reminder with "snooze" button capability to prevent leaving the alarm shelved longer than necessary. Reminder can be set for date/time or end of each shift. Operator response to reminder should be journaled.

5 Management of Change

To maintain the integrity of the facility, the plant Management of Change (MOC) procedure shall be used to control and document all modifications to the alarm system. This procedure includes the review and concurrence by plant management and experienced personnel in the facility.

6 Alarm System Performance Analysis and Monitoring at Operating Facilities

6.1 Baseline Analysis

A "Baseline" consists of a group of analyses that are conducted using both static and dynamic information. The dynamic alarm data should cover six weeks or more in an attempt to establish a normal, average operating condition. It is recommended to perform a Baseline at any operating facility where this has not previously been conducted. A Baseline should be used to verify the proper design of alarms after commissioning a new project.

Purposes:

• Document existing condition for later comparison to measure improvement

• Measure alarm system performance (measure risk)

• Pinpoint locations (consoles) of most serious risk

• Determine major problem root causes (too many alarms, incorrect alarm setpoints, faulty instruments, etc.)

• Compare subject consoles to others in Saudi Aramco and to worldwide targets.

Page 13: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 13 of 18

Analyze configuration metrics:

Analysis Type Metric Target Configuration Info Alarms configured/ recommended maximum

alarms configured (recommended max. = 6*C + 2*AI + .6*DI where C = no. of controllers, AI = no. of analog inputs, DI = no. of digital inputs)

<1.00

Configuration Info Frequency distribution of configured alarms Emergency: at or below 5% High: at or below 15% Low: at or above 80%

Dynamic Alarms Long term average alarms/ day <288 / day

Dynamic Alarms Peak alarms/ 10 min <20 / 10 min

Dynamic Alarms Standing alarms <10 at any time

Dynamic Alarms Disabled (shelved) alarms <30 at any time Dynamic Alarms Chattering alarms (activated 5 times or more

per minute) 0

Dynamic Alarms Stale alarms (in alarm state longer than 24 hours)

0

Dynamic Alarms Risk time – long term

Dynamic Alarms Risk time – peak

The configuration of the alarm system requires ongoing maintenance to ensure accuracy, operability, and compliance with plant standards. Once an alarm database is developed, the effective management of that alarm database requires performance assessments and a proven workflow process.

6.2 Alarm Redesign (Rationalization)

When performance of the alarm system is poor compared to the guidelines of Table 6, the permanent solution is normally a complete redesign of all the alarms within that area by following the procedures described in Section 4. This task can be very labor intensive and it is recommended to use a software tool specifically designed for the task in order to minimize utilization of manpower, provide consistency, and provide adequate documentation.

6.3 Weekly Bad Actor Report

A weekly report of bad actors enables the OME team (Operations foreman, Maintenance planner, Ops Engineer) to focus quickly on the instrument loops that are causing the most alarms in various categories. At the OME team level, root cause should be determined and the problem corrected. This procedure is beneficial to give the console operator relief whenever alarm rates are high. But, where alarm rates are consistently or significantly above recommended limits, the only permanent solution is a comprehensive redesign of the alarms

Page 14: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 14 of 18

(see section 6.4). Weekly reports are also useful for the foreman to monitor operator actions (e.g., which alarms were disabled during the week), and pinpoint which controllers have required operator changes most frequently. Controllers needing frequent attention by operators (mode changes, setpoint changes, output changes) indicate problems that need engineering attention. Recommended weekly bad actor reports should initially include the following analyses, which can be adjusted based upon operating experience.

• Average alarm rate • Chattering alarms (>5/minute) • Stale alarms (>24 hours) • Duplicate alarms • Consequential alarms • Alarms disabled/enabled • Controller mode changes • Controller setpoint changes • Controller output changes

6.4 Monthly Key Performance Indicators (KPIs)

The following table shows the alarm system Key Performance Indicators (KPIs) for long term monitoring (on the basis of a single operator console).

Table 6 – Key Performance Indicators

Key Performance Indicator (KPI) Monthly Target

Long Term Alarm Rate 0 days exceeding 288 alarms/day Peak Alarm Rate (defined as the number of alarms for 10 minute time frame)

0 10-minute slices exceeding 20 alarms/ 10 minutes

Inhibited/Disabled Alarms < 30 (Unless as part of defined Shelving or State-based Strategy)

Chattering Alarms (defined as alarms that are repeated 5 or more times per minute)

0

Stale alarms (defined as an alarm that remains in alarm condition for more than 24 hours).

0

7 Application of Design Guidelines

This section is provided to give examples of application of the design guidelines. Practical examples serve to enhance the understanding of the guidelines and provide ready made solutions that are applicable to a large number of alarms.

7.1 Alarm Priority Assignment

Page 15: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 15 of 18

7.1.1 In all cases, a documented consequence detrimental with regard to safety, environment, equipment damage, or other cost shall constitute justification for every alarm (as described in section 4).

7.1.2 "Return to Normal" alarms should be set to Journal priority. Alarms are to alert the operator when his action is required, not when conditions return to normal. However, return to normal can be important to identify in journals after an incident.

7.1.3 "Bad I/O" alarms should be set to Low priority (or High if the loop has any Emergency priority alarm). This is an abnormal situation that requires operator response, but time duration is unknown.

7.1.4 Actions by Operator (e.g., switch of loop to "Calibration" mode for work by the instrument tech) should be set to Journal priority. Many operator actions are journaled automatically by the DCS.

7.1.5 Deviation from setpoint alarms are especially useful for those control loops where the setpoint is frequently moved.

7.1.6 Rate of Change alarms should be used sparingly.

Table 7.1 – Alarms and Priority Values

Alarm Default Priority Value (and exceptions) "Bad PV" alarms (any alarm that indicates an inaccurate or unavailable PV)

Low (or High if the loop has any Emergency priority alarm)

Output Open, (any alarm that indicates an inaccurate or unavailable output signal)

Low (or High if the loop has any Emergency priority alarm)

Analog Output exceeds absolute limit No Alarm

Rate of change alarms on PV and Output No Alarm

Deviation alarms on analog control loops No Alarm Command-Disagree Journal (or Low if there is a significant time

delay before alarm, such as 60-sec time delay for MOV to open) [The faceplate shows the status as operator performs action]

Actions by console operator (e.g., switch of loop to "Calibration" mode for work by the instrument tech)

Journal [the operator performs the action; no need to alert him]

"Return to Normal" No Alarm []

7.2 Alarm Type Configuration Guidelines

7.2.1 For inputs: to avoid redundant alarms, BAD I/O alarm should only be configured on the raw input point.

Page 16: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 16 of 18

7.2.2 For control loops: process alarm should be set on the controller point, not on the "raw" point.

7.2.3 If multiple "raw" points are being used as input to a function block then process alarms must be set on the raw points, and not on the composite point.

7.3 Grouped Alarms

Where Grouped Alarms are used, the individual tags in alarm will be displayed with their alarm indications shown on process graphics, but they will not appear on the Alarm Summary display. The Group Alarm for the group will appear on the Alarm Summary display.

A good example is a compressor. All high vibration, high displacement, and low displacement alarms will be combined into a single, priority 2 Common Alarm that will alert the operator that a high vibration exists on the compressor. Each individual alarm will be Journal priority, so that the operator does not get all the individual alarms. Upon receiving the Grouped Alarm, the operator will immediately look at the compressor display to see which alarm activated it. There will be one Grouped Alarm for the high vibration and a separate common for the high-high (set at Emergency priority ). The process display graphic must indicate the proper color code for the individual alarm (Emergency or High priority).

Since there may be instrument problems that make vibration instrument(s) inoperable, it is important that an alarm shelving function work properly for each individual loop. If a Grouped Alarm for high vibration is activated by any one of 15 different instruments, the operator must be able to use his alarm shelving function on any of the 15 (making it unable to activate the common alarm), while the other 14 individual alarm points can still activate the common in the normal fashion.

7.4 Emergency Shutdown Alarms

The following are suggested approaches:

ESD Bypass:

An ESD bypass performed by the console operator will be assigned Journal priority. An ESD bypass performed remotely by a different operator will be raise an alarm (Low priority since no console operator action is required).

Page 17: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 17 of 18

ESD Pull buttons:

Hard wired ESD pull buttons are provided for the most critical shutdowns that the operator may be required to exercise. These will be set to be recorded in the journal without alerting the operator since the operator initiates the action. The resets for these pull buttons will cause the pull button alarm to return to normal. Reset of ESD pull button is not alarmed, but merely recorded as an operator action.

Local (field) EIV or local ESD pull button will be alarmed to the console operator since he must be informed of this important change of status performed by the outside operator.

Testing-in-progress (e.g., 40% closed on EIV) will be Journal priority since the console operator pre-approves the testing, the test is not an abnormal condition, and the test does not require his action.

Status switches (opened & closed) are in ESD SOE, but not DCS.

7.5 Operator Actions

Console operator actions (e.g., "soft" bypass activation) should be configured with Journal alarm priority only and should not generate audible alarms.

Status changes of hand switches are journaled as operator actions by the DCS. No additional alarms are needed. Manual loader (hand controller) adjustments likewise are already recorded as operator actions.

7.6 Equipment Status and Auto Start/Stop

Equipment status shall be given Journal priority. Resultant changes to process conditions will be evident from temperatures, pressures, flows, etc.

Switches used to automatically start or stop equipment shall be Journal priority when the automatic action is not abnormal (e.g., a pump automatically started/ stopped based upon knockout drum level.

8 Advanced Alarm Applications

A significant reduction in the long-term alarm rate should be observed with the new alarm settings, and alarm priority re-configurations. However, excessive peak-alarm rate and standing alarm problems may require advanced alarm applications, which have the ability to change the alarm settings in real-time depending on the operational states of the equipment. Advanced alarm applications are required for plant-state alarms, nuisance alarms and operator alerts.

Page 18: SAER-5895

Document Responsibility: Process & Control Systems Dept. SAER-5895 Issue Date: 30 September 2003 Alarm Management Guideline Next Planned Update: 1 October 2008 for Process Automation Systems

Page 18 of 18

The plant-state applications can further reduce the number of standing alarms, as well as the peak-alarm rate, by adjusting the process alarm settings and alarm priorities in real-time, depending on the operational states of the equipment. For example, alarms around a boiler may have different settings depending upon the state of the boiler (off, purging, low fire, normal operation). In some cases it is possible to automatically detect the various plant states; such as a boiler beginning a purge cycle. In other cases, the operator may need to inform the control system when a plant state changes; such as a changed feed composition.

The nuisance alarm applications facilitate the removal and maintenance of the bad actors, by providing a centrally located interface for the operator to remove nuisance alarms in a timely manner, and for maintenance personnel to obtain a quick daily overview of the bad actors so that they can schedule them for repair in a timely manner.

The operator alert applications provide a user-friendly tool to monitor and alert the operator when any of his process parameters violate any of the pre-configured limits. This can further reduce the long-term alarm rate, as it allows disabling numerous process alarm points currently configured in Low alarm priority for the purpose of "alerting" the operator of pending abnormal situations.

Revision Summary 30 September 2003 New Saudi Aramco Engineering Report.