Wellbore Design - A Safety Critical Process Human and Software Factors

The Human Factor

Tubular Design Issues More complex, with increased number of HPHT wells. Higher Temperatures represent one of the main causes of this increased complexity. Stress Analyses: Temperature profiles for both Initial Conditions and Final Conditions (Load Cases) were traditionally assumed/estimated. For many challenging projects, such as HPHT wells, this is not accurate enough.

Increased Complexity Computer based models are used in performing thermal simulations Complex Wellbore Design => More Complex Computer Apps: –Harder to learn –Harder to maintain knowledge –Easier to use wrongly, to select wrong options

The Designing Engineer Must master 3 things: A.Domain Expertise B.Actual Operations – to prevent from presenting a theoretical solution without practicality C.In-depth knowledge of the Computer App that is being used in the design. Most satisfy A & B, but are deficient in C.

Deficiency in Mastering the App Most engineers tasked with designing the well are using the app only once every 6 to 12 months: –Lack of adequate training –Hard to maintain expert knowledge –Easy to make usability mistakes

The Risks of App Deficiency Computer App Results are used in real life It is here that one simulates real life situations within the world of the software. It requires all of A, B & C to make sure that the two realities are in sync. The designer must understand what the app is capable of doing and how it should be used correctly

Misusing the App - Example Simulating a Hydrocarbon Gas Production Operation, to be used for stress analysis of tubular strings. The user must choose the proper theory for modeling the hydrocarbon flow: Black Oil or VLE Incorrectly, the VLE model was used Consequently, the resulting temperatures were too low

Produced Fluid Temperature

The Actual Mistake The designer, more than likely because he did not properly understand how the app works, did not investigate the Design Parameters diagram Flow Parameters were outside the contour lines For the App employed, this causes an extrapolation during the calculations, and thus the results are less accurate.

Phase Diagram Flow Parameters were outside the contour lines

The Software Factor

Landmark Initiative In 2002 Landmark put in place a Safety Critical Systems Network of Excellence Details about this can be found in SPE papers: –SPE –SPE Landmark has a process for managing safety critical defects reported on released versions of applications.

Defect Tracking System – SC option

How will you know about it? 1.The defect will immediately be available on the LGC web site ( 2.Via the monthly Critical Defects Report, sent to clients via 3.The Product Manager in consultation with the Systems Development Director may issue a special note to clients.

WellCat Defect WellCat Severity SC PEF 21 Reported on 12/9/2002 Index: MultiString – Results – MultiString AFE Summary Current Status: In Progress Current Design allows for wrong MultiString APB pressures to be calculated PROBLEM: Incorrect (by a significant margin) MultiString AFE pressures are obtained if the final conditions of the analysis is linked to a Prod operation which has a significant annular (A annulus) pressure defined in addition to the pressure from initial conditions. This problem exists in SP3. WORKAROUND In such a situation, the user will have to edit the input file prior to calculating the MultiString AFE calculation. To do this you have to select Diagnostics from the Calculate dialog and select the Edit Input File check box. Scroll down to the IPRES cards and notice the IPRES data grouped with headers 0 2; 1 2; 2 2; 3 3, etc. Edit the second set of data labeled as 1 2. In all subsequent rows of each group, the first column represents depth, in feet, while the second column represents pressure, in psi. Make sure that the pressures at the top and at the bottom of the string are the same as the pressures shown in the FPRES card for the same group of data (1 25). You can now select OK from the input file dialog. This should give you the correct answer. Critical Bugs Report - Example

The App’s connection to Real World Input Input = actual well data + settings & selections in the app The App is composed of algorithms that are based on certain theories The App Results

When should we call a defect SC? If the Results do not correspond to the actual theory (existing within the algorithms of the app) applied with the set of input data as defined and selected in the app.

How to Catch SC Defects? SC defects can mostly be identified by proper Interpretation of results, performed by an experienced design engineer (A+B+C): –Look for Suspect results –Hand checking some results when possible The Human Factor can be key in catching Software SC defects.

The Data Base

Integrated DB Mandates Sophisticated Security Systems Integrated DB (such as EDM) are deployed at corporate level. There are Multiple Users for one large DB Each User: customized access to appropriate data Customized level of control, based on skill level

Effects of Integration in One DB No specialized standalone communities No “personalized” versions of the data All engineers using the same data Data in the DB must be of high and dependable quality.

DB Owners Must Have Excellently designed security systems Well understood ADMINISTRATION of the security – especially User Creation. This should be approved as a policy by business managers. High quality and varied training courses for DB users to continuously amend their security access as life goes on

Recommendations The design should be performed by an engineer with proper experience in all A, B, and C. Each design should be reviewed by another engineer who also has proper experience in all A, B, and C. DB - professionals, with a mix of both DB admin skills and technical domain knowledge, are needed in constructing security systems within any environment with centralized technical DB. (DB admin skills generally fall outside the domain of engineers)