The importance and potential impact of revising API 17G

Joe Scranton

July 24, 2014

The ongoing revision of API 17G (specification for subsea well intervention equipment) includes many changes from prior editions.  These changes extend beyond the added design rules and product qualification processes for hardware typically seen in design code updates.  The additional sections elaborate on specific project risk analysis procedures that are interwoven with the limits and capabilities of equipment developed according to API 17G.  It is within these sections where most readers will find that API 17G deviates from a traditional API specification.

Much like the layers of protection analysis (LOPA) theory used successfully in other industries, API 17G has included this approach for manufacturers and operators of intervention hardware to develop and select the appropriate “grade” of hardware based on the level of risk involved.  Rather than selecting a single product to meet all requirements, this approach adds a cost-risk-benefit analysis to the equation.  This allows the option of selecting conventional intervention systems such as direct hydraulic control systems for low risk intervention opportunities, while advising the use of MUX controls with SIL (IEC 61508/61511) ESD for DP intervention on live wells where hydrocarbons may be expected.    

In addition to establishing protection layers, it is important to understand the capacity of the mechanical equipment, and what defines the limits.  Capacity could be defined by a failure due to mechanical overload (example being vessel compensator lock-up), or fatigue due to repetitive motion and aggravated by a seawater environment.  Significant effort was spent updating sections of 17G on design and qualification to ensure the methodologies were well balanced with theory, practice, and regular maintenance intervals. 

As exciting as all the engineering details of all the API 17G are, the question most people want to know is: how will this affect the way I do my job?  The best response is: “depends.” Depends upon what your job role is.  If you are a manufacturer of intervention equipment, you will find much more guidance on design and qualification requirements in one document than you ever had before. However, you may be stymied by the fact that you now need better definition from the proposed application, so that bending limits, fatigue life, and other variables are properly quantified. This is where input from the operator is crucial to define design parameters.

For the operators/users of the equipment there is extensive coverage of risk mitigate processes within Clause 4 of the specification to define the steps required to de-risk a project or program and select the appropriate hardware before the campaign begins. API 17G is not a “one size fits all” code. It requires some effort to select the safest and most cost effective solution.  When working with equipment, supplier’s knowledge of their hardware will streamline the risk mitigation process and can help select existing technologies for some intervention scenarios.

When API 17G is released, the key to successful deployment is knowledge-sharing and training.  For example, I doubt anyone would simply sit down and read ASME Section 8 to learn how to build a pressure vessel. API 17G is not as extensive as ASME Section VIII, but the point is the same; take a large design code, which at first glance appears complex and break it down into manageable and trainable elements.  API 17G can quite easily be translated into training packages to improve the communication of the core message for the use of appropriate hardware for the intended application.

Once widely adopted, API 17G will allow operators to properly select and design intervention campaigns with full understanding of the capacities of the equipment they are deploying before the equipment ever reaches the vessel.  This as a major step forward in engineering safety into every intervention campaign and reducing the role of relying on good luck for success. 

Joe Scranton 
is the engineering manager at AlTiSS Technologies in Houston.  He has worked in various product engineering and management roles over the last 31 years with assignments ranging from reliability improvement, functional safety, E-H intervention control system design, and downhole tool design. His current role in new product development focuses on the use of Titanium and other CRAs. Scranton is a registered professional engineer in Texas.