IADC/SPE 151182

Blowout Preventer (BOP) Health Monitoring

Jim McKay (BP), Clayton Simmons (National Oilwell Varco), Tony Hogg (Ensco), Gavin Starling (Rock Oilfield
Group), Mike Doty (National Oilwell Varco), Allen Pere (BP)

Copyright 2012, IADC/SPE Drilling Conference and Exhibition

This paper was prepared for presentation at the 2012 IADC/SPE Drilling Conference and Exhibition held in San Diego, California, USA, 6–8 March 2012.

This paper was selected for presentation by an IADC/SPE program committee following review of information contained in an abstract submitted by the author(s). Contents of the paper have not
been reviewed by the International Association of Drilling Contractors or the Society of Petroleum Engineers and are subject to correction by the author(s). The material does not necessarily
reflect any position of the International Association of Drilling Contractors or the Society of Petroleum Engineers, its officers, or members. Electronic reproduction, distribution, or storage of any
part of this paper without the written consent of the International Association of Drilling Contractors or the Society of Petroleum Engineers is prohibited. Permission to reproduce in print is
restricted to an abstract of not more than 300 words; illustrations may not be copied. The abstract must contain conspicuous acknowledgment of IADC/SPE copyright.

Abstract
As every motorist knows, a vehicle’s dashboard is an important interface that alerts the driver of real-time changes regarding
certain car engine “health” metrics and alerts the driver that the engine may need to be serviced. While not a diagnostic tool
in and of itself, the dashboard serves to alert the driver that a performance or health issue may exist. Blowout Preventer
(BOP) equipment is designed to secure the well and a BOP’s health is critical to ensuring that it works as designed. A real-
time BOP dashboard can improve communication between operations personnel, rig contractor subsea engineers and the
Original Equipment Manufacturer (OEM) to assess potential BOP health issues.

This paper describes a development process for a BOP dashboard and discusses the potential benefits, challenges, and lessons
learned associated with implementing a BOP monitoring system.

Background
Traditional multiplex (MUX) BOP control system diagnostics (see Figure 1) are designed by OEMs for use by personnel
proficient in BOP control systems such as a rig contractor’s subsea engineer. Control system diagnostics are generally
geared more toward maintenance and troubleshooting system problems than toward operational decision making.
Traditionally the BOP diagnostic data is solely available at the rig based Engineering Work Station (EWS), also known as the
event logger. Historically BOP data is not exchanged to shore from the offshore event logger. The industry could benefit
from having BOP control system integrity or BOP health, presented in a manner that allows operations people (offshore and
onshore) to participate in communication with BOP experts to assess any risk associated with the BOP and the BOP control
system.

The Concept
The BOP dashboard (see Figure 2) aims to simplify complex BOP diagnostics in an easy to understand format that facilitates
a joint assessment of the issue. In early 2011 BP, Ensco, and Nation Oilwell Varco (NOV) collaborated on a project to
consider preliminary development of a BOP dashboard that takes existing alarms, analog data, and events from the BOP
EWS and translates them into a high level traffic light status. The traffic light logic is based on levels of system redundancy
that allow the user to understand when critical functions are impaired.

The first phase of the project focuses on the electrical components (see Figure 3) of the control system with further extension
to the hydraulic components (see Figure 4) in the subsequent phases of the project. Although the initial dashboard would rely
solely on the eHawk platform, the end product could be a BOP monitoring dashboard incorporated into a mud logging
network. When integrated with the common mud logging database the BOP data could be interconnected with other real
time well construction systems such as Digital BOP pressure testing technology. If a BOP health issue should arise, the
OEM / NOV eHawk web platform can provide additional layers of detail beyond the dashboard. These additional layers
should provide the user the same screens that are already available in the offshore BOP diagnostic system. Such a system can
also be designed to allow near real-time archiving of raw BOP data on an onshore computer and can produce a BOP health
report.
2 IADC/SPE 151182

Although this system is not designed for, or intended to be used for continuous monitoring, the end-user can view the
dashboard at anytime, and reports summarizing alarm and event information can be sent automatically to select users. Thus,
this system could be a useful tool for well site leaders (WSL, aka company man), offshore installation managers (OIMs), or
shore based operations teams. For example, operations teams could use this system to review applicable BOP health
attributes prior to each daily rig call.

Software and hardware development and installation

In this project, the EWS must be configured to allow for data export to the eHawk server. Although historically sql data was
used, NOV determined that the interoperability standard for automation (OPC) provided advantages for configuration. OPC
has the ability to queue data and to push an initial state for BOP positions and outstanding alarms. This is important when
data transfer is lost or upon initial installation of the BOP monitoring system. OPC simplified the configuration by not
requiring manual entry of outstanding alarms and initial positions into the eHawk database.

A simplified system diagram shows the connection between the EWS, the eHawk server, and the relevant Sitecomm server
(see figure 4).

For the installation NOV had to update the OEM drawings to show the new connection from the EWS and the eHawk server.
The BOP control system had to be recertified from American Bureau of Shipping (ABS) to reflect this change.

“Traffic Light” Development

The OEM holds the unique system knowledge required for traffic light logic development. For example, the OEM can
provide guidance on the meaning of alarms and system redundancy. The operator and rig contractor can define the levels of
risk that would be associated with each level of traffic light. Originally three automated tiers of colors were envisioned to
provide the health status of the BOP. “Red” status would mean no functionality, “yellow” status would mean functional but
no redundancy, and “green” status would be fully functional and with redundancy. As the BOP owner, the rig contractor
may wish to retain the ability to manually change the traffic light severity due to the potential for false positive or false
negative traffic lights. For example, it is possible that due to interdependencies between alarms, a minor alarm could also
trigger a more severe alarm. In those instances the dashboard traffic lights can be manually changed from a more severe
status to a less severe status. The manual override can be done for a specific alarm and the related traffic lights will be
identified by an “F” indicating the traffic light was “forced” to a more or less severe status. To manually force or clear any
alarm, the user is forced to enter a description that details the reason for the force. In addition to a management of change
(MOC) process, this information allows for future review and oversight. The forcing of alarms, not traffic lights, allows
subsequent alarms to change a traffic light status with an “F” to an increased severity level. In addition the user can scroll
over a traffic light to view the outstanding alarms and to identify those alarms that were forced.

Different parts of the control system may have different levels of redundancy. In this project, at a minimum, redundancy for
a specific BOP function is required for the traffic light to be green. An example of redundancy is the use of dual pods
(yellow and blue). An example of dual redundancy would be the communications to the pods. Each pod receives redundant
communications and the pods themselves are redundant, hence each pod receives a spare communication link to the surface
control system. For the BOP system, if the component is shared by the pod then redundancy is required. If the component is
specific to the pod then redundancy is not required.

The current traffic light logic development used in this project omitted alarms related to the hydraulic system data (Phase II)
or minor alarms (e.g. stuck push button alarms).

Dashboard GUI Development

When developing the Graphical User Interface (GUI) for the dashboard the target users were assumed to include both
experienced subsea engineers and also those on an operations team with only a rudimentary knowledge of the BOP control
system.

Starting in the top left of the dashboard and working to the bottom right, the following design requirements were built in the
dashboard for this project.
− Top Left - the last test date for auditing purposes will be manually entered and recorded.
− Upper Left - leaks and hydraulic issues will be detected with logic (Phase II development) and reported with a traffic
light status.
− Lower Left - “emergency systems” status will be based on the solenoid valve health.
− Bottom Left - “event log data” will capture raw commands in a table with volumes, times for the activation and the
location of the command.
IADC/SPE 151182 3

− Bottom Left - “outstanding alarms” will capture raw alarm data, the time of the first alarm, the number of alarms
counts in the last 24 hours, time of the last alarm acknowledgement, and location of the last alarm acknowledgement
− Bottom Left - “MUX fiber” will report multiplex fiber health based on existing alarms
− Bottom Left - “Surface Alarms” and “Subsea Alarms” will report all alarms and sort them based on the location of the
equipment. This will allow the user to understand if the BOP stack should be pulled in the event of a yellow health
status on a specific BOP function. These are envisioned as all inclusive alarm traffic lights regardless of redundancy
or alarm severity. This will also allow the user to understand if a minor alarm has been triggered.
− Middle Left - “Read back Pressures” will report the analog pressure for each specific function closing pressure. For
example, this will allow the user to understand if the closing pressure was increased to obtain a seal.
− Middle - “BOP function health” separated by yellow and blue pods. Each major BOP function will have a displayed
traffic light health indicator for each pod. The active pod will be indicated by a traffic light that is 50% larger than the
non-active pod.
− Middle - “BOP positions” will be viewable by colored circles and blocks that animate physical position of the rams,
annulars and subsea BOP valves.
− Right - “Chronology Log” will display the positions and the overall health of the system over a 24 hr period. If the
user is not constantly monitoring the BOP dashboard then they can look back at a high level to understand if the BOP
was functioned or if there was a BOP health issue.

Monitoring & Decision Making

The real time BOP dashboard will only be used as a communication tool by facilitating conversation between operations
teams on BOP health issues. The primary diagnostic system will remain the original rig based OEM EWS. The workflow
process (see Figure 5) requires that the EWS be used to confirm the dashboard before making any decisions. (Note: One item
that the project considered in the workflow process was the need to avoid uncontrolled distribution of data to individuals that
may not fully understand the significance of various alarms. Not all alarms are equally important and this distinction must be
addressed when working with the dashboard.)

Part of the pilot intent is to develop a decision tree protocol (see Figure 6) where operations teams can make standard
operation decisions. This will help eliminate the potential for subjective BOP health resolutions. Ideally all BOP health
scenarios would be mapped with a decision tree, however it is more realistic to assume that some alarms will not fully reflect
the true health of the BOP. Once an alarm is triggered, the rig crew will need to confirm the BOP health issue by trouble
shooting the issue. For example, if a MUX fiber signal triggers an alarm indicating fiber degradation the crew will be able to
perform a decibel loss test to confirm the issue.

For this version of the console, the decision protocol was set at a high enough level to allow operations teams to determine
both the health status and remedial action. By allowing the user to manually change the health rating to a more or less severe
status, the user can override the automated traffic light logic. In time, as the diagnostic system and traffic light logic is vetted
and accepted by the operations teams, the ability to manually override the BOP health status may be eliminated. For
example, a future operations decision tree could have a defined scenario that requires the BOP to be pulled if a blind shear
ram solenoid valve becomes inoperable.

Pilot Program
The milestones for the pilot program will be: 1) sending alarm and event data back to shore, 2) developing a working
dashboard, and 3) potentially using the dashboard for decision making and learning from that experience.

As stated previously, Phase I of the technology will focus strictly on the MUX electrical system; however, Phase II will
include hydraulic diagnostics.

Digital security processes and hardware are long lead items that require careful planning for the first installation. An
installation plan cannot be finalized until rig surveys are complete. The monitoring system can only be installed between
wells when the BOP is on surface.

The major challenge and learning in this pilot program will be when the rig contractor and operator disagree on the BOP
health status or the proposed remedial action of a BOP health issue. As this technology is adopted, it is anticipated that these
situations will be addressed through agreed upon policies and procedures or decision trees.

The way forward

The hydraulic system will be addressed in Phase II by creating high level traffic lights for leak detection and pressure vessel
health. Leak detection methods include mix pump cycles, hydraulic fluid usage and flow measurements (see Figure 4). In
4 IADC/SPE 151182

addition each BOP function uses a specific volume that can be measured and compared to a previous baseline for leak
detection.

Advancing the diagnostics with better sensors or algorithms will further develop the BOP dashboard. Ram position sensors,
tool joint position sensors, BOP cameras, and additional BOP wellbore pressures are examples of potential sensor upgrades.
The BOP dashboard data can eventually be integrated with the digital BOP pressure testing. This will allow the rams that
were functioned to be identified for the pressure testing data. Also numerous Key Performance Indicators (KPIs) can be
calculated as more real time data is gathered. For example, the number of cycles on a solenoid valve or the frequency of
successful annular pressure tests can be captured. These KPIs and other collected data might eventually be shared amongst
the industry through existing organizations such as Offshore REliability DAta (OREDA). This collective industry data can
provide more robust fault tree analysis that could potentially provide real time probability of ‘failure on demand’ when
certain functionality is lost.

Drilling Contractor Perspective

As the ‘big crew change’ begins, more and more of the very experienced subsea engineers are transferring to shore based, or
auditor type, positions challenging the industry to develop competent replacements. A well setup dashboard, supported by an
agreed detailed decision tree, will allow these shore based experts to better assist the rig based subsea engineers to diagnose
any problems, to discuss the issues with their client counterparts and to decide the most sensible path forward.

The BOP dashboard will NOT reduce the need for development and training of the rig based subsea engineers. The BOP
dashboard can only report the ‘health’ of the system. It cannot, by itself, do anything to maintain its condition; this has to
come from the allocation of sufficient time and resources, between each well, to properly maintain and test all of the
subsystems.

This equipment can only be maintained and operated to the standards to which it was designed and manufactured (API 16D
2nd Ed.), regardless of the ease of monitoring afforded by the BOP dashboard. Improvements in BOP and BOP control
system designs, by the OEMs, will be important factors in realizing future reliability enhancements.

OEM Perspective
Transferring the most up to date and accurate information back to the OEM allows him to design more reliable equipment as
well as providing the appropriate support to the customer. In the past, this was done over the phone, email, or required travel
to the rig. Using this tool, OEMs can look at BOP information in near real time and better assist in decisions regarding the
safe and proper operation of the equipment.

Summary
In summary a BOP dashboard that simplifies existing diagnostics and allows for remote monitoring of the subsea BOP
control system will improve communication of BOP health. Future deployments of the BOP dashboard could serve as a
common platform across rig fleets that allow standardization of BOP diagnostic data and aids in operational decision making.

Nomenclature
ABS = American Bureau of Shipping
BOP = blowout preventer
EWS = engineering work station, also known as the event logger
GUI = graphical user interface
KPI = key performance indicators
MOC = management of change
MUX = multiplex control system
NOV = Nation Oilwell Varco
OEM = original equipment manufacturer
OIM = offshore installation managers
OPC = Interoperability Standard for Automation
OREDA = Offshore REliability DAta, a joint industry database
WSL = well site leaders, also known as company man
IADC/SPE 151182 5

Figure 1: Existing BOP diagnostics

6 IADC/SPE 151182

Figure 2: BOP dashboard

Read Back
Surface Pressures
Pressure to Kill Boost SPP Choke
Element Health 0 psi 0 psi 0 psi 0 psi
Position Health
Testing:
Active Time History History
Pressure 12/2/2010 Y B POD Kill Choke
Boost 11:00 Zoom
Function 12/2/2010 POD U. Annular
Blue
ROV 12/2/2010
12:00
EDS 11/1/2010
1.5k Upper Annular Vent Vent
*7.5K (10K WP)
Hydraulics:
Leaks? 1.5k Lower Annular 13:00
Stripping Element Open Open
U. Annular
Accumulator *5K (10K WP)
Pressures
14:00
Emergency Systems:
EDS 3.0k PT1
Shear / Blind Ram 15:00
Open Open
AMF/EHBS
3.0k Casing Shear Ram Close
Non Sealing
Auto shear
3.0k Upper (VBR) Ram Open Open 16:00
System Conditions:
PT2
3.0k Middle (VBR) Ram
Event Log Data Open Open
Lower (VBR) 17:00
Outstanding 3.0k Test Ram
Open Open

Alarms
Fiber Comms 3.0k Wellhead Connector Open Open Temp Press
Position Legend
(º F) (psi)
Power Health Legend Open
PT1 100 500
Connectors Fully Functional
Wellhead Close
PT2 102 500

Subsea Electric Health Issue Sea Bed

IADC/SPE 151182 7

Figure 3: Generic Traffic Light Logic - electrical systems

8 IADC/SPE 151182

Figure 4: Generic Traffic Light Logic - hydraulic systems

IADC/SPE 151182 9

Figure 4: High Level IT Network

BP

Mud Logging
Dual
SiteCom
MWD/LWD
and Dweb
Servers

Remote Support
Data Export

NOV eHawk
Copper to Fibre
WWW Convertor

NOV BOP Copper to Fibre

Convertor

eHawk Server

Copper to Fibre
Convertor

DPS
Copper to Fibre
Convertor
DCMS

EWS Drillers PLC

“Firewall” PLC

HPU PLC

PLC A PLC B

BLUE SUBSEA YELLOW

ELECTRONICS SUBSEA
ASSEMBLY ELECTRONICS
ASSEMBLY
10 IADC/SPE 151182

Figure 5: Possible BOP Monitoring Workflow

Note: the actual work flow would depend on contractual provisions and/or procedures to be developed
IADC/SPE 151182 11

Figure 6: Possible Operations Decision Tree for the Pilot

Yes Has Dual Yes Yes

Health Is the Fault and Manually Change the
Redundancy Been Is the Health Issue Pull the BOP at a Risk
Status is Traffic Light Status Emergency System
Lost on a Critical Subsea? Assessed Safe Point
Yellow Correct? Health To “Red”
Function?
F F

No No No

Manually Change Keep Health

the Health from Status at Make Well Safe While
Yellow to Green “Yellow” Fixing the Health Issue

F F

Legend
Dual Redundancy Criteria:
- Two independant methods
Fully Functional, Dual Redundancy of communicating to the Pods
- Ability to activate the
function from each Pod
Fully Functional, Single Redundancy
Not Functional
Short List of Critical Emergency System Functions:
1) Blind Shear Ram
2) Casing Shear Ram
3) Riser Unlatch
4) Riser Latch – Vent
5) EHBS / AMF

F Forced Health Status

(Green, Yellow, or Red)