BOP risk/reliability model gives critical decision support for offshore drilling

Sept. 1, 2012
When a system or component failure is detected, industry's response is to analyze the possible consequences and to assess the risk levels.
Program allows adjustment to reflect actual configuration

Inge A. Alme
Xuhong He
Thomas Black Fylking
Johan Sörman
Scandpower

When a system or component failure is detected, industry's response is to analyze the possible consequences and to assess the risk levels. These risk assessments help to decide whether the risk level is unacceptable and requires the BOP, for instance, to be recovered to the surface; or the fault does not raise risk to that level, and operations can continue.

Deepwater drilling faces complex challenges because:

  • Current risk assessments are not uniform in process, detail, or nature, so "Pull" or "No Pull" BOP decisions are made on inconsistent risk models. This can create a subjective and opaque decision-making process that is unacceptable to senior management or regulatory bodies.
  • BOPs and their control systems are complex. A useful analysis of what failed, why, and the possible consequences can take several weeks to produce.
  • Risk assessments are often done by direct stakeholders which may affect the decision-making and decrease the level of comfort to regulatory bodies.
Example of how the BOP monitor software interface could look. Here all components in the BOP are working.

ModuSpec and Scandpower, both Lloyds Register Group subsidiaries, have teamed to propose a solution – a BOP risk model for deepwater that generates within hours risk-based advice on whether to pull a BOP or to continue operations. This will be done with RiskSpectrum software and models of BOPs currently working in deepwater Gulf of Mexico.

This is a risk management software suite developed by Scandpower and primarily used to assess and manage risk in nuclear power plants, nuclear-powered submarines, and offshore oil and gas platforms. Modeling existing BOPs and their submerged control systems defines in real-time the existing operational risk level, including the possibility for faulty components. Switching on and off "blocks" in the risk model customizes the BOP model to match the specific BOP in question. Response can be expedited by customizing the risk model for any specific BOP ahead of its use.

A solenoid valve in yellow pod for upper annular preventer close fails. The upper annular preventer close function is affected (yellow), but has not failed as indicated by the status of the solenoid in blue pod (green) and the BOP annular preventer function is affected (yellow) in redundancy.

Once the BOP is modeled, risk can be assessed in hours by comparing any available redundancy of the BOP with the regulations to create a basis for the "pull" or "no pull" decision. The definition of "acceptable" and "unacceptable" risk can be decided jointly by industry and government and can be adjusted for different regulatory regimes. The intention is to have a risk model of common deepwater BOPs in the Gulf of Mexico via a joint industry panel.

Here the upper annular preventer is totally out of service (red), the lower annular preventer is working (green), and we see that the defence in depth level has changed for the BOP annular preventer function (yellow).

The BOP model risk assessments would be completed in advance, with required documentation and drawings readily available. Because the risk assessments will be completed in a controlled setting and against proven methodologies, quality levels will exceed those of ad-hoc assessments.

Overall BOP functions.

Risk model software

Starting with RiskSpectrum, the BOP risk model will be constructed in a fault tree modeling workshop based on the main BOP functions. A detailed failure mode effects analysis will provide the input for the fault tree modeling.

Subsequent qualitative risk levels will be monitored in RiskWatcher. This program's operator interface does not require risk analysis or fault tree modeling experience. The modeling will have been completed previously by risk assessment experts, leaving the operator to alter only input parameters and/or configurations as needed. The underlying fault trees cannot be modified, and this ensures model integrity.

A BOP is complicated with a number of subsystems and a high degree of redundancy. To input a BOP into a risk and reliability model requires:

  • Creating a database including all subsystems and components
  • Identifying all the functions carried out by the BOP
  • Establishing block diagrams describing the logic path identifying every main component for the function to work. This is further broken down to each component all the way down until every main, minor, and subcomponents needed for the function is identified
  • Establishing fault trees based on the logic block diagrams
  • Integrating the fault tree model into the risk monitor, being able to compare the actual status with pre-defined risk levels.

Such a comprehensive project has a lot of technical considerations and validations. Important considerations include:

  • Component failure, effects, and mitigation factors
  • System failure, effects, and mitigation factors
  • Redundancy of components, systems
  • Stack configuration
  • Recognized minimum criteria for BOP systems from both industry and regulators
  • Identification of critical and non-critical components and systems (emergency capabilities of the BOP systems).

Cooperation with rig owners, operators, and equipment manufacturers is crucial. In this project, that was done through a joint industry panel (JIP) with representatives from all major stakeholders in GoM drilling. The JIP met once a month and has challenged the project in a very fruitful way and has given important insights and feedback to the modeling.

Using the model

Risk levels would be monitored in the RiskWatcher application. The application can be installed and used onboard the rig and also by support personnel elsewhere. If regulators are given access to the code, it can be possible for them to use the tool when approving the decisions to pull or not pull the BOP.

The operator interface does not need experience in or deep knowledge of the risk model on the part of the user. The interface is simple and the user can alter input parameters and/or configurations to visualize the risk effects of non-working components. This means in the case of a detected error in the stack, that error can be put into the model and the effects on the risk level will be shown. If the error is hard to track to specific components, the model can check failures that might result in that effect. The risk model can help identify causes of faults. The risk model does not replace other fault finding procedures and methodologies, but can be an addition to these.