Part 2: Implementation of Alarm Management at Grangemouth Refinery
Donald Campbell Brown and Manus O’Donnell
This paper reports on the recent BP trial of the ProSys Dynamic Configuration Software at Grangemouth Refinery. Key elements of this project to reduce alarm flooding on the Catalytic Reformer are described, from identification of the problem and process/operation design, through applications design and implement to testing commissioning. The impact of the software is demonstrated, using data captured from real plant trips.
In 1993 the Catalytic Reformer at BP Oil Grangemouth (BPOGRL) started up again after a three-month overhaul. The modifications had included:
- Revamping/replacing the five furnaces and installation of ESD systems.
- Installation of a Burner Management System (BMS), with many of the signals connected to the Distributed Control System (DCS) – a TDC3000 supplied by Honeywell.
- Implementation for the first time of pump auto start functions, on many of the product, fee and steam systems, using sequence programs resident at the primary device level.
- Many modifications elsewhere on the plant to improve the efficiency of distillation columns etc.
All of this work had required modifications to the existing DCS database, resulting in a two-fold expansion in size. Alarm settings and priorities for the new DCS tags were determined by the commissioning team.
During the following two years of operation, as the console operator built up his familiarization with the latest revision of DCS hardware/software and the new plant equipment, there were several shutdowns on the Cat Reformer unit. On these occasions the console operator was forced to deal with large "floods" of DCS alarms.
In 1995, an Alarm Review team challenged the existing alarm settings and priorities, and changes were made to reduce the potential number of alarms. A study of intelligent alarm management was conducted, and a proposal to implement this via Bespoke software in the DCS was submitted as part of BP's Site Engineering Modification Procedure (known as the PMP). The result was a strong recommendation against the proposal; BP wanted Alarm Management in a generic "off the shelf" package that was easy to implement through "open" configuration.
In early 1996, the engineering support group at BP Sunbury organized a presentation of Alarm Management Software by ProSys Inc. (based in Louisiana, USA). Interest was focused on the Dynamic Configuration Software, which allowed alarm parameters to be switched automatically according to the plant operating 'case'. A pilot exercise was kicked off to try out the software on the Cat Reformer, specifically to deal with the “Feed and Fires" trip scenario.
Design Study Phase
A team of five, consisting of Plant Operations, Process Engineer, Support Engineer, Control Consultant and Systems Engineer, was formed to produce a paper design of the proposed configuration, prior to implementation. This exercise involved deciding how many 'cases' (plant operating states) were required, what each case was, and the criteria required to recognize a change of case. In our '"pilot" implementation we decided to concentrate on the Cat Reformer “Heaters and Fires" trips so we settled for three cases:
Default (where current case cannot be determined)
All intelligently enabled
We then considered what points to include in the software, allocating them to a process section e.g. Feed section, Heaters, Debutanizer and associated Cryogenic Hydrogen Purification Unit.
The total number of points to be included in the application was 80, out of some 700 points in the entire database. This was only a small-scale application, as the intention of the pilot exercise was to evaluate the ProSys software. If the outcome was favorable, it would then be extended to cover the remaining sections of the Cat Reformer.
Alarm and Master selector blocks were then allocated for each section of the process. The detection criteria for case change was coded into logic blocks and validation of inputs was also considered. Finally, the Alarm Management software was built in simulation mode using dummy points so that testing could be done off-line.
Technical Review Phase
Our proposed configuration of the Alarm Management software was then subjected to Technical Review by the Central Engineering group at BPOGRL as part of the Plant Modification Procedure (PMP). This technical review highlighted a number of issues:
- The requirement to have a minimum of three separate inputs per case selection logic block. This meant a rework for the start-up logic on the cryogenic section.
- The need for records to be filled on all training carried out, mechanisms for refresher training, contact with other users of the software and a statement of the supplier’s policy on product quality.
- The need for a facility to allow the operator to set all points to ENABLE in the event of a failure of the software processor (a Honeywell Application Module), which could potentially leave the software ‘stuck’ in Case 3 (Shutdown and DISABLE). A brief study revealed that the Application Module was in fact the most reliable node on the Local Control Network (LCN), and that since 1992 there had not been a single failure. However, the issue was finally closed by a solution under with the operator could trigger a program resident in a second Application Module (in the event of primary Application Module failure). This would automatically reset all the appoints to the ENABLE state.
Approval was given by the PMP Committee for the installation of the Alarm Management Software, but with a recommendation that a Hazard Assessment be carried out of the scope and functional design before commissioning.
As a result, an 'Alarm Management Hazard Assessment' (AMHAZ) team was brought together, comprising a senior Cat Reformer specialist from BP’s technical support unit in Sunbury and process/operations personnel from BPOGRL. This team reviewed the list of alarms to be suppressed, together with the configured logic. The AMHAZ team recommended that the Debutanizer section should have separate start-up logic and gave advice to the form should take. The AMHAZ team also defined a generic methodology for configuring future applications of Alarm Management, and this document is now part of the Process Systems Branch procedures at BPOGRL.
Test and Implementation Phase
A program of Site Acceptance Tests (SAT) started after changes had been made to the Alarm Management software in accordance with the recommendations from the AMHAZ report. The SAT team consisted of a Systems Engineer, a Process Engineer and a Senior Operator from the Cat Reformer. The software was tested very thoroughly in simulation mode using dummy points.
The process graphics on the DCS were modified for the Cat Reformer and associated Cryogenic unit, with new subpictures to indicate to the operator when a point was disabled, whether or not in alarm. An operator overview graphic was built to show the current state of the Alarm Management package, with help pages explaining the logic used.
Training was given to all control room operators for the Cat Reformer console, together with the shift supervisors. This training made extensive use of the Alarm Management package configured in “simulation mode”", to demonstrate to the operators the validation, logic, master selector blocks, alarm blocks and functionality of case switching.
Finally, the Alarm Management was switched from simulation m ode to live mode on Dec 3rd 1996.
A number of lessons have emerged from the Project:
- The ProSys package is easy to configure using generic engineering displays. The configuration is “open” with minimal programming code required for validation of input signals only. The packaged performed faultlessly throughout the acceptance tests.
- There was (and continues to be) substantial operator support md enthusiasm for this type of application throughout design, testing and implementation.
- Do not underestimate the effort required by the production asset, to determine which alarms may be suppressed, and under which circumstances.
- Alarm Management is an iterative process. It does not stop when the application is turned on the first time. When incidents occur, extract the historical data and analyze how the package responded to the events. Did it do what you intended? Was the design intent correct? Can it be improved?
- Consideration should be given to methods/mechanisms that store real time and system journals. At BPOGRL we use an IMAC™ database system to record our Real Time journal. The IMAC™ database is archived to optical disk each day and it is relatively easy to pull the data into Excel for analysis. However, the Real Time journal does not record the transitions of points which are DISABLED. The Honeywell DCS treats alarms in this state in a different manner, putting them into a system journal which has a limited buffer. If data is not downloaded from this buffer quickly, it gets overwritten. BPOGRL is currently looking to improve the mechanisms for capturing the Honeywell DCS systems journal for analysis.
Analysis of Real Plant Data
There have been four incidents since the Alarm Management software was commissioned. None of the incidents was a Cat Reformer "Feed and Fires" trip, yet at each incident the Alarm Management software activated a switch to CASE3 because the sequence of events led down this “logic path”.
Extracting a clean and complete System Journal file on each occasion has not been possible, therefore making analysis of the event rather crude. However, it is possible to observe that in the first incident the Dynamic Configuration Software reduced the potential number of alarms by 18%. On that occasion some 600 alarms were generated the reduction was 23.5% of total number of alarms.
I would like to thank John Davis at BP Oil for the support he has given me in analyzing the performance of the software and providing material for this paper.
Alarm Module AM
Configuration Module CM
Special Alarm Management SAM
Marathon Oil Company
*Scheduled for 1998 evaluation/installation, ** Multiple installations per site