Alarm Management - Alarms, Inhibit and Overrides

• Explore and identify control system alarms

• Ensure expected alarm load is manageable for the CROs
• Mitigate alarm flooding and nuisance alarms
• Understand how alarm management can be improved

• Identify all control system or control devices requiring bypass or

setting changes for topsides.
• Walk through process start up to identify control system status
and expected operating parameters to determine bypass
requirements.
• Assess risk of the bypasses and mitigations to ensure safe
operating process variables are maintained.
ICSS Architecture
One Team. One Home. One Destiny.

• The ICSS controls all process

information level / pressure /
temperatures as well as one / off
signals
• Package interfaces are extended
to the CCR via the KVM
network
• Colour coded alarm events is
displayed in panels on the
WinCC HMI
• The system interfaces with the
MCS via the OPC network
Alarm + Trip List
One Team. One Home. One Destiny.

• Class A Document Must be Maintained

to As Built Revision

• Although working copy typically used

• Testing 3 levels applied

• loop check Instrument Test Result B

check on setting

• cause and effect test OTP for alarms

• ICSS OTP with punch-listing of

• SIF loop additional requirement s

MoC – SCR
One Team. One Home. One Destiny.
Alarm Prioritization Philosophy: Goals

• Review alarm prioritization for subsea and topsides

• Understand classification of Priority 1 / High alarms

• Understand the criticality of P1/H alarms

• Examples of each level of priority

Alarm Prioritization
One Team. One Home. One Destiny.

For ICSS

• Low – System Priority (visible to ICSS only)

• Medium Priority – Warning (Yellow)

• High Priority – Trip/Alarm (Red)

Packages

• Package audible alarm only

Alarm Prioritization
One Team. One Home. One Destiny.
 Alarm Frequency Reduction Techniques
One Team. One Home. One Destiny.

• From the Philosophy Doc • From the ICSS GTS

• Note that these Default values are to be seen as a guideline and must be optimized on
start up for the applications
Automatic Alarm Hiding
One Team. One Home. One Destiny.

• Use of dynamic suppression techniques via the

Siemens state rep block – use of logic – example
from a pump where alarms are taken out if it is
stopped.

• This enables significant reduction in standing and

flooding alarms

• Extension beyond the prime function (pump PSLL

auto OOS) - A complete list of all “Low” and “Low-
Low” Alarms has to be evaluated to determine
possibility / desirability of Hiding when the
Equipment / System is offline or closed

• Still ongoing on destiny

Liza Objective  - Automatic Alarm Suppression
One Team. One Home. One Destiny.

• Implementation of Siemens StateRep Block

• (Note Block Groups with same name)

Destiny State Rep Application Example
One Team. One Home. One Destiny.
• If all 3 x riser valves closed then test separator offline and alarms for pressure, flow are suppressed / hidden

• ‘System example’ as opposed to simple equipment (pump offline etc…)

KPI Target & Alarm Collector
One Team. One Home. One Destiny.

• Internal Target is 2 alarms/operator / 10 minutes

• EEMUA 1/5 mins manageable and 1/10 mins very likely to

be acceptable.

• From the philosophy section 10.1“The rate of new alarms

….. should be limited at a frequency of less than 12 alarms
per hour per operator”

• Based on 2 operators on FGS / Topsides and 1 Cargo / 1

AMS

• Tracking via reports from web based alarm collector

“Honeywell Dynamo Metrics R200.1 ” with preconfigured
reports formatted by per area, type, period
 Jan-21

Report Example (Destiny)

One Team. One Home. One Destiny.
Alarm Working Instruction
One Team. One Home. One Destiny.

• Under the responsibility of the OIM

• Weekly basis top 10 or 20 worst performers are addressed and responsible parties identified
for follow up via

• Weekly Meeting – involving all HOD

• Defined Action Tracker Shared with Onshore

• Monthly KPI Reporting for Business Review

 Override Type and Permissions
One Team. One Home. One Destiny.

Definitions as per the Software Functional Block GTS PECEICPF550003 v9

• MOS (maintenance override switch) –

• requires Safety System Isolation Certificate (SSIC) or written permission from the OIM prior to application

• Can be applied at any time with no time out (no timer)

• Auto MOS is applied on FGS in case of IO failure (dirty optics ) – however with the new voter philosophy from ABS the
MOS is now counted as a trip so is being phased out.

• Authorization is by engineering key (physical switch, one per area, under OIM control) enables MOS application for 3
minutes.

• Note for SIF functions no bypass permitted

• SIF MOS Key exists however has been removed

• Simulations are the only way to work on SIF functions

 Override Type and Permissions
One Team. One Home. One Destiny.

• OOS (operator override switch) - intent is for equipment trip start up override applied by the operator.

• Enhanced OOS functionality ensures that the OOS

• is automatically removed on running equipment after the settling time

• is can only be applied to offline equipment.

• Auto OOS functionality enables the OOS to be applied by logic and maintained indefinitely until the trip signal clears. The
advantage is therefore to reduce the risk of trip during the start up preparation. Provided the logic does not introduce
inherent risk this is the preferred design option.

• Authorization by login for area CRO.

• Simulation – IO driver (interface between the PLC and the physical signal) set to a simulated condition.

• Only performed under SSIC by ICSS specialist from the engineering station.

• On - line logic change on the IO driver (no download required).

 New Voting System
One Team. One Home. One Destiny.

• NEW VOTING CONFIGURATIONS

The current strategy is based on a benchmark against major international oil companies’ standards, SBM internal workshops,
and the requirements of the Brazilian regulator, ANP.

The intent is to make SBM’s fire and gas voting more robust, that is improving both availability and reliability.

The principal modifications:

• Different treatment of (non fatal) diagnostic faults and (fatal) I/O or transmitter faults
• Removal of the AUTO MOS concept
• Change voting degradation to be 2ooN -> 1oo(N-1) for I/O Failure or bypass (MOS)
• Voting does not degrade for detectors (still working) with diagnostic alarms
• In case of full voting in I/O Failure, initiate the executive action relative to this Voting (ESD, Electrical isolation, PAGA.).

• Voting logic
• Gas / Flame / Smoke / Heat
• 2ooN in normal operation
• As detectors become faulty or are put into MOS: Voter degrades 2ooN -> 1ooN -> no
• confirmed fire.
MOS inhibit
One Team. One Home. One Destiny.

MOS inhibit Logic

• If the application of MOS to F&G voting would create a trip, then the MOS shall be
inhibited
• by logic to prevent CRO operation error.
• Note: The MOS inhibit logic does not interfere or interrupt with the voter logic trip path.
• The MOS inhibit logic only obtains the voting block trip and MOS inputs to determine the
• MOS inhibit for each detector.
Disable MOS
One Team. One Home. One Destiny.

• Disable MOS:
If a detector is tripped then disable MOS to all other not tripped.
This will prevent an unwanted trip due to operation errors (voter will degrade to from 2ooN to 1ooN when MOS=>1
or FAULT=>1).
 Trip to Fail Logic
One Team. One Home. One Destiny.

Trip to Fail Logic

• TTF (Trip to Fail)

The voter output is set to the trip state if some or all detectors are in an IO Fail state, this is the Trip To Fail
logic.

• In case of partial or full voting loss due to I/O Failure then the voter output OUT is deenergized if No_TTF
(the number of detectors that are failed AND not in MOS) >= TTF_LIMIT. A delay timer can be set at
TTF_DELAY (default=0sec). If input TTF_EN is false then the Trip to Fail is disabled.

• MOS
A failed detector that is MOS’d will be removed from the TTF count No_TTF.

Example 1 voting 2oo7:

TTF_LIM=4
5 detectors are failed, 1 of these 5 is MOS’d.
Action: voter TRIP because 4 non-MOS'd detectors are failed (No_TTF >= TTF_ LIMIT).
Older Library Versions
One Team. One Home. One Destiny.

Library V3.5 and older

• 2ooN in normal operation
• As detectors become faulty (automatic MOS applied) or are put into MOS:
Voter degrades 2oo6 -> 2oo5 -> 2oo4 -> 2oo3 -> 2oo2 -> 1oo1 -> no confirmed f
ire/gas

• Library V3.6
• 2ooN in normal operation
• As detectors become faulty (automatic MOS applied) or are put into MOS:
Voter degrades 2oo6 -> 2oo5 -> 2oo4 -> 2oo3 -> 1oo2 -> 1oo1 -> no confirmed
fire/gas
MOS Trip
One Team. One Home. One Destiny.

• MOS will degrade the Voting Groups, it can trigger the C&E action, therefore only perform the MOS
and work in the instrument if you are sure of the consequences.

• In any doubt case, check with CRO/ICSS what will be the consequences of working on this instrument,
and if it will be safe to work, therefore no unwanted C&E action will be triggered.

• In past, several trips and PSD was caused by simple misunderstandment on working on the wrong
instrument, or applying the wrong MOS.

• Communication and understanding how it works is key in order to safe work environment.

• Take in consideration that different SBM units has still different MOS functionality.

• BR units and Guyana are similars, but Angolan are still using the old voting system for FGS. From the
ICSS Library version it´s possible to identify how it works on each unit.
Simulation / OOS / MOS Displays • Summary Lists
One Team. One Home. One Destiny.

• Simulation

• OOS

• MOS