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 2 3 4 5 6 7 8 Objective........................................................ 2 Introduction.................................................... 2 Definitions...................................................... 2 Alarm Design................................................. 5 Management of Change............................... 12 Alarm System Performance Analysis and Monitoring at Operating Facilities......... 12 Application of Design Guidelines................. 14 Advanced Alarm Applications...................... 17

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

Page 1 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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. b. c. Require an operator action. Provide sufficient time for operator action. 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: PV: 3.2 Maximum Response Time Process Variable

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 2 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

• • •

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 3 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 4 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

• • •

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 5 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 High Low

5% 15% 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 6 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

Table 1 – Example Risk Matrix
Severity of Consequence Impact Personnel Public or Environment Minor None Minimal exposure. No impact. Does not cross fence line. Contained release. Little, if any, clean up. Source eliminated. Major Lost time injury Exposed to hazards that may cause injury. Hospitalizations and medical first aid possible. Damage Claims. Severe Life Threatening 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. Results in loss of entire unit or critical equipment for more than 15 days Event costing >1MM$

Plant/Equipment

Equipment damages that result in negligible unit downtime. Event costing <10M$

Results in unit downtime up to 15 days, some to severe equipment damage. Event costing 10M$-1MM$

Costs/Production

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 7 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 Response Time > 30 Minutes 10 to 30 minutes 3 to 10 minutes < 3 minutes Severity of Consequence Minor No Alarm No Alarm Low High Major No Alarm Low High Emergency Severe No Alarm High High 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 8 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 Flow Level Pressure Temperature Delay Time (Digital) 2 sec 2 sec 1 sec 0 sec Dead Band (Analog) 5% 5% 2% 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 9 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 Emergency High Low Unacknowledged Red – blinking Orange – blinking Yellow – blinking Acknowledged Red – solid Orange – solid 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 10 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 11 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

• • •

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 12 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

Analyze configuration metrics:
Analysis Type Configuration Info Metric 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) Frequency distribution of configured alarms Target <1.00

Configuration Info

Emergency: at or below 5% High: at or below 15% Low: at or above 80% <288 / day <20 / 10 min <10 at any time <30 at any time 0 0

Dynamic Alarms Dynamic Alarms Dynamic Alarms Dynamic Alarms Dynamic Alarms Dynamic Alarms Dynamic Alarms Dynamic Alarms

Long term average alarms/ day Peak alarms/ 10 min Standing alarms Disabled (shelved) alarms Chattering alarms (activated 5 times or more per minute) Stale alarms (in alarm state longer than 24 hours) Risk time – long term 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 13 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

(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. • • • • • • • • • 6.4 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

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) Long Term Alarm Rate Peak Alarm Rate (defined as the number of alarms for 10 minute time frame) Inhibited/Disabled Alarms Chattering Alarms (defined as alarms that are repeated 5 or more times per minute) Stale alarms (defined as an alarm that remains in alarm condition for more than 24 hours). Monthly Target 0 days exceeding 288 alarms/day 0 10-minute slices exceeding 20 alarms/ 10 minutes < 30 (Unless as part of defined Shelving or State-based Strategy) 0 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 14 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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). "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. "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. 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. Deviation from setpoint alarms are especially useful for those control loops where the setpoint is frequently moved. Rate of Change alarms should be used sparingly. Table 7.1 – Alarms and Priority Values

7.1.2

7.1.3

7.1.4

7.1.5 7.1.6

Alarm "Bad PV" alarms (any alarm that indicates an inaccurate or unavailable PV) Output Open, (any alarm that indicates an inaccurate or unavailable output signal) Analog Output exceeds absolute limit Rate of change alarms on PV and Output Deviation alarms on analog control loops Command-Disagree

Default Priority Value (and exceptions) Low (or High if the loop has any Emergency priority alarm) Low (or High if the loop has any Emergency priority alarm) No Alarm No Alarm No Alarm 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] Journal [the operator performs the action; no need to alert him] No Alarm []

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

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 15 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

7.2.2 7.2.3

For control loops: process alarm should be set on the controller point, not on the "raw" point. 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 16 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 17 of 18

Document Responsibility: Process & Control Systems Dept. Issue Date: 30 September 2003 Next Planned Update: 1 October 2008

SAER-5895 Alarm Management Guideline for Process Automation Systems

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 realtime, 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 New Saudi Aramco Engineering Report.

30 September 2003

Page 18 of 18